Здравствуйте
Вопрос следующего характера: у меня есть два устройства wb в одной локальной сети. С одного из них через мост mosquitto в одностороннем направлении я передаю данные разных устройств (реле, датчики температуры, виртуальные устройства).
Проблема вот в чем, иногда эти данные не передаются корректно, например на основном контролере реле/виртуальное устройство перешло в статус true, а на вспомогательном (куда летят данные по
mosquitto) ничего не поменялось. Например в вечернее время это отлично было заметно, а в какие-то периоды все работает быстро стабильно.
Все устройства одним мостом передаю, нужно, чтобы они всегда четко данные передавали, важные правила завязаны на этих передачах. Куда лезть/смотреть, почему не всегда корректно данные направляются?
Добрый день.
А в каком состоянии сам мост и меняется ли оно? Покажите пожалуйста результат подписки на топик состояния моста.
Ну и - как (должны) быть отображены топики, для примера?
мост работает, просто иногда сразу, иногда вообще не реагирует. работает в одностороннем порядке, то есть только с основного на вспомогательный передает.
nano /etc/mosquitto/conf.d/25-bridge.conf
connection bridge
address 192.168.1.127:1883
try_private false
notifications true
notification_topic /client/bridge/bridge_status
keepalive_interval 20
restart_timeout 20
cleansession true
topic wb-mcm8_12/# in 0 /devices/dom_ /devices/ //девайсы что хотим перекинуть
topic wb-mcm8_196/# in 0 /devices/dom_ /devices/
topic wb-m1w2_188/# in 0 /devices/dom_ /devices/
topic wb-m1w2_10/# in 0 /devices/dom_ /devices/
topic wb-m1w2_76/# in 0 /devices/dom_ /devices/
topic /client/# in 0 /dom “”
вот так я передаю устройства ну и так же они видятся как обычные девайсы
Меняется ли “notification_topic”?
Ну и - пока мало информации…
Покажите пожалуйста подписку на notification_topic, на какой-нибудь топик из моста. С таймштампами, для того чтоб понятней было.
Ну и опубликуйте что-нибудь в топик в исходном брокере.
То есть оптимально - посмотреть что именно происходит когда “не работает”.
notification_topic не меняется, он статический:
/client/bridge_dom_to_VRY/bridge_status
Подписка на него на wb(приемник):
mosquitto_sub -h localhost -F '@Y-@m-@d @H:@M:@S.@N | %t | %p' -t '/client/bridge_dom_to_VRY/bridge_status'
При подключенном bridge получаю:
/client/bridge_dom_to_VRY/bridge_status 1
Также смотрю один из топиков из моста с таймштампами, например:
на wb(приемник):
mosquitto_sub -h localhost -F '@Y-@m-@d @H:@M:@S.@N | %t | %p' -t '/devices/dom_heat_request_system/#'
на wb(передатчик):
mosquitto_sub -h localhost -F '@Y-@m-@d @H:@M:@S.@N | %t | %p' -t '/devices/heat_request_system/#'
Bridge-конфиг на wb(приемник) такой:
notification_topic /client/bridge_dom_to_VRY/bridge_statustopic heat_request_system/# in 0 /devices/dom_ /devices/- также через bridge прокинуты и обычные устройства:
wb-mcm8_12,wb-mcm8_196,wb-m1w2_188,wb-m1w2_10,wb-m1w2_76
Что уже удалось увидеть:
- Bridge-status =
1, то есть соединение между брокерами поднято. - Пинг между контроллерами стабильный, потерь нет.
- При этом данные на wb(приемник) в
/devices/dom_heat_request_system/#могут отличаться от текущих данных на wb(передатчик) в/devices/ heat_request_system/#. - Проблема не только у виртуального
heat_request_system, но и у обычных прокинутых устройств.
А результаты публикации?
Тогда - их публикует что-то еще. Проще всего - определить включив debug для брокера.
Доброго!
Не понял, у вас один конфиг на бридж или два (в передатчике и приёмнике)? ИМХО должен быть у кого-то одного
Дополнительно, вдруг на мысль наведёт:
- try_private полезно в “true”, если не дерётся с чем-то ещё - оно зацикливания убирает
- QoS попробовать 1 вместо 0
- Версия mosquitto какая? Я на keenetic отказался от мастер-бриджа на версии 2.0.18 - бридж просто “отваливался” молча, если инициатором был keenetic. Вроде в 2.0.22+ это поправили, но пакетов нет, а собирать неохота
- Что с retain? Замечено, при отвале связи бриджа может прилетать какое-то “левое” древнее значение (детально пока не разбирался, откуда оно берётся)