Интегрируем метеостанцию Ecowitt в Spruthub

Началось

Выбравшись жить в загородный и проведя в него нормальный, проводной интернет, появилось непреодолимое желание знать точную температуру на улице. И не датчиком "за окном", показания которого искажаются теплопотерями от дома, а чем-то отдельно стоящим. На глаза попалась метеостанция Netatmo, которая и была приобретена. А потом мне захотелось знать о ветре и дожде, и соответствующие модули были докуплены. А потом Netatmo отключила доступ к своим серверам, и всё это оборудование превратилось почти в тыкву. Однако, метеостанция уже вошла в мою каждодневную жизнь, и мне очень захотелось продолжать получать информацию о погоде рядом с моим домом. Снова бродя по интернету я натолкнулся на упоминание об интересной китайской метостанции Ecowitt. Заинтересовавшись, я изучил предлагаемый ассортимент, был удивлён разнообразию доступных модулей, и заказал себе сначала один из комплектов, а затем и дополнительный модуль. 

Wittboy

Выбранный мной комплект состоит из базовой станции GW2001 (встроенный софт говорит о модели GW2000, но скорее всего это минимальное развитие линейки) и уличного модуля WS90, гордо описываемого 7-в-одном. Базовая станция включает в себя датчики температуры и влажности для измерения таковых в помещении, а также датчики атмосферного давления (которое обычно несильно отличается от уличного). Станция принимает сигнал по радиоканалу от выносных модулей, отправляет данные на сервера компании или указанные независимые сервисы (вроде openweathermap), а также предоставляет локальный интерфейс. Подключение к интернету может осуществляться по WiFi (тьфу на него) или по проводному Ethernet. Собственно, данная модель и была выбрана за наличие проводного подключения. Встроенный экран в данной модели отсутствует. В линейке производителя присутствуют и другие варианты базовых станций. Например, есть базовая станция с экраном и WiFi. Так что каждый сможет подобрать что-то своё. Уличный модуль позволяет фиксировать температуру, влажность, освещённость, ультрафиолетовое излучение (в виде индекса UVI), направление и силу ветра, а также интенсивность осадков. Ультразвуковым (без движущихся частей) анемометром удивить сложно - такой же был у Netatmo. А вот пьезоэлектрический датчик дождя выглядит весьма перспективно. Этот датчик позволяет определять наличие и интенсивность дождя, не пропуская воду внутрь датчика, и не имеет движущихся частей. В целом это означает (ну, во всяком случае, очень на это надеюсь, а так - первая зима покажет) отсутствие необходимости убирать датчик осадков на зиму - как это мне приходилось делать с NetAtmo. Также в число интересных особенностей данного модуля входит фотоэлемент, который обеспечивает электропитание, в дополнение к батарейкам. Конечно, продолжительность светового дня в Подмосковье осенью и зимой вряд ли позволит работать только от солнца, но как решение для продления срока службы батареек - вполне себе. И ещё датчики анемометра снабжены нагревательным элементом (требующим дополнительного сетевого питания) для разморозки в зимнее время. Увы, так и не собрался проложить эту линию в этом сезоне, так что оценить предстоящей зимой не смогу. Ecowitt по сути представляет собой отдельную экосистему, которая позволяет подключать дополнительные модули, которых в ассортименте заметное количество. Например, я приобрёл дополнительный модуль - грозоотметчик.

Интегрируем в умный дом

К моменту появления Ecowitt у меня уже стоял Sprut.hub, в который уже понемногу проникали разные полезные в хозяйстве автоматизации. Поэтому вопрос об интеграции встал практически сразу. Для чего интегрировать метеостанцию в умный дом? Ну, ради повышения его интеллекта, конечно же! Из очевидного - уличную температуру можно использовать для компенсации уличной температуры (КУТ) в системе отопления. Ту же температуру и влажность (а можно ещё и прогноз добавить) - для управления обогревом водостоков, ступеней и дорожек. Датчик уличной освещенности - для управления уличным освещением. А может быть, и не только уличным, и не только освещением. Датчик дождя может быть использован для управления системами полива. Датчик атмосферного давления... нет, не знаю... наверняка и для него можно что-то придумать, как и для анемометра. В общем, если есть метеостанция - её надо интегрировать. Гугление позволяет найти различные готовые решения по интеграции ecowitt в home assistant, либо в другие системы по MQTT. Однако, поскольку имеющийся у меня Spruthub.CE не позволяет ставить дополнительный софт, а добавлять ещё дополнительный сервер мне на данном этапе не хочется, готовые варианты отпали. Потратив пару недель получилось сделать собственный вариант интеграции исключительно средствами Sprut.Hub. Я постарался сделать решение максимально простым для использования максимально широкой массой пользователей. Так что сначала - инструкция по установке и использованию, а ниже я расскажу подробнее о своём опыте в написании этой интеграции.

