Практическая автоматизация дома на базе openhab. Часть 2 — экосистема и инфраструктура
OH в базе самодостаточен и из “коробки” может использоваться сам по себе, как минимум для ознакомления но он предусматривает по своей природе что его нужно дополнить программными пакетами.
Influxdb
Несмотря на то что openhab собирает данные из 100500 внешних систем, по хорошему, не требует их хранения, он просто их закидывает в биореактор сценариев в памяти, который на базе текущих значений строит некую логику взаимодействия которая вам нужна.
Однако есть возможность openhab дополнить так называемым Persistent Storage (www.openhab.org/docs/tutorial/persistence.html). Это внешнее хранилище, куда OH будет складывать данные которые он получает из разных систем, и которые считает сценариями, данные четко привязаны к сущностям и могут быть в будущем использованы в логике самого опенхаба.
В результате, вы получаете доступ в сценариях к таким штукам как “среднее значение датчика за последние сутки” “значение 24 часа назад” “прошлое состояние” и т.п. “багацтво”, с которым логика играет совершенно другими красками.
Потому Persistent Storage это то что нужно подключить и настроить сразу, как настроить про это все есть в документации. Я же просто хочу остановится на том почему это должен быть именно influxdb :)
Influxdb (www.influxdata.com) это opensource timeseries база данных, которая изначально заточена под хранение данных завязанных на время, в openhab она интегрируется максимально просто и естественно, НО дело даже не в этом а в том что данные, сохраненные опенхабом в influxdb, это автоматически и сразу отличный способ получить визуализированные данные в другом программном продукте — grafana. Вот прямо сразу и с разгону, с минимальными движениями и усилиями, вы получаете мощное средство для визуализации, анализа и изучения данных которых в случае с OH будет очень много.
Mqtt
Другая штука которая вам с вероятностью 99% понадобится при автоматизации дома это MQTT.
Википедия сообщает следующее
MQTT (англ. Message Queue Telemetry Transport) — спрощений мережевий протокол, що працює на TCP/IP. Використовується для обміну повідомленнями між пристроями за принципом видавець-підписник.
Другими словами это стандартизированный простой протокол который разработан для задач автоматизации и получения данных от железок и программных систем. С MQTT работает огромное количество продуктов — все возможные ESP прошивки, в тч под sonoff, все железки shelly. А главное все возможные самодельные железки на базе ESP чипов, я также написал пару программ для внутреннего использования которые в конечном счете данные отправляют в mqtt броккер или подписываются на него для получения данных.
Поддержка MQTT в опенхабе реализована в максимальной мере, и предусмотрена на каждом шагу, если у вас есть возможность отправить данные по MQTT вы всегда их просто и удобно сможете обработать в опенхабе.
Есть только одно НО, если одно время (2я версия) опенхаб поставлялся с встроенным броккером то в современных версиях эту возможность убрали и броккер требуется поднимать отдельно, но с другой стороны он может быть любым по вкусу.
Я, как и подавляющее большинство других пользователей опенхаба, использую броккер Eclipse Mosquitto mosquitto.org/ (да-да, те самые ребята которые пилили фреймворк под иот). Брокер легковестный, простой, в достаточной степени беспроблемный.
Есть только один нюанс на который я наступил — в дефолтном конфиге москито через какое-то время переставал принимать данные от медленных железок, лечится настройкой — stackoverflow.com/questions/49130641/mosquitto-outgoing-messages-are-being-dropped
Для приятной работы с mqtt очень целесообразно использовать один из 100500 существующих клиентов. Вам понадобится смотреть что, в каком формате, как часто отправляют разные системы, что им можно послать и т.п. штуки. Я использую Windows клиент MQQT-Explorer (https://www.microsoft.com/store/productId/9PP8SFM082WD) но это сугубо дело вкуса и “тысячи их”.
Железо
Итого, для комфортного взлета вам нужно 4 пакета — openhab, influx, grafana, mosquitto.
Все указанные пакеты на столько “родные” для опенхаба что опенхабовцы разработали специальную утилиту для пакетной установки в режиме мастера всех сразу — www.openhab.org/docs/installation/openhabian.html
Все 4 пакета работают в тч на малине и очень много людей так и использует опенхаб, поставили все на малину и погнали, НО по моему личному убеждению, производительности малины не достаточно например для большого потока данных в influx или при просмотре потом данных в графане, да и в целом малина решение ограниченное и я решил не идти по этому пути и не создавать себе приключения на ровном месте.
За несколько лет использования опенхаба я пришел к следующей схеме, которая может показаться на первый взгляд очень избыточной но на практике показала себя с самой лучшем стороны.
На eBay, за очень небольшие деньги (порядка 80 баксов), я приобрел микро ПК HP EliteDesk 800 G1 Desktop Mini, в конфигурации intel i3–4030U/8G.
Это коробочка очень миниатюрных размеров с внешним БП, которая при этом является брендовым (а значит в теории более надежным) полноценным ПК. Они бывают в разных конфигурациях но вот я нашел именно такой из соображений “до 100 баксов но живой и на приличном процессоре”. На него ставится любая ось, начиная от винды 10 и заканчивая любым линуксом.
Некоторое время (наверное около года) на этом ПК крутилась убунта с установленными пакетами опенхаба и всего нужного, в том числе того до чего еще не дошел разговор, это работало и каши не просило, но по факту оказалось что такое решение не очень удобное.
Пакеты и софт имеют свойство обновляться, выходят новые версии, новый функционал который хочется попробовать, пару раз обновления не проходили без проблем, было пару ситуаций когда обновление рас***ашивало все, и я мог потратить весь вечер на банальное восстановление работоспособности.
А потом у меня умер дешевый SSD и е-но утянул за собой все.
Это был эпик фейл который мне показал что я делаю что-то не так (см. самый первый пост серии про проблемы и надежность)
Я решил что мне нужна контейнерная виртуализация, так что-бы я мог бекапить контейнеры, поднимать их по щелчку пальцев, переключаться между версиями и вообще спать спокойно.
Я изучил разные бесплатные решения и остановился на proxmox ve (www.proxmox.com/en/), который мне показался не сильно красноглазым и с удобным веб-интерфейсом для тех кто любит “открывать окна мышкой”.
Потратив пару вечеров на чтение документации пришел к тому что по хорошему для proxmox требуется 3 физические машины в кластере, что-бы заработал HA-сервис и бекапирование автоматическое и авторазворачивание сервисов при падении физической машины. Но у меня 3х пока нет, зато был второй ПК HP Microserver Gen8 который я давно использовал как файлопомойку и бекап.
Я поднял на двух ПК proxmox, объединил их в кластер и наподнимал на них тонких контейнеров LXC под все сервисы отдельно, в том числе на файлопомойке поднял ее сервисы, но теперь конвейеризованные.
Сейчас это выглядит так:
Что мне это дало сразу:
- Все сервисы в отдельных контейнерах, все контейнеры бекапятся по расписанию
- Я могу сервисы обновлять не переживая, если обновление не взлетело — я просто откатываю контейнер до предыдущего состояния
- Я могу поднять совсем новый контейнер рядом с новой версией софта (делал так когда вышел третий опенхаб), поиграться и если вижу что все работает то — старый гашу, новый оставляю
- Контейнеры бекапятся перекрестно — первый “сервер” на второй, второй на первый. Если упадет железка или диск то восстановить будет сильно-сильно проще.
В планах — докупить еще один микродесктоп, добавить его третьим в кластер и настроить HA в proxmox
Важные нюансы:
- Самый главный нюанс, если контейнер предполагает использование USB (zwave zigbee modbus и тп) то контейнер надо поднимать сразу как “unprivileged” иначе вас ждет куча секса с правами на порт в линуксе. Переделать существующий контейнер в unprivileged в теории можно но на практике у меня получалось с вероятностью 50%.
- Контейнеры по возможности следует поднимать с alpine linux, разница по диску и памяти с ubuntu колоссальная. Но увы не все (например openhab) на alpine поднять или проблематично или невозможно, тогда по вкусу убунту/дебиан/генту…
