Умный дом своими руками или Smart Home DIY

Доброго здравия, уважаемые читатели!

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

Сразу оговорюсь, чтобы избежать недопонимания: я не против Home Assistant, OpenHAB, MajorDomo и прочих готовых систем автоматизации. У меня самого имеется сервер Home Assistant, и я понимаю, почему он нравится тысячам людей. Эта статья — не манифест против него или других SH-систем и не призыв «выбросить малинку». Эта статья о другом. О том, что начинать строить DIY умный дом с Home Assistant — не обязательно. Home Assistant (и прочие) вполне может быть не основой системы, а лишь полезным, но не обязательным дополнением к ней.

 

Многие начинающие конструкторы-самодельщики, вдоволь наигравшись с Arduino-примерами и поняв, что знания уже можно применять на практике, сталкиваются с вопросом: с чего начать строительство своего личного «умного дома»? Многие идут на форумы — и очень часто читают один и тот же совет:

Возьмите “малинку”, поставьте на неё сервер Home Assistant (MajorDomo, OpenHAB, далее по вкусу отвечающего), и будет вам щасье и благолепие – на нем вы сможете настроить обработку поступающих данных и сценарии автоматизации.

Совет, в принципе, довольно хороший. Я сам по этому самому пути когда-то и пошёл — купил “малинку”, пробовал, тренировался. Но спустя время, перепробовав несколько готовых решений, поймал себя на мысли: «а оно мне вообще надо?» И в итоге понял – во многих случаях Home Assistant избыточен, он не обязателен для любого DIY-проекта. Начните с простого – а потом вы поймете, нужно ли вам большее!

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

---

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

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

Важно то, что всю автоматизацию и логику — создаете вы сами! То есть изложенный в статье вариант — это далеко не путь “взял из коробки, распаковал, поправил конфиг и работает”. Это и есть главный недостаток данного подхода. И если Вы не готовы к этому – наверное, не стоит читать дальше.

Но ведь мы говорим про “умный дом своими руками“, не так ли?

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

 

А если у вас уже есть Home Assistant?

Отлично — пользуйтесь на здоровье. Более того — никто не мешает совмещать автономные устройства, созданные на изложенных ниже принципах, прекрасно уживаются с HA, например для того, чтобы просто собирать с них данные и строить графики в удобном интерфейсе. Речь не о «или-или», а о том, что автономное устройство не должно переставать работать, когда сервер Home Assistant выключен.

 

---

Базовые принципы действительно умных устройств

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

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

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

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

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

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

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

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

Да и без этого – лишившись сети или mqtt сервера, вы теряете возможность контроля и удаленного управления, но само устройство продолжить работать, работать и работать (с) реклама батареек.

---

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

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

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

А что нужно для того, чтобы подключить некое “умное устройство” к сети и MQTT? Правильно! Проще всего использовать специально предназначенные для этого ESP8266 и ESP32.

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

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

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

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

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

 

---

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

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

Одно дело, когда вы строите свой личный умный дом и планируете автоматизировать все аспекты своей жизни. Тогда конечно, можно и одноплатник прикупить, и Home Assistant поставить…  Или даже специальный сервер. Или колонку от Яндекса и наслаждаться голосовым общением с AI.

И совсем другое – когда требуется сделать всего-лишь одно единственное устройство удаленного контроля отопительного котла на даче, маме в деревне или даже соседу. Что, для этого вам тоже потребуется сервер Home Assistant? Вот то-то и оно…

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

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

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

 

---

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

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

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

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

---

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

Много слов, мало дела. Теперь давайте “соберем” (виртуально, в данной статье кода не будет, от слова “совсем”) наше полоумное устройство. Как собрать практически – я уже писал на данном сайте. Итак…

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

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

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

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

Конечно, ESP не идеальный продукт. ESP8266 в особенности – у него мало памяти, ножек и в моем случае он показал себя довольно не надежным устройством. Да и у ESP32 есть недостатки, узкие места в производительности, памяти и т.д. Но в при использовании в домашней автоматизации – ваши потребности в большинстве случаев будут перекрыты полностью, да еще и с  хорошим таким запасом. Я ещё ни добился того, чтобы ESP32 израсходовал все свои ресурсы ни в одном моем проекте, даже с учетом десятка подключенных датчиков и управления двумя десятками реле в нескольких задачах одновременно. Хотя я старался.

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

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

 

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

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

Все это достаточно подробно описано в статье Arduino ESP32 шаг за шагом. Телеметрия через WiFi и MQTT для чайников. Этого уже достаточно для начала – а далее уже можно реализовывать прикладную логику и удаленное управление со смартфона или планшета.

Схема работы в простейшем случае:

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

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

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

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

 

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

Вот таким вот не очень сложным способом и можно построить децентрализованную, масштабируемую и вполне проверенную практикой, систему “типа умного” дома, без регистрации и SMS. Далее, при необходимости, вы сможете подключить ваше DIY автономное устройство, созданное на описанных принципах, к Home Assistant, OpenHAB и другим системам через тот-же самый MQTT без какой-либо переделки.

 

---

-= Каталог статей (список по разделам) =-   -= Архив статей (плитки, все подряд) =-

Небольшой анонимный опрос: какие статьи вы предпочитаете?