Homeassistant

Я Community Manager и у меня есть зависимость. Ну хорошо, не зависимость, но хобби: я увлекаюсь автоматизацией собственной квартиры с помощью того, что принято теперь называть Умным Домом. Начинал я пару-тройку лет назад с чистого Apple HomeKit, затем расширил его возможности с помощью Homebridge и далее полностью погрузился в дебри HomeAssistant.

Но поскольку я Community Mananger, мне интересна та часть моего хобби, которая касается вопроса коммуникации сообщества людей, имеющих такое же увлечение, как и моё.

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

Статья также о том, как я попал в секту строителей Умных домов и что я о ней узнал. Для начальной ориентации новичков, в общем.

Предыстория

Предупреждая все возможные разговоры о целесообразности Умного Дома, скажу сразу: в настоящее время, в домашних любительских условиях, автоматизация собственного жилища действительно, всего лишь хобби для большинства участников сообщества. Причем весьма дорогостоящее хобби, которое не приносит никаких материальных выгод. Говорить об экономии расходов на тепло, электричество и воду, при использовании весьма дорогостоящих комплектующих для этой экономии, совершенно не приходится. Все это лишь ради собственного удовольствия и для создания некоторых удобств существования в личном пространстве. Новичкам, вступающим на этот путь, нужно четко себе это понимать и быть готовым к существенным расходам.

Мой путь начался с того, что в один прекрасный момент я внезапно осознал, что имеющийся в хозяйстве AppleTV 4K может служить шлюзом для построения Умного Дома на базе Apple HomeKit. Было приобретено и успешно подключено несколько HomeKit ready устройств. Все было прекрасно, стабильно, но дорого. Хотелось дальнейшего расширения, но за меньшие деньги.

И тут я сделал открытие, что существует, оказывается, множество сообществ людей, подобных мне. И что многие устройства можно делать самому и при этом ничуть не хуже, а главное, дешевле. И что вездесущая Xiaomi, со своими инкарнациями вроде Aqara и прочих, делает устройства для Умного Дома значительно менее затратные для моего кошелька.

Так, с помощью внимательного чтения и вопросов к коллективному разуму я влился в обширное и очень эффективное русскоязычное сообщество строителей Умных Домов, Бань, Дач и прочих Гаражей. Мир DIY и OpenSource решений захлестнул меня и, нужно заметить, я был к этому подготовлен. Я уверенно обращался с паяльником и имел очень долгий опыт работы с Linux. Мне было легко и приятно быть среди единомышленников.

С каждой новой итерацией своего продвижения по этому пути все новые и новые ресурсы открывались мне, с великими Гуру можно было спокойно общаться в телеграм группах практически на одном языке и порой даже осмеливаться их критиковать. Я узнал, что большинство самых ценных сообществ живет в профильных телеграм каналах, что сообщество на форуме 4PDA живет какой-то своей жизнью, что известный всем русскоговорящим умнодомщикам Спрут портал раскинул свои щупальца настолько широко, что даже проник на территорию подкастов и инстаграма, что адепты св.Квазиса повсюду и что AlexxIT, Jager, Илья Киров и Иван Бессарабов настолько же доброжелательны и приветливы в общении, насколько круты в своем профессионализме. А для владеющих английским открываются поистине бездонные кладези знаний на Reddit, YouTube и, например, официальном форуме HomeAssistant.

Опыт накапливался быстро и вместе с ним пришло понимание тем и вопросов, вызывающих наиболее горячие и часто повторяющиеся дискуссии. Опыт так же сформировал собственное мнение по этим вопросам. Давайте же их рассмотрим и обсудим.

OpenSource против готовых решений

На самом деле это не самая животрепещущая и обсуждаемая тема. В той части сообщества, в которой обитаю я, общаются люди, которые уже сделали свой выбор в пользу OpenSource решений. Но тем не менее вопрос нередко ставится ребром новичками и, как следствие, становится весьма актуальным.

На чем строить свой Умный Дом? На готовых решениях от Miija, Sonoff, Tuya, Apple, Aqara, Rubetek, Yandex, Google и прочих и прочих? Или же построить его самому на базе OpenSource решений типа HomeAssistant, NodeRed, OpenHub, IOBroker и так далее?

Тем, кто стоит перед таким выбором приходят на помощь авторитетные прожженные линуксоиды и начинают говорить о непревзойденной гибкости автоматизаций и отвязки от коварных "китайских облаков" в OpenSource решениях. Они будут говорить о том, что все будет контролироваться только лично тобой и что ты сможешь использовать почти весь доступный на рынке зоопарк устройств Умного Дома, да еще и DIY устройства. Стоит лишь купить "малинку", установить на нее Linux, потом поколдовать в командной строке, чтобы установить этот самый альтернативный Умный Дом, а потом еще потратить месяцы на настройку и понимание что вообще тут к чему.

И вот новичок, который про Linux только на уроках информатики слышал, а командную строку видел только в голливудских блокбастерах про геройских хакеров, обалдев от такого объема информации, мало ему понятной, принимает решение переплатить, но сделать свой Умный Дом легко и просто на базе существующих на рынке готовых решений. Или вообще ничего не делать. И правильно сделает, кстати.

Консьюмерские решения имеют полное право на существование, и принижать их адептов не стоит в сообществах ни в коем случае. Люди принимают решение, основываясь на собственном опыте, знаниях, ресурсах, и тащить их силком в OpenSource не нужно. Мучения таких людей, вставших на путь, на который их убедили вступить, их обескураживающие и порой наивные вопросы очень хорошо заметны, а попытки профессионалов им помочь выглядят удручающе. Но вызывают неподдельное уважение те, кто начинает с такого уровня вхождения в тему и успешно преодолевает его.

Поэтому отсюда мое наблюдение: не стоит тащить и убеждать не готовых людей. Пусть каждый будет в комфортных для него условиях его личного выбора. И выбор этот нужно уважать.

Малинка против Intel NUC, Gigabyte BRIX и прочих x86

Итак, новоявленного строителя Умного Дома затащили на темную сторону OpenSouce и перед ним встает первый из ключевых вопросов: а на что мне все это хозяйство устанавливать?

Популярность использования платформы Rapberry Pi для сервера Умного Дома я могу объяснить лишь пресловутыми "исторически сложившимися причинами", а так же, не в последнюю очередь, мощью авторитета Алекса Квазиса и его YouTube канала.

При всех своих недостатках, "малинка" остается самой популярной платформой и поныне. А недостатки у нее серьезные:

1. Использование в качестве накопителя медленной и очень ненадежной SD карты

2. Необходимость в хорошем охлаждении

3. Склонность к троттлингу при недостаточно качественно обеспеченном питании

4. Слабый встроенный Bluetooth

5. Довольно слабая производительность ARM процессора, которой, впрочем, в большинстве случаев достаточен для систем Умного Дома

6. Важная для многих необходимость в приличном корпусе

Для устранения части этих недостатков потребуется покупка SSD или eMMC накопителя, мощного корпуса-радиатора, внешнего Bluetooth донгла, корпуса вроде Argon One. Все эти дополнительные покупки приводят к значительному удорожанию вашего сервера Умного Дома на базе "малинки".

И тут на авансцену выходят опытные члены сообщества с вполне резонным вопросом: А почему бы вам сразу не купить компактное, бесшумное и быстрое решение на базе гораздо более производительных процессоров x86 с встроенным SSD диском, расширяемой памятью? Ну, например, что-нибудь подходящее по цене из обширного семейства миниатюрных компьютеров Intel NUC или Gigabyte BRIX?