Первым шагом вам нужно изучить инструкцию к вашему домашнему роутеру и сделать IP адрес базовой станции неизменяемым. Разные производители делают это по-разному. Ключевые слова, которые нужно искать - DHCP, Lease, Reservation. Скриншот со своего устройства не прикладываю, ибо если у вас Mikrotik, вы и без меня справитесь. Запомните IP адрес метеостанции - он нам пригодится в дальнейшем.

Второе необходимое действие - обновить прошивку и настроить единицы измерения на метеостанции. Я не стал заморачиваться пересчётом единицы измерения (с одним мелким исключением), решив, что у нас обычно температура измеряется в градусах Цельсия, освещённость - в люксах, а давление - в миллиметрах ртутного столба. Так что вам необходимо настроить единицы измерения аналогично. Это можно сделать либо в приложении, либо в браузере, по IP адресу вашей метеостанции, где предусмотрен вполне удобный интерфейс для этого: http://x.xx.xxx.xxxx/unitSettings.html

Настройка единиц измерения

Что ж, подготовительная работа сделана, и теперь можно перейти непосредственно к интеграции в Sprut.Hub. Следующая часть самая болезненная, т.к. ручная, и если вы где-то ошиблись или что-то забыли, то её придётся делать с нуля. Это добавление виртуального устройства и сервисов. К сожалению, возможность изменения виртуального устройства после его создания в Sprut.Hub отсутствует, как и возможность создания по внешнему шаблону (во всяком случае, на момент написания этой статьи). Поэтому - извините, но дальше придётся вручную создать виртуальное устройство, и к нему привязать указанные ниже сервисы, с указанными характеристиками и названиями. Названия и типы сервисов должны соответствовать указанным в таблице. Также, как и включаемые характеристики сервисов. Впрочем, названия можно менять и позднее, чего не скажешь про сами сервисы и характеристики.

Обязательный сервис, на самом деле, один. Это Параметр с гордым названием IP адрес. Без него скрипты интеграции работать не смогут. Остальные вы можете создавать или не создавать на своё усмотрение - скрипт просто пропустит соответствующие части, если не найдёт нужный сервис (правда, оговорюсь, что я целенаправленно такое не тестировал). Также рекомендую после создания виртуального устройства сделать Параметр и две батареии скрытыми, чтобы они не мозолили глаз в повседневной жизни. В итоге у вас должно получиться нечто похожее на это:

Виртуальное устройство Ecowitt

Сразу зайдите в настройки кнопки и уберите ненужные двойные и долгие нажатия. Для нашего использования они не к чему.

Настройка допустимых значений для кнопки "Обновить"

Самая трудная часть позади. Дальше будет проще. Скачайте и установите глобальный скрипт. Это скрипт, который при запуске находит виртуальное устройство и все сервисы в нём, и запоминает для дальнейшего использования. Теперь скачайте и установите блочный скрипт. Задачей этого скрипта является периодический запуск скрипта, который вытаскивает данные из метеостанции и раскладывает их по сервисам виртуального устройства. По умолчанию я сделал периодичность 5 минут. Просто не вижу потребности обновлять данные чаще. Может быть, можно и реже. Вы можете сделать любую периодичность, которая вам нужна.В этот момент интеграция уже работоспособна. Осталось сделать одну маленькую вещь. Помните виртуальную кнопку? Давайте сделаем так, чтобы нажатие на неё обновляло данные с метеостанции вне расписания. К сожалению, опять вручную. Откройте блочный сценарий, и сделайте в нём вот такую модификацию:

Блочный сценарий для Ecowitt

На этом интеграция будет полностью готова. В вашем умном доме теперь доступны данные с метеостанции, которые вы можете использовать в любой автоматизации. Вы также получите уведомления (ну, если включите соответствующую настройку) о разряде батареек. А если вдруг сценарий не сможет по какой-либо причине забрать данные, то сервисы станут неактивными. Кстати, данные забираются локально, поэтому отсутствие интернета в доме не станет проблемой. Пожалуй, единственное, что требует дополнительного упоминания - это переименование сервисов. Если вам не нравятся названия, которые я указал в таблице выше в инструкции для создания, вы можете их изменить. Но после этого придётся поправить и глобальный сценарий - ведь именно по названию он находит, куда записывать данные. Соответствующие названия удобно собраны в виде констант в самом начале сценария. После внесения правок глобальный сценарий необходимо выполнить для обновления переменных. Если устройство или сервис не будут найдены, об этом появится соответствующая строка в логе, но работа интеграции продолжится, если ранее нужные сервисы были найдены. На этом всё. Если вы просто пользователь, то дальше можете не читать.

Техническое

