Умный дом без “умного дома”

Добрый день, уважаемые читатели! В данной статье я поделюсь с вами своим вариантом реализации “дома с зачатками разума”, без использования центрального сервера автоматизации (сервера “умного дома”) в локальной сети.

Многие начинающие конструкторы-самодельщики, вдоволь наигравшись с Arduino примерами, и поняв, что уже можно применять новые знания на практике и начать создавать свой собственный “умный дом”, сталкиваются с проблемой: а с чего собственно начинать, какую технологию использовать? На текущий момент существует огромное множество вариантов и технологий, от open source до промышленных решений. Выбрать из этого “зоопарка” то, что подходит именно вам – не простая задача даже для человека опытного, а уж для начинающего DIY-самоделкина и вовсе непосильный труд. Что делает в таком случае человек? Правильно – идет читать форумы и умных людей на них (точно так же поступил в свое время и я сам).

А что пишут на форумах по этому поводу в большинстве случаев?

Возьмите “малинку”, поставьте на неё Home Assistent (MajorDomo, OpenHub, далее по вкусу отвечающего), и будет вам щасье и благолепие!

Что ж, покупаем, пробуем, тренируемся… Но только спустя некоторое время, перепробовав несколько вариантов готовых решений, приходит понимание – “а оно вам надо???“. Этот путь прошёл и я сам, но потом отказался от этой идеи.

До чего я докатился в итоге, я и расскажу в этой статье.

---

Warning! Предупреждение!

Если Вы пожелаете реализовать автоматизацию (ну не люблю я термин “умный дом”) по тем же принципам, что и у меня, то Вы должны будете создавать и программировать свои устройства самостоятельно. Хоть в Arduino IDE, хоть в ESP-IDF, хоть в PlatformIO, хоть на Python или на чем-то ещё – это, в общем-то, и не важно. Важно то, что всю логику – создаете вы сами! То есть мой вариант это далеко “взял из коробки, распаковал и работает”. Это главный недостаток моего подхода, не спорю. И если Вы не готовы к этому – наверное, не стоит читать дальше. Но взамен мы получаем ни с чем не сравнимое удовольствие от творчества.

Разумеется, предложенная с статье схема применяемых технологий не единственно возможная, и я не призываю вас делать “так и только так”, слепо следуя этому, но она имеет полное право на жизнь во многих прикладных случаях. Меня пока удовлетворяет на 100%. Но я открыт для новых идей, все может измениться со временем. Главное условие – чтобы они удовлетворяли базовым принципам, о которых ниже.

---

Базовые принципы

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

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

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

• Заболели вы или уехали в отпуск – автоматика должна продолжать свою работу с теми параметрами, которые были получены от пользователя в последний раз. Если необходимо изменять какие-либо параметры работы в зависимости от времени, то стоит предусмотреть некое расписание – например изменение температуры в доме в зависимости от дня недели и времени суток.
• Полностью автономная работа не всегда возможна, и если логика работы требует периодического вмешательства человека (например для той же регулировки температуры в доме), то с этим должен справится любой член семьи – то есть такое вмешательство должно быть максимально простым и понятным для всех. Недопустимо завязывать всю автоматику в доме только на самого себя.
• Любые “внешние” причины не должны приводить к прерыванию основной прикладной логики. Пропал интернет, сгорел роутер, вышел из строя какой-то сервер, сломался смартфон управления, отключили электричество (если устройство имеет автономное питание) – автоматика должна продолжать свою основную работу с последними полученными от пользователя параметрами в меру существующих в данный момент ограничений.
• Если устройство все-таки вышло из строя – должен быть предусмотрен некий аварийный выключатель для перевода автоматической системы на ручной режим, с которым сможет справится любой член семьи. Особенно это относится к системам жизнеобеспечения, например – управление котлом.

Из этих принципов напрямую следуют следующие выводы:

• Максимально (насколько это возможно в данном конкретном случае) исключаются “ручные” режимы управления. То есть принцип “мне не сложно включить насос котла со смартфона вручную” – не катит принципиально. Как не подходят и всевозможные искусственные интеллекты вроде Алисы и Гугла, так как по сути всего лишь пульты дистанционного голосового управления.
• Все необходимые для работы прикладной логики данные должны быть получены с датчиков, непосредственно подключенных к устройству. Но это не всегда возможно, поэтому иногда приходится получать какие-то данные с соседних устройств. В этом случае необходимо ещё на этапе проектирования предусмотреть запасные варианты работы при проблемах со связью.
• Исключаются схемы работы с использованием любого центрального сервера автоматизации (например Home Assistant и прочие), так как в случае отказа сети или сервера вся автоматика в доме накрывается медным или иным тазом. В случае отказа полностью автономных устройств (как описано выше) это грозит потерей только этого устройства.

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