В действительности цены на подобные новые минисерверы довольно высоки и далеко не каждый будет готов потратится. Но на просторах интернет барахолок, вроде Avito, вполне можно найти приличные варианты за вменяемые деньги. Я, например, купил там немного устаревшую модель Gigabyte BRIX с процессором Celeron N3000, 4GB RAM, 120GB SSD и пассивным охлаждением всего за 5 тысяч рублей. И машинка эта прекрасно работает в круглосуточном режиме с HomeAssistant на борту вот уже больше года. Некоторые домовладельцы покупают на Авито даже подержанные HP Microserver Gen8 под свой домашний сервер, на котором, кроме системы Умного Дома, работает еще и медиасервер, торрент-качалка, NAS и что-нибудь еще. Многие используют в качестве сервера Умного Дома уже имеющиеся в хозяйстве NAS от Synology или реже Qnap с поддержкой Docker. Но в этом варианте много подводных камней, которые вызывают множество вопросов и дискуссий. Этот вариант сервера, на мой взгляд, подходит только уверенным пользователям Linux с достаточно глубокими знаниями Docker.

На мой взгляд, если говорить о сервере только для Умного Дома, наиболее целесообразным вариантом сейчас является использование миникомпьютеров на базе процессоров x86 (не Atom!). Это могут быть не обязательно Intel NUC или Gigabyte BRIX, а любой подходящий на базе Celeron и выше, и желательно с пассивным охлаждением, особенно для тех, кто строит Умный Дом в городской квартире и для кого уровень шума сервера является критическим параметром. Наличие именно SSD диска не обязательно, но крайне желательно для общего быстродействия. Памяти в большинстве случаев достаточно 2-4Gb. Подключать к сети такой сервер рекомендую по более надежному Ethernet, но и по WiFi 5Ггц у многих работает вполне стабильно.

Zigbee против WiFi (BLE mesh, Zwave, Thread пока не в счет)

Теперь, когда система успешно установлена на сервер, выполнена первоначальная настройка, приходит время покупать и подключать конечные устройства Умного Дома: всевозможные датчики и исполнительные устройства.

У всех дома есть WiFi роутер и, как правило, Умный Дом начинает разрастаться за счет недорогих WiFi устройств от производителей вроде Sonoff, Yeelight, DIY устройств на базе ESP8266 и прочих. Действительно, WiFi прост, есть у всех, дополнительно что-то приобретать и настраивать не нужно. Отсюда в сообществе происходят иногда не то чтобы споры, но оживленные дискусси с основным посылом - зачем мне вообще этот ваш "зигбее" (варианты написания бывают порой очень забавными, "zig been" как-то попадался), мне и на WiFi хорошо и все отлично работает. Мне кажется это мнение происходит от недостаточно хорошего представления о преимуществах протокола Zigbee новичками. Давайте их перечислим:

• Низкое энергопотребление конечных устройств (где вы найдете WiFi датчик двери или, например, датчик движения, датчик протечки, который работал бы от батарейки годами?)

• Самоорганизующаяся Mesh сеть, в отличие от звездообразной WiFi сети, где роутер является центром звезды. Например, так выглядит моя домашняя Zigbee сеть, где хорошо видно, как устройства-роутеры (синие) являются точками подключения физически далеко расположенных устройств:

• Наличие класса конечных устройств-роутеров с постоянным питанием позволяет строить сеть на очень большой территории. Да, WiFi тоже умеет строить Mesh сети, но не с помощью исполнительных устройств-роутеров, а с помощью дополнительных WiFi роутеров подключенных в mesh сеть.

• Огромный выбор доступных устройств на рынке. На данный момент Zigbee Alliance насчитывает сотни членов, а на рынке существует тысячи разнообразных решений с заявленной поддержкой Zigbee.

• Безопасность. С 128-битным алгоритмом AES, используемым для шифрования данных и аутентификации, и тремя типами ключей, используемых для управления безопасностью, конечным пользователям не стоит беспокоиться об опасности взлома.

• Относительно низкие цены на устройства.

• Можно упомянуть еще прямой биндинг между устройствами, когда они продолжают взаимодействовать при отключении центрального координатора. Но эта фича слишком мифологична и недостаточно широко распространена на данный момент.

Лично для меня преимущества Zigbee очевидны и я строю свой Умный Дом почти полностью на этой технологии. Конечно, у меня еще есть несколько WiFi устройств, например, кондиционер управляемый WiFi USB стиком на ESP8266, датчик потребления фильтрованной воды на Wemos D1 mini, настольная лампа Yeelight. Среди активных сторонников Zigbee такой неоспоримый авторитет в сообществе, как Алекс Квазис, который в подкасте Спрута однозначно высказывался о преимуществах Zigbee перед Wifi. Кстати, кто не слышал подкаст, то рекомендую:

Если говорить о Zigbee дальше, то всплывает еще одна горячая тема: USB Zigbee стик, шлюз Xiaomi Gateway 3 (возможно перепрошитый Sonoff шлюз) или SLS использовать в качестве координатора сети Zigbee. Или еще одна, касающаяся пользователей HomeAssistant: что лучше, Zigbee2mqtt или ZHA? Это настолько объемные темы, что заслуживают отдельной статьи. Скажу лишь за себя - я за использование Zigbee USB стика в союзе с Zigbee2mqtt. В двух словах почему: стабильность, количество поддерживаемого оборудования, независимость от прихотей производителей шлюзов или SLS, при необходимости возможность самостоятельно обеспечить поддержку неподдерживаемого устройства с помощью zigbee2mqtt external converter. Но если вы уже имеете Xiaomi Gateway 3 шлюз и хотите использовать его в качестве координатора вашей Zigbee сети, а также, возможно и для BLE mesh сети, то очень рекомендую вам послушать подкаст с AlexxIT, авторитетнейшим участником сообщества и автором интеграции этого шлюза в HomeAssistant, чтобы узнать все нюансы из первых рук:

Говорить о распространенности других протоколов для Умного Дома можно, но на мой взгляд, пока рано. Отличный протокол Zwave живет своей жизнью уже очень давно, но из-за дороговизны устройств и географического разделения рабочих частот протокола мало распространен в русскоговорящем сообществе. Хотя есть пользователи очень давних реализаций Умных Домов на Vera или Homey, у которых осталось Zwave оборудование, например от Fibaro, и которые в рамках HomeAssistant, где поддержка этого протокола очень развита, успешно используют эти устройства и поныне.

Протокол BLE mesh выглядит очень многообещающим и поддерживается последними версиями шлюзов Xiaomi. Кроме того, явно заметно разделение направлений, если устройства для Умного Дома от Aqara практически все выпускаются для протокола Zigbee, то последние новинки от Xiaomi выпускаются почти исключительно для BLE mesh. И уже сейчас вполне реально активно использовать этот протокол, покупая доступные на рынке устройства.

Что касается протокола Thread, то его в последнее время стали продвигать в Apple, включив его поддержку в HomePod Mini и новой версии AppleTV. Солидные производители вроде Eve или Nanoleaf тоже стали включать поддержку Thread в своих новых устройствах. Я думаю, маркетинговая мощь Apple может продвинуть популярность этого протокола достаточно далеко и стоит не упускать из вида этот очевидный тренд.

Но пока протокол Zigbee в Умных Домах безусловно доминирует. И меня это устраивает. Я за Zigbee, как самое сбалансированное решение на рынке на данный момент.

Красивый GUI против текстовых конфигов и чистых автоматизаций

Это очень обширная тема со множеством ответвлений и нюансов. Постараюсь быть кратким и замечу, что в моем изложении она больше относится к HomeAssistant, как к системе Умного Дома, которую я использую. В целом, эта горячая тема подразделяется на следующие два больших направления:

• Как настраивать систему и писать автоматизации - через предоставленные возможности GUI или редактированием текстовых файлов конфигураций?

• Зачем заморачиваться с красивым и удобным интерфейсом, делая его похожим на пульт управления космолета? Ведь настоящий Умный Дом тот, в интерфейс которого вообще не нужно заходить - все работает через точно и тонко настроенные многочисленные автоматизации.

