Умныйдом

Я 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 против готовых решений

Xiaomi MiHome стал уже символом консьюмерской системы Умного Дома

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

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

NodeRed очень популярное OpenSource решение для Умного Дома

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

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

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

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

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

Та самая знаменитая "Малинка" Raspberry Pi 4

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

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

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

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

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

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

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

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

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

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

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

Очень популярный Intel NUC

В действительности цены на подобные новые минисерверы довольно высоки и далеко не каждый будет готов потратится. Но на просторах интернет барахолок, вроде 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:

Дебаг автоматизаций в HomeAssistant

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

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

Логотип HomeAssistant

Но тем не менее, я могу поговорить о чем спорят и говорят на эту тему в сообществе. А говорят следующее. 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

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

Приветствую.

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

Дом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этаж

Принцип такой же как и в доме КУБ-8400х8400х8400 - ничего лишнего - максимальная простота и удобство во всем (начиная строительством дома и заканчивая его эксплуатацией) - минимализм во всех смыслах.

Оба дома являются универсальными заготовками:

• возможно строительство по любой технологии;

• использование любых материалов;

• любая внешняя и внутренняя отделки.

Оба дома максимально равнозначны.
Таким образом остаются в основном субъективные нюансы - кому что больше нравится.

Стоимость вышла ~ на 20% выше, энергоэффективность на 10-20% ниже, чем у дома серии КУБ - с другой стороны площадь крыши и террасы увеличились.
В следующей статье сравню эти 2 варианта дома.

ТЭП (выборочные):

• габариты = 14400 х 9000 х 4200 (возможно 4400 будет оптимальней с учетом парапета);

• площадь застройки = 130м2 (+ пристройка 58м2; + отмостка 74м2);

• площадь полезная вутренняя = 98м2 или 103м2;

• высота потолков в чистоте = 3600мм;

Экспликация помещений:

• тамбур-прихожая = 8,7м2 / 9,4м2;

• гостиная-столовая-кухня = 41,4м2 / 42,0м2;

• СУ 1 = 6,1м2 / 6,4м2;

• техпомещение = 5,4м2 / 5,6м2;

• СУ 2 = 5,4м2 / 5,6м2;

• спальня 1 = 11,0м2 / 11,8м2;

• спальня 2 = 11,0м2 / 11,8м2;

• спальня 3 = 8,7м2 / 9,4м2;

• эксплуатируемая кровля = 120,0м2;

• терраса = 56,0м2.

В качестве подгонки планировки под себя возможно следующее:

• спальни можно увеличивать за счет СУ и Тамбура-прихожей;

• один из СУ можно отдать под кабинет или спальню;

• вход с любой стороны.

Инженерные системы (внутренние):

Уточнение:

Так как дом одноэтажный, то полноценное функционирование естественного инженерного комбайна под вопросом - требуется большая мощность естественной тяги.
Можно, конечно, вывести утепленную трубу на 5-6м над крышей - но это такое себе : )
Само собой можно добавить вентилятор, и проблема будет решена, но это приводит к зависимости от автоматики.

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

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

• индивидуальный тепловой пункт внутри дома (газовый котел / электрический котел пеллетный котел или горелка с бункером на 7-14 дней автономной работы / твердотопливный котел);

• отопление (водяной теплый пол);

• вентиляция (естественного типа или принудительного, но в любом случае стандартного исполнения);

• рекуперация;

• кондиционирование;

• очистка;

• обогащение;

• увлажнение;

• водопровод;

• канализация;

• электрика;

• система умного дома;

• бензиновый генератор (дешевле) или аккумулятор (удобней);

• система водостока (скрытый или открытый).

Инженерные системы (наружные):

• скважина;

• септик глубокой очистки;

• или центральные системы.

Фундамент:

(выбирается под конкретную геологию и итоговый вариант дома (с подвалом или без))

• монолитная плита 300мм с утеплителем XPS 100мм снизу и по торцам плиты;

• свайно-ростверковый с плитами перекрытий 160мм и утеплителем XPS 150-200мм (полы по грунту как альтернатива);

• заглубленный фундамент (ФБС или монолит) для организации подвала и возможности пристроек на месте крыльца и/или террасы.

Основание крыльца, террасы итд :

• или монолитная плита 150-300мм с утеплителем XPS 100мм снизу и по торцам плиты;

• или сваи с ростверком с деревянными балками и настилом из строганных досок камерной сушки;

• или заглубленный фундамент (ФБС или монолит) для организации подвала и возможности пристроек на месте крыльца и/или террасы.

Стены периметральные:

• газоблок D400 400мм.

Внутренние стены и перегородки:

