OpenHAB — стань программистом собственного жилища

Дом — это машина для жилья

_{Ле Корбюзье}

В этом посте я расскажу об opensource проекте домашней автоматизации openHAB ^[1].
openHAB переводится как "Open Home Automation Bus". Это значит, что он нацелен на создание универсальной платформы для объединения всей домашней «умной» техники в единую систему управления.

Что же это дает на практике? Под катом я расскажу о том, как с помощью этого решения можно создать настоящий интернет вещей в своем доме.

Что такое «единая платформа домашней автоматизации»?

Направление умных домов развивается уже давно. За это время появилось множество различных поставщиков «умного» оборудования (освещение, RGB подсветки, термостаты, приводы для штор/жалюзи, разнообразные датчики и т.п.) Все они работают на разных протоколах (проводных и беспроводных).
В результате, пользователь, желающий автоматизировать свое жилище, должен выбирать между продуктами от различных производителей. В конечном итоге ему приходится пользоваться разными системами (пульты, приложения) для контроля разных устройств. Вдобавок, задача создания полноценного интернета вещей (когда устройства могут быть связаны в единую цепь и управляться все вместе в результате каких-либо условий и событий) становится очень сложной.

Чем поможет openHAB

openHAB реализует единую шину, т.е. позволяет объединить все устройства с разными протоколами в единую сеть, абстрагируя пользователя от каждого конкретного протокола. Таким образом, можно пользоваться единственным средством управления (скажем, приложением на смартфоне) и реализовать сколь угодно сложную логику взаимосвязи между устройствами.

Что отличает проект openHAB от аналогов?

Во-первых, он развивается уже довольно давно и уже сейчас готов к полноценному использованию. По своему личному опыту (впервые я начал работать с этой системой около года назад) могу сказать, что его освоение занимает совсем немного времени. И после этого он работает действительно так, как заявлено в описании.
Сейчас разработчики трудятся уже над вторым поколением платформы, основанной на специализированном фреймворке Eclipse SmartHome ^[2].

Во-вторых, это проект с открытым исходным кодом. А это значит, что весь код создается программистами со всего мира, которые заинтересованы в теме интернета вещей и создания единой системы умного дома. Этот код доступен в репозитории GitHub ^[3].

В-третьих, в результате открытости уже сейчас openHAB поддерживает около 50 (пятидесяти!) различных протоколов «умных» устройств. Среди них ZWave, KNX, EnOcean, системы мультимедиа типа Sonos, кинотеатр XBMC, Samsung SmartTV и многие-многие другие. Это, в свою очередь, дает возможность пользователю выбирать устройства для своего дома по самым разнообразным параметрам, практически не ограничиваясь возможностями всей платформы.

Как это работает?

openHAB — это специальный сервер, который может работать на любом компьютере под управлением любой ОС (вы даже можете использовать RaspberryPi). Вся установка заключается в распаковывании дистрибутива сервера и установке Java машины. Далее начинается процесс настройки и созидания.

openHAB — это очень гибкий конструктор. Основанный на технологии OSGi, он позволяет конфигурировать каждый отдельный плагин (Binding) «налету», не перезагружая весь сервер.

Плагин (биндинг) в openHAB — это то самое связующее звено между конкретным протоколом устройства и единой системой openHAB. Пользователь может добавить в свою инсталяцию openHAB только те плагины, которые нужны именно ему. Например, если у вас есть только ZWave и Phillips Hue, то вам понадобятся только два биндинга.
После настройки связи между каждым устройством и соответствующим биндингом система сможет общаться с ним посредством простых команд, абстрагированных от конкретного протокола. Скажем, для включения/выключения есть команды ON/OFF, для открытия/закрытия UP/DOWN и т.д.
В дальнейшем, используя только такие абстрактные команды, можно будет создавать очень сложные сценарии и, что называется, программировать собственный дом.

Настройка item-ов и binding-ов

Каждое «умное» устройство в доме должно быть сконфигурировано в openHAB как один или несколько item-ов. Они описываются в специальном файле в директории configuration/items. Вот пример одного такого item-а

Dimmer Light_GF_Living_Table "Table" (GF_Living, Lights)

Здесь описан один item с именем Light_GF_Living_Table и типом Dimmer. Т.е. это некое устройство, которое может быть диммировано (включено, выключено или изменить свое значение в диапазоне от 0 до 100). Как правило, диммерами являются различные световые приборы, но также это может быть диммируемая розетка, или что-либо еще.

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

Dimmer Volume "Volume [%.1f %%]"

Как видите, openHAB дает возможность использовать разные item-ы как элементы управления для всего, что подходит под какие-либо критерии (в данном случае, что-то должно уметь включаться, выключаться и принимать значение от 0 до 100).

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

itemtype itemname ["labeltext"] [<iconname>] [(group1, group2, ...)] [{bindingconfig}]

Как видите, сперва идет тип (Switch, Dimmer, Color, String, Number, Rollershutter, DateTime, Contact, Group), затем уникальное в рамках файла имя, опциональные label (то, что будет отображено в UI), иконка (из набора openHAB), одна или несколько групп (для объединения устройств по смыслу или расположению) и собственно конфигурация самого биндинга — в фигурных скобках;

Подробное описание каждого типа и список возможных команд представлен на странице Explanation-of-Items ^[4]

Binding — или как связать item с устройством

Биндинг связывает item с каким-то конкретным устройством (или его функцией). Это нужно для того, чтобы openHAB преобразовывал абстрактные команды типа On/Off в конкретные сообщения нужного протокола, а также правильно интерпретировал сообщения от устройства. Вот пример KNX биндинга для простого переключателя:

Switch Light_GF_Living_Table "Table" (GF_Living, Lights) { knx="1/0/15+0/0/15" }

