РЕКЛАМА НА ФОРУМХАУС не могу назвать себя опытным пользователем ОН, хотя для теста попробовал достаточно многое, включая модбас. Пробовал z-wave, но с верой edge. Mqtt и node-red в общем-то не самоцель. Я вообще пока не собираюсь ставить датчики движения-освещенности и затягивать на них логику включения. Поскольку не вижу особых мест, где это просто необходимо использовать. Ну может разве что лестница и один с/у. Кто-то может сказать, что нафига тогда вообще УД - скорее игрушка. Что касается конкретного вопроса - в любом УД есть понятия "исполнителя" и "актуатора". Связь многие ко многим. И с этих соображений нужно подходить. Кстати свитч для выключателя решение кривоватое, скорее momentary button. На истину не претендую, но как у меня будет выглядеть панель к примеру 1 этажа. Выведены свитчи управления группами освещения - управляют конкретными реле. Вверху кнопки помещений, которые "включают-выключают" целиком помещения. Физические выключатели просто шлют mqtt событие. В большинстве случаев это будет конкретный свитч, 10-20% какая-то группа свитчей. Но логика обработки должна понимать, что делать - включать оставшиеся свитчи группы или все выключить. Можно перенести эту обработку на NR - но пока смысла не вижу. Возможно позже так и сделаю. Но это вводить дополнительный элемент в архитектуру. В которой и так уже modbus+codesys+mqtt+OH. Думал еще добавлять imperihome для панелей, но habpanel пока устраивает.
Да. Выключатель - это вход. Один item. Он имеет только состояние - включен/выключен, или нажат/ненажат - как вам удобно. Лампочка - это выход. Это другой айтем. Она воспринимает команды: включить/выключить и также имеет свое состояние - включена/выключена.
у меня всегда возникал вопрос как с обычными бистабильными выключателями можно работать с УД, на мой взгляд крайне криво. Если отключить с панели - при обычном физическом выключателе придется каждый раз перещелкивать при пользовании. А с кнопкой - пришло событие сделали инверсию и забыли. Кстати в хабпанеле специально разнесли эти два понятия на button и switch. В sitemaps кнопки делаются плохо.
В ОпенХабе вроде бы нет такого элемента (айтема) как кнопка. Поэтому ее делают из switch путем разных извращений. Это пока один из недостатков ОпенХаба. Точнее не недостаток, а усложнения для понимания. В Хабпанеле действительно есть виджет button, но привязывается он все равно к Опенхабовскому Switch. Или, если я правильно Вас понял, Вы имеете ввиду, что можно вообще убрать айтем "выключатель", оставив только айтем "лампочка", которым управлять через Хабпанель. Обычные клавишные выключатели и правда малопригодны для автоматизации. Я предполагаю вместо них установку либо выключателей без фиксации (кнопок), либо сенсорных выключателей.
не совсем так - один из вариантов использования button посылать событие в какой-то элемент ОН. Я собираю все события в том числе и от панельных кнопок в элементе Код: String CDS_Command <settings> { mqtt="<[mosq:/cds/out/di/click:state:default]" } А потом их обрабатываю в одном месте. Код: rule "CDS_Command" when Item CDS_Command changed then var command=CDS_Command.state.toString //logInfo("CDS command", "command<"+command+'>' ) switch(command) { case '-': {} //Спальня 1 этаж case 'C101' : inverseSwitch.apply(CDS_BD1_Light1) case 'C102' : inverseSwitch.apply(CDS_BD1_Light2) case 'C103' : inverseSwitch.apply(CDS_BD1_Light3) case 'C104' : inverseSwitch.apply(CDS_BD1_Torch) case 'D103',case 'D104' : { commandSwitch.apply(CDS_BD1_Light1,'ON') commandSwitch.apply(CDS_BD1_Light2,'ON') commandSwitch.apply(CDS_BD1_Light3,'ON') commandSwitch.apply(CDS_BD1_Torch,'ON') } case 'L103',case 'L104' : { commandSwitch.apply(CDS_BD1_Light1,'OFF') commandSwitch.apply(CDS_BD1_Light2,'OFF') commandSwitch.apply(CDS_BD1_Light3,'OFF') commandSwitch.apply(CDS_BD1_Torch,'OFF') } case 'H103' : if (CDS_BD1_Light1.state ==ON ){ commandSwitch.apply(CDS_BD1_Light1,'OFF') commandSwitch.apply(CDS_BD1_Light2,'OFF') commandSwitch.apply(CDS_BD1_Light3,'OFF') commandSwitch.apply(CDS_BD1_Torch,'OFF') } else { commandSwitch.apply(CDS_BD1_Light1,'ON') commandSwitch.apply(CDS_BD1_Light2,'ON') commandSwitch.apply(CDS_BD1_Light3,'ON') commandSwitch.apply(CDS_BD1_Torch,'ON') } //синхронизировать все реле case 'sync' : { gSwitchSet?.members.forEach[ i| commandSynchronize.apply(i)] } //неизвестная команда default: logInfo("CDS Command", "Unknown command <"+command+'>' ) } if (command !='-'){ CDS_Command.sendCommand('-') } end Команда H103 приходит от панели. Проверяет включен ли первый ряд светильников и дальше выполняет действия. Единственно пришлось написать несколько функций для простоты обработки. Это как раз то, что можно перенести в NR, но код настолько простой, что пока не вижу смысла. Скорее наоборот - думаю сделать резервную связку для codesys для входов-выходов DI-DO и в случае отвала ОН автоматом переходить на резерв. А то пришел домой - свет не работает, пока разобрался где глюки - пора уже на работу собираться Еще скорее всего обработку команд придется раскидать на отдельные блоки по комнатам, поскольку этот главный обработчик может потянуть на тысячу строк кода, хоть и не сложного.
Есть такие ноды. Я просто хотел разобраться с разными вариантами. Меня очень сильно пугали встроенные правила в ОН. А сейчас я немного с ними разобрался и, пожалуй, это лучший вариант чем использование НодеРед. И, кстати, концепция, о которой говорит Lingvo при этом сохраняется. На нижнем уровне мы имеем айтемы и биндинги для связи с железом. На верхнем уровне имеем правила для логики и разных функций.
Да он есть, но принцип долгого сна и спокойствия гласит: для связки двух разных компонентов по возможности используйте стандартизированные и легко отлаживаемые интерфейсы. Так можно хоть будет определить какой из компонентов глючит или сделать имитатор другого компонента для отладки. А какой интерфейс использует встроенный Openhab-NodeRed коннектор - ХЗ. Наверняка какой-нибудь Rest Api.
Всем доброго дня! Не пинайте сильно если этот вопрос уже рассматривался... Думаю как бы поэффективние подключить систему контроля протечки воды (без радио и GSM блока) Гидролок к OH. Сейчас подключен к Гидролоку через сухие контакты - то есть могу из OH перекрыть/открыть воду, но нет обратный связи чтобы видеть когда гидролок срабатывает на протечку. Если кому может быть полезен мой опыт - сейчас через OH управляю устройствами по следующим стандартам: z-wave (через USB свисток воткнутый в OH). В основном микромодули fibaro. Так же через релешки fibaro подключил простые головки danfoss на клапаны регулировок радиаторов Xiaomi zigbee. Датчики движения, температуры/влажности/давления, кнопки, магический кубик Xiaomi WiFi. Робот пылесос первого поколения от Xiaomi - правда концепция его контроля из OH мне и самому не понятна Bluetooth. Bluetooth датчики температуры/влажности с экраном на электронных чернилах от Xiaomi Aqara. Broadlink RM Pro для управления устройствами по радио и инфракрасному порту. Управляю телевизорами (потенциально кондерами, но это еще не прописывал) и электрокарнизами по радиоканалам. Modbus по шине rs485 (через отдельный IP шлюз). Считываю характеристики электросети с электросчетчика и тестирую с пяток мини релешек wirenboard от contactless. ru для управления светом и считывания показаний с счетчиков воды. жду когда google зарелизит своего асистента на русском, тогда попробую прикрутить управление голосом через google home.
тут можно подробнее чего за счетчик? я кроме китайского SDM ничего подходящего не нашел. У меркурия крайне заморочено. Вместо обычного modbus rtu сделали свой протокол на его основе.
Именно его и использую SDM220 - однофазный, однотарифный. У меня трехтарифный режим, поэтому тарифы расчитваю скриптом в OH В конце дня получаю письмо с суммой потраченой на электричество... просто прикольно . Раньше еще была идея прикрутить аналитику чтобы отслеживать потенциально проблемные электроприборы в сети, но пока ничего подъемного не нашел.
Звучит здраво, хотя я наверное предпочту что-нибудь на Modbus прикрутить ИМХО раза в два дешевле будет. Думал, может кто уже курочил Гидролоковский контроллер, чтобы воспользоваться опытом и побыстрее в него подключиться Как только разберусь, отпишусь.
китайский модбас WP по фикс прайс в 1.6 тыр - работает вполне сносно. По крайней мере косяков пока не замечено. Z-wave на канал будет на порядки дороже.
баловство все это, как и УД в целом я вчера омотрел трехфазный SDM630 - в общем-то у eastron появился двухтарифный вариант. Но на али еще нет. Второй момент - пропускать 40+ ампер через китайский счетчик все же не решусь. Скорее всего буду через "накидные клещи". Да и будет попроще - перегорит - так не придется срочно перебрасывать ЭЭ напрямую.