коннект не устанавливается.
месяцев пять назад с другим контроллером бридж с cloudmqtt настраивал в виде пробы пера.
итак, лыжи или я косячу?
и второй вопрос - если нужно передавать некоторые топики то будет перечисление вроде такого:
topic /devices/test1_122/# in 2 “” /devices/wb122
topic /devices/test2_122/# in 2 “” /devices/wb122
?
Так, судя по команде вы хотите:
топик с брокера “122” с адресом /devices/wb122/devices/test122/controls/on сбриджевать в “/” брокера “125”?
Предполагаю что надо использовать конструкцию вида:
topic что in 2 куда(На_приемнике)откуда(На_источнике)
то есть
topic /test122/controls/on in 2 /devices/wb122 /devices
А “вручную” с помощью mosquitto_sub - подключается к облаку с контроллера?
на wb_122 есть виртуальное устройство с топиком /devices/test122/controls/on
на wb_125 хочу поймать его состояние в такой же топик /devices/test122/controls/on
topic /devices/test122/controls/on in 2 /devices/ /devices
вот так получается и на wb_125 появляется вирт. устройство, причем независимо от направления in, out или both изменения идут только со 122 в сторону 125. если переключать на 125 этот контрол, то на 122 состояние не меняется.
может так и должно быть.
попробовал еще топики со 122 закинуть на 125 такой командой
topic /devices/knx_group_addrs/controls/1-1-10 in 2 /devices/ /devices
думал зайдет только один адрес 1.1.10
добавились все групповые адреса knx, которые были на 122, корректно отображали статус при изменении на wb_122. после этого заремил этот топик, перезагрузил москитто.
после этого топики на 125 существовали по-прежнему и дублировали состояние топиков адресов knx на wb_122.
удалил их mqtt-delete-retained.
такое поведение топиков на wb_125 норма?
Тут “ключевое” - это то, что топик on
Попробую объяснить:
Этот топик обрабатывается драйвером, причем сразу же. Если остановить драйвер - то состояние топика меняться драйвером не будет.
В результате такой записи бридж будет пытаться создать из исходного брокера по пути /devices/devices/test122/controls/on такой же топик на целевом.
Надо:
создал вирт.устр test2/controls/vkl
переправил его на другой контроллер, все норм, после рема топика и перезапуска службы - на втором контроллере вирт.устр не реагирует на изменение состояния этого устройства на первом.
но путь был такой: topic /test2/controls/vkl both 2 /devices/ /devices
значит ли это что изменения test2 на wb2 также должны были менять состояние на исх wb1?
дальше
В результате такой записи бридж будет пытаться создать из исходного брокера по пути /devices/devices/test122/controls/on такой же топик на целевом.
был (и есть) топик на wb2 по вашему стандартному шаблону /devices/test122/controls/on
topic /devices/test122/controls/on in 2 /devices/ /devices в настройках бриджа пока не меняю, раз все работает как надо.
финал-
Нет. А точно был перезапущен брокер?
146%, сразу после любых изменений bridge.conf рестартую москитто и проверяю статус службы.
Всем здравия и с наступившими!
Аналогичная проблема - не получается настроить Бридж на передачу топиков из WB 6.7 в Облако.
В bridge.conf пишу -
connection vscale
address 82.148.28.xxx:1883
notifications true
notification_topic /client/WB_SerNum/bridge_status
keepalive_interval 20
restart_timeout 20
topic /devices/# both 2 “” /client/WB_SerNum
Соответственно перезапускаю Москито и с помощью MQTT Explorer смотрю в Облаке, но там появляется только один топик /client/WB_SerNum/bridge_status со значением = 0.
Пробовал и так -
topic /devices/# out 2 “” /client/WB_SerNum
результат одинаковый.
Смотрел mosquitto.log там при перезапуске появляется - Error socket ДлинноеНазвание, но в конце - Москито запущен.
Может в Облаке тоже надо Москито перезапускать?
Также изучая тему настройки Бриджа столкнулся с непоняткой - Какой .conf нужно редактировать? Одни правят mosquitto.conf, а другие как и я bridge.conf
Короче - Или лыжи не едут, или ноги кривые
Логин и пароль, надеюсь, не забыт? (не надо его здесь указывать)
Судя по тому что notification появляется - связь есть.
Как писал выше:
То есть:
topic /devices/# out 2 /client/WB_SerNum ""
Собственно говоря нет разницы. Но правильно, идеологически - bridge.conf
В основном конфиге есть строчка “include_dir /etc/mosquitto/conf.d”
То есть все конфиги которые распологаются по этому пути (их содержимое) подставляются “вместо” нее.
Спасибо что ответили!
Поменял на такую запись -
topic /devices/# out 2 /client/AC57A3KJ “”
потом на такую
topic /devices/mercury230ar02_62 out 2 /client/AC57A3KJ/mercury230 “”
перезапускал, но результат тот же - топики не появлются, bridge_status=0.
Может попробовать ручную публикацию с контроллера в облако?
И еще у Москито который в облаке обязательна авторизация, а то пока ее нет ?!
верна только если есть топик “/devices/mercury230ar02”
У вас в “облаке” что за брокер? Либо дайте доступ к вашему либо подробную о нем информацию - воспроизведу.
Топик /devices/mercury230ar02_62 существует в контроллере.
Брокер в облаке такой же как в контроллере - Mosquitto MQTT.
Версии не сравнивал, стоит на Ubuntu 20.04 64bit, вот его Статус
таки есть вопросы еще по бриджу. до этого я создавал вирт.устр на приемном wb. и все было нормально. сейчас удалил их и пробую настроить обмен только через конф-файл бриджа
topic /devices/test122/controls/on in 2 “” /devices
topic /devices/test2/controls/vkl in 2 /devices /devices
тут просто пробовал по-всякому прописать путь.
так тоже:
topic /test2/controls/vkl in 2 /devices /devices
на приемнике test122 и test2 не появляются, ЗАТО появляется топик и вирт устр-во knx
/devices/knx/controls/data. каждый раз сразу после перезагрузки москитто. причем даже не нужно обновлять страницу
настройка бриджа скопипащена из файла и никаких упоминаний о knx там нет давно. где нужно искать следы?
mqt-box у приемного wb /devices/test2/controls/vkl видит и отображает состояние корректно.
нужно каждый раз создавать вирт. устройство на приемнике? хотя случай с knx-топиком говорит об обратном.
На контроллере выполняю команду -
mosquitto_pub -h 82.148.28.ххх -p 1883 -t “/client/AC57A3KJ/hwmon/CPU_Temp” -m “30” -u “user” -P “psw”
Смотрю в облаке с помощью MQTT Explorer (класная прога) - Опубликовалось, в дереве Брокера появилось практически мгновенно!
mosquitto_pub -h 82.148.28.ххх -p 1883 -t “/client/AC57A3KJ/mercury230/U1” -m “230” -u “user” -P “psw”
Аналогично опубликовалось!
bridge_status=0 и не менялся, хотя количество его сообщений растет.
Делаю вывод - Бридж на стороне контроллера не отрабатывает!
Что еще посмотреть?
Уважаемый, Андрей Р., то что вы пишите в качестве примеров касается ручной публикации (mosquitto_pub) и в моем случае работает на 100%. У меня не отрабатывает Бридж, даже такое -
topic # out 0
topic # in 0
Может дело в значении QOS ?! В моем WB WebUi 2 / MQTT Channel их нет, не указаны.
Какой QOS нужно писать в bridge.conf ?
Вчера был момент - при попытке update mosquitto, перед этим сделал service mosquitto stop, контроллер ушел в перезагрузку. После загрузки WB и повторной командой обновление mosquitto прошло успешно. Но, результата нет!
Разъясните пожалуйста какие механизмы задействует Бридж в своей работе? Понятно что им рулит Брокер, но где затык происходит, как его отследить на пути WB брокер > Бридж > Облачный брокер?!