В процессе работы над этой интеграции мне пришлось изучать сразу несколько ранее неизвестных мне направлений. Во-первых, пришлось познакомиться с новым иностранным языком - JavaScript. Это далось нелегко, хотя некоторые вещи мне, с моим родным Pascal, получилось сделать даже проще, чем ожидалось. Во-вторых, я нырнул в механизмы, которые предоставляет Sprut.Hub. И в третьих пришлось изучить API, предоставляемый Ecowitt.

Ecowitt предоставляет несколько механизмов экспорта данных. От уже встроенной передачи информации в несколько погодных сервисов, до разных API. Основной API выглядит красиво и позволяет получать любую информацию с метеостанции и подключенных к ней модулей. Судя по всему, именно через этот API и работает официальное приложение. Вот только этот API работает через сервера производителя. А значит, при пропадании интернета данные будут недоступны. Что не соответствует нашим желаниям. Второй вариант предлагает "пушить" данные с метеостанции в реальном времени при помощи некоего бинарного протокольчика. Увы, но на данном этапе открыть сокет на Sprut.Hub не представляется возможным. Да и описание протокола выглядит слабоватым и сильно непонятным. Интернет подсказал ещё один источник данных, который хотя и является недокументированным, но существует уже много версий, и изменился за это время незначительно. На самом деле, это просто массив данных, предназначенный для наполнения собственной страницы с текущими данными (http://x.xx.xxx.xxxx/liveData.html). Этот json доступен по URL http://x.xx.xxx.xxxx/get_livedata_info и его очень удобно дёргать из сценариев на Sprut.hub. Что я и сделал.

Интеграцию в Sprut.Hub, как мне кажется, можно было бы сделать проще, если бы не требовалось разделение на глобальный и блочный сценарии. Глобальные сценарии имеют ограничения, которые не позволяют изменять характеристики устройств, или создать расписание (хотя объект Cron упоминается в API). Если бы не эти ограничения, всю эту логику можно было бы упаковать в один файл. Ну и, конечно, ручное создание виртуального устройства с сервисами без возможности исправить сделанную ошибку, создаёт проблемы не только для рядового пользователя, но и для профессионального интегратора. Вот сейчас, в процессе написания статьи, мне пришла в голову идея, что, возможно, домашний и уличные блоки стоило бы сделать раздельными виртуальными устройствами - для помещения в разные комнаты. И я немного в ужасе от того, что все эти устройства мне придётся пересоздавать вручную. Хотя бы и только с целью проверить само по себе удобство такого подхода. Аналогично и с добавлением новых устройств. Предположим, я закуплю датчики влажности почвы для последующей интеграции с автополивом. Их может быть несколько штук на одной базовой станции. Покупать их я, скорее всего, буду не одновременно, а по 1-2 штуки в течение какого-то периода времени. Получается, мне придётся каждый раз пересоздавать виртуальные устройства? Или пересмотреть выбранную модель интеграции, и каждый датчик оформлять в виде отдельного виртуального устройства? Не слишком ли много получится? Очень удобен был механизм создания (и обновления) виртуальных устройство по шаблону. В этом случае пользователь мог бы легко создать или пересоздать устройство при помощи файла, написанного интегратором.

И ещё пара слов про выбранные датчики. Датчик дождя - бинарный. Дождь либо идёт, либо нет. Тут можно было выбирать и датчик касания, и выключатель, но мне показалось, что датчик дождя - прямой эквивалент датчика протечки (и может быть реализован и при помощи настоящего датчика протечки). Я так и не смог придумать, в какой сервис заносить интенсивность осадков (мм/ч) или количество осадков (мм), а дополнительные поля (options) в виртуальные сервисы Sprut.Hub добавить не позволяет. Поэтому эта информация, как и скорость ветра (м/с) не импортируется в Sprut.Hub. Аналогично и с грозоотметчиком. Можно, конечно, было вытащить количество разрядов в счётчик импульсов, но такая интеграция мне показалась притянутой за уши, и я её пропустил. В итоге от грозоотметчика импортируется только уровень батарейки - в основном с целью единого центра оповещения о разряде. Остальное, на мой взгляд, само собой разумеещееся. Для задания в скрипте характеристик, в которые нужно записывать значения, я отказался от числовых ID-констант, задаваемых пользователем, и использую поиск по названиям. Во-первых, мне показалось так более дружелюбно для обычного пользователя. Если его/её устраивают мои названия, то никакой потребности открывать и редактировать код нет. Кроме того, если вдруг придётся пересоздать виртуальное устройство, то не придётся переписывать все идентификаторы сервисов и характеристик в сценарии. Хотя код получился потяжелее, но и гибкость значительно возросла.

Код сценариев специально выкладываю на github с коварной целью вносить в него правки и улучшения, чтобы пользователь всегда мог добраться до актуальной версии.