Грязные значения от Input Counter

Программное обеспечение Rule Engine
1

Есть очень неприятная ситуация при использований правил, которые триггерятся от счетчиков нажатий. Обходные пути видел тут, но не видел здесь. Ситуация особенно не очивидна для тех, кто переходит от использования прямых топиков (IN/Kn) на счетчики.

Проблема: при перезагрузке контроллера или сервиса wb-mqtt-serial в MQTT топики прилетают пустые значения этих счетчиков, из-за чего происходит ложное срабатывание правил.

При дебаге можно увидеть что при запуске происходит отчистка/обнуление этих значений:

30-07-2023 20:37:43.077 [wb-mqtt-serial] INFO: [modbus] Init: Mode: setup register <modbus:16:holding: 14> <-- 0 (0x0)
30-07-2023 20:37:43.074 [wb-mqtt-serial] INFO: [modbus] Init: Mode: setup register <modbus:16:holding: 13> <-- 0 (0x0)
30-07-2023 20:37:43.069 [wb-mqtt-serial] INFO: [modbus] Init: Mode: setup register <modbus:16:holding: 12> <-- 0 (0x0)

Предложение: производить инициалицию топиков счётчиков тихо, чтобы сервис wb-rules не выполнял сработку правил до полного окончания процесса.

Что-то подобное при необходимости делаем из правил, чтобы не тригернуть лишнего:

getDevice('master').getControl('action').setValue({value: true, notify: false})
1 лайк
2

Добрый день.
А, собственно, зачем? Ведь в случае NULL - он фильтруется (может фильтроваться) и так.
Ну и подобный костыль не сработает если просто перезапустить драйвер, например.

4

Я понимаю что можно добавить каких угодно проверок в правило, но тем не менее они должны срабатывать от полезных значений. Переинициализация модуля это как ни крути служебных процесс.

Это как я понимаю речь про то, что после перезапуска драйвера происходит наполнение каналов MQTT и что и так будет произведений заливка текущих значений? Если так то вопрос неизменен - можно не объявлять wb-rules что случилось изменение, а уже ждать нормальные данные с устройство?

5

Да. То есть если что-то перезапустилось именно на запущенном контроллере - это явно после изменения настроек.

Сейчас это точно не реализовано. Ну и для некоторых устройств, например zigbee NULL в топике - нормально. То есть нет простого пути чтобы определить “нормальные” данные или нет.
Сейчас типично оборачиваю фнкцию в проверку значения.

6

Поэтому и создал эту тему :slight_smile:
Очень хочется обезопасить себя и других :smiling_face_with_tear:

Согласен и это вполне ожидаемо. Но совсем наоборот когда дело доходит до счётчика.

Если наши мнения разнятся - предлагаю сделать опрос хотя бы в этой теме, тем самым определим целесообразность в реализации :face_with_peeking_eye:

7

Я, конечно, не против. Сейчас вот пытаюсь воспроизвести “задвоенные” события. То есть, как самые показательные - те что с одинаковыми значениями счетчиков.

8

Такой ситуации не встречал. Но в концепцию отработки правила тоже хорошо вписывается. Ждем же изменений, а не повторов) Надеюсь все получится на уровне драйвера/сервиса решить :saluting_face:

9

Что-то ожидать в новых версиях?

10

В новых версиях планируется глобальный рефакторинг и преезд на nodejs, возможно.
Так что старые баги постараемся не перевозить туда.

11

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.