Начнем с первого. В последних версиях HomeAssistant тренд на уход от правки yaml конфигурационных файлов в сторону настройки всего и вся через GUI был настолько очевиден, что многие старожилы сообщества загрустили о старых добрых временах, когда все настраивалось вручную. Кроме того, в свое время весомый вклад в популяризацию правки yaml конфигов внес не раз уже упомянутый Алекс Квазис со своими видео уроками по настройке HomeAssistant. Но его продвижение этого метода дало и обратный результат. Вместо того, чтобы вникать в код его примеров и пытаться в нем разобраться, начинающие, неопытные пользователи стали просто бездумно копипастить код из его уроков и слепо следовать его рекомендациям, как истине в последней инстанции. Я уверен, что Алекс не подразумевал изначально такого эффекта, но теперь в сообществе сложился устойчивый мем "так было у Квазиса в его уроке" или "я делал все по урокам Квазиса". Опытные участники сообщества лишь саркастически ухмыляются, отсылая вопрошающих с их проблемами к чтению документации и к пониманию того, что и как они делают.

Многие не любят HomeAssistant именно из-за его формата конфигураций yaml. Жесткая требовательность к форматированию, отступам многих раздражает. Написать вручную, к примеру, такую автоматизацию света на кухне с учетом датчиков движения, датчика освещенности и времени суток с множеством условий, без серьезной подготовки и опыта очень сложно:

alias: Kitchen Lighttrigger:  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'on'  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'off'    for: '00:02:03'condition: []action:  - choose:      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '09:20'            before: '23:00'          - condition: numeric_state            entity_id: sensor.lux_kitchen_illuminance_lux            below: '23'        sequence:          - service: switch.turn_on            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center          - service: light.turn_on            data:              transition: 4              color_name: crimson            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            before: '23:40'            after: '09:20'        sequence:          - service: switch.turn_off            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center                - switch.switch_kitchen_switch_right                - switch.switch_kitchen_switch_left          - service: light.turn_off            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_on            target:              entity_id: switch.relay_switch_l2      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_off            target:              entity_id: switch.relay_switch_l2    default: []mode: single

Но с другой стороны, эту же автоматизацию можно собрать в GUI автоматизаций HomeAssistant. А в последних версиях еще и появилась возможность визуального дебага автоматизаций в GUI:

Таким образом, по этому пункту, я бы посоветовал начинающим следующее. Попробуйте совмещать оба способа при написании автоматизаций, благо интерфейс теперь это позволяет. Пробуйте составить ее через GUI, потом переключитесь в текстовый режим и поправьте что нужно в нем. Или наоборот, скопипастите готовый yaml код автоматизации и затем переключившись в режим GUI попробуйте понять логику его работы, подставьте свои нужные сущности. На мой взгляд, сочетание обоих режимов при создании автоматизаций сейчас наиболее эффективный и оптимальный подход. Также не следует забывать об очень интересной недавней фиче в автоматизациях HomeAssistant: Blueprints, или готовых шаблонах автоматизаций.

Второй пункт нашего списка касается опять HomeAssistant и настройке его интерфейса Lovelace. Да, сейчас его можно настраивать исключительно средствами интерфейса, предоставленного HomeAssistant и не думать о правке вручную файла ui-lovelace.yaml в режиме Lovelace "yaml", как было в уроках Квазиса. Но лично я предпочитаю ручную полировку интерфейса. Весь интерфейс моих дашбордов как для десктопа, так и для мобильных устройств полностью написаны вручную. Сделать два разных дашборда очень просто, достаточно в configuration.yaml прописать что-то вроде:

lovelace:  mode: yaml  resources:  - url: /hacsfiles/mini-graph-card/mini-graph-card-bundle.js    type: module  - url: /hacsfiles/mini-media-player/mini-media-player-bundle.js    type: module  - url: /hacsfiles/ha-yandex-icons/yandex-icons.js    type: module  - url: /hacsfiles/lovelace-card-mod/card-mod.js    type: module  - url: /hacsfiles/lovelace-auto-entities/auto-entities.js    type: module  - url: /hacsfiles/button-card/button-card.js    type: module  - url: /hacsfiles/vertical-stack-in-card/vertical-stack-in-card.js?v=0.4.0    type: module  - url: /hacsfiles/simple-thermostat/simple-thermostat.js    type: module  - url: /hacsfiles/simple-weather-card/simple-weather-card-bundle.js    type: module  - url: /hacsfiles/text-element/text-element.js    type: module  dashboards:    lovelace-generated: # Needs to contain a hyphen (-)      mode: yaml      filename: mobile-ui.yaml      title: Mobile UI      icon: mdi:cellphone-text      show_in_sidebar: true      require_admin: true

и уже в файле mobile-ui.yaml конфигурировать ваш отдельный Lovelace для мобилок. Для десктопа мой интерфейс сейчас выглядит примерно вот так:

Для мобильных устройств примерно так:

Ну и наконец, резонный вопрос - зачем этот пульт управления космическим кораблем, если настоящий идеальный Умный Дом не должен подразумевать ручного вмешательства, управления и контроля, а все должно работать как надо автоматически?

Скажу честно, у меня нет аргументированного ответа на этот вопрос и более того, я совершенно согласен с таким пониманием идеального Умного Дома. Но я люблю интерфейсы в который не только все удобно, но и красиво, и это для меня вопрос эстетики и эргономики. Как деревенские мастера украшают совершенно утилитарные вещи вроде ставен на окнах домов изысканной резьбой, так же и мне доставляет эстетическое и эргонометрическое удовольствие оптимизация вручную интерфейса моего Умного Дома. Кроме того, я достаточно регулярно пользуюсь мобильным приложением HomeAssistant, где мой удобный и оптимизированный мобильный дашборд весьма кстати.

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

HomeAssistant против Node Red. Или вместе с ним.

Эта тема характерна для споров между уже опытными и продвинутыми строителями Умных Домов, Бань, Дач и Сараек. Она не так остра и популярна, но написать о ней мне все же хочется. Хочется, потому, что когда-то этой теме было посвящено немало споров в уютном лампово-теплом сообществе телеграм чата Homever.

Скажу сразу, я попробовал Node Red и он мне не зашел. Визуальное создание автоматизаций перетаскиванием и связыванием каких-то прямоугольников различного назначения лично мне не показалось удобным и интуитивным. Мне гораздо проще и понятнее описывать автоматизации текстом, в yaml, в HomeAssistant. В общем, опыт с Node Red у меня небольшой, судить о нем авторитетно я не могу. Я запустил и отладил несколько флоу, но не более того.

Но тем не менее, я могу поговорить о чем спорят и говорят на эту тему в сообществе. А говорят следующее. Node Red может быть совершенно самостоятельной системой Умного Дома, с интеграцией устройств, собственным дашбордом, ну и конечно, собственными мощными автоматизациями. Также Node Red может работать в тесной связке с HomeAssistant выступая системой автоматизации для него. То есть вы подключаете устройства через HomeAssistant, который позволяет это сделать намного эффективнее, чем Node Red, и поддерживает гораздо больше интеграций для подключения огромного количества всевозможных устройств, но все автоматизации для этих подключенных устройств и сущностей вы создаете средствами подключенного Node Red.

Почему-то принято считать, что возможности и гибкость автоматизаций в Node Red значительно превосходят таковые в HomeAssistant с чем я совершенно не согласен. Я не знаю ни одного сценария автоматизации, который можно было бы реализовать в Node Red и нельзя было повторить средствами автоматизаций HomeAssistant. На этот неоднократно заданный адептам Node Red вопрос я так ни разу и не получил убедительного примера такого сценария.