2. Мне необходим удаленный контроль и управление

Помимо автономности, лично для меня на текущий момент критически важно наличие удаленного контроля и управления устройствами дома с зачатками разума. Причем удаленное управление должно быть по настоящему “удаленным”, то есть работать из любой точки, где есть доступ в сеть интернет, а не только из локальной сети дома или квартиры. С работы, из отпуска, из дома на даче и наоборот. А для управления устройств “за NAT-ом” возможен только один простой вариант – с использованием промежуточного “облачного” сервера (таки да, я знаю про другие варианты, но в виду сложности и ограниченности использования я их изначально не рассматривал). 

То есть лично для меня облачный сервер абсолютно необходим – тут без вариантов. Вопрос – какой? С моей точки зрения для этой цели лучше всего подходит простой и надежный MQTT-протокол, никто ещё не придумал ничего проще и лучше. Да, MQTT-брокер это тоже обычно “облачный” сервер, но при острой необходимости можно использовать и только локальный.

Отсюда выводы:

• Все мои устройства на данный момент построены на базе ESP32 или ESP8266, так как они имеют “на борту” встроенный WiFi-интерфейс. Их вычислительных ресурсов хватит для всех бытовых (и не только) потребностей автоматизации. Они не дороги и легко доступны.
• Я никогда не создавал web-интерфейсы для управления устройствами просто через браузер, потому что это не работает извне локальной сети; да и просто не удобно, если у вас больше одного устройства автоматики.
• Я никогда не использовал и даже не рассматривал BLE (Bluetooth Low Energy) или Bluetooth в своих разработках, так как это работает только на малых расстояниях.
• По этой же причине не очень хорошо подходят и решения на базе Home Assistant и прочих готовых систем “умного дома”, так как они изначально разработаны для управления из только локальной сети. Да, я знаю что при должной настройке это не так, но тем не менее – про готовые облачные серверы Home Assistant для публичного использования я таки ни разу не слышал.

Иногда можно встретить упреки, что WiFi – это архи-ненадежно и далеко не небезопасно. Нужно использовать только кабель, только hardcore.

С одной стороны это конечно верно, провод надежнее. Но во первых, такое возможно только в квартире. Вы попробуйте “раскидать” пару десятков кабелей “витой пары” по дому и участку в частном доме… А во вторых – даже если вы протянули условную витую пару к условной теплице, что мешает его повредить, даже неумышленно, например мышкам? Я уже молчу о применении дополнительных аппаратных компонентов.

Хотя, с другой стороны, я часто использую проводной интерфейс RS485 внутри помещений, но там, где это возможно и действительно целесообразно. Это позволяет подключать множество “периферийных” устройств и датчиков к одному контроллеру.

 

---

Почему я не использую Home Assistant, Алису и прочую облачность? Масштабируемость!

Стоит упомянуть об еще одном аспекте, почему я перестал использовать Home Assistant (хотя начинал как и все с него) и даже смотреть в их сторону.

Одно дело, когда вы строите свой личный умный дом и планируете автоматизировать все аспекты своей жизни. Тогда конечно, можно и Parspberry Pi прикупить, и Home Assistant поставить… Или колонку от Яндекса и наслаждаться голосовым общением. И совсем другое – когда нужно сделать всего-лишь одно единственное устройство удаленного контроля отопительного котла на даче соседу (или даже только для себя любимого). Что, для этого вам тоже потребуется выделенный сервер Home Assistant? Вот то-то и оно…

А изучать и вникать в глубины двух (или более) разных систем – нет уж, увольте. Я лучше потрачу это же время на то, чтобы “лучшее и глубжее” изучить что либо одно. Например ESP-IDF в моем случае.

Кроме того, лишний сервер – лишние затраты и лишняя точка отказа. Такое себе… А оно вам надо? Да, публичный брокер – это такая же точка отказа, НО ЕСТЬ ЖИРНОЕ “НО” – в случае с mqtt вы можете в течении пары секунд перепрыгнуть с основного брокера на резервный без каких либо потерь в функциональности. Или настроить в прошивке даже два, или три резервных брокера. Попробуете провернуть такое с HA – какие будут затраты?

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

 

---

Почему я не люблю использовать готовые покупные решения?

Сейчас множество производителей предлагает еще большее множество готовых решений “умных домов”. Казалось бы – вот оно, щасье! Купил, установил и радуйся! И я тоже пытался пойти по этому пути. Но здесь вас подстерегает несколько подводных камней:

