MQTT не работают командные топики, если настроен не стандартный порт брокера.

Здравствуйте. Установлена свежая версия 2022.10.30. MQTT-брокер в моей системе автоматики работает не на 1883 порту, а на порту 44444. При первой настройке еще в сети r4s в WEB-интерфейсе установил MQTT-порт 44444, сохранил и вся телеметрия с чайника появилась в MQTT-топиках. Но на командные топики нет реакции. Поднимаю в локальной сети еще один брокер со стандартным портом 1883, в настройке шлюза прописываю этого брокера с портом 1883 - работает весь функционал, включая реакцию на командные топики. Тогда в шлюзе возвращаю настройку на основной брокер с портом 44444 - все продолжает работать отлично. Но стоит перезагрузить модуль по питанию, как проблема возвращается: телеметрия чайника в rsp-топиках публикуется, а на cmd-топики реакции нет. И опять надо перенастроить на брокер со стандартным портом и обратно.

А какой брокер используется? Это Home Assistant в паре с mosquitto или что-то другое? Когда шлюз читает данные из командных топиков, он потом их очищает. Есть такое? Если нет, то что-то с подпиской на эти топики, может даже в драйвере mqtt среды esp-idf. Если топики чистятся, может что-то шлюз не понимает в данных. И не совсем понятно, как после изменения порта с 1883 на 44444 все становится нормально, ведь после смены порта и записи настроек шлюз все равно рестартует. Чем тогда этот рестарт лучше следующего... Попробую у себя поднять другой брокер, не хочется экспериментировать на работающем ХА.)

Андрей, а с какой целью чистятся топики команд после чтения ?

А какой брокер используется? Это Home Assistant в паре с mosquitto или что-то другое? Когда шлюз читает данные из командных топиков, он потом их очищает. Есть такое? Если нет, то что-то с подпиской на эти топики, может даже в драйвере mqtt среды esp-idf. Если топики чистятся, может что-то шлюз не понимает в данных. И не совсем понятно, как после изменения порта с 1883 на 44444 все становится нормально, ведь после смены порта и записи настроек шлюз все равно рестартует. Чем тогда этот рестарт лучше следующего... Попробую у себя поднять другой брокер, не хочется экспериментировать на работающем ХА.)

Командные топики чистятся, чтобы команда не исполнялась повторно, это раз, и в брокере сразу видно, что шлюз реагирует на команды, даже если она неверная. Это не я придумал, так было сделано в прообразе этой программы товарищем olehs. Думаю, что это общепринятая практика при работе с раздельными топиками команд и состояний. Другое дело, что только недавно обнаружил, что чистка шла без ретайна. Это значит, что при обрыве связи брокер-шлюз она потенциально могла приходить повторно, если она была записана с ретайном, мало того шлюз ее никак не мог сбросить сам. Сейчас это уже поправлено.

А какой брокер используется? Это Home Assistant в паре с mosquitto или что-то другое? Когда шлюз читает данные из командных топиков, он потом их очищает. Есть такое? Если нет, то что-то с подпиской на эти топики, может даже в драйвере mqtt среды esp-idf. Если топики чистятся, может что-то шлюз не понимает в данных. И не совсем понятно, как после изменения порта с 1883 на 44444 все становится нормально, ведь после смены порта и записи настроек шлюз все равно рестартует. Чем тогда этот рестарт лучше следующего... Попробую у себя поднять другой брокер, не хочется экспериментировать на работающем ХА.)

У меня на главном контроллере используется программное обеспечение SprutHub (https://github.com/sprut/Hub) со встроенным MQTT-брокером. Для SprutHub по умолчанию настроен порт брокера 44444. С этим брокером нормально работает openHAB 2.5 и Номе Assictant с другого контроллера по локальной сети. Топики этого брокера настроены в режиме retain (с запоминанием). С описываемой проблемой столкнулся впервые. Дополнительно хочу сказать, что для восстановления работы с cmd-топиками можно не перенастраивать порт 44444 на 1883, а произвести reboot из WEB-интерфейса. Кроме того, нарушение работы с cmd-топиками я наблюдаю после реконнекта к сети Wi-Fi (например, после перезагрузки роутера). Сейчас устал экспериментировать и просто на втором контроллере в сети поднял MQTT-брокер Mosquitto на стандартном порту 1883, перенастроил все связи и все работает пока стабильно. Иногда отваливается по BT сам чайник, хотя шлюз расположен близко и средний RSSI около -65, но через некоторое время коннектится вновь.

Почитал ссылочку. В общем, там ничего кроме рекламы не нашел. Что за брокер, тоже непонятно. Похоже, это коммерческий проект. Но можно кое-что попробовать. Я так понял, Вы работаете с раздельными топиками команд и состояний. Шлюз после чтения каждой команды очищает данные топика с ретайном, что по факту означает удаление топика. Может быть такой вариант, что брокер в спруте при следующем соединении отвергает подписку на топики, которых на данный момент в нем нет. Проверить это легко, можно просто перейти на общие топики соманд и состояний, отметив "Common command/response topics" в настройках. Если все будет нормально, то похоже, что проблема именно в этом. Можно попробовать в шлюзе после чтения команды вместо очистки топика писать туда , скажем, пробел. А в шлюзе на входе проверять, если пробел, данные игнорировать. Замечу, что стандарт mqtt не накладывает никаких ограничений на формат данных, так что формально ни шлюз, ни брокер в спруте за рамки стандарта не выходят. Хотя mosquitto тут все нормально отрабатывает. Upd: В папку "jpg" залил бинарник, в котором реализована после чтения команды запись в командные топики точки (чтобы было видно тем же mqtt explorer-ом) . Топики, данные в которых начинаются с точки, теперь шлюзом игнорируются.

Изменения учтены в версии 2022.12.10.

alutov / ESP32-R4sGate-for-Redmond

MQTT не работают командные топики, если настроен не стандартный порт брокера. #120