Таким образом, целесообразность такой связки двух систем мне кажется избыточной и нерациональной хотя бы с точки зрения стабильности. Каждая из этих двух систем вполне самодостаточна, разве что в Node Red нет такого красивого интерфейса, как в HomeAssistant. Но это важно далеко не всем. Ну и возможности подключения огромного разнообразия устройств у Node Red значительно скромнее. Для чего нужен конгломерат двух серьезных и мощных систем, мне непонятно. Знаю пользователей таких симбиозов, которые используют подключения устройств и там и там, да еще и автоматизации создают средствами обоих систем. Представляете, какая каша из сущностей и связей там образуется? Надежность и стабильность такой связки двух систем вызывает у меня большие сомнения.

Мое мнение: максимально глубоко изучите возможности Node Red или HomeAssistant и используйте что-то одно. Каждая из этих систем в отдельности способна полностью удовлетворить все ваши требования к Умному Дому. Хотя, с другой стороны, я могу понять тех, кто имеет устройства, которые не поддерживаются в Node Red, но подключаются в HomeAssistant и он используется в качестве некоей прослойки для проброса подобных устройств в Node Red, а также, возможно, для красивых дашбордов для настенных панелей в виде вмонтированного планшета, например.

В общем, спор, какая из систем лучше совершенно не актуален. А на вопрос о том, стоит ли собирать их в симбиоз, каждый отвечает сам для себя.

Заключение

На самом деле я затронул лишь малую часть горячих тем в сообществах строителей Умных Домов. Их гораздо больше по самому широкому кругу вопросов. Например, есть популярная тема о том, что лучше и надежнее - проводное или беспроводное подключение устройств? Или тема о том, каким воспользоваться способом для настройки подключения SSL сертификатов и проброса HomeAssistant наружу в интернет.

Если вас интересует тема Умных Домов и вы готовы погрузиться в нее с головой, подписывайтесь на профильные телеграм чаты по HomeAssistant, этот, или этот. На чат обо всем, касающемся темы Zigbee. На персональный канал большого авторитета Ивана Бессарабова, где найдете кладезь полезной информации. Ну и на упомянутый выше ламповый чат сообщества Homever

Хорошо понимаю, что опытным участникам сообщества многие мои выводы могут показаться спорными и даже неверными. Но ведь для того мы и создаем сообщества, чтобы в споре и обсуждениях находить истину, не так ли?

Home Assistant - прекрасное программное решение для умного дома. У неё современный интерфейс, множество плагинов и дополнений почти на все случаи жизни. В интернете можно найти множество компонентов для самых экзотических устройств. Но чтобы начать им пользоваться, надо как следует позаботиться об аппаратной платформе. Нужно либо купить одноплатный компьютер наподобие Raspberry PI, или же использовать десктопный компьютер, который должен работать в режиме 24/7.

Но что если я скажу, что даже простой ZigBee шлюз от Xiaomi с евро-вилкой, который вставляется в розетку, может работать как хост система для Home Assistant? Он может показывать значение датчиков в веб интерфейсе, управлять светом и розетками, контролировать ZigBee сеть, проговаривать текст голосом через встроенный динамик, делать полноценную автоматизацию и всё это на скромном устройстве, которое нужно лишь воткнуть в розетку.

Немного истории

Данная статья является логическим продолжением другой статьи о том, как команда энтузиастов взломала ZigBee шлюз от Xiaomi и получила доступ к ОС Linux, которая там установлена. Когда я прочитал эту статью, у меня возникло желание попробовать повторить манипуляции, которые @lenz1986 описал в своей статье.

Это потенциально вело к получению ZigBee шлюза, который можно будет как-нибудь хакнуть, чтобы он поддерживал работу со всеми ZigBee устройствами, а не только с устройствами от Xiaomi (число которых в случае европейского региона ещё и сильно урезано). Потому я приобрёл шлюз и поспешил воспользоваться инструкцией из статьи. Я спросил у автора, насколько безопасно прошивать, и он заверил меня, что это безопасно. Я, уверенный, что новая прошивка загрузится только в оперативную память, запустил команду для прошивки системы. Оказалось, что только в оперативной памяти работает новая операционная система OpenWrt, а все разделы, которые отвечают за стоковую систему, перетёрты новой полурабочей системой (которая на тот момент даже не видела flash-память).

Так началось моё приключение, которое и привело к тому, что на данный момент шлюз может работать как универсальный контроллер для умного дома. Он работает с ZigBee, bluetooth, может быть хост-системой для программ zigbee2mqtt, node-red, Domoticz и даже Home Assistant!

Всё что описано в статье касается европейского шлюза Xiaomi версии 2 (DGNWG05LM), а также первого шлюза Aqara (ZHWG11LM).

Статья так же применима к шлюзу Aqara в аналогичном форм-факторе, за исключением того, что в нём отсутствует bluetooth модуль.

Установка операционной системы OpenWrt

Далее приведена упрощённая инструкция. Более подробная версия находится на основном сайте проекта https://openlumi.github.io/, в ней подробно описывается каждый шаг. С картинками!

Исходная система на шлюзе использует сборку через yocto и не позволяет её расширять. В дополнении, она ещё и занимает большую часть из 256-мегабайного флеш-диска.

Потому мы меняем ОС на портированную последнюю стабильную версию OpenWrt 19.07. Образ системы с веб-интерфейсом LuCI занимает 10 мегабайт.

Сейчас установка и обновление максимально упрощены, но на первом этапе требуется USB-UART адаптер и паяльник, чтобы подпаяться к консоли, получить root и запустить установку OpenWrt.

Упрощённо это выглядит так:

1. В uboot прописать загрузку в single mode

setenv bootargs "${bootargs} single rw init=/bin/bash" && boot

2. В UART-консоли надо задать пароль через passwd, а после перезагрузки уже войти в систему и запустить скрипт установки OpenWrt.

Он находится в репозитории https://github.com/openlumi/owrt-installer и прошьёт последнюю версию OpenWrt.

На этом месте провода больше не нужны и можно собрать шлюз.
Голая система OpenWrt поднимает точку доступа без пароля, чтобы можно было зайти и настроить подключение к своей WiFi сети.

Отлично, теперь у нас есть (относительно) полноценный линукс с возможностью устанавливать сторонние пакеты, но пропала главная функциональность шлюза: его возможность работать с ZigBee устройствами. Вернём же её!

Zigbee2MQTT

Zigbee2mqtt является де-факто стандартом для работы с устройствами ZigBee. Он умеет прокидывать параметры устройств и их состояние в брокер mqtt, где их уже может считывать ваша система умного дома.Мы же установим Zigbee2mqtt и MQTT брокер mosquitto прямо на шлюз.

В шлюзе установлен зигби модуль JN5169, и для неё рабочей прошивкой является прошивка zigate, которая позволяет использовать чип, как координатор сети зигби. Благодаря стараниям @G1K, в zigbee2mqtt появилась поддержка работы с zigate и сейчас, начиная с версии zigbee2mqtt 1.17, в нём уже есть поддержка этой прошивки. Также, с его помощью мне удалось собрать пакет для OpenWrt размером в скромные 5 МБ. Чтобы установить, вам нужно в OpenWrt добавить feed с собранными пакетами для шлюза, и затем стандартным способом установить нужные пакеты

Добавляем фид:

wget -q https://openlumi.github.io/openwrt-packages/public.key -O /tmp/public.key && opkg-key add /tmp/public.key && rm /tmp/public.keyecho 'src/gz openlumi https://openlumi.github.io/openwrt-packages/packages/19.07/arm_cortex-a9_neon' >> /etc/opkg/customfeeds.conf

Устанавливаем пакеты:

opkg updateopkg install mosquitto node node-zigbee2mqtt

Прошить зигби чип можно прямо из веб-интерфейса LuCI:

Прошивки с разными скоростями работы с внешним последовательным портом можно скачать отсюда: https://github.com/openlumi/ZiGate/releases/tag/snapshot-20210103

