Контроль исполнения

Добрый день.

Имею следующую проблему. Даю команду включения реле (к примеру). В топиках сразу же появилось новое состояние, но реле по факту еще не отработало. Так вот, хотелось бы как-то узнать момент когда реле однозначно отработало (может какой-то отдельный топик под это дело есть?). Про задержку (иногда в 2-3 секунды, но не всегда, бывает и моментально срабатывает) тоже отдельный вопрос.

Ajdar_Sabirzyanov, добрый день! А можно поподробнее, откуда вы даете команду и какую? И какая модель реле?

Тут особого значения не имеет, что за реле или команда. В моем случае это MR6C, но у меня в щитке есть и другие (MR3 например) и они все реагируют одинаково (либо с задержкой либо сразу).
Тут дело в протоколе. Сейчас я даю команду и не могу точно знать, что она успешно исполнена. Я ее просто записал в mqtt. Я хочу примерно следующее: даю команду, реле включается, я получаю фидбек, что оно включилось.
Это нужно по многим причинам. Вдруг это протечка воды и я должен быть уверен на 100%, что команда отработала верно.
Надеюсь мысль донёс верно.

Айдар, смотрите, как устроен цикл отправки команд/опроса модулей.

На контроллере запущен драйвер wb-mqtt-serial, который отвечает за связку modbus-mqtt.

При запуске драйвер берет из конфига список устройств и начинает их по очереди опрашивать. Если в mqtt приходит команда на запись (/devices/wb-mr6c_162/controls/K1/on 1), то драйвер после завершения цикла опроса очередного устройства тут же отправляет команду на запись (типа включить реле). Чтобы не терять время, в mqtt публикуется сообщение, что реле включено (/devices/wb-mr6c_162/controls/K1 1). При этом по умолчанию подозревается, что реле тут же и включится.

Далее продолжается цикл опроса Когда очередь доходит до релейного модуля, wb-mqtt-serial опрашивает состояние (в том числе и реле), и если реле на самом деле не включено еще, то в mqtt будет опубликовано сообщение /devices/wb-mr6c_162/controls/K1 0

То есть через интервал опроса в mqtt будет содержаться текущее состояние реле.

Источник задержки (нажал на кнопку, а реле не отработало по факту — это текущий опрос устройства, который может длиться долго, в течение нескольких секунд, если это WB-MAP12 с шаблоном с большим количеством регистров, например).

Вы хотите знать точное состояние реле, чтобы выполнить какое-то еще действие, при условии, что реле действительно включено? Какие задержки допустимы между отправкой команды и получением точного статуса реле в вашей задаче?

и если реле на самом деле не включено еще, то в mqtt будет опубликовано сообщение /devices/wb-mr6c_162/controls/K1 0

Еще до того как писать пост я это проверил, оно сразу показано как включено. Наверное, если его физически отключить, там и появится нолик, надо проверить, но сама теория так себе. Вы же понимаете, что такую схему сложно отследить, сначала появится, что все включено, а потом, возможно, реальное состояние.

то драйвер после завершения цикла опроса очередного устройства тут же отправляет команду на запись

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

Вы хотите знать точное состояние реле, чтобы выполнить какое-то еще действие, при условии, что реле действительно включено? Какие задержки допустимы между отправкой команды и получением точного статуса реле в вашей задаче?

Сейчас проблема с включением света по датчику движения. Сам факт наличия сигнала от датчика движения я проверил - он моментальный, и команду на включение (судя по логам) я тоже моментально посылаю, но реально 2-3 секунды задержка. У меня раньше вместо MR6C стоял самописный модуль на ESP и там время реакции было в пределах 50-100 мс. А сейчас перед гостями стыдно)
Может не стоит тот же MAP12 так часто опрашивать? Это как-то настраивается?
У меня сейчас не так много всего подключено к контроллеру и уже появились задержки, а планируется к запуску проект на 3 MAP12, 13 MSW и кучу реле и диммеров, как я в глаза заказчику буду смотреть, если у него такие же задержки будут?))

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

Вы можете включить отладку на порту и смотреть в логах, что вносит такую задержку.
В ближайшем будушем исправить логику поллера не представляется возможным, но код открыт, и теоретически можно пересобрать под свои нужды: https://github.com/contactless/wb-mqtt-serial
Или попробовать, поддержит ли работу Node-Red.
Еще, естественно, помогает увеличение скорости на шине и устройствах до 115200 кбит/с.

В шаблонах WB-MAP имеет смысл минимизировать количество опрашиваемых регистров до минимально необходимого. В настройках устройств есть отдельное значение опроса для каждого устройства и даже для каждого регистра.

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

Айдар, смотрите, если вы хотите получать обратную связь от реле, то надо задумываться о том, какие отказы вы хотите контролировать. Очевидно, это надо делать в порядке убывания вероятности.
Какие неисправности могут возникнуть:

  1. Нет питания релейного модуля
  2. Нет связи по Modbus
  3. Контакты реле залипли и не коммутируют нагрузку
  4. Модуль не отрабатывает команду включения/выключения реле
  5. Модуль неверно передает состояние реле по Modbus

Пункты 1 и 2 определяются контроллером, кроме того, релейные модули имеют настройку таймаута – выключить все каналы при отсутствии обмена данными с контроллером в течение заданного на модуле значения времени.

Пункты 3-5 программно детектировать не получится, вам надо анализировать физическое состояние выходов. Для некритических систем, типа освещения, это не имеет смысла делать.

Для водоснабжения и отопления (если говорить о бытовых применениях) можно:

  1. Измерять/детектировать напряжение на управляемых выходах (https://wirenboard.com/ru/product/WBIO-AI-DV-12/, https://wirenboard.com/ru/product/WBIO-DI-HVD-8/, https://wirenboard.com/ru/product/WBIO-DI-WD-14/)
  2. Измерять потребление мощности нагрузкой (https://wirenboard.com/ru/product/WB-MAP6S/)
  3. Следить за потоком воды (https://wirenboard.com/ru/product/WB-MCM8/, https://wirenboard.com/ru/product/WB-MWAC/)

Далее, чтобы устранить зависимость мониторинга и управления, можно подключать устройства контроля к отдельному контроллеру. Можно дублировать питание. Ну и где-то наступает грань разумного.

Быстродействие:
Наибольшей скоростью реакции обладают боковые модули WBIO-xxxxxxx. Они подключаются к контроллеру непосредственно и о событиях от них контроллер узнает по аппаратным прерываниям (считайте, мгновенно). Какой-нибудь датчик движения можно подключить к WBIO-DI-WD-14, и движком правил включать свет, отправляя команду либо по Modbus (задержка), либо включать свет боковым же релейным модулем (возможно через контактор или управляющий вход релейного модуля).

Ну, и, конечно, чем больше компонентов, тем больше потенциальных точек отказа.

Добрый день!
Подключил реле на отдельный порт - стало заметно лучше.
Получается рекомендации такие - то что управляется на один порт, то что для чтение и тяжелое - на другой, верно?

Добрый день!
Тут возникла связанная проблема.
У меня есть чемодан, в котором спустя какое-то время перестает работать модуль MR3.
Изначально чемодан совсем проблемным оказался и я его перепрошил, но проблема с реле осталась. Я даю команду на включение, реле не включается, но все (и ваш интерфейс и мой) думают что оно включено. После перезагрузки вроде чинится.
Короче вот это как раз живой пример, что все думают, что вода перекрыта а на деле затопили 9 этажей)