• или цементно-песчаный блок (ЦПБ) полнотелый 140/200мм;

• или полнотелый глиняный кирпич 120/250мм;

Крыша эксплуатируемая (эксплуатируемая кровля):

• оцинкованные кровельные сендвич-панели с утеплителем типа PIR (негорючий и экологичный утеплитель (по всем характеристикам лучше XPS)) 150-200мм по деревянным строганным второстепенным балкам камерной сушки 45х190мм и главным балкам + деревянный настил на эксплуатируемой крыше;

• так как сендвич-панели значительно подорожали (так как металл весь подорожал), то экономически целесообразней выходит обычный стандартный пирог крыши с усиленными стропилами (только вместо металлочерепицу профлист h=60-75мм);

• если будет надстройка, то тогда монолитное перекрытие.

Фасад:

• или с фактурой и текстурой газоблока;

• или окрашенный газоблок.

Стены и перегородки внутренние:

• с фактурой и текстурой бетонных блоков/кирпича.

Периметральные стены (внутренняя отделка):

• покрытие, деревянный каркас и обшивка строганными досками камерной сушки 200х25-50мм.

• или общепринятые варианты.

Стены периметральные во влажных помещениях (внутренняя отделка):

• ГКЛВ 12,5ммх2 и керамогранит 600х600-1200х600.

Потолки (внутренняя отделка):

• строганные доски камерной сушки 200х25-50мм;

Полы (внутренняя отделка):

• или упрочненный гидрофобный бетонный пол;

• или керамогранит/ламинат/итд на обычный бетон (подложка при необходимости);

• или деревянный пол по лагам из половых строганных досок камерной сушки (во влажных помещниях на полу ГВЛВ 12,5ммх2 или фанера и керамогранит).

Окна (900-1000 х 1800-3000):

• пластиковые двухкамерные энергоэффективные с утепленной четвертью итд.

Двери на террасу (900-1000 х 2800-3000):

• пластиковые двухкамерные энергоэффективные с утепленной четвертью итд.

Входная дверь (900-1000 х 2800-3000):

• или теплая металлическая с утепленной четвертью, защитой от осадков в виде навеса итд;

• или пластиковая двухкамерная энергоэффективная с утепленной четвертью, с защитой от осадков в виде навеса итд.

Межкомнатные двери (800-1000 х 2200-2400):

• деревянные с фурнитурой.

Дополнительно (при необходимости):

• отмостка утепленная гравийно-цементная шириной 1200мм с XPS утеплителем 100мм;

• перголы (металлический каркас с обшивкой деревом) на крыльце и террасе;

• панорамное остекление 3600х2800-3000(высота) в гостиной-кухне-столовой;

• окна 900-1000 х 2800-3000 (высота) в замен окон 900-1000 х 1800(высота);

• лифт на крышу наружный;

• надстройка мансарды или зимнего сада на крыше;

• пристройка к дому на месте террасы и/или крыльца.

Как итог получаем по-настоящему качественный и по-настоящему доступный по стоимости теплоемкий дом, готовый для постоянного проживания.

Дом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этажДом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этаж

Благодарю за внимание.

P.S.:

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

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

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

Среда разработки

Пусть меня закидают грязными тряпками, но тут для меня однозначно лучшая - Keil uVision (4)5. Эта одна из самых мощных IDE для большого количества камней. Я даже не буду агитировать за нее и описывать все преимущества, поскольку мое мнение в данном вопросе крайне предвзято. Просто я давно работаю с этой IDE и она мне нравится. Самый большой ее минус - она платная и стоит очень конских денег. Но только не в данном случае. На наше счастье у Keil есть демо режим с ограничением в 32Кб. А в LPC11C14 всего 32Кб! Получается для этого камня можно вполне легально и полноценно использовать этот мощный инструмент! Достаточно скачать его с официального сайта. Заполняем простую анкету и получаем ссылку на скачку.

Остался открытым вопрос работы с "железом". Самый удобный - это использовать заводской программатор. Keil поддерживает большое количество отладочных систем и JTAG адаптеров. Такой подход позволит вести полноценную отладку проекта. А что делать, если нет отладчика\программатора и требуется только прошить контроллер? А на этот случай есть замечательная утилита Flash Magic, которая позволяет оживить устройство, используя вшитый в ARM загрузчик. Данная утилита работает только с контроллерами NXP. Загрузка происходит через UART. Эта замечательная прога не раз выручала меня в командировках, когда под рукой не было программатора или он выходил из строя. Замечу, что все необходимые сигналы у девайса уже выведены на разъем для программирования. Ссылка для скачивания Flash Magic здесь.

Сборка платы

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

Пустышки на столе