Там же нужно сбросить EEPROM чипа, который хранит в себе данные о подключённых устройствах.Нужно выбрать скорость, на которой работает прошивка и нажать кнопку Erase PDM.

Уже на этом этапе, после перезагрузки, на порту 8080 загрузится веб интерфейс zigbee2mqtt, который позволяет включать режим спаривания и управлять подключёнными устройствами.

Улучшенная прошивка

Разработка прошивки Zigate идёт достаточно вяло и в ней присутствуют определённые проблемы. Потому тот же самый @G1K взялчистый пример координатора от NXP и применил только необходимые патчи из проекта Zigatе. В итоге прошивка лишилась ряда проблем, и при этом продолжила исправно работать с zigbee2mqtt

Альтернативная прошивка для z2m находится тут: https://github.com/openlumi/JN-ZigbeeNodeControlBridge-firmware

Home Assistant

И вишенкой на торте стало портирование целиком системы Home Assistant прямо на шлюз. Целиком это некоторое преувеличение, т.к. даже начальная установка занимает гораздо больше места, чем есть на шлюзе, а каждый компонент может требовать версию библиотек, которые отсутствуют в поставке.

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

Устанавливается это тоже всего лишь в одну команду (при условии, что у вас подключён фид openlumi).

wget https://raw.githubusercontent.com/openlumi/homeassistant_on_openwrt/main/ha_install.sh -O - | sh

Будет установлена последняя версия с поддержкой python 3.7 Home Assistant 2021.1.5

В поставке есть компоненты для работы с MQTT, если вы захотите его использовать с zigbee2mqtt, а также ZHA, компонент для работы с сетью зигби напрямую, если вам будет хватать поддержки устройств от этого компонента. Для ZHA потребуется оригинальная прошивка Zigate, работающая на скорости 115200.

В Home Assistant работают автоматизации, а также есть отзывы об успешном запуске компонентов mpd, tts, mysensors, камер