• Иногда предлагаемый из коробки функционал не очень-то и подходит к конкретным условиям работы, а возможность внести изменения самому в логику работы отсутствует.
• Целый зоопарк самых разных протоколов и систем, которые зачастую не совместимы между собой. Появляется необходимость в различных шлюзах и дополнительных устройствах.
• Как правило, все современные “умные дома из коробки” завязаны на интернет и облачность. Нет ножек – нет и компотика связи (например с китайским сервером), нет и работоспособности. А это в корне противоречит изложенным выше принципам. Да, далеко не всегда в условиях offline готовые решения превращаются в тыкву, но быть “завязанным” на сторонние сервера за границей не особенно полезно.
• Даже именитые бренды не застрахованы от ошибок в прошивках своих устройств. Однажды я столкнулся даже с откровенным хамством со стороны производителя (это был Falcon Eye), когда я обратился в техподдержку по поводу купленного устройства с указанием проблемы. В Falcon Eye проблему подтвердили и посоветовали его выкинуть и купить другую модель. Вот так.
  Конечно, ни одно устройство не застраховано от ошибок в коде. И мои тоже. Но я хотя бы могу ошибку найти и исправить, в случае необходимости. А вот в готовом устройстве чаще всего это невозможно. Именно по этой причине я предпочитаю делать все своими руками.

---

Пошаговое руководство

С теоретическими аспектами познакомились. Но! Много слов, мало дела. Давайте “соберем” наше полоумное устройство, хотя бы виртуально. Как собрать практически, я и так уже рассказывал и буду рассказывать на данном канале. Итак…

Микроконтроллер

Мы определились, что для удаленного управления будем использовать WiFi-сеть с дальнейшим доступом в интернет. Доступных микроконтроллеров с WiFi на борту не так уж и много: ESP8266, ESP32, Easpberry Pico W и возможно что-то еще, не интересовался особо. Первые два из списка покроют все мои потребности.

Теоретически для устройств автоматики можно использовать любой микроконтроллер, и подключить к нему WiFi-адаптер на базе того же ESP c “заводской” прошивкой, которая позволяет работать через AT-команды. Что-то вроде этого:

Но ESP8266, а тем более ESP32 – сам по себе достаточно мощный SoC, на котором можно (и нужно) реализовать всю прикладную логику. А если это так, то зачем платить дважды?

Конечно, ESP не идеальный продукт. ESP8266 в особенности – он показал себя довольно не надежным. Но и у ESP32 есть узкие места и с точки зрения пропускной способности памяти и кое-что ещё. Но в при использовании в домашней автоматизации – а не все ли оно Вам равно?!!! Ваши потребности в производительности будут перекрыты полностью, да еще и с запасом. Я ещё ни разу не израсходовал все ресурсы ни в одном своем проекте, даже с учетом десятка подключенных датчиков и управления двумя десятками реле в нескольких задачах одновременно. Разумеется, если вы не будете пытаться городить на ESP какой-нибудь искусственный интеллект с распознаванием видео – тут его ресурсов может и не хватить (хотя я не пробовал, судить на 100% не могу).

Ещё один тип часто встречающихся диаметрально противоположных комментариев, особенно для простых устройств типа автополивайки: “ESP32?! Зачем это здесь? Расточительство! 8-битного AVR хватит! Ужос, ужос, ужос!!!“. Позвольте, а на 8-битном МКУ вы сделаете удаленное управление, OTA, графики и прочие плюшки? То-то и оно…

Итак, с микроконтроллером определились – ESP32 нам вполне подходит. И по цене, и по популярности, и по наличию WiFi, и по производительности. Что дальше?

Шаг 1. Удаленный контроль и управление через WiFi

Так как нам требуется удаленное управление (см. главу “базовые принципы” выше), в первую очередь потребуется подключить наше устройство к точке доступа WiFi. Разумеется, вариантов подключения к WiFi великое множество.  Сделать для Arduino это очень просто, для ESP-IDF как-то громоздко и поначалу не полнятно, но тоже не слишком сложно (ссылки кликабельны и ведут на другие статьи на данном сайте).

После того, как подключения к WiFi установлено – подключаемся к MQTT-серверу. Публичных серверов – более чем деостаточно, есть из чего выбрать. И всё готово – можно реализовывать прикладную логику и удаленное управление со смартфона или планшета. Схема работы в простейшем случае:

Что дает локальный брокер внутри сети:

