Практическая автоматизация дома на базе openhab. Часть 3 — Proxy Item шаблон

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

Следование этим шаблонам дело сугубо добровольное но, как показывает практика, целесообразное.

На мой взгляд, есть один главный шаблон использование которого строго обязательно если система чуть больше чем маленькая.
Называется Proxy Item community.openhab.org/t/design-pattern-proxy-item/15991.

Попробую пояснить почему он необходим и как я его использую.

У вас есть конкретный дом, есть абсолютно конкретные потребности (контроль освещения, доступа, утечек, потребления, задвижек и тп), вы для реализации этих потребностей заводите в опенхабе виртуальное оборудование, вот реальный пример из моего дома (почему элементы организованы именно так я расскажу в следующем посте):

На что я тут хочу обратить внимание :

1. тут нет никакой привязки к настоящему оборудованию, это некий макет который отображает мое представление об идеальном умном наполнении комнаты, этот макет с очень небольшими изменениями у меня повторяется и в других комнатах.
2. тут есть слой UI а именно мета-теги для привязки к Google Assistant
3. тут есть очень четкая иерархия, в том числе соответствие рекомендованной семантической модели (Semantic Model | openHAB)
4. Некоторые элементы тут “на вырост”, так например в кабинете у меня пока нет термостата (не купил) но поскольку я точно знаю что он будет я его сразу закладываю в виртуальную модель (GF_Office_SetpointTemperature)

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

Фактически для измерения микроклимата используется у меня оборудование Legrand Netatmo WeatherStation.

Что тут важно:

1. Тут нет никакой иерархии и нет никакой привязки к структуре дома
2. Тут используется специальный мета-тег expire, это нужно для контроля работоспособности оборудования. Если Openhab перестанет по какой-то причине получать от оборудования данные (ну например села батарейка или железка просто сломалась) то “железные” элементы просто перейдут в специальное состояние UNDEF (не определено). Без expire они просто будут в последнем полученном состоянии.

Далее необходима специальная магия, которая через правила свяжет виртуальные элементы с реальными. В исходной статье Rich Koshak (фундейшен мембер) очень подробно описано как написать такие правила.

Но я человек ленивый и писать столько однотипных конструкций посчитал слишком накладным процессом. Для упрощения рутинных правил проксирования, с также имея некоторый опыт их написания и точно понимая что мне нужно, я написал JS библиотеку (openhab-proxy-pattern — npm (npmjs.com)) для этого.

Библиотека openhab-proxy-pattern

Библиотека может быть использована для написания проксирования через JS автоматизацию (JavaScript Scripting — Automation | openHAB). Для применения библиотеки вам необходимо эту автоматизацию добавить в ваш openhab.

Начиная с версии 3.2 openhab JS автоматизация предлагается как основное средство для написания новых сценариев, потому я очень рекомендую начинать сразу писать правила с ее использованием.

После установки автоматизации в вашей домашней директории опенхаба появится папка automation/js/, при установке openhab в Ubuntu физически это папка /etc/openhab/automation/js/

Добавляем библиотеку в виде пакета

cd /etc/openhab/automation/js/
npm i openhab-proxy-pattern

Теперь проксирование будет максимально простым, по крайней мере в js автоматизации.

Библиотека работает максимально просто и топорно, она умеет автоматически создавать правила проксирования либо от железа в виртуальное (метод update) либо от виртуального в железо (forward), ну либо оба сразу. Оба метода поддерживают опциональный параметр callback куда можно написать логику по преобразованию значения.

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

Логика любого проксирования, в данном случае, характеризуется следующим мнемоническим правилом

если состояние “железной железки” изменилось то меняем состояние виртуальной, также для железок которые предусматривают управление делаем второе правило “если нажали на виртуальную то эмулируем нажатие на железную”.

Чем прекрасен этот шаблон:

1. Вы пишите основную бизнес логику по виртуальному железу, “Если влажность в кабинете упала до … включаем увлажнитель в кабинете”. Бизнес-логика абсолютно не в курсе какой модели у вас увлажнитель, какой модели у вас датчик влажности, ее задача связать одно с другим. Логика полностью абстрагирована от железа
2. Железо имеет свойство ломаться, обновляться — у вас поломался увлажнитель, вы купили другой — перебросили за 5 минут прокси логику на новую железку, основная логика (которой всегда много и она сложная) осталась неизменной а значит продолжает работать. А пока увлажнитель отсутствует — ничего не ломается в других местах.
3. Персистентный слой хранения настроен только для виртуальных устройств, вы поменяли железку а статистика в графане у вас продолжается как будто ничего не случилось и персистентность именно в тех единицах которыми вы привыкли оперировать. Не важно что у вас железка меряет напряжение в сотых долях вольта в виде целого числа — в логике и графиках у вас будут вольты с плавающей точкой.
4. Вы можете планировать архитектуру наперед, при этом оставив реализацию до того момента когда у вас появится настоящая железка.
5. Семантическая модель опенхаба гараздо логичнее и прозрачнее натягивается на прокси чем на настоящее железо, где разработчики бондинга могли что-то сделать на свое усмотрение
6. У вас во всем доме “оборудование” получается однотипным, например все диммеры света 0..100 несмотря на то что у одних железок это 0–100, у других 0–128 а у третьих 1–5. Пересчет а адаптация выполняется в прокси-слое логики.
7. При добавлении “железных железок” вы можете прямо копировать из мануала, вам нет необходимости “адаптировать” имена или группы под ваш конкретный дом.

Единственный минус этого подхода — чуть больше работы в самый первый раз.

Если вы серьезно хотите играть в автоматизацию с опенхабом изучите и осознайте великолепие этого шаблона, также есть смысл посмотреть другие (community.openhab.org/tag/designpattern), там много полезного, пусть и не на столько.

Предыдущая часть