Для управления датчиками и устройствами самого шлюза можно использовать сервис lumimqtt (https://github.com/openlumi/lumimqtt)

При использовании компонента MQTT устройства сами залетят в систему, используя механизм mqtt discovery.
Установленный Home Assistant занимает на диске около 100 МБ и после загрузки работает достаточно быстро для подобной аппаратной платформы.

Более подробная инструкция по установке тут https://github.com/openlumi/homeassistant_on_openwrt

Что ещё можно сделать?

На шлюз Xiaomi с установленной OpenWrt можно устанавливать почти все пакеты из официального репозитория. Однако есть проблемы с использованием модулей ядра из пакетов, это может привести к kernel panic при установке. Такое было замечено при установке пакетов для openvpn, l2tp.В случае же приложений для userspace ограничений нет.

Например, была успешно бекпортирована более легковесная система умного дома Domoticz 2020 из master-ветки openwrt. В ней работают как плагин для работы с Zigate напрямую, так и плагин для zigbee2mqtt.

Если вы хотите более сложную логику для автоматизаций, чем предоставляет Home Assistant, есть возможность установить пакета для визуального поточного программирования node-red прямо на шлюзе. Разнообразные ноды для управления шлюзом уже в комплекте.

На шлюз можно установить сетевой музыкальный плеер mpd и слушать радио. Надо отметить, что качество звука не очень невысокое, хотя громкость достаточная.

На плате шлюза есть выведенные пятаки GPIO, правда, очень мелкие, но можно их использовать в linux через sysfs.Также на платах, где используется модуль WiFi Realtek 8723bs (все евро-шлюзы Xiaomi), есть возможность использовать встроенный bluetooth. В шлюзах Aqara стоит чип 8189es, в котором модуля bluetooth нет.

Несмотря на то, что проект уже выглядит вполне завершённым, если у вас есть навыки или знания, вы всё ещё можете присоединиться к улучшению достигнутых результатов.

Все текущие результаты собраны в едином проекте на гитхабе https://github.com/openlumi

Телеграм-чат для обсуждения.

Благодарности

Чтобы достичь данного результата, над проектом также работало множество замечательных людей:

@lenz1986 добавил поддержку nand, bluetooth

@Alx2000y написал драйвер для звука для шлюза, внедрил поддержку overlayfs, бекпортировал модуль ядра для паттернов мигания светодиодами

@G1K написал адаптер для zigbee2mqtt, которая поддерживает zigate в качестве координатора, организовал фид с пакетами для установки их на шлюзе через opkg и оптимизировал node-red для работы на шлюзе

@divanikus написал скрипт по установке OpenWrt на стоковой системе по воздуху

И, напоследок, бонус

Приблизительное сравнение аппаратных систем, чтобы понимать что вы потеряете и приобретёте, если возьмёте шлюз Xiaomi в качестве хоста для умного дома.

(eu version lumi.gateway.mieu01)

В этом посте я расскажу как можно собирать данные BLE и передавать через MQTT в системы умного дома, например в HomeAssistant.

Как все начиналось?

Эта история началась в прошлом году: у меня появился несколько таких шлюзов. В то время было несколько статей по получению root доступа, интеграции miio в HA и по прошивке чистого openwrt на шлюз. Толчком к развитию стал сезон распродаж в разных магазинах, где стоимость шлюза стремилась к нулю, и многие энтузиасты получили интересную железку.

Первым большим делом для меня было заставить работать zigbee2mqtt с чипом и прошивкой находящимся в шлюзе. И пока я допиливал интеграцию в zigbee-herdsman, ребята в чатике @xiaomi_gw_hack занимались добавлением поддержки в openwrt периферии, которая была в шлюзе (светодиоды RGB, динамик, датчик света, wi-fi модуль).

Отдельное спасибо @lenz1986, @Alx2000y, @belokobylskiy!

Было обнаружено, что в wifi модуле rtl8723bs европейской версии шлюза есть встроенный bluetooth с поддержкой BLE.

Но в стоковой системе на шлюзе нет никаких следов bluetooth. И лишних uart, по которому можно было бы с ним работать тоже. @lenz1986 провел раскопки

Он вызвонил контакты, и обнаружил что на плате разведены все 4 UART от процессора. Один из которых вел на uart от bluetooth части модуля wifi rtl8723bs. Потом он добавил поддержку этого uart в DTB, где описываются вся периферия устройства для openwrt и нашел подходящие драйвера. За что @lenz1986 огромное спасибо!

модуля

Внимание! Все действия я описываю и делаю на базе openwrt прошивки для шлюза. Установить ее можно по воздуху просто подключившись по uart к шлюзу. (спасибо @divanikus)

Подробнее описано на https://openlumi.github.io/

Bluetooth инициализируется через rtk_hciattach при запуске шлюза. После загрузки мы получаем такую картину hciconfig

Я знаю 2 пути, как можно включить bluetooth адаптер.

• Руками hciconfig hci0 up

• изменив параметр AutoEnableконфиге /etc/bluetooth/main.confна true

Я выбираю второй. Интерфейс запущен. Для проверки можно запустить скан hcitool lescan

Работа с BLE

Мои знания по BLE были на нуле, и чтобы было проще разобраться я искал что-то готовое по типу zigbee2mqtt. Перепробовал несколько решений на Node.Js, в том числе пакеты для node-red. Остановился на проекте EspruinoHub. (хоть и код там не супер современен и технологичен, но зато работает)

После запуска с отсылкой данных в локальный mqtt сервер, в CLI и web интерфейсе уже показались распарсенные данные с части датчиков LYWSDCGQ (круглые гигротермографы) .

Это меня порадовало, но у меня было еще несколько устройств, данные от которых я увидел почти в raw виде. И я решил использовать эту программу и немного улучшить ее.

Многие устройства Xiaomi с bluetooth шлет BLE Advertising Packet, в большинстве случаев в нем содержится полезная нагрузка в виде измерений, которые производит устройство. Часто данные отправляются открыто, но используется шифрование с ключом.

Например для браслета MiBand данные выглядят вот так. Если есть данные о пульсе то они добавляются в конец

В устройствах xiaomi, часто используется BLE сервис fe95. В интернете есть небольшая документация по нему .На github есть множество проектов которые умеют парсить эти данные. На основе этих данных и существующей реализации espruino я немного улучшил парсинг открытых данных, но потом я нашел более красивое решение из hannseman/homebridge-mi-hygrothermograph. Мне особенно понравилась стандартизация разных событий и расшифровка исходя из данных заголовка.

Этот парсер закрыл вопрос с большинством устройств Xiaomi, отправляющих данные в fe95. Можно еще попробовать добавить некоторые типы событий (движение, дым, нажатие на кнопку), но у меня нет таких устройств под рукой.

Я добавил в EspruinoHub данный парсер, и реализовал возможность указать настройки для разных устройств. Это необходимо для устройств, которые шифруют с помощью bindKey свои пакеты. Получить bindKey можно из miHome.

MQTT Discovery - Home Assistant

Данных стало больше, но хотелось чтобы они автоматически появлялись в HomeAssistant. EspruinoHub отправляет данные которые и слышит в эфире, и не имеет на данный момент привязки к конкретным устройствам. Поэтому в момент появления данных, если они из списка поддерживаемых отправляется config устройства в топик homeassistant в mqtt и устройства появляются в системе умного дома

Добавленные и протестированные устройства.

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

LYWSDCGQ - работал "из коробки". Добавил только mqtt discovery в HA

LYWSD02 - температура, влажность и батарейка

Самый бюджетный датчик температуры и влажности с экраном LYWSD03MMC - температура, влажность и батарейка (нужен bindKey). Существует 2 альтернативные прошивки, они очень крутые и продвинутые. Особенно от Виктора pvvx. Рекомендую использовать именно ее. Помимо лучшего потребления она шлет данные в одном пакете, а не в трёх и имеет множество настроек.

MI SCALE - 181d v1 По крупицам из разных источников допилена реализация в которой показываются данные о - стабилизации веса (весы моргают) - убрали вес (встали с весов) - дата и время измерения. 181b v2 Работает, но не тестировал лично. Возможно нужно что-то допилить

Mi band 3 fee0 Шаги и Пульс в режиме тренировки. Чтобы браслет отправлял данные необходимо включить обнаружение в MiFit.

Как оказалось шлюз очень хорошо и далеко слышит, а эта функция включена у многих людей. Работает это и для других моделей и даже на некоторых часах например Amazfit GTS

HHCCJCY01 MiFlora, Huahuacaocao - temperature, moisture, illuminance, conductivity, battery_level

Другие устройства тоже можно попробовать подключить. Если они шлют в кодированном виде, то в mqtt об этом будет ошибка с просьбой указать bindKey в конфиг.

YEERC - я обнаружил что прошивка для esp32 tasmota сообщает, что поддерживает данный пульт. Он идет в комплекте с многими люстрами YEELIGHT, но к сожалению у меня не получилось нигде найти как получить 32 символьный bindKey для него. Сообщения нажатий я вижу, но не могу расшифровать. (Значение event закодировано и зависит от counter который увеличивается с каждым нажатием) Возможно кто-то из читателей подскажет как добыть данный ключик. Пульт можно привязать к нескольким люстрам в разное время и они будут вместе расшифровывать и отрабатывать нажатия. Скорей всего ключ там не изменяется со временем или привязкой.

Как установить EspruinoHub на шлюз Xiaomi с OpenWrt ?

Можно установить и на другие устройства с помощью git / npm, инструкция на странице проекта EspruinoHub

Установка

Мои последние наработки собраны в пакет и ставятся с помощью opkg

Необходимо подключить фид по инструкции https://openlumi.github.io/openwrt-packages/

Дальше установить собранный пакет.

opkg updateopkg install node-espruinohub

Конфигурирование

По-умолчанию он будет пытаться подключиться к локальному mqtt без авторизации. Если вы хотите подключить к внешнему брокеру mqtt, то нужно изменить конфиг в /etc/espurinohub/config.json

Внимание! у некоторых настроек в начале стоят слеши чтобы они не применялись. (конфиг в этом проекте частично сделан как пример и я не стал ничего менять)

Пример конфига можно посмотреть тут. Если вы знаете мак адреса своих устройств то рекомендую их прописать и установить"only_known_devices": true, чтобы не отправлялись данные с чужих устройств из эфира.

Для работы с HomeAssistant достаточно отправлять данные в json формате, а остальное можно выключить. По умолчанию будет отправлять в топики с группировкой по типу данных.

"mqtt_format_json": true,"homeassistant": true,"mqtt_cache_state": true

Планы

Отслеживание носимых устройств по rssi между комнатами. Для этого в конфиг я добавил возможность указать минимальный rssi в разрезе устройства и таймаут присутствия.

Активные подключения: хочу попробовать управлять некоторыми устройствами по BLE, но для одновременного подключения и сканирования Bluetooth модуль и ПО могут работать нестабильно. Поэтому я пока только изучаю этот вопрос.

Альтернативные opensource проекты работающие с BLE на шлюзе

• devbis/ble2mqtt - своя реализация на python через bleak, умеет подключаться к чайникам, но сильно грузит процессор.

• Beetle-II/lumi - тот же парсер из hannseman/homebridge-mi-hygrothermograph, но без возможности задать индивидуальный ключ bindKey для устройства. Нет raw данных и управление через mqtt. + Умеет работать не только с BLE.

Заключение

Спасибо, что дочитали до конца!

Если у Вас есть вопросы, то можете задавать их в комментариях.

Предисловие

История берет свое начало в мае, когда в один из непогожих питерских дней, местная котельная решила отключить отопление. За окном было +10, влажность зашкаливала, ветер дул, а тепленькое солнышко не светило в окна от слова совсем (чертова северная сторона). В квартире стало ощутимо холодно. Кот слезал с теплых колен только дляопустошения миски. Мы же кутались в флиски и пледы. Через два дня такой жизни стало понятно - к черту все, нужен обогреватель! Требования были довольно просты - цена, определенная мощность, возможность эту самую мощность регулировать и какой-либо интерфейс (wi-fi\BT\ZigBee\485). Последнее хотелось больше для баловства и неведомого "а вдруг потребуется!". Оставлю за рамками статьи муки выбора, количество обогревателей на полках магазинов в конце весны и прочие приколы наших доставщиков. В итоге, я стал обладателем конвектора под брендом впрочем, если не показывать шильдик, то можно найти картинки аж трех производителей "клепающих" одинаковые модели. А если погуглить чуть поглубже, то окажется что в РФ франшиза на выпуск конвекторов под этими брендам принадлежит одной единственной конторе. И все встает на свои места - конвектор один, а шильдик лишь влияет на цену. Впрочем, мне то какая разница - грело бы, да управлялось.

Что-то я отвлекся. Итак, конвектор модульный:

• нагревательный блок

• блок с инвертором для управления

• Wi-fi свисток

Cобрано, запущено, кот согрет, самое время посмотреть, что там с интерфейсом. Приложение для мобилки подключилось к конвектору, залило настройки wi-fi сети и радостно предложило управлять обогревателем через интернет. И в принципе на этом можно было бы закончить, но в процессе эксплуатации появилось желание - время от времени использовать конвектор для просушки одного из помещений. Датчик влажности есть, к Home Assistant подключен, дело за малым, завести туда же конвектор. Тут меня ждало полнейшее разочарование - никакого API, никаких интеграций, вообще ни_че_го. Лан, инженером же работаю, не в первой городить программно-аппаратные решения.

Часть 0. Исходные данные

Первое, что делает любой инженер - берет отвертку и смотрит внутрь. А внутри USB-модуля оказалась железка HF-LPT220. Заботливый гугл находит:

• Статью (часть 1 и часть 2) пользователя @avstepanov Краткое содержание: Кондиционер, модуль такой же, попробовали wi-fi, API нет, решили проблему через управление по IR.

• Сайт производителя

Закатываем рукава достаем чемоданчик с инструментарием:

Часть 1. Wi-Fi!

Раз мобильное приложение общается с железкой через wi-fi, логично запустить сниффер и посмотреть что там бегает. Хорошо что микротик умеет "зеркалить" траффик в Wireshark (wiki mikrotik, инструкция попроще). Запускаем wireshark, включаем обогреватель и наблюдаем.

После отрабатывания DHCP-клиента, железка запрашивает IP адрес dongle.***.ru, где *** представительство в РФ (не вендор). Просто примем эту информацию к сведенью и сделаем вывод - в других международных регионах скорее всего будут свои фирмы-представители и, соответственно, адреса.

Происходит установка TCP-соединения и начинается обмен AT-командами

< - запрос от сервера, конвектору > - ответ от конвектора, серверу< AT+NDBGL=0,0< AT+APPVER> +ok< AT+WSMAC> =<ver>-20170810 . +ok=<MAC>

Данные команды повторяются несколько раз, как и ответы на них, видимо, происходит не очень быстрая обработка со стороны сервера.

Идем в документацию с сайта hi-flying и действительно находим:
AT+NDBGL - Enable\Disable UART information
AT+WSMAC - Set\Query Module MAC address parameters. Setting is valid after reset.
AT+VER - Query module software version information. AT+APPVER в документе отсутствует, т.к. модуль и прошивка датированы 2017 г. а вот документация на сайте 2016.

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

А вот вторая, заставляет задуматься.

Честно говоря, в эпоху пристального внимания к безопасности IoT, не надеялся увидеть что-либо дельное, однако Серьезно? Как-то это не похоже на зашифрованный TLS\SSL\Ipsec - траффик.

Cходу можно сделать предположение - последний байт, это контрольная, однобайтовая сумма. Открываем калькулятор и складываем AA+C+A+1+1A+1+6+5+1 = E8. Ясно, понятно. Начинаем жать все кнопки в приложении и обнаруживаем некоторые закономерности, попутно пишем на LUA dissector для Wireshark. Не парсить, же байты каждый раз =)