• возможность простого способа общения устройство внутри сети практически без переписывания кода прошивки
• большая безопасность – критичные данные можно вообще не передавать за пределы локального брокера и локальной сети
• снижение нагрузки на внешний брокер – лишние данные опять же можно просто не отправлять “наружу”
• нет необходимости поддерживать TLS-подключения внутри сети
• в случае неисправности локального брокера устройства могут легко “перепрыгнуть” на резервный публичный брокер, так как используется один и тот же протокол связи

Локальный MQTT-брокер, конечно же, потребует дополнительных затрат в виде “малинки”, но можно поднять локальный MQTT-брокер и на ESP и даже на роутере определенной модели.

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

Шаг 3. Добавляем уведомления в telegram

Протокол MQTT прост, легок, и достаточно удобен. Но и у него есть недостатки. Например с помощью него невозможно отправить срочное уведомление на смартфон или компьютер о тех или иных событиях. Нет, ну можно что-то придумать, конечно, но сложно…

Самый простой и универсальный способ отправки оперативных уведомлений – это telegram bot. Telegram API достаточно прост, работа с ним возможна путем простых html-запросов. К достоинствам этого метода можно отнести следующее:

• Нет необходимости создавать свое приложение-велосипед для push-уведомлений на смартфон. Оно уже есть. И для Android, и для других ОС
• Простой и легкий API для отправки уведомлений.
• Уведомления будут практически синхронно доставляются и на смартфоны и на “взрослые” компьютеры.
• Легкая и удобная доставка сообщений в группы, то есть сразу нескольким получателям одновременно (например для всех членов семьи)

Что ж, в этом случае схема будет выглядеть следующим образом:

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

Шлюз Telegram – MQTT

Описанным выше образом мы можем только отправлять уведомления из ESP в клиент на смартфоне. Но Telegram API позволяет не только отправлять уведомления с устройства на смартфон или компьютер, но и наоборот – отправлять команды управления с телефона на ваши умные устройства.

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

Но вот устройств стало два. И схема работы ломается.

• Во-первых, Telegram API не позволяет “читать” обновления в чатах с двух устройств одновременно с одного аккаунта бота. Отправить уведомления – пожалуйста. А вот получать команды – только каждый свои. Но вы не сможете создать больше 20 ботов на один аккаунт.
• Во-вторых – как распознать какая команда какому устройству предназначена? Создавать к каждому устройству свой чат – архи не удобно. Разные команды для разных устройств – замучаешься программировать.

В общем, есть у меня идея. Пока на стадии проекта. Создать программу для сервера (или на базе той-же ESP32, я пока обдумываю варианты) шлюз “MQTT <-> Telegram API“.

• Шлюз должен подключаться с MQTT брокеру, с одной стороны; и к Telegram API – с другой стороны. При появлении команды она просто транслируется в публикацию соответствующего топика на MQTT-брокере. И наоборот, при запросе данных из MQTT шлюз должен подписаться на топик, считать данные и сформировать из них понятное сообщение.
• Шлюз должен быть полностью настраиваемым через какой-либо интерфейс. То есть не требовать внесения изменений в уже готовую прошивку устройства.

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

 

Шаг 4. Добавим графики

Ещё одна проблема, которая вытекает из MQTT-протокола – это невозможность фиксации каких-либо данных во времени. MQTT-брокер по сути это простой маршрутизатор, он хранит максимум только самое последнее пересылаемое сообщение.

Но это не большая проблема. Для накопления данных и построения по ним графиков существует масса готовых к употреблению сервисов, например:

• thingspeak.com
• open-monitoring.online
• narodmon.ru
• и многие другие.

Есть из чего выбрать. Как правило, отправка необходимых данных на такие сервисы осуществляется так же с помощью простых HTTPS-запросов.  Причем не запрещается их комбинировать в разных сочетаниях – здесь все зависит только от вашего желания.

Вам не хочется использовать облачные сторонние сервисы? Ничто не мешает сделать личный локальный – способов не просто много, а очень много, на разных платформах и системах. Было бы желание.

Примеры использования данных сервисов:

Осталось только дополнить нашу схему для лучшей наглядности.

---

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

Вот таким вот не очень сложным способом и можно построить децентрализованную, масштабируемую и вполне проверенную практикой, систему “типа умного” дома. Или полоумного? Но без регистрации и SMS.

Любой компонент (telegram, облачный серсис) может быть отключен или подключен в любой момент, по желанию и необходимости. В случае его временной неисправности (например не доступен Thing Speak или Telegram API) так же никакой катастрофы не случится. Кроме MQTT-протокола, разумеется, но он может быть продублирован, чтобы исключить потерю удаленного управления.

Есть дополнительные идеи? Прошу в комментарии! На этом пока всё, до встречи на сайте и на telegram-канале! 

💠 Полный архив статей вы найдете здесь