РЕКЛАМА НА ФОРУМХАУС Я бы тут поспорил. Node-red вполне может (и это довольно часто используют) общаться с железом напрямую. Например в простейшем случае конечное уст-во или датчик может напрямую связаться с node-red через mqtt (который не является частью openhab так же как и node-red) минуя openhab. Обычно, таким образом группу датчиков заводят на node-red. который в соответствии с заложенными в него правилами из нескольких источников выдает на выход определённые команды или информацию. Таким образом упрощается конфигурация в самом openhab. Моё замечание не столь принципиальное, но новичку для понимания сути может быть полезным.
Спасибо за как всегда подробнейший ответ. То есть в NodeRED выносится весь функционал, который не зависит от протокола? И насколько это эффективно? Протокол меняется ведь не так часто? Вот этот момент не очень понятен. NodeRED ведь может самостоятельно получать все события. Для чего такие сложности с разными уровнями? Только из-за возможной смены протоколов? Я на первый очень поверхностный взгляд большую часть функционала переложил бы на NodeRED, а ОпенХаб использовал бы как "веб-морду". Как пишет @vshaev, NodeRED обладает достаточно большими возможностями и почему бы их не использовать? Вы сами пришли к подобной схеме? Или она является неким неформальным необязательным "стандартом", которого лучше придерживаться для единообразия?
На самом деле вопрос взаимодействия с конечными девайсами непростой и во многом философский. Простой пример - большинство устройств ввода показывают, что сейчас на входе ноль или единица. Для отработки выключателей важен переход 0->1 или 1->0, кому как религия больше позволяет. Для отслеживания двойного нажатия все становится намного веселее. Условно имеем 500 мс на отслеживание и условно 10 модбас девайсов. Чтобы отследить двойной клик нужно минимум 3 раза опросить модуль. Т. е. на модуль остается 16-17 мс. Цифра для модбас малореальная. У меня планируется 6 девайсов, по 16DI но и 30 мс оптимизма тоже не внушает. Посмотрим на практике. К чему этот спич - крайне сомневаюсь, что OH или nodered смогут обеспечить такую производительность в принципе. Сейчас я нарисовал прослойку на codesys и то не слишком уверен. Второй момент - тоже интересный, у меня на шлюз сотня DI+ сотня DO+ несколько десятков температурных датчиков <-> mqtt получилось меньше сотни строк кода на ST. При этом я могу отследить одинарный клик с контролем дребезга или полный фарш с одинарным-двойным-длинным кликом. Причем добавление девайсов код практически не меняет. Как это бы выглядело на чем-то другом непонятно, но крайне сомневаюсь что проще.
Конечно, если устройство умеет MQTT, его не обязательно подключать через OpenHAB. У меня так подключен выключатель Sonoff и все настенные планшеты. Протоколы на самом деле меняются очень часто. Добавляется поддержка новых устройств, да и сами драйвера обновляются очень быстро. Например, я несколько раз обновлял Z-wave binding. Да и вы сами, когда выходит новая умная железяка для умного доме, не хотели бы, чтобы ее поддержка появилась как можно быстрее? В OH очень хорошая поддержка протоколов, в NodeRED все гораздо хуже. И в конце концов, если не понравится OH, в данном случае его легко заменить на что-то другое - HomeAssistant, MajorDomo, ioBroker - то, где поддержка нужного вам протокола лучше. А ваши правила останутся с вами. Это довольно распространенный подход к конструированию сложных систем управления - разделение системы на уровни со стандартизированными интерфейсами между ними. В данном случае мы отделяем аппаратно-зависимую часть от алгоритмов управления, позволяя обновлять и модифицировать их независимо друг от друга, не рискуя нарушить работу всей системы.
У меня была мысль обрабатывать подобные события (нажатия кнопок, срабатывания различных датчиков) не через состояния цифровых входов, а через счетчики изменения состояния этих входов. Но до "железа" я это ещё не доводил.
это второй классический подход, в новых овенах 210 серии так и сделано. Но там масса нюансов. К примеру частота отслеживания, чтобы не "пролюбить" инверсный переход. Поэтому на каждый вход еще и задается частота. Но они так толком и не доделали, глюкавит сильно.
Это не филосовский вопрос. Это как раз пример функциональности, которая в случае с централизованной системой приводит к завышенным требованиям к производительности контроллера из-за почти реалтаймовых требований. Она решается достаточно просто - так как отслеживание двойных и тройных нажатий не требует взаимодействия с другими устройствами, будет вполне резонно поместить эту функцию в само оконечное устройство, а более высшему уровню управления предоставлять уже готовую информацию о том, сколько кликов было сделано. Это вполне в рамках централизованной религии. Например все устройства Z-wave, KNX и даже некоторые прошивки для Sonoff так умеют. И никаких проблем с OH или NodeRed. А в случае с Modbus или другими тупыми модулями вам, естественно, придется сделать реалтаймовую прослойку. Но это не так страшно, я еще давно намалевал данную картинку. Ваша прослойка с Codesys - это есть виртуальный ПЛК в моей архитектуре - он отвечает за реал-тайм не только в случае, как у вас - отслеживание двойных кликов, но может также исполнять всякие алгоритмы ПИД контроллеров, которые тоже в OpenHAB и NodeRED не очень реализуемы. Единственное, что в этом случае я считаю, что NodeRED не нужен - ПЛК может легко взять на себя функции правил и сценариев и при этом он также легко программируем и отлаживаем, но это кто как хочет. В итоге имеем: - нет реалтайма - связка OpenHAB + NodeRED как у меня. - нужен реалтайм - связка ПЛК + OpenHAB. Надеюсь общие элементы сами найдете.
вполне естественно. Но ценник оконечного устройства при этом конский. По соноффу в дискуссию вступать не будем, как-то не готов я весь дом обвешать ими. А вот с ценниками KNX и z-wave можно ставить по одной малине с кодесисом на модбас железку - всяко выйдет дешевле так оно в общем-то и сделано, я сейчас жду очередную китайскую железку - проверю и закажу 6 модулей на один этаж 3x16DI+3x16DO. Не могу сказать что малиновый кодесис честный реальтайм, но предполагаю, что о реалтайме эти ребята знают поболее OH и NodeRed. пока решил сделать в ОН, будет плохо работать - перенесу на ПЛК. Код получается простейший. Но приходится делать задержку в 10 мс при последовательном включении релюх из-за проблем на приеме в cds нескольких mqtt команд. Код: rule "CDS_Command" when Item CDS_Command changed then var command=CDS_Command.state.toString //logInfo("CDS command", "command<"+command+'>' ) if (command !='-'){ switch(command) { //Спальня 1 этаж case 'C101' : inverseSwitch.apply(CDS_BD1_Light1) case 'C102' : inverseSwitch.apply(CDS_BD1_Light2) case 'C103' : inverseSwitch.apply(CDS_BD1_Light3) case 'D101',case 'H102' : { commandSwitch.apply(CDS_BD1_Light1,'ON') commandSwitch.apply(CDS_BD1_Light2,'ON') commandSwitch.apply(CDS_BD1_Light3,'ON') } case 'L201',case 'H203' : { commandSwitch.apply(CDS_BD1_Light1,'OFF') commandSwitch.apply(CDS_BD1_Light2,'OFF') commandSwitch.apply(CDS_BD1_Light3,'OFF') } //синхронизировать все реле case 'sync' : { gSwitchSet?.members.forEach[ i| commandSynchronize.apply(i)] } case '-': break //неизвестная команда default: logInfo("CDS Command", "Unknown command <"+command+'>' ) } CDS_Command.sendCommand('-') } end
А какие железки? Случайно не из этой серии? https://ru.aliexpress.com/item/Modbus-tcp-Ethernet-IO-4di-4do-4AI-2ao/32838142273.html?spm=a2g0s.13010208.99999999.293.3xGDIO
Еще вопрос по NodeRed. Уже чуть более конкретный. Программу минимум я вроде осилил. У меня есть ЕСП с прошивкой ESPEasy и подключенный к ней светодиодик. Подключил ЕСП к Опенхабу и к НодеРед. В одном и другом приложении сделал по выключателю (switch). Включается и выключается прекрасно из обоих приложений. С этим разобрался. Следующим шагом попытался синхронизировать выключатели в ОпенХаб и НодеРед. С Опенхаб разобрался с настройками. Когда включаю/выключаю выключатель в NodeRed UI, в Опенхаб тоже переключается состояние (сделал через MQTT). А вот обратная связь не получается. Если попытаться внятно сформулировать вопрос, то звучит он так: как с помощью MQTT изменить состояние switch UI в дашборде NodeRed?
У вас создается mqtt сообщение по изменению состояния выключателя? Или по другому, есть обратная связь на команду? В первом приближении, логику обмена я вижу так: OH (или Node-RED) дают команду выключателю (например, ESP) в виде mqtt сообщения включить (или выключить) свет. Выключатель получает команду, отрабатывает и отправляет ответ, также в виде mqtt сообщения, что он включился (или выключился). Эти сообщения ловят и OH и Node-RED и отображают на своих дашбордах текущее состояние выключателя.
Обратная связь есть. Прошивка ЕСП отсылает MQTT сообщение о своем состоянии. Принять его я могу. Не могу понять как изменить состояние выключателя в UI NodeRed. Какой функцией/нодой это можно сделать. Просто "в лоб" не работает.