У каждого биндинга свой синтаксис конфигурации. В openHAB это одна строчка в фигурных скобках, в которой необходимо указать все что нужно для связи с устройством по конкретному протоколу. Здесь указан протокол KNX и его конфигурация в виде двух адресов — 1/0/15 для управления и 0/0/15 для получения статуса от устройства.

Также не забывайте, что у каждого биндинга есть набор глобальных настроек, которые нужно указать в файле configuratnios/openhab.cfg. Например, для KNX — это IP адрес knx шлюза, который связывает knx-шину с IP сетью.

Пользовательский интерфейс

Здесь openHAB предлагает довольно интересный способ построения UI «на лету» с помощью файлов описания sitemap. В директории configuratnios/sitemaps лежат файлы, в которых нужно описать то, как должен выглядеть пользовательский интерфейс (а точнее, его layout) для управления теми устройствами, которые мы описали в items. Вот простейший пример

sitemap demo label="Main Menu"
{
Frame label="Percent-based Widgets" {
  Slider item=DimmedLight switchSupport
  Colorpicker item=RGBLight icon="slider"
  Switch item=DemoShutter
  Slider item=DemoBlinds
 }
}

Здесь UI состоит только из одного «фрейма» (не путать с фреймами в терминах HTML), в котором есть 4 элемента (два слайдера для управления диммерами, выбор цвета для подсветки, простой переключатель). Список всех возможных элементов интеофейса можно найти на странице Sitemaps ^[6].

Почему UI нужно описывать именно так? Почему бы просто не использовать тот же HTML?
Дело в том, что sitemap — это абстрактное описание того, как должен выглядеть интерфейс. Любая программа (например, для смартфона) или javascript клиент в браузере может отрендерить интерфейс по такому описанию по-своему. Таким образом, openHAB абстрагирует описание интерфейса от конкретной реализации.
К слову, кроме веб-интерфейса openHAB предоставляет клиентов под Android и iOS (не учитывая того, что любой программист может написать своего собственного клиента под любую платформу). И что также важно — любое изменение sitemap приводит к измнению UI на клиенте без перезагрузки сервера.

Программируем «умный дом»

И вот наконец мы подобрались к самой интересной части — программированию поведения умного дома!
Все что было кратко описано до этого позволяет настроить связь item-ов с биндингами и правильно отобразить элементы управления в UI. Но openHAB еще предоставляет очень мощный инструмент программирования логики — скрипты и правила. С помощью них можно описать действительно умное поведение устройств в зависимости от разных условий.

Скрипты и правила описываются в файлах директорий scripts и rules соответсвенно на языке Xtend ^[8], разработанном Eclipse.
Если скрипт — это кусок кода, который может быть запущен в какой-то момент, то правила — это основной механизм автоматизации. На нем и остановимся подробнее.

И сразу пример простого правила:

/**
 * This rules controls the volume on the local host
 */
rule "Volume control"
	when
		Item Volume received command
	then
		if(receivedCommand instanceof PercentType) {
			setMasterVolume(receivedCommand as PercentType)
		} else {
			if(receivedCommand==INCREASE) increaseMasterVolume(20)
			if(receivedCommand==DECREASE) decreaseMasterVolume(20)	
		}
		postUpdate(Volume, masterVolume * 100)
end

При поступлении команд increase/decrease с диммера Volume срабатывает простое правило Volume control, которое увеличивает или уменьшает громкость системы, на которой работает opеnHAB сервер.
Вот еще один пример:

/**
 * The following rules help initializing the demo items with some helpful states.
 */
rule "Initialize light states"
	when
		System started
	then
		Lights?.members.forEach(light|
			postUpdate(light, if(Math::random > 0.7) ON else OFF)
		)
end

Здесь при включении системы каждое устройство в группе Lights включается в 30 процентах случаев.

Dimmer LedR     "LED Red"     <dimmer>        { knx = "11/0/0+11/0/1,   11/0/2,  11/0/3+11/0/4" }
Dimmer LedG     "LED Green" <dimmer>        { knx = "11/0/5+11/0/6,   11/0/7,  11/0/8+11/0/9" }
Dimmer LedB     "LED Blue"     <dimmer>       { knx = "11/0/10+11/0/11, 11/0/12, 11/0/13+11/0/14" }
Color  RGB      "RGB Light"        <slider>

{
 Frame label="RGB" {
  Colorpicker item=RGB
 }
}

var HSBType hsbValue
var String  redValue
var String  greenValue
var String  blueValue

rule "Set RGB value"
when
        Item RGB changed
then
        hsbValue = RGB.state as HSBType

        redValue   = hsbValue.red.intValue.toString
        greenValue = hsbValue.green.intValue.toString
        blueValue  = hsbValue.blue.intValue.toString

        sendCommand( LedR, redValue )
        sendCommand( LedG, greenValue )
        sendCommand( LedB, blueValue )
end

Да, изменение в исходнике правила также приведет к его автоматической перезагрузке без перезапуска. Подробности о возможностях правил и скриптов, а также множество примеров можно найти на странице Rules ^[9]

Триггеры

Каждое правило начинает выполняться только при срабатывании одного из триггеров, описанного между when и then. Триггер — это некоторое событие:

• поступление команды от item-а (например, при включении Switch через UI)
• изменение состояния item-а (например, в момент открытия штор от привода последовательно приходят значения от 0 до 100)
• изменение текущего времени на сервере openHAB (например, Time is midnight)
• старт или остановка сервера opnaHAB

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

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

В итоге

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

Если у вас возникнут вопросы или пожелания по теме следующей статьи, с удовольствием готов более полно раскрыть какую-либо сторону использования openHAB.

Автор: morfeusys

Источник ^[10]