Home Assistant
Я уже некоторое время эксперементирую с системами автоматизации и управления умным домом. Ну как "с системами"... Если честно, я пока ищу подход (ибо полноценным использованием это никак назвать нельзя) к единственной системе - Home Assistant. Количество вопросов настолько велико, что у меня и в мыслях нет пробовать параллельно ещё какой-нибудь продукт - боюсь запутаться.
Почему именно Home Assistant
? На этот вопрос у меня нет точного ответа. Просто так сошлись звёзды[1]. В один прекрасный (?) момент я взял и установил его у себя на сервере, благо, дело это не хитрое, если, конечно, есть возможность запустить виртуальную машину, образ которой любезно предоставлен разработчиками. На сервере у меня как раз установлен VirtualBox, так что, через непродолжительное время, я наблюдал web
интерфейс этой системы автоматизации и управления умным домом у себя на экране.
Я не буду сейчас рассписывать подробно сам процесс установки и первичной настройки Home Assistant
. Возможно, когда-нибудь, я соберусь и напишу про эти процедуры отдельно. Сейчас же я хочу рассказать про то, как я направил информацию о температуре и влажности, получаемую с метеостанций La Crosse
, умеющих передавать данные в интернет, в Home Assistant
.
Метеостанции La Crosse
Немного про эти самые станции. В разное время я приобрёл две станции. Одна, La Crosse MA10006, представляет из себя набор из трёх устройств: сама станция (с монохромными дисплеем), которая измеряет температуру и влажность по месту своей установки (внутри помещения), выносной термометр с датчиком влажности, предназначенный для наружных измерений, и шлюз, который позволяет передать данные, полученные от станции, в интернет. Кстати, согласно документации, шлюз может получать данные от 50 различных устройств, что важно, так как позволяет не покупать его с каждым датчиком. Вторая, La Crosse MA10920, тоже набор, но из двух устройств: станции (с цветным дисплеем), измеряющей комнатные температуру и влажность, и выносной прибор - для измерения тех же самых параметров, только наружных. Шлюза у этой станции нет, но она умеет к нему подключаться. Так что да, мои две станции пользуются одним шлюзом из поставки La Crosse MA10006
.
Работают обе станции одинаково: они сами измеряют температуру и влажность[2] (раз в две минуты), а так же, периодически, получают "по воздуху" (то есть, без проводов) данные от своих выносных приборов (тоже раз в две минуты). Затем, с определённой частотой (но реже, чем получают информацию, в документации написано раз в шесть минут) они передают данные шлюзу (по радиоканалу), который транслирует их в интернет (шлюз по витой паре подключается к роутеру), конкретнее, на сервер Mobile Alerts
. Пользователю же остаётся только скачать мобильное приложение Mobile Alerts, настроить его на получение данных из облака от своих метеостанций и отслеживать изменения параметров практически в реальном времени (мой опыт подсказывает, что шлюз отправляет данные раз в семь минут).
Станции появились у меня до того, как я стал баловаться с Home Assistant
. И, если честно, не всё у меня было с ними гладко. Нет, обе работали, в локальном, так сказать, режиме проблем не было, но вот в интернет данные отправляла только одна станция - MA10006
. Что я только не делал, но MA10920
в мобильном приложении всегда была неактивной.
Как подружить станции и Home Assistant
Надо сказать, что с самого начала, как только у меня появилась станция MA10006
, я, как ярый приверженец self-hosted сервисов, мечтал получать данные без обращения к серверам Mobile Alerts
. Теоретически, я понимал, что это возможно, так как в настройках шлюза можно было указать адрес и порт прокси сервера. Как разработчик, я не раз использовал тот же Fiddler для отладки взаимодействия клиента с сервером, так что перехватить данные, отправляемые шлюзом, не представляло проблем. Главный вопрос заключался в расшифровке протокола взаимодействия, и вот на решение этой задачи могло уйти непредсказуемое количество времени и усилий.
К счастью, я не уникален (🙁), и мне удалось найти в интернете информацию о протоколе, огромное спасибо автору за его труды. Более того, он ещё и написал приложение, которое не только могло выступать в качестве прокси сервера, то есть, перехватывать данные, но и разбирать их, после чего ретранслировать получившийся JSON в MQTT и/или HTTP(S)
REST сервер, а сами исходные данные отдавать в облако Mobile Alerts
, по желанию, само собой. И опять же, автор не только не забросил своё детище, но и, относительно недавно, реализовал возможность запуска этого приложения в виде Docker контейнера, даже приложив разработанный файл для Docker Compose[3].
Правда, должен признаться, получив всю эту ценную информацию, я не спешил ею воспользоваться. Отчасти из-за того, что забавлялся новой игрушкой -Home Assistant
. И, в какой-то момент, у меня возник логичный вопрос - а не написал ли кто интеграцию устройств Mobile Alerts
с этой системой автоматизации и управления умным домом? И каков, как вы думаете, правильный ответ? Да, конечно, да. Есть addon
, который реализует именно то, что мне нужно - позволяет осуществлять взаимодействие Home Assistant
и Mobile Alerts
. Он основан на упомянутом чуть выше сервере, просто реализовано встраивание в программную инфраструктуру Home Assistant
.
И снова я должен сознаться, что не сразу бросился устанавливать всё это хозяйство - как всегда, не хватало знаний. Все плагины, которые я устанавливал до того, были из официального магазина, ну в крайнем случае, из магазина HACS. Там всё просто - установка одним нажатием, потом настройка. Тут же устанавливать надо было ручками, и это, какое-то время, меня ввергало в ступор. Но время шло, я, мало-помалу, набирался опыта и знаний, пока, наконец, не осознал - всё, созрел 🧐. Далее следуют шаги, в том порядке, как их осуществлял я, возможно, всё будет работать и в другой последовательности, но ...
Конечно, я опирался на описание, которое имеется в репозитории плагина, и в котором прямо указана последовательность действий, которая должна привести к желаемому результату - появлению данных о температуре и влажности в web
интерфейсе Home Assistant
:
1. install Mosquitto broker plugin
2. install this Weather Station MQTT and configure it
3. check logs addon logs
4. list MQTT broker messages to get sensor: sudo apt-get install mosquitto-clients , mosquitto_sub -t "#" -h 192.168.0.123 -u username -P password
5. add sensors to configuration.yml
Ну что, всё понятно, поехали.
MQTT брокер
Первым делом автор советует установить Mosquitto broker plugin
. Идём в магазин дополнений - у меня для этого надо на боковой панеле активизировать элемент Configuration
(1), после чего, вверху экрана выбрать Add-on Store
(2), и указать, наконец, нужный плагин (3); правда, должен отметить, что встречал упоминание о том, что этот элемент (Configuration
) есть не всегда, а у меня он есть, потому что я устанавил Home Assistant
как виртуальную машину 🤔.
Далее, следуя заветам документации плагина, жмём кнопку Install
:
Спустя непродолжительное время картинка изменится:
Жмём кнопку Start
, правда, подождать придётся подольше - в документации так и написано - наберитесь терпения, а потом гляньте, что написано в журнале. Я так и сделал:
[23:49:12] INFO: Starting mosquitto MQTT broker...
1635108552: mosquitto version 1.6.12 starting
1635108552: |-- *** auth-plug: startup
[23:49:14] INFO: Successfully send discovery information to Home Assistant.
[23:49:14] INFO: Successfully send service information to the Supervisor.
1635108552: Config loaded from /etc/mosquitto/mosquitto.conf.
1635108552: Loading plugin: /usr/share/mosquitto/auth-plug.so
1635108552: ├── Username/password checking enabled.
1635108552: ├── TLS-PSK checking enabled.
1635108552: └── Extended authentication not enabled.
1635108552: Opening ipv4 listen socket on port 1883.
1635108552: Opening ipv6 listen socket on port 1883.
1635108552: Opening websockets listen socket on port 1884.
1635108553: Warning: Mosquitto should not be run as root/administrator.
1635108553: mosquitto version 1.6.12 running
Потом я чуть-чуть изменил конфигурацию - добавил пользователя, чтобы использовать его для аутентификации клиентов (хотя в документации плагина указано, что это делать не обязательно и можно использовать пользователя (пользователей) самого Home Assistant
, тем не менее, я решил подстраховаться и создать "локального" пользователя). Для этого я перешёл на закладку Configuration
(1)
добавил пользователя, отредактировав поле Options
, после чего оно стало выглядеть так (не забудьте поменять имя и пароль на свои, если пойдёте тем же путём):
logins:
- username: mqttuser
password: 'mqttuserpassword'
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false
и перегрузил плагин (на всякий случай 😉), использовав кнопку Restart
(2).
Как я уже отмечал выше, я описываю последовательность шагов, которую проходил сам. Поэтому, идём дальше.
Плагин SAMBA Share
А дальше, по плану, у нас установка плагина для Mobile Alerts
. И тут у меня возникли некоторые сложности, ведь до сих пор я не устанавливал плагины вручную.
Я попытался добавить репозиторий (в Супервизоре
, в окне, появившемся после выбора пункта меню Репозитории
, указал нужный адрес и нажал кнопку Add
), но в ответ получил сообщение об ошибке - что-то про то, что структура не соответствует ожидаемой. Тогда я понял, что руками придётся делать вообще всё.
Для начала, нужный мне репозиторий надо было скачать к себе. К счастью, сделать это в GitHub
совсем не сложно: нажимаем на кнопку Code
(1) и, в появившемся меню, выбираем Download ZIP
(2):
После этого надо скопировать содержимое ZIP
файла в определённый каталог (если быть точным,addons
) файловой системы виртуальной машины Home Assistant
. К сожалению, при установке этой системы автоматизации и управления умным домом я не разрешил использовать SSH
, поэтому пришлось искать обходной путь. И, к счастью, это не заняло много времени - под руку подвернулся официальный плагин Samba share
, основным предназначением которого и является предоставление доступа к файловой системе Home Assistant
.
Установка этого официального плагина никаких сложностей не представляет. Если честно, я даже конфигурацию не менял, за исключением имени и пароля пользователя:
workgroup: WORKGROUP
username: USER_NAME
password: USER_PASSWORD
allow_hosts:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- fe80::/10
veto_files:
- "._*"
- ".DS_Store"
- Thumbs.db
compatibility_mode: false
Кроме username
и password
кому-то, возможно, придётся ещё отредактировать и allow_hosts
- это перечисление сетей (в нотации CIDR), из которых будет разрешён доступ к каталогам Home Assistant
.
Если всё настроено правильно (а у меня так и было 😉), то, после запуска плагина, получаем доступ к следующим каталогам:
addons
- каталог, в котором размещаются локальные плагины.backup
- каталог для резервных копий.config
- каталог для конфигурационных файловHome Assistant
.media
- каталог для локальных медиа файлов.share
- каталог для пользовательских данных, которые совместно используются и плагинами иHome Assistant
.ssl
- каталог для пользовательскихSSL
сертификатов.
Плагин Weather Station MQTT
С точки зрения установки плагина работы с Mobile Alerts
меня, конечно же, больше всего интересовал каталог addons
- именно в него я и скопировал содержимое скачанного ранее ZIP
архива с плагином (грубо говоря, разархивировал плагин в этот каталог). В результате, в каталоге addons
появился подкаталог с именем weather_station_mqtt-master
и теперь надо было рашать задачу его установки и запуска.
Для достижения этой цели я обновил закладку Add-on Store
(2) экрана Configurator
(1), для чего открыл меню (3) и выбрал пункт Reload
(4), после чего появился раздел с названием Local add-ons
(5), в котором был представлен единственный (пока?) плагин Weather Station MQTT
(6).
Его надо установить и запустить - делается это стандартным способом: для установки используется кнопка Install
, после чего появится кнока Start
, которую и следует использовать для запуска плагина. Но перед запуском, я, пользуясь доступом к подкаталогу addons/weather_station_mqtt-master
(зря, что ль, Samba share addon
устанавливал?!) отредактировал файл config.json
. На самом деле, настройку можно произвести и из web
интерфейса плагина, воспользовавшись закладкой Configuration
, но я... почему-то сделал это так, как сделал - при помощи Total Commander
и Notepad
-а.
Первоначально файл addons/weather_station_mqtt-master/config.json
имел вот такой вид:
{
"name": "Weather Station MQTT",
"version": "0.1",
"slug": "weather_station_mqtt",
"url": "https://github.com/jakubonty/weather_station_mqtt",
"description": "Port of maserver: https://github.com/sarnau/MMMMobileAlerts/tree/master/maserver",
"arch": ["armhf", "armv7", "aarch64", "amd64", "i386"],
"startup": "services",
"boot": "auto",
"schema": {
"localIPv4Address": "str",
"gatewayIPv4Address": "str",
"mqtt": "str",
"mqtt_home": "str",
"mqtt_username": "str",
"mqtt_password": "str",
"logfile": "str",
"logGatewayInfo": "bool",
"proxyServerPort": "int",
"mobileAlertsCloudForward": "bool"
},
"ports": {
"8080/tcp": 8080,
"8080/udp": 8080,
"8003/udp": 8003
},
"options": {
"localIPv4Address": "192.168.0.123",
"gatewayIPv4Address": "192.168.0.126",
"mqtt": "mqtt://192.168.0.123",
"mqtt_home": "MobileAlerts/",
"mqtt_username": "",
"mqtt_password": "",
"logfile": "./MobileAlerts.log",
"logGatewayInfo": true,
"proxyServerPort": 8080,
"mobileAlertsCloudForward": true
}
}
Я достаточно быстро сообразил, что изменять надо только объект (это же у нас JSON
) options
, а конкретно:
localIPv4Address
- локальныйIP
адрес хоста (у меня это виртуальная машина), на котором установленHome Assistant
gatewayIPv4Address
- локальныйIP
адрес шлюзаmqtt
- локальныйIP
адрес хоста, на котором установленMQTT
сервер, с которым мы хотим взаимодействовать, этот адрес совпадает с локальным адресом хоста, на котором работаетHome Assistant
, ведь именно там у нас запущен плагинMQTT broker
mqtt_username
- имя пользователя для аутентификации вMQTT
брокере, понятно, что оно должно совпадать с именем, которое я указал в конфигурации при настройке плагинаMQTT broker
mqtt_password
- пароль для аутентификации вMQTT
брокере, и да, он должен совпадать с тем, что я задал при настройке плагинаMQTT broker
.
Я советую не отключать журналирование (параметр logfile
должен иметь значение, я его не менял), по крайней мере, пока не будут настроены сенсоры. Если вдруг есть желание перестать передавать данные в облако Mobile Alerts
, то надо для параметра mobileAlertsCloudForward
установить значение false
. И ещё один параметр, который может потребовать корректировки, это proxyServerPort
: я его не менял, но если у вас этот порт (8080
) занят, то вам придётся указать какой-нибудь другой порт. Скорее всего, в этом случае потребуется изменить ещё и объект ports
, описывающий, как я понимаю, разрешённые для использования порты, но это лишь предположение - сам я не проверял, но, если у вас что-то не заработает после правки proxyServerPort
, имейте это в виду.
После сохранения изменений в конфигурационном файле я, наконец, запустил плагин. Но этого, конечно, мало. Плагин должен получать данные от шлюза, а для этого надо настроить уже сам шлюз. Шлюз-то я уже настраивал, но то было для передачи данных в облако Mobile Alerts
. Сейчас же конфигурацию нужно поменять так, чтобы использовать прокси сервер, реализованный в установленном нами плагине. Сделать это можно при помощи мобильного приложения Mobile-Alerts
для Android
[4]. Правда, есть один нюанс - мобильное устройство, на котором запускается программа, и шлюз должны находиться в одной сети, иначе программа просто не сможет обнаружить шлюз (для этого используется UDP
порт 8003
).
Настройка шлюза Mobile Alerts
Итак, если мобильное устройство и шлюз находятся в одной сети, то первым делом надо войти в настройки программы Mobile Alerts
, для чего нажать на пиктограмму в виде шестерёнки:
Список параметров, которые можно настраивать достаточно велик, в нём надо найти элемент для настройки шлюза, а потом указать в списке нужный шлюз (у меня шлюз один, поэтому проблем с выбором нет 😉):
Наконец-то перед нами параметры нашего шлюза:
Что тут важно. Первое, обратите внимание, что у меня включён DHCP
(1). Это делает бесполезными значения в полях IP
, Netmask
, Gateway
и DNS
, так как шлюз получает все эти данные от DHCP
сервера, в качестве которого выступает мой роутер. Вы можете отключить использование DHCP
и задать эти параметры вручную, то есть, присвоить шлюзу статический адрес. Достаточно часто так и поступают - иметь постоянный адрес для шлюза удобнее, чем всё время меняющийся, но мой DHCP
сервер настроен так, чтобы выдавать этому устройству всегда один и тот же адрес - тот же результат, только полученный другим путём.
Второе - включено использование прокси сервера (2) и указан его IP
адрес. Именно эта настройка, в совокупности с указанием порта прокси сервера (3), заставляет шлюз отправлять данные через нужный мне промежучный прокси сервер, в качестве которого выступает работающий плагин Weather Station MQTT
. Как, наверное, ясно, указанные IP
адрес и порт должны совпадать со значениями параметров плагина localIPv4Address
и proxyServerPort
соответственно (то есть, указывать на хост, на котором установлен и работает Home Assistant
с плагином Weather Station MQTT
, и на порт, который используется плагином для проксирования).
Третье - актуальный IP
адрес шлюза (4). Если вы настроили статический адрес шлюза, вы его знаете и указываете его везде, где нужно, в частности, в настройке gatewayIPv4Address
плагина. Если у вас, как у меня, используется DHCP
сервер, то именно он выдает адрес шлюзу, и этот адрес и фигурирует в качестве актуального. Опять же, его и надо использовать в качестве значения параметра gatewayIPv4Address
плагина.
И вот ещё что... Если вы что-то изменили (а я, например, изменил настройку для прокси сервера), то без кнопки Set
(5) не обойтись.
Взаимодействие шлюза и плагина
После того, как настройки шлюза изменены, установленный нами ранее плагин Weather Station MQTT
должен начать получать от него данные. И проверить мы это сможем на закладке Log
web
интерфейса плагина. Чтобы попасть в web
интерфейс плагина в интерфейсе Configurator
(1) выбираем закладку Dashboard
, затем, в появившемся списке, нужный нам плагин - Weather Station MQTT
(3), и, наконец, в уже появившемся интерфейсе работающего плагина выбираем закладку Log
(4):
Главное, что я высмотрел в логе плагина, были строчки типа:
undefined MobileAlerts/07XXXXXXXXXX/json {"in":{"temperature":[15.7,15.6],"humidity":[45,45]},"out":{"temperature":[9.3,9.2],"humidity":[92,92]},"id":"07XXXXXXXXXX","t":"2021-10-28T09:18:16.000Z","offline":false}
undefined MobileAlerts/07YYYYYYYYYY/json {"in":{"temperature":[17.1,17],"humidity":[41,41]},"out":{"temperature":[14.9,14.9],"humidity":[45,45]},"id":"07YYYYYYYYYY","t":"2021-10-28T09:18:41.000Z","offline":false}
Эти строки журнала и содержат данные, передаваемые шлюзом в облако Mobile Alerts
, перехваченные, дешифрованные и преобразованные в JSON
плагином. Помимо значений температуры и влажности, в этих данных есть ещё один очень важный параметр. Я немного подредактировал его значения, так что, в приведённом примере, они выглядят как 07XXXXXXXXXX
и 07YYYYYYYYYY
. Почему, параметр важен? Во-первых, параметр этот - уникальный идентификатор устройства (id
), которое передаёт данные шлюзу для последующей передачи в облако Mobile Alerts
. Во-вторых, их два, так как у меня две метеостанции. В-третьих, именно на эти идентификаторы можно (и надо) будет опереться, когда будем описывать сенсоры. Ну и, в-четвёртых, я, наконец, понял, почему MA10920 не передавала данные в облако и/или они не отражались в мобильном приложении Mobile Alerts
.
Проблема с этой станцией была в том, что её уникальный код, передаваемый шлюзу (и далее в облако), и код, который я использовал, регистрируя станцию в мобильном приложении, различались!!! Я не знаю, как так получилось - я добавлял станцию в приложение, отсканировав QR
код, приклеенный на саму станцию. Этот код совпал с идентификатором в документах к станции, но... не совпал с тем, что станция передавала о себе в эфир. Мне не очень интересно, чья эта вина, но очень радостно, что ситуация благополучно разрешилась.
Плагин File editor
Итак. Плагин данные получает, теперь надо их отобразить. Для этого, как я понимаю, надо дать знать Home Assistant
, что я хочу вот эти вот данные вывести. Я пока не гонюсь за красотой пользовательского интерфейса, поэтому просто делаю то, что советует автор плагина - добавляю описание сенсоров в конфигурационный файл Home Assistant
- configuration.yaml
.
И тут встаёт вопрос: а как это сделать? Можно пойти уже проторенной дорожкой и непосредственно отредактировать нужный файл: SAMBA
, файловый менеджер, текстовый редактор (получилось почти "Небо. Самолёт. Девушка" 🤣). Но я побоялся: одно дело - курочить настройку ещё не используемого плагина, а другое - поломать ненароком основной конфигурационный файл всей системы. Поэтому я спросил у ясеня Гугла, как это (редактировать конфигурацию Home Assistant
) правильно делать. Оказалось, ответ есть в начальной документации Home Assistant
. Почитав, я решил попробовать воспользоваться официальным плагином File Editor
:
Установка и запуск этого плагина ничем особенным не отличается от установки и запуска уже рассмотренных плагинов (и многих, многих других) - всё те же кнопки Install
и Start
. Но у этого, после запуска, есть пара операций, которые, скажем так, не совсем обычны. Это OPEN WEB UI
(1) и Show in sidebar
(2). Включение последнего приводит к появлению в боковой панели нового элемента - File editor
(3):
Использование кнопки OPEN WEB UI
и элемента боковой панели File editor
приводят к одному и тому же результату - появлению текстового редактора:
На картинке показан уже открытый с помощью File editor
файл config/configuration.yaml
.
Мои впечатления от использования плагина следующие: текст редактировать можно, но... надо чаще сохранять правки. Дело в том, что интерфейс Home Assistant
время от времени перерисовывается - видимо, есть какая-то периодическая задача, связанная с обновлением того, что выведено на экран (если честно, я пока не разбирался). Так вот, если вы изменили содержимое файла и обновление интерфейса произошло, а вы не сохранили осуществлённые правки, то они (правки) будут потеряны.
Скорее всего, это проблема не самого плагина, но от этого не легче. Уже позже, я наткнулся в более полной документации на упоминание другого плагина - Visual Studio Code Add-on
. Не знаю, будет ли он себя вести подобным образом, или нет - пока не устанавливал его и не использовал. Но в документации упоминаются всякие "вкусняшки" типа автоматической подстановки и проверки корректности "на лету", так что, вероятно, стоит попробовать. Сейчас же, я, после правки файла File editor
-ом, проверяю правильность полученной конфигурации при помощи специальной функции проверки Check configuration
(3) на закладке Server Controls
(2) в web
интерфейсе Configuration
(1):
Если проверка прошла успешно, то для того, чтобы изменения в файле configuration.yaml
вступили в силу, как правило, необходимо перегрузить Home Assistant
, что я делаю при помощи кнопки Restart
(4) на той же закладке. Ну и понятно, что придётся подождать какое-то время, прежде чем увидеть результат произведённых изменений - серверу требуется время на перезагрузку.
Описание сенсоров
Вернёмся к сути правки. В документации плагина приведён пример, как можно описать сенсор:
sensor:
- platform: mqtt
name: bathroom_humidity
state_topic: MobileAlerts/1148a76fa501/json
unit_of_measurement: '%'
value_template: "{{value_json.humidity[0]}}"
Если честно, я не знаю, какой сенсор описывает этот пример (хотя ID11
есть в описании устройств Mobile Alerts
), но данные, приходящие в моём случае, имеют ряд особенностей. В частности, приходит информация о температуре (temperature
) и влажности (humidity
) как для внутреннего датчика (in
), так и для внешнего (out
), причём данные эти (и для температуры и для влажности) представляют из себя массив двух значений.
Из документации, описывающий протокол взаимодействия шлюза с облаком, становится ясным, что первое значение в массиве - текущее значение параметра (температуры или влажности), а второе - предыдущее значение. Мне интересно текущее значение, поэтому я должен использовать первый элемент массива (индекс первого элемента - 0
, соответственно, элемент массива указывается как [0]
, как и в приведённом автором плагина примере).
Далее, массивы значений влажности и температуры принадлежат объектам с именами in
и out
, поэтому доставать я их должен немного по другому: если автор плагина указывает значение как {{value_json.humidity[0]}}
, то я должен ещё указать, значение какого датчика меня интересует, поэтому, в моём случае, получение значения будет выглядеть {{value_json.in.humidity[0]}}
для внутреннего датчика и {{value_json.out.humidity[0]}}
для внешнего. Для температуры всё указывается по тем же правилам: {{value_json.in.temperature[0]}}
и {{value_json.out.temperature[0]}}
.
Сенсоров у меня получается восемь:
- станция
MA10006
:- внутренний датчик:
- сенсор температуры (1)
- сенсор влажности (2)
- внешний датчик:
- сенсор температуры (3)
- сенсор влажности (4)
- внутренний датчик:
- станция
MA10920
:- внутренний датчик:
- сенсор температуры (5)
- сенсор влажности (6)
- внешний датчик:
- сенсор температуры (7)
- сенсор влажности (8)
- внутренний датчик:
Платформа (параметр platform
) в моём случае, такая же, как и в примере - mqtt
, название каждого сенсора (параметр name
) я задам, исходя из места установки датчика и того, что этот сенсор отображает (влажность или температуру), что касается единиц измерения (параметр unit_of_measurement
), то влажность измеряется в процентах (%
) а температура - в градсах Цельсия (°C
), ну и как получить значения для сенсоров (параметр value_template
) я уже описал чуть выше. Осталось выяснить, что писать для параметраstate_topic
.
Тут тоже всё достаточно просто: в примере указано значение MobileAlerts/1148a76fa501/json
, где MobileAlerts/
- значение параметра mqtt_home
из настройки плагина, я это значение не менял, поэтому у меня будет также. Далее следует, как можно догадаться, уникальный идентификатор датчика, а в моём случае - станции[5], я их знаю (теперь 😊) для обеих станций. Ну и поледняя часть значения (json
), скорее всего, указывает на формат данных и в моём случае не меняется. Таким образом, получаем значение MobileAlerts/07XXXXXXXXXX/json
для сенсоров, свзанных со станцией MA10006
, и MobileAlerts/07YYYYYYYYYY/json
для сенсоров, свзанных со станцией MA10920
.
Подводя итог под всем вышесказанным получаем примерно такой отрывок, который надо вписать в файл configuration.yaml
:
sensor:
- platform: mqtt
name: место_1_влажность
state_topic: MobileAlerts/07XXXXXXXXXX/json
unit_of_measurement: '%'
value_template: "{{value_json.in.humidity[0]}}"
- platform: mqtt
name: место_1_температура
state_topic: MobileAlerts/07XXXXXXXXXX/json
unit_of_measurement: '°C'
value_template: "{{value_json.in.temperature[0]}}"
- platform: mqtt
name: место_2_влажность
state_topic: MobileAlerts/07XXXXXXXXXX/json
unit_of_measurement: '%'
value_template: "{{value_json.out.humidity[0]}}"
- platform: mqtt
name: место_2_температура
state_topic: MobileAlerts/07XXXXXXXXXX/json
unit_of_measurement: '°C'
value_template: "{{value_json.out.temperature[0]}}"
- platform: mqtt
name: место_3_влажность
state_topic: MobileAlerts/07YYYYYYYYYY/json
unit_of_measurement: '%'
value_template: "{{value_json.in.humidity[0]}}"
- platform: mqtt
name: место_3_температура
state_topic: MobileAlerts/07YYYYYYYYYY/json
unit_of_measurement: '°C'
value_template: "{{value_json.in.temperature[0]}}"
- platform: mqtt
name: место_4_влажность
state_topic: MobileAlerts/07YYYYYYYYYY/json
unit_of_measurement: '%'
value_template: "{{value_json.out.humidity[0]}}"
- platform: mqtt
name: место_4_температура
state_topic: MobileAlerts/07YYYYYYYYYY/json
unit_of_measurement: '°C'
value_template: "{{value_json.out.temperature[0]}}"
Пользуясь плагином File editor
вносим эти правки, проверяем конфигурацию и перегружаем сервер.
Интерграция с MQTT брокером
Если честно, после перезагрузки я ожидал увидеть... хоть что-то, но - ничего. И это, на самом деле, не удивительно. Мало завести сенсоры, надо ещё наполнить их содержанием. Да, я установил Mosquitto broker
плагин, но для того, чтобы его смог использовать Home Assistant
, надо установить ещё и соответствующую интеграцию. Об этом написано в документации плагина, но я, пока, этого не сделал. К счастью, установить интеграцию совсем не сложно: После установки плагина надо зайти в интерфейс Configurftion
(1) и выбрать элемент Integrations
(2):
В появившемся интерфейсе интеграция с MQTT
брокером будет "подсвечена".
Надо воспользоваться кнопкой Configure
, после чего, в появившемся окне, включить (по желанию) опцию, разрешающую обнаружение MQTT
, и нажать кнопку Submit
. И вот уже после проделанных манипуляций получаем примерно такую картинку:
Итоги (промежуточные)
Подведём небольшой итог. Для начала - плюсы. В общем, я добился того, чего хотел - вывел данные, получаемые от метеостанций, в Home Assistant
в виде сенсоров, и теперь, опираясь на значения этих сенсоров, можно построить какие-нибудь автоматизации. К большому плюсу можно отнести то, что, в процессе, я разобрался с отсутствием данных от одной из станций в облаке Mobile Alerts
. Ну и полученные знания и опыт - просто бесценны 😎.
Из минусов стоит отметить, что теперь получение данных от станций зависит от работоспособности прокси, а точнее, плагина Weather Station MQTT
. У меня уже была ситуация, когда данные никуда не приходили несколько часов: то ли я случайно отключил плагин, пока писал эту статью и делал снимки экранов, то ли он сам отключился в результате сбоя. Пока я включил режим плагина Watchdog
, чтобы, по возможности, поддерживать его в работающем состоянии.
Ну и немного о планах: есть у меня желание повозиться с автоматизациями, пользовательским интерфейсом и, наверное, отказаться от облака Mobile Alerts
, ведь self-hosted - наше всё 😎! Вот такие дела...
Конечно же нет, но об этом - в другой раз ↩︎
Они измеряют ещё и давление, но данных этих никуда не передают, только отображают ↩︎
Надо сказать, что, изначально, именно отсутствие возможности запуска из Docker останавливало меня - очень не хотелось ставить нужное ПО руками - обленился я 😏 ↩︎
Может, можно использовать и приложение для
IOS
, но у меня нет "яблочных" устройств, поэтому утверждать не могу. ↩︎Небольшое отступление: именно из-за того, что идентификатор присвоен комплекту в целом, то есть сразу двум датчикам, внутреннему и внешнему, станция не поддерживает подключение дополнительных датчиков - она просто не сможет передать их данные. ↩︎