Получаем занятную штуку, на примере: aa 0c 0a 01 1a 01 06 00 00 00 00 05 00 01 e8

Отдельно хочется выделить запрос текущей конфигурации от сервера:

* На этапе инициализации используются дополнительные пакеты и команды, но оставим это за рамками статьи.

Фуф, с данными, вроде как понятно. Но будет ли устройство принимать команды от стороннего сервера? Адрес сервера забит в прошивку. Мы конечно можем, подменить ответ DNS-сервера на локальном маршрутизаторе, но сначала стоит попробовать что-нибудь попроще.

Посмотрим, какие порты открыты на сервере конвекторе. Linux\WSL > Bash > Netcat
nc -vnz <IP конвектора> 1-65000 2>&1 | grep succeeded

Через довольно продолжительное время, обнаружится открытый, 8899 порт. ONVIF у конвектора? Whaaat?! Но нам то что? Попробуем отправить пакет на включение и выставление настроек:
echo -e "\xAA\x0C\x0A\x01\x17\x01\x01\x00\x00\x00\x00\x00\x00\x00\xDA" |
nc <IP конвектора> 8899

И, внезапно, оно работает!

Есть одно, НО. При отправке запроса о текущей конфигурации (AA 03 08 10 04 C9), ответ отправляется не тому кто запросил, а на сервер с которым установлено соединение. Как итог, управление возможно только в слепую, никаких данных о включении, отключении, режиме и температуре получить невозможно.

Есть два способа изменить это поведение (сборка своей прошивки не в счет).
Первый. Так как в прошивке зашито DNS-имя, можно изменить IP-адрес в ответе DNS-сервера, так чтобы dongle.*****.ru ссылался на 192.168.0.* - т.е. прописать статическую DNS запись.
Плюс данного способа - все настройки делаются на маршрутизаторе\DNS-сервере в пару кликов.
Минус - очевидно, способ нерабочий, если ваш DHCP-сервер выдает клиентам публичные DNS-сервера (8.8.8.8, 1.1.1.1 и прочие "семейные DNS")

Второй способ приведен ниже, в части посвященной UART и касается изменении адреса сервера в модуле wi-fi.
Плюсы - гарантированная работа в ЛВС.
Минусы - жесткая привязка к конкретной ЛВС - это надо помнить.

Итак, запускаем (или пишем на коленке) на локальной машине простенький tcp-сервер. Отправляем железке AA 03 08 10 04 C9 в ответ получаем aa 0c 88 01 15 01 01 00 00 00 18 00 70 00 00 00 6e Теперь, все работает как надо.

Промежуточные результаты: Можно начинать писать свой шлюз\OPC-сервер\плагин для системы управления умным домом.

Часть 2. Android

А что если есть более простой способ рулить конвектором? Например, подключить систему управления умным домом напрямую к серверу и перекидываться JSON'ами. Реализовать такое управление, безусловно, проще.
Чтож, стоит посмотреть, как мобильное приложение общается с сервером. Запускаем wireshark, настраиваем mikrotik и смотрим. А посмотреть есть на что.

Приложение обращается к тому же самому IP - 82.209.**.** (правда я не увидел запроса к DNS, но возможно ОС взяла значение из кэша). А так же сморим первый TCP Stream. Да у нас тут целый запрос-ответ.

Ответ (К сожалению в ответе пришлось бы блюрить огромное количество данных, по этому вставка текстом, некоторые заголовки вырезаны):

