Управление zigbee в WB реализовано только через wb-rules создавая правила на js, но существует ли какая нибудь возможность управлять через node-RED? Пусть не совсем правильно но может как то вставляя туда JS код туда и включать/выключать zigbee устройства. Направьте на мануаль плиз.
Добрый день.
Собственно говоря “управление” - это просто запись топиков.
Либо publish из wb-rules либо “mqtt out” в NR. Код из JS - не нужен.
Из wb-rules всё работает, да. А из node-RED не получается управлять. Не реагирует, хотя в mqtt подключается. Киньте в меня мануалем плиз.
Поажите, что публикуете из wb-rules для управления этим же каналом реле.
Zigbee устройства шлюзом только отображаются в devices, “обратно” изменения не передаются, поэтопу публиковать нужно в топик устрйоства начинающийся с zigbee2mqtt.
Спасибки, через zigbee2mqtt в node-RED получилось. Почему то не пробовал этого раньше.
Вот по такой схеме:
Анализируя полученные дебагом логи от включения-выключения зигби устройств заметил что они Очень избыточно большие и как будто бы один и тот же параметр передаётся много мнного раз. https://cropoff.com/NgxyAm Это лог передачи ON один раз в розетку. В логе полученном с розетки 6 раз OFF и 8 раз ON пришло. Сталкивались ли с таким? С чем может быть связано что mqtt отправляет такой набор в устройство?
Сталкивались, перезапустите wb-rules, возможно правила шлюза созданы несколько раз.
Закомментировал тестовые правила, перезапустил сервис. Стало меньше выдачи, при включении всего три раза ON отправляет, а при выключении смерва шлёт ON а потом три раза OFF. Очень мешает создавать правила в node-RED, т.к. он обрабатывает все значения по очереди и сперва считает что розетку включили а потом три раза выключили и запускает все варианты обработки соответственно. Это фикситься как то?
Подпишитесь на сам топик устройства, именно zigbee2mqtt/Rozetka_00/# для проверки. Если само устройство присылает несколько раз - то только программно, например буферизируя сообщения и устанавливая “действительное” состояние по самому новому, после которого в тезении пары секунд статус не меняется.
Да, действительно приходит по нескольку раз: https://cropoff.com/07imc9
Спасибо ещё раз, буду разбираться как игнорировать лишние сообщения.
В настройках zigbee2mqtt есть параметры debounce, возможно стоит их попробовать использовать.
Вот описание параметров Devices and Groups | Zigbee2MQTT
debounce
Debounces messages of this device. When setting e.g. debounce: 1 and a message from a device is received, Zigbee2MQTT will not immediately publish this message but combine it with other messages received in that same second of that device. This is handy for e.g. the WSDCGQ11LM which publishes humidity, temperature and pressure at the same time but as 3 different messages.
debounce_ignore
Protects unique payload values of specified payload properties from overriding within debounce time. When setting e.g. debounce: 1 and debounce_ignore: - action every payload with unique action value will be published. This is handy for e.g. the E1744 which publishes multiple messages in short time period after one turn and debounce option without debounce_ignore publishes only last payload with action rotate_stop. On the other hand debounce: 1 with debounce_ignore: - action will publish all unique action messages, at least two ( e.g. action: rotate_left and action: rotate_stop)
1 лайк
Благодарю, эта команда предотвращает умножения логов если несколько раз в секунду включить и выключить девайс. А от самого девайса так и приходит множество копий.
Причём если опрашивать zigbee2mqtt приходит 3-6 копий, то через топик /devices/ сразу 20+ копий ответа от mqtt. Придётся как нибудь делать задержку в полсекунды и брать последний пришедший экшен.