Есть WB-MGEv2 и по несколько модулей реле/диммеров (WB-MR6Cv3, WB-LED, WB-MDM3).
Для примера рассмотрим простой случай: по долгому нажатию любого выключателя в комнате A выключать все связанные с ним линии всех реле/диммеров этой комнаты. Разных комнат несколько и каждая использует какое-то количество входов-выходов этих модулей.
Если соответствовать духу гайдлайнов, то это необходимо делать на головном модуле, либо обрабатывать “снаружи” своими силами через Modbus (RTU over) TCP.
Я хотел бы уметь обрабатывать такие простые сценарии автономно, головной модуль или внешняя обработка выглядят для меня излишними. (хотя, конечно, имеющими право на существование)
В каких-то конкретных единичных случаях можно было бы решить подключением выключателя сразу к нескольким модулям (например мастер-выключатель подключить к каждому модулю), но в общем случае такое решение невозможно.
Нет. Сами прошивки модулей - не GPL, не выкладывались и не планируются выкладываться в свободный доступ.
Оптимальный - наличие на шине (шинах) Modbus мастера, который обеспечивает обработку изменений состояния.
А прокси между чем и чем? то есть в чем будет заключаться его задача?
Я одно время шел по DIY пути создания “одноранговых” устройств, обменивающихся информацией между собой. Но сразу же столкнулся с проблемой интеграции с другими, не самодельными устройствами и вообще с окружающим миром. Да и настройка самого взаимодействие путем изменения прошивок - удовольствие ниже среднего. Причем замена, на сегодняшний день тот же HA на малинке - дешева и удобна.
Идея в том, чтобы простые сценарии, которые не затрагивают ничего кроме самих диммеров/реле (например, долгие/двойные нажатия, но не в рамках одного модуля, а в рамках всех модулей димеров/реле) обрабатывались автономно, но всё ещё оставалась возможность управления извне, например с того же HA.
Т.е. примерно вот так:
← внешняя шина (Modbus либо Ethernet) → [“умный” прокси] ← внутренняя шина Modbus → [WB-MR6Cv3, WB-LED, WB-MDM3]
Под “умным” я здесь подразумеваю то, что он может какие-то базовые сценарии обработать сам, в остальном он просто прокидывает регистры на “внешнюю” шину как это делает WB-MGEv2.
Согласен, что HA на Raspberry и подобном — легко и недорого, как промежуточное решение я буду именно такой вариант использовать.
Но мне принципиально хотелось бы всё “внутреннее” делать автономно на чём-то с Real-time OS или ещё более низкоуровнево, условно не хотелось бы чтобы выключатель перестал работать как надо из-за того, что HA или докер понаписал кучу логов и на флешке Raspberry внезапно кончилось место, пришёл OOM или просто что-то упало с segfault
Опять же все варианты нажатий выключателей даже в рамках одного модуля можно было бы обрабатывать “извне” в головном модуле или на HA, но они сейчас обрабатываются внутри самого модуля — хотелось бы вот такого же добиться, но между несколькими модулями реле/диммерами.
Это, описанное, возможно. Но - цена разработки и поддержки - изрядно велика получается.
Я бы посоветовал если есть желание сделать именно вот такой отдельный мастер - сразу закладывать в него работу с “основным” по IP, например по MQTT.
Ну и вижу основные задачи, которые проходил сам:
опрос Slave устройств (таблица регистров для каждого, с MQTT топиком для каждого регистра)
публикация в брокер актуальных состояний (изменений) регистров.
при изменении на брокере - запись в регистр устройства
при изменении в регистрах - проверять не участвуют ли они в “локальных” автоматизациях и запускать их.
Да, можно реализовать Modbus-master на микроконтроллере и это несложно. Но дальше…
Если хотите реально реализовать желаемое и иметь достаточно удобный механизм изменения - посмотрите на 1.5 Installing OpenPLC Runtime on Microcontrollers – Autonomy
Открытая СКАДА с автономным рантаймом выполняемым в том числе и на микроконтроллере.
но может быть всё-таки есть какие-то более стандартные варианты.