HTTP/1.1 200 OKServer: nginx/1.12.2Content-Type: application/json;X-Powered-By: PHP/7.0.27X-Powered-CMS: <название одной популярной CMS>{  "result": {    "token": "<токен>",    "user": {      "name": ""    },    "enc_key": "<ключ>",    "server": {      "host": "dongle.<вендор>.ru",      "port": "10001"    },}

Что имеем? В запросе используется голый http, передающий в открытом виде:
appcode - бренд. Напомню, производитель изготавливает оборудование под разными брендами.
login - номер мобильного телефона, который является логином в приложении
password - пароль. Не хэш. Именно пароль, указываемый при регистрации, и использующийся для входа в приложение.

Интересное в ответе:
-На той стороне используется би_cms_.
-Нам передают токен
-Забегая вперед скажу, что нам передают ключ шифрования - enc_key

*Б - безопасность. Но давайте посмотрим что происходит дальше, а потом проанализируем все вместе.

Сморим, что же происходит дальше. А дальше происходит небольшой обмен командами. Cервер запрашивает присвоенный токен, приложение его отправляет и в ответ получает это:

IoZAWjxg/vHjEBEZvX1zTkrmbT2k8tVG0T1NjHjw2Qx1fwChQsv7PkRKKQ=6829b7302ad50470a5ddb3cd41566dafIoZAWjxg/vHjEBEZvX1zTgwVJIsFn6VqMtnyYurmE3p9TjpjjgxfpJDlRMyTKNqmZto39j4X4Y8nKH/XPIdynRedAM/4gQ4s9fXbd402ed9aec13b9a3ab4521212294f7cIoZAWjxg/vHjEBEZvX1zTgwVJIsFn6VqMtnyYurmE3p9TjpjjgxfpJDlRMyTKNqmZto39j4X4Y8nKH/XPIdynRedAM/4gQ4s9fXbd402ed9aec13b9a3ab4521212294f7c

Погодите, шифрование? Вот это поворот! Тут наши полномочия, как говорится все.
Но погодите, мы встречаем 3 одинаковых последовательности. Причем, одно из сообщений дублируется два раза. Открываем приложение, нажимаем разные кнопочки и обнаруживаем, что некоторые пакеты не меняются.
Делаем первый промежуточный вывод - шифрование не привязано ко времени.

Конец сообщения очень сильно что-то напоминает. Да и по закону жанра в конце сообщения должен быть хэш\CRC. Проводим некоторое время в калькуляторах перебирая алгоритмы и действительно, конец сообщения содержит свой хэш в MD5 (дайджест?). Ок.

Осталось определить алгоритм шифрования. Developer android заботливо подсказывает, что алгоритмов поддерживается дофига, но рекомендуется использовать AES256. Запомним.
На вопрос "Как определить алгоритм шифрования зная шифротекст?", гугл лаконично отвечает "Никак, анализируй приложение (де)шифровщик".

Забрались далеко, отступать не наши методы. Качаем APK, при помощи dex2jar конвертируем в jdk и открываем в JD.

Можно заняться полным реверсом (не ассемблер же), но быстрее будет запустить поиск по ключевому слову. Вопрос, что искать? Что-то отвечающее за шифрование - "encrypt"

Внезапно.

• Библиотека от espressif

• Библиотека от hyflying, с их SmartLink'ом.

• Три класса с реализующих AES. Причем во всех трех классах используются разные режимы шифрования.

Библиотеки от espressiа и hyflying можно отложить на потом, WifiUtils, логично предположить, отвечает за шифрование Wi-Fi. Остаются TcpServices, EncryptUtils и AES256Chipher. Заглянем в EncryptUtils и увидим:

public class EncryptUtils {private static final String AES_MODE = "AES/CBC/PKCS7Padding";private static final String CHARSET = "UTF-8";private static final String ENC_PASSWORD;private static final String HASH_ALGORITHM = "SHA-256";private static final String TAG = EncryptUtils.class.getSimpleName();private static final byte[] ivBytes;static {ENC_PASSWORD = EncryptUtils.class.getSimpleName().concat(EncryptUtils.class.getSimpleName());ivBytes = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };}public static String decrypt(String paramString) {try {return decrypt(ENC_PASSWORD, paramString);}private static String decrypt(String paramString1, String paramString2) throws GeneralSecurityException {try {SecretKeySpec secretKeySpec = generateKey(paramString1);byte[] arrayOfByte = Base64.decode(paramString2, 2);return new String(decrypt(secretKeySpec, ivBytes, arrayOfByte), "UTF-8");}private static SecretKeySpec generateKey(String paramString) throws NoSuchAlgorithmException, UnsupportedEncodingException {MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");byte[] arrayOfByte = paramString.getBytes("UTF-8");messageDigest.update(arrayOfByte, 0, arrayOfByte.length);return new SecretKeySpec(messageDigest.digest(), "AES");}

Краткое содержание:
Переменной ENC_PASSWORD два раза присваиваем имя текущего класса ("EncryptUtilsEncryptUtils"). Получаем хэш и на его основе генерим ключ, которым и дешифруем данные.

Запускаем Android Studio и пишем простенький код (или пользуемся он-лайн дешифровщиками) и скармливаем наш шифротекст.

Fail. Пробуем по другому, снова фейл. И так и сяк - Fail.

Окей, посмотрим что лежит во втором классе - AES256Chipher

paramString1 - шифротекстparamString2 - ключpublic static String decrypt(String paramString1, String paramString2) {         <отрезание и проверка MD5, not null и все такое прочее>           MessageDigest messageDigest = MessageDigest.getInstance("SHA384");          try {            byte[] arrayOfByte2 = messageDigest.digest(paramString2.getBytes("UTF-8"));            byte[] arrayOfByte1 = Arrays.copyOfRange(arrayOfByte2, 32, 48);            arrayOfByte2 = Arrays.copyOfRange(arrayOfByte2, 0, 32);                    try {              Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");              IvParameterSpec ivParameterSpec = new IvParameterSpec(arrayOfByte1);              cipher.init(2, new SecretKeySpec(arrayOfByte2, "AES"), ivParameterSpec);              return new String(cipher.doFinal(Base64.decode(paramString1, 0)));  }

Краткое содержание: берем пароль, считаем от него SHA384 (почему 384?), разбиваем на два байтовых массива [32-48] и [0-32].
Первый - вектор инициализации (IV)
Второй -ключ, который и скармливаем SecretKeySpec

Вроде, ничего криминального, все так делают. Внимание вопрос - что же у нас может выступать в роли пароля? Может быть, тот самый enc_key из JSONa передающийся открытым http?
Пробуем, и вуаля, сообщения расшифровываются. Внутри нас ждет тот самый REST API с командами getDeviceParams, setDeviceParams, changedDeviceParams. Можно начинать писать плагин для системы управления.

Возникают смешанные чувства:- Передача номера телефона и пароля в открытом виде. Я даже не знаю, что тут написать. Хэш? SSL\TLS? Не, не слышали. Зато, на сайте разработчиков гордо красуется "Входим в ТОП-100 разработчиков мобильных приложений".- Ключ шифрования (по сути) передается в открытом виде при установлении каждой сессии. А сессия создается при каждом запуске приложения. Нет, он не сохраняется. Открыл приложение, выставил температуру, закрыл приложение - такой же жизненный цикл имеет ключ. Т.е. нам достаточно перехватить начало одной, любой сессии и все, можем рулить железкой.- Зачем в приложении аж 3 класса реализующих AES? Ладно, тут ответ очевиден - "я его слепила из того что было"

Однако!- Благодаря этому, можно легко написать сторонне приложение\плагин\расширение для системы управления умным домом.Утечки ПД, нет, т.к. нет ФИО (оно вообще нигде не указывается, даже при регистрации)

Часть 3. UART

Как выяснилось в первой части, наш wi-fi свисток, это всего лишь "UART to Wi-Fi" преобразователь. Это значит, что мы можем при помощи Esp32\Arduino\RPI создать свою железку для управления конвектором - с MTTQ, bluetooth и прочими соединениями. Надо лишь узнать протокол.

Итак, свисток имеет разъем USB-AM, и подписи на плате (см. фото выше) +5v, Tx, Rx, GND. Дело за малым, взять кабель AM - AF, разрезать, зачистить и в параллель подключить логический анализатор. +5v, можно оставить в покое. Таким образом, сразу будем видеть и Тx и Rx - главное, определиться с какой стороны смотреть.

Запуск, тыканье в кнопочки на мобильнике и

что-то это напоминает.

UART to Wi-Fi оказался тупым конвертером. Никакой внутренней обработки, никакой логики. Формат сообщения такой же как и в первой части.

В Wireshark мы видели AT-команды. Да и в документации про это что-то было. Берем UART-USB, выставляем +5В и подключаем. Главное Tx и Rx подключить перекрестно (очевидно, но можно забыть). Запускаем Putty или любой другой терминальный клиент. Выбираем com-порт в документации указана скорость 115200, но по факту 9600.

Окей, железка что-то шлет в терминал, но на ввод не реагирует. Курим ман и находим - для перехода в режим настройки необходимо отправить "+++" (без enter'а), на что HF-LPT220 ответит "a" и нам надо в ответ послать такую же "a". Сделать это все надо за 3 с.

После данной эквилибристики, железка становится отзывчивой. Введем AT+H и увидим список доступных команд:

Можно позапускать всякое, но интерес представляет AT+SOCKB, который возвращает "+ok=TCP,10001,dongle.******.ru". Как внезапно

Попробуем заменить на что-нибудь свое?

"AT+SOCKB=TCP,10001,192.168.0.2". Возвращаем модуль в конвектор и смотрим в wireshark. Теперь железка пытается установить соединение не с сервером в интернете, а с ПК из локальной сети.

Выводы и заключение.

Буква S в аббревиатуре IoT обозначает Security

Существует три способа управления конвектором. Через сервер производителя (REST API), напрямую из ЛВС, через UART.

Остался открытый вопрос с модулем для HA - возможно никогда-нибудь, он будет написан=).