Я 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

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

Если вы когда-либо обзаведётесь технологиями умного дома, то скорее всего, в числе первых купленных устройств у вас окажутся именно умные лампочки. Они действительно удобны. Включение-выключение света при движении. По таймеру. Плавное нарастание яркости для более комфортного пробуждения. Разные цветовые температуры. И так далее.

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

Я говорю о том, как умные лампочки реагируют на кратковременный перебой в подаче электроэнергии.

Глупые умные лампочки

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

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

Почему при скачке напряжения они включаются? Есть мнение, что это сделано для обратной совместимости с обычными глупыми лампочками. Если вы вкрутите умную лампочку в патрон, управляемый обычным выключателем, она должна работать. Появляется питание -> лампочка включается. Именно это и приводит нас к неприятному побочному эффекту при нештатном исчезновении и повторной подаче питания. К сожалению, умные лампочки недостаточно умные, чтобы такое поведение было настраиваемо. Есть, впрочем, исключения, о которых ниже.

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

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

Умные технологии, ага.

Решение

По щучьему веленью, по моемухотенью Народная мудрость

Идеальный конечный результат, в моём понимании, был бы таким умная лампочка может быть настроена на умное поведение при перебое питания. А именно: при подаче питания вместо включения на максимальную яркость, лампочку можно заставить оставаться выключенной или, скажем, восстанавливать предыдущее состояние (к примеру, если в момент перебоя с электричеством лампочка была включена на 30% яркости, то восстанавливается тот же самый режим).

Год назад, когда я пытался решить эту проблему, готовых решений, вроде как, не просматривалось. На форумах удовлетворительных решений не было, и я махнул рукой.

И вот однажды я натыкаюсь на такую запись на странице замечательного проекта zigbee2MQTT

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

^{Описания обновлений прошивок (ссылка) и приложения iOS (ссылка). Упоминание функции power-on behavior.}

Уж не знаю, чем вызвана такая застенчивость по отношению к функциональности, которую они сами описывают как долгожданную (вольный перевод фразы long awaited). Что же касается других производителей, то я не смог найти аналогичную настройку. Возможно, они стесняются ещё сильнее (хотя казалось бы, куда сильнее-то). Если вам такие известны, пожалуйста, напишите в комментарии.

решение доступное всем, но неполное

В теории нет разницы между теорией и практикой. А на практике есть

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

Нас интересует настройка со значком молнии. Именно она оставит лампу в выключенном состоянии если она была выключена и произошёл перебой в подаче питания. Вот оно решение! Однако, тут как в том анекдоте, есть нюанс. Если свет мигнёт дважды в течение 15 секунд, то лампочка включится принудительно причём на максимальную яркость и мы снова проснёмся посреди ночи в поисках выключателя. Об этом даже написано в приложении. Интервал в 15 секунд проверен мной на лампочке с артикулом 9290023349 и прошивкой 1.65.11_hB798F2BF от 11 мая 2020.

Конечно, шанс получить двойной перебой питания питания с интервалом в 15 секунд ниже чем получить одиночный. Но он всё-таки есть.

Если бы я не увлекался умными устройствами с интерфейсом ZigBee и не наткнулся на эту функциональность именно на сайте проекта zigbee2MQTT, я бы тут же бросил эту затею. Да и статью на Хабр писать не стоило бы

и решение полное, но не для всех

Если долго мучиться, Что-нибудь получится

Оказывается, что по протоколу ZigBee доступна ещё одна возможность настройки, до которой не добраться из приложения. Она позволяет настроить умную лампочку на режим всегда выключена. То есть как бы быстро напряжение ни мигало, или как бы яростно вы ни щёлкали выключателем, лампочка не включится. Включить её можно только через сопряжённые устройства умного дома (ZigBee-координатор или всё ту же Bluetooth-приложеньку от производителя).

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

В моём случае (у меня есть ZigBee-координатор CC26X2R1 и zigbee2mqtt) окончательное решение выглядит так:

1. лампочку нужно сопрячь с координатором

2. в логах найти её уникальный номер (к примеру 0x0017880108fe7a41)

3. и послать через zigbee2mqtt MQTT-сообщение.
   Topic: zigbee2mqtt/[FRIENDLYNAME]/set/hue_poweron_behavior
   Data: off

Только после этого мы получим по-настоящему умную лампочку, которая горит, когда нужно и не горит, когда не нужно.

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

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 в качестве хоста для умного дома.

Некоторое время назад мы попытались дать ответ на этот вопрос. Через призму нашего видения.

Вот, что у нас получилось.

За последнее время мы выпустили несколько крупных обновлений ПО, которые как исправляли некоторые недоработки, так и расширяли функционал устройства.

В целом, на сегодняшний день, термостат обладает всем разнообразием функционала, который мы хотели реализовать в нём. Конечно, будет еще несколько нововведений, добавление более продвинутого расписания; но контроллер, установленный в термостат, себя исчерпал. Надо двигаться дальше.

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

Позвольте представить, Панель управления климатом и светом.

По традиции, начнем с начинки. Как и ранее, Панель состоит из двух плат.

Верхняя плата

Мы решили выбрать народный микроконтроллер esp32. Два ядра, BLE, вагон памяти под наши задачи. Что еще можно желать?

ESP32 хорош, но какой умный дом без ZigBee? Компоновка платы позволяет, и мы полностью воспользовались этим, установив модуль NJ5169 (E75).

Нижняя плата

Над начинкой платы мы так же поработали и решили подойти с учетом имеющегося опыта.

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

Как насчёт экрана?

Установили экран диагональю 4 дюйма с IPS матрицей (разрешение 480х480px) и емкостным тачскрином.

Данный экран будет доступен и для обладателей предыдущей, 101, модели термостата. Заменить экран можно будет просто сняв старый и установив этот. Он раскроет свой потенциал у тех, кто использует MQTT. А для обладателей HK это будет чуть более информативный экран.

Какие протоколы поддерживает Панель?

Wi-Fi

Cамо собой - для связи с внешним миром.

ZigBee

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

MQTT

Все устройства, которые будут подключены к Панели по Zigbee, как и сами термостаты, будут передавать актуальные данные по MQTT. Можно будет как управлять, так и наблюдать. Подключить Панель можно будет и к нашему облаку, и к любому стороннему MQTT-брокеру.

Так будет выглядеть наше приложение, открывающее удалённый доступ ко всем подключенным устройствам в квартире:

Но на этом варианты применения MQTT не заканчиваются. Для обладателей таких систем как Home Assistant, MajorDoMo, OpenHub и аналогичных, будет возможность подписаться на сторонние топики и за счёт этого собрать свой вариант интерфейса Панели на основе заранее заготовленных нами шаблонов. Такие топики могут содержать как информацию с датчиков, так и управляющие топики для кнопок, реле и тому подобных исполняющих устройств. Также, можно будет связать кнопку и запуск/остановку какого-либо сценария.

Вот такой комбайн получился у нас.

Вроде и термостат, а вроде уже что-то более продвинутое.

Как же можно его применить?

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

Вдобавок, можно вывести датчики, установленные неподалёку от Панели.

Таким образом, Панель может служить и для вывода основных показаний в комнате.

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

Всех желающих поучаствовать в обсуждении функционала такого устройства приглашаем в нашу группу телеграм