Причину этого я понять могу: не создались нормально топики в /devices. Такое бывает, если добавить датчик, потом удалить его в веб-интерфейсе контроллера и снова добавить.
Чтобы всё заработало, обычно достаточно перезапустить wb-rules: systemctl restart wb-rules.
Топики действительно не создаются. Не помогает ни перезапуск wb-rules, ни перезагрузка контроллера, ни удаление и переподключение устройства. Могут ли какие-то настройки z2m столь драматично влиять на работу конвертора? И почему топики при этом создаются избирательно? Может ли конвертор крэшиться на каких-то сторонних устройствах?
А какие идеи по первой проблеме?
Два датчика"из коробки" оказались переключенными в режим модбас, один - в режим зигби. Что уже странно. Независимо от положения переключателя, все датчики добавкляются по зигби, но первые два в payload вместо показаний каждого сенсора отдают null. При этом положение переключателя влияет только на работоспособность светодиодов и пищалки, а также на мигание status LED.
Тот датчик, который был изначально переключён в режим зигби, отдаёт в payload все значения корректно.
Все три датчика испытывались на трёх разных системах идентичным образом… Тот, который был изначально переключён на зигби, во всех сетапах отдаёт корректные данные, остальные два корректно отдают показания сенсоров только по модбас, а в режиме зигби не отдают данные с сенсоров ни в одном сетапе. Предполагаю, что в этих двух датчиках зигби модуль опрашивает основной микроконтроллер (судя по миганию status LED), но не получает запрошенные данные (судя по тому, что отправляет null).
В датчике есть микроконтроллер, который общается с внешним миром по UART. Далее этот UART можно подключить либо к трансиверу RS-485, либо к радиомодулю Zigbee, то и делает красный переключатель. А так как модуль Zigbee продолжает работать, то вы можете подключить датчик по Zigbee, но показаний не будет. Предположу, то null может отдаваться при положении переключателя “RS-485”.
Это и правда не очевидные вещи, опишу их в документации. Спасибо вам за терпение и желание разобраться — каждый такой случай помогает сделать продукт чуточку лучше.
Архитектуру датчика я понял сразу. И действие выключателя тоже.
Как я уже писал ранее, NULL ПЕРЕДАЁТСЯ ПО ZIGBEE ПРИ ЛЮБОМ ПОЛОЖЕНИИ ВЫКЛЮЧАТЕЛЯ. То есть, даже при “правильном” положении выключателя zigbee модуль не получает данные.
Вопрос - почему управление светодиодами и пищалкой по зигби работает? Они управляются не через serial порт, а непосредственно через GPIO? Или связь между микроконтроллерами работает только в одну сторону? Если второе (при отсутствии проверки связи в протоколе), это похоже на банальное отсутствие контакта Tx-Rx от микроконтроллера к зигби-модулю.
Думаю, дальше процесс пошёл бы продуктивнее, если бы добрый человек из компании Wirenboard привёз бы мне заведомо работоспособные датчики, а неработающие забрал бы в вашу лабораторию для дальнейшего исследования. И с точки зрения клиентоориентированности это было бы очень правильно. Я не представляю, как использовать оборудование WB в проекте на несколько десятков шкафов автоматизации, когда уже неделю не удаётся добиться работоспособности просто датчика, который должен работать “из коробки”.
Крайне забавно. В одном из неработавших датчиков подёргал выключатель туда-обратно много раз подряд, контакт вроде появился, данные стали передаваться… Другой дома лежит, попробую проверить вечером.
Что же, и на приём, и на передачу контакты переключаются чисто механически??? И какова вероятность того, что контакт не пропадёт снова, когда датчики будут у клиента?
Обновление. После спаривания “ожившего” датчика (с многократно подёрганным выключателем) с z2m на WB (а в этом датчике в ходе эксперимента была обновлена прошивка микроконтроллера), в WB появились все топики для этого датчика! Плохая новость в том, что данные пробросились однократно и в софте WB не обновляются. В интерфейсе z2m показания видны в реальном времени, а в WB - нет, замерли на значениях, имевших место при инициализации топиков.
Специально съездил за третьим датчиком. Проделал ту же процедуру с многократным передёргиванием выключателя. После этого данные по zigbee начали передаваться, но топик создаётся только на co2.
Итого, обнаруживаются странные закономерности:
Выключатели ненадёжны. Могут временно вылечиваться многократным передёргиванием, но, вероятно, могут и обратно терять контакт. Лучше сделать автоматическое программное переключение или реализовать параллельную работу с двумя интерфейсами.
Без обновления через сериал порт, конвертор wb-zigbee2mqtt создаёт топики только для co2. После обновления создаются все топики, но данные в них не передаются (остаются те, которые были при создании). При этом, payload, отдаваемый z2m, обновляется в реальном времени и содержит все данные вне зависимости от того, обновлялась прошивка датчика или нет.
Да, это нехорошо. Пришлите, пожалуйста, фото наклеек датчиков с серийными номерами и укажите, с какими из них возникли проблемы, чтобы определить проблемную партию.
Попробуйте еще раз перезапустить сервис wb-rules:
systemctl restart wb-rules
Убедитесь, что он работает:
systemctl status wb-rules
Также попробуйте обновить пакет zigbee2mqtt до последней версии 1.25.2
Да, все правильно. Из логов видно, что конвертер wb-zigbee2mqtt почему-то не смог корректно обработать данные, которые публикуются сервисом zigbee2mqtt. Постараемся изучить проблему.
Если это все логи, то в этом случае явных ошибок нет. Пришлите, пожалуйста, еще архив с диагностической информацией контроллера. Создание архива описано в инструкции.
При переключении переключателя режимов работы датчика ползунок точно переводили в крайнее положение ON, до упора? Иногда может показаться, что переключатель включен, но это его не крайнее положение.
Да, все правильно. Из логов видно, что конвертер wb-zigbee2mqtt почему-то не смог корректно обработать данные, которые публикуются сервисом zigbee2mqtt.
Покажите еще лог сервиса zigbee2mqtt с данными от датчиков: