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 как виртуальную машину 🤔.

Вот он, Mosquitto broker addon

Далее, следуя заветам документации плагина, жмём кнопку 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.

Плагин Samba share

Установка этого официального плагина никаких сложностей не представляет. Если честно, я даже конфигурацию не менял, за исключением имени и пароля пользователя:

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).

Плагин Weather Station MQTT

Его надо установить и запустить - делается это стандартным способом: для установки используется кнопка 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):

Интерфейс Configurator Интерфейс плагина Weather Station MQTT

Главное, что я высмотрел в логе плагина, были строчки типа:

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 код, приклеенный на саму станцию. Этот код совпал с идентификатором в документах к станции, но... не совпал с тем, что станция передавала о себе в эфир. Мне не очень интересно, чья эта вина, но очень радостно, что ситуация благополучно разрешилась.

Станция MA10920 не передаёт данные
MA10920 с исправленным ID передаёт данные

Плагин File editor

Итак. Плагин данные получает, теперь надо их отобразить. Для этого, как я понимаю, надо дать знать Home Assistant, что я хочу вот эти вот данные вывести. Я пока не гонюсь за красотой пользовательского интерфейса, поэтому просто делаю то, что советует автор плагина - добавляю описание сенсоров в конфигурационный файл Home Assistant - configuration.yaml.

И тут встаёт вопрос: а как это сделать? Можно пойти уже проторенной дорожкой и непосредственно отредактировать нужный файл: SAMBA, файловый менеджер, текстовый редактор (получилось почти "Небо. Самолёт. Девушка" 🤣). Но я побоялся: одно дело - курочить настройку ещё не используемого плагина, а другое - поломать ненароком основной конфигурационный файл всей системы. Поэтому я спросил у ясеня Гугла, как это (редактировать конфигурацию Home Assistant) правильно делать. Оказалось, ответ есть в начальной документации Home Assistant. Почитав, я решил попробовать воспользоваться официальным плагином File Editor:

Плагин File Editor

Установка и запуск этого плагина ничем особенным не отличается от установки и запуска уже рассмотренных плагинов (и многих, многих других) - всё те же кнопки Install и Start. Но у этого, после запуска, есть пара операций, которые, скажем так, не совсем обычны. Это OPEN WEB UI (1) и Show in sidebar (2). Включение последнего приводит к появлению в боковой панели нового элемента - File editor (3):

Интерфейс плагина File Editor

Использование кнопки OPEN WEB UI и элемента боковой панели File editor приводят к одному и тому же результату - появлению текстового редактора:

Редактирование файла при помощи 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):

Редактирование файла при помощи File Editor

Если проверка прошла успешно, то для того, чтобы изменения в файле 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 брокером будет "подсвечена".

Интерграция MQTT

Надо воспользоваться кнопкой Configure, после чего, в появившемся окне, включить (по желанию) опцию, разрешающую обнаружение MQTT, и нажать кнопку Submit. И вот уже после проделанных манипуляций получаем примерно такую картинку:

Метеостанции, встроенные в Home Assistant

Итоги (промежуточные)

Подведём небольшой итог. Для начала - плюсы. В общем, я добился того, чего хотел - вывел данные, получаемые от метеостанций, в Home Assistant в виде сенсоров, и теперь, опираясь на значения этих сенсоров, можно построить какие-нибудь автоматизации. К большому плюсу можно отнести то, что, в процессе, я разобрался с отсутствием данных от одной из станций в облаке Mobile Alerts. Ну и полученные знания и опыт - просто бесценны 😎.

Из минусов стоит отметить, что теперь получение данных от станций зависит от работоспособности прокси, а точнее, плагина Weather Station MQTT. У меня уже была ситуация, когда данные никуда не приходили несколько часов: то ли я случайно отключил плагин, пока писал эту статью и делал снимки экранов, то ли он сам отключился в результате сбоя. Пока я включил режим плагина Watchdog, чтобы, по возможности, поддерживать его в работающем состоянии.

Ну и немного о планах: есть у меня желание повозиться с автоматизациями, пользовательским интерфейсом и, наверное, отказаться от облака Mobile Alerts, ведь self-hosted - наше всё 😎! Вот такие дела...


  1. Конечно же нет, но об этом - в другой раз ↩︎

  2. Они измеряют ещё и давление, но данных этих никуда не передают, только отображают ↩︎

  3. Надо сказать, что, изначально, именно отсутствие возможности запуска из Docker останавливало меня - очень не хотелось ставить нужное ПО руками - обленился я 😏 ↩︎

  4. Может, можно использовать и приложение для IOS, но у меня нет "яблочных" устройств, поэтому утверждать не могу. ↩︎

  5. Небольшое отступление: именно из-за того, что идентификатор присвоен комплекту в целом, то есть сразу двум датчикам, внутреннему и внешнему, станция не поддерживает подключение дополнительных датчиков - она просто не сможет передать их данные. ↩︎