Монтаж не заставил себя долго ждать и вот что получилось в результате:

Плата смонтирована

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

Подготовка софта

По началу тут было всё относительно просто. Пишем\адаптируем все необходимые драйверы для периферии, а именно:

• драйвер датчика освещенности MAX44009EDT

• драйвер датчика расстояния VL53L0X

• драйвер управления адресной лентой

• драйвер CAN интерфейса

После того, как все драйвера были подготовлены наступила очередь первого тестового включения на публике.

Тестовое включение

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

Здесь хотел сделать небольшое техническое отступление, поскольку хронологически событие, с которым оно связано, именно здесь и наступило. Я раньше не работал с компонентами из ближайшего магазина и цели максимально снизить стоимость у меня на работе не стоит. Спрос идет за качество. А тут я в полной мере ощутил что значит "китайское электричество до конца не изучено". Просто все работало - работало, а в один не очень прекрасный день вдруг перестало. Причина была выявлена очень быстро. Сгорел линейный стабилизатор AMS1117-5.0. И не просто сгорел сам и все, а прикинулся перемычкой и утащил с собой всех, кто на него надеялся. Цензурных слов у меня в тот момент не было. Я, как человек, привыкший доверять техническому описанию на компоненты не мог понять, что не так. Стабилизатор работал в штатном режиме. А фраза из описания "The AMS1117 series have internal power and thermal limiting circuitry designed to protect the device under overload conditions" уже была похожа на издевку. Немного полазив по просторам инета я понял, что не у меня одного такие проблемы с этим стабилизатором. А что вы хотите? Дешево! Какой спрос? Короче, не имея никакого желания заново перепаивать половину схемы я поставил годами проверенный вариант - LM1117-5.0 (кстати, не в Чип-Дипе купленный). На мое счастье он встал на плату как родной.

Ну да ладно, плата восстановлена, можно двигаться дальше.

И тут наступил какой-то творческий ступор. А что дальше? Есть железо, на котором можно сделать много разных эффектов. А что делать конкретно? Можно просто включать монотонную подсветку (неинтересно и скучно), можно поиграть с цветами (пестрота быстро надоест), можно организовать необычные динамические сцены. Много чего можно, надо на чем-то остановиться. Здесь главное не переборщить с творчеством!

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

• в темноте светится дежурная подсветка (первая ступень)

• при пересечении датчика плавно разгорается центральная полоса подсветки вдоль всего пролета лестницы (видим линию по центру вдоль пролета)

• как только линия вдоль пролета разгорелась, она разделяется на две, которые расходятся в стороны (посадочные огни вдоль полосы)

• между этими огнями начинает плавно по очереди разгораться подсветка ступеней

Это описание касается только стадии включения. Гашение ступеней можно сделать аналогично, только в обратную сторону или просто плавно погасить.

Что-же потребуется для реализации?

Чисто технически вся подсветка пролета - это один длинный кусок ленты, просто разбитый на фрагменты (ступени). А поскольку по ленте бегают достаточно быстрые управляющие сигналы, для того, чтобы не было проблем с восприятием приказов, необходимо сделать мостики между лентами максимально короткими. Да и еще крайне желательно мостики эти выполнить из витой пары:

Перемычки из витой пары между фрагментами (ступенями)

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

Логическая организация ступеней

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

Для того, чтобы проще было "рисовать" на таком "экране" и не требовалось каждый раз вычислять положение нужной LED-точки в программе подготавливается массив, содержащий "карту" их расположения:

// создание карты светодиодов (см. файл LED-карты)void CREATE_LEDS_MAP (void){static const uint8_t stepPerStair = STAIRS_NUM;static const uint8_t ledsPerStep = LEDGROUPS_FOR_STAIR;for (uint8_t step = 0; step < stepPerStair; step++){for (uint8_t led = 0; led < ledsPerStep; led++){if (step % 2 == 0){LedMap[led][step] = ((step) * ledsPerStep) + led + 1;            }            else            {LedMap[led][step] = ((step + 1) * ledsPerStep) - led;            }        }    }}

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

Не обращайте внимание на внешний вид ступени - это временный вариант

В качестве заключения

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

Печатная плата

Программа

P.S. Если у кого-то будет желание доделать или внести что-то свое могу отдать два комплекта пустышек (по комплекту на лестницу) и процы к ним (как помните, у меня их много).

Предисловие

История берет свое начало в мае, когда в один из непогожих питерских дней, местная котельная решила отключить отопление. За окном было +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 - главное, определиться с какой стороны смотреть.

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

Данные канала Rx

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

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

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

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

Скриншот из инструкции HF-LPT220

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

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 - возможно никогда-нибудь, он будет написан=).