Arduino.ru

Первое, что приходит в голову - не подписываться на этот топик, тогда и не будете ловить его от сервера. Если данный вариант неприемлем, то второе, что приходит в голову: при отправке топика запоминать время, при получении callback - сравнивать, и если промежуток меньше какой-либо дельты - считать, что это эхо, которое надо игнорировать.

Не особо понятно что вы вообще хотите и сколько слушателей, только есп или еще кто-то... Но вообще идеологически правильнее отделить статус топик от командного, не будет лишней нагрузки на брокер, не будешь ловить эхо, кто захочет статус видеть, тот и подпишется, обратная связь полноценная. Так что делайте лучше все по уму сразу. Зачем каждые 5 секунд спамить? Сменился статус шлите изменения, Qos, retained есть же

нет большого опыта разработки, учусь. 
Теперь знаю что это называется эхо. Цель. Видеть состояние кондиционера и управлять им.

Решить проблему можно:
1е - реализовать кеширование (Можно с помощью hash)
2е - разделить топики на информационные и командные

Запахло "веб программистом" ) Поподробнее про 1й подход пжалста распишите, время паковать собрались или порядковый номер?

Как я вижу. (Основываясь на знаниях JS)
Создать объект - ключ значение. Где ключ это топик. А в callback сравнивать с тем что пришло. Если значения совподают то не записывать в кондиционер. 
Осталось почитать как в Си это релизовать.

Да нафиг вообще подписываться на топики, которые не нужны, блин? Я вот одного не пойму - зачем героически наступать на грабли, когда достаточно - только публиковать нужные топики, при этом - самому НЕ подписываться на эти топики - тогда от брокера не будет приходить эхо.

Нет - надо выдумывать хэш-таблицы, пляски с бубном, заклинания. За-че-м?

Дык управлять то тоже надо, я ж говорю запахло веб кодером, проще велосипед на костылях сделать чем мух от котлет отделить) наплодят сущностей что уже почта от гугла открывается по 20 секунд и оперативки отъедает как не в себя...

Если честно - нихера непонятно. Вот у тебя есть ESP, которая чего-то там опрашивает с кондиционера и публикует в брокер топик, так? И она же (ESP, в смысле) - подписывается на этот же топик, или вообще - подписка сделана по wildcard, так? И у тебя от брокера в ESP падает тот топик, который ты только что туда опубликовал, так? Если всё так - то не делай дичь, а подписывайся только на те топики, которые нужны для управления, поскольку состояние кондиционера ты на ESP знаешь и так, без брокера - ты же раз в 5 секунд опрашиваешь кондишн.

Ага, тоже подумалось :) Сначала мы подпишемся по wildcard на всю дичь, которая попадает в брокер, а потом - героически будем думать, как отличить эхо от не эха. Вот мне чего интересно: какими путями раздумий идёт мозг, когда решает, что надо сперва разбросать грабельки, а потом - искать хитрые подземные пути обхода разбросанного, чтобы легко не жилось? :)

Состояние кондиционера - и так уже есть на ESP, судя по стартовому сообщению темы. Зачем подписываться на топик состояния кондиционера у брокера - сия загадка великая есть.

Разными путями идет мозг. Для этого и зашел сюда чтобы совет у вас спросить как корректнее сделать. Т.к. не до конца понимаю как все работает.

Корректнее - разобраться в том, как же всё-таки устроен протокол MQTT, что такое публикация, подписка. Ещё раз повторюсь: вы подписываетесь на некоторые топики. Например, можно подписаться на все топики ветки "HOME" вот так: "HOME/#". Теперь любой топик, который будет опубликован в эту ветку НЕВАЖНО КЕМ - придёт к подписчику этой ветки. И если сам подписчик опубликует топик "HOME/LIGHT" - то самому подписчику придёт этот топик эхом.

Вывод: незачем подписываться на топики, информацию которых мы и так уже имеем по определению, т.к. мы сами их и публикуем. Если надо иметь возможности управления, то подписываемся, например, на ветку "DO/#", а публикуем данные в ветку "DATA/....". При этом, если мы публикуем статус кондиционера в топик "DATA/AIR_CONDITIONING", и при этом хотим получать температуру другого устройства, которое оно публикует в топик "DATA/TEMP", то НЕ НАДО подписываться на топик DATA по маске, т.е. "DATA/#", а надо подписаться на конкретный топик "DATA/TEMP" - вот и всё.

Хинт: подписываться/отписываться можно на неограниченное число топиков, протокол MQTT - прост, изящен, гибок. Пользуйтесь этим, и не разбрасывайте грабли там, где их быть не должно по определению.

Так понятней?

Для того и полезно понимать как инфа идёт по по всем уровням osi и хотя бы понимать поверхностно в мк на асме/чистом си. В порядок ум приводит. А то вы сидите на самом верху на своём мопеде с костылями вместо колёс и даже mqtt пытаетесь использовать как привыкли) Всей задачи мы не знаем, потому и советовать что-то конкретное не берёмся(что у вас там, умный дом? openhab или что-то ещё? или включение кондея через мобилочку через облачный mqtt?), кроме как того что уже выше писал:

зачем спамить каждые 5 секунд? esp опрос делает пусть раз в 5 сек, хотя можно и почаще, статус отсылает, когда видит что изменилось состояние в топики myhome/status/conditioner/....(/power, /settemp, /nowtemp, /hum ещё какие либо), соответственно на эти статусные топики не надо подписывать esp, она и так знает состояние, это только в брокер улетает и далее по потребителям

ну и должен быть командный топик  myhome/command/conditioner/ который можно для удобства и поделить (/power, /settemp, /hum), на который esp подписана, но не постит туда ничего

а ещё удобно завести статуc топик самой esp myhome/status/espcond к примеру, заюзать willmessage offline, при коннекте публиковать online с ритейном, особенно удобно будет на wi-fi сетях, хотя я и на проводе всегда юзаю

тащемта :)

Ай нехороший, зачем такими словами страшными ругаешься? Совсем хочешь ТС запугать? :))))

Расшифрую для ТС: почитайте, что такое флаг Retain у топика MQTT.

Вроде понятнее. Разберу на примере вкл/выкл
Опрос делать и слать "DATA/Conditioner/Power" (on/off)
А команду принимать с другого топика "DO/Conditioner/Power" (on/off)
Я просто подумал что одно состояние один топик. 
​Ок спс вроде разобрался.