Добрый день, уважаемые читатели! В данной статье я поделюсь с вами своим вариантом реализации "дома с зачатками разума", без использования центрального сервера автоматизации (сервера "умного дома") в локальной сети.
Многие начинающие конструкторы-самодельщики, вдоволь наигравшись с Arduino примерами, и поняв, что уже можно применять новые знания на практике и начать создавать свой собственный "умный дом", сталкиваются с проблемой: а с чего собственно начинать, какую технологию использовать? На текущий момент существует огромное множество вариантов и технологий, от open source до промышленных решений. Выбрать из этого "зоопарка" то, что подходит именно вам - не простая задача даже для человека опытного, а уж для начинающего DIY-самоделкина и вовсе непосильный труд. Что делает в таком случае человек? Правильно - идет читать форумы и умных людей на них (точно так же поступил в свое время и я сам).
А что пишут на форумах по этому поводу в большинстве случаев?
Возьмите "малинку", поставьте на неё Home Assistent (MajorDomo, OpenHub, далее по вкусу отвечающего), и "будет вам щасье и благолепие"!
Что ж, покупаем, пробуем, тренируемся...
Но только спустя некоторое время, перепробовав несколько вариантов готовых решений, приходит понимание - "а оно вам надо???". Этот путь прошёл и я сам, но потом отказался от этой идеи.
До чего я докатился в итоге, я и расскажу в этой статье.
Warning! Предупреждение!
Если Вы пожелаете реализовать автоматизацию (ну не люблю я термин "умный дом") по тем же принципам, что и у меня, то Вы должны будете создавать и программировать свои устройства самостоятельно. Хоть в Arduino IDE, хоть в ESP-IDF, хоть в PlatformIO, хоть на Python или на чем-то ещё - это, в общем-то, и не важно. Важно то, что всю логику - создаете вы сами! То есть мой вариант это далеко "взял из коробки, распаковал и работает". Это главный недостаток моего подхода, не спорю. И если Вы не готовы к этому - наверное, не стоит читать дальше. Но взамен мы получаем ни с чем не сравнимое удовольствие от творчества.
Разумеется, предложенная с статье схема применяемых технологий не единственно возможная, и я не призываю вас делать "так и только так", слепо следуя этому, но она имеет полное право на жизнь во многих прикладных случаях. Меня пока удовлетворяет на 100%. Но я открыт для новых идей, все может измениться со временем. Главное условие - чтобы они удовлетворяли базовым принципам, о которых ниже.
Базовые принципы
Изложу принципы, на основе которых я проектирую, изготавливаю и программирую устройства своего дома с зачатками разума. Я уже не раз упоминал о них на своем канале, но сформулирую их ещё раз. Их всего два.
Вся автоматика должна работать тихо и незаметно, без какого-либо вмешательства пользователя, в том числе и в нештатных ситуациях.
Это самое главный мой принцип. Вы один раз установили и настроили какую-либо автоматику, а затем она должна работать уже максимально автономно, без вмешательства со стороны человека.
- Заболели вы или уехали в отпуск - автоматика должна продолжать свою работу с теми параметрами, которые были получены от пользователя в последний раз. Если необходимо изменять какие-либо параметры работы в зависимости от времени, то стоит предусмотреть некое расписание - например изменение температуры в доме в зависимости от дня недели и времени суток.
- Полностью автономная работа не всегда возможна, и если логика работы требует периодического вмешательства человека (например для той же регулировки температуры в доме), то с этим должен справится любой член семьи - то есть такое вмешательство должно быть максимально простым и понятным для всех. Недопустимо завязывать всю автоматику в доме только на самого себя.
- Любые "внешние" причины не должны приводить к прерыванию основной прикладной логики. Пропал интернет, сгорел роутер, вышел из строя какой-то сервер, сломался смартфон управления, отключили электричество (если устройство имеет автономное питание) - автоматика должна продолжать свою основную работу с последними полученными от пользователя параметрами в меру существующих в данный момент ограничений.
- Если устройство все-таки вышло из строя - должен быть предусмотрен некий аварийный выключатель для перевода автоматической системы на ручной режим, с которым сможет справится любой член семьи. Особенно это относится к системам жизнеобеспечения, например - управление котлом.
Из этих принципов напрямую следуют следующие выводы:
- Максимально (насколько это возможно в данном конкретном случае) исключаются "ручные" режимы управления. То есть принцип "мне не сложно включить насос котла со смартфона вручную" - не катит принципиально. Как не подходят и всевозможные искусственные интеллекты вроде Алисы и Гугла, так как по сути всего лишь пульты дистанционного голосового управления.
- Все необходимые для работы прикладной логики данные должны быть получены с датчиков, непосредственно подключенных к устройству. Но это не всегда возможно, поэтому иногда приходится получать какие-то данные с соседних устройств. В этом случае необходимо ещё на этапе проектирования предусмотреть запасные варианты работы при проблемах со связью.
- Исключаются схемы работы с использованием любого центрального сервера автоматизации (например Home Assistant и прочие), так как в случае отказа сети или сервера вся автоматика в доме накрывается медным или иным тазом. В случае отказа полностью автономных устройств (как описано выше) это грозит потерей только этого устройства.
Разумеется, полностью избавится от сторонних устройств не удасться. У вас всё равно будет "центральный роутер" и "центральный MQTT-брокер". Но роутер и MQTT брокер в данном контексте не стоит рассматривать как "центральный сервер", так как сам по себе он не содержит никакой прикладной логики и его легко "на лету" заменить на другой (резервный) без потери функциональности. Ну например у меня в прошивке одновременно можно "прописать" два брокера - основной и резервный, и устройство само по себе самостоятельно умеет переключаться между ними при необходимости.
Удаленный контроль и управление
Помимо автономности, лично для меня на текущий момент критически важно наличие удаленного контроля и управления устройствами дома с зачатками разума. Причем удаленное управление должно быть по настоящему "удаленным", то есть работать из любой точки, где есть доступ в сеть интернет, а не только из локальной сети дома или квартиры. С работы, из отпуска, из дома на даче и наоборот.
Отсюда выводы:
- Все мои устройства на данный момент построены на базе ESP32 или ESP8266, так как они имеют "на борту" встроенный WiFi-интерфейс. Их вычислительных ресурсов хватит для всех бытовых (и не только) потребностей автоматизации. Они не дороги и легко доступны.
- Я никогда не создавал web-интерфейсы для управления устройствами просто через браузер, потому что это не работает извне локальной сети; да и просто не удобно, если у вас больше одного устройства автоматики.
- Я никогда не использовал и даже не рассматривал BLE (Bluetooth Low Energy) или Bluetooth в своих разработках, так как это работает только на малых расстояниях.
- По этой же причине не очень хорошо подходят и решения на базе Home Assistant, так как он разработан для управления из локальной сети.
С моей точки зрения для этой цели лучше всего подходит простой и надежный mqtt-протокол, никто ещё не придумал ничего проще и лучше.
Иногда можно встретить упреки, что WiFi - это архи-ненадежно и далеко не небезопасно. Нужно использовать только кабель, только hardcore. С одной стороны это конечно верно, провод надежнее. Но во первых, такое возможно только в квартире. Вы попробуйте "раскидать" пару десятков кабелей "витой пары" по дому и участку в частном доме... А во вторых - даже если вы протянули условную витую пару к условной теплице, что мешает его повредить, даже неумышленно, например мышкам? Я уже молчу о применении дополнительных аппаратных компонентов.
Почему ещё я не использую Home Assistant, Алису и прочую облачность? Масштабируемость!
Стоит упомянуть об еще одном аспекте, почему я перестал использовать Home Assistant и даже смотреть в их сторону.
Одно дело, когда вы строите свой личный умный дом и планируете автоматизировать все аспекты своей жизни. Тогда конечно, можно и Parspberry Pi прикупить, и Home Assistant поставить... Или колонку от Яндекса и наслаждаться голосовым общением.
И совсем другое - когда нужно сделать всего-лишь одно единственное устройство удаленного контроля отопительного котла на даче. Что, для этого вам тоже потребуется выделенный сервер? Вот то-то и оно...
А изучать и вникать в две разных системы - нет уж, увольте. Я лучше потрачу это же время на то, чтобы "лучшее и глубжее" изучить что либо одно. Например ESP-IDF в моем случае.
Кроме того, лишний сервер - лишние затраты и лишняя точка отказа. Такое себе... А оно вам надо?
Другими словами, мои устройства на базе 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, и по производительности. Что дальше?
Удаленный контроль и управление через WiFi
Так как нам требуется удаленное управление (см. главу "базовые принципы" выше), в первую очередь потребуется подключить наше устройство к точке доступа WiFi. Сделать для Arduino это очень просто, для ESP-IDF громоздко, но тоже не слишком сложно.
Разумеется, вариантов подключения к WiFi великое множество. После того, как подключения к WiFi установлено - подключаемся к MQTT-серверу. Публичных серверов - более чем достаточно.
И всё готово - можно реализовывать прикладную логику и удаленное управление со смартфона или планшета. Схема работы в простейшем случае:
Программ-клиентов для MQTT изобретено большое количество, на любой цвет и вкус: поставил, настроил и радуйся! Если вы используете "правильный" брокер, то можно настроить несколько пользователей, разделение доступов и зон ответственности и прочие плюшки. И все это вполне бесплатно - было бы желание все изучить и разобраться.
Обмен данными между устройствами в локальной сети: добавляем локальный брокер
Эта схема при должном подходе работает отлично, пока устройств немного. Каждое из них обладает полным набором датчиков, необходимых ему для работы, поэтому при пропадании доступа к публичному брокеру ничего ужасного не происходит - просто отсутствует возможность контроля и изменения параметров работы.
На каком то этапе начинаешь понимать, что к каждому устройству невозможно подключить все необходимые датчики. Просто физически невозможно. А иногда и экономически нецелесообразно.
То есть мы приходим к необходимости обмена данными между отдельными устройствами в локальной сети. О!!! - скажут любители Home Assistant, - "а мы предупреждали!". "А вот и нет" - отвечу я! Для того, чтобы отправить данные о температуре воздуха с метеостанции на термостат вовсе не требуется ставить мощный сервер, достаточно передать всего-то 4 байта данных заинтересованным лицам модулям. Способов много - можно, например, попытаться сделать это через радиоканал. Но как это сделать проще всего?
Да нет ничего проще - через тот же самый MQTT брокер! Он же как раз для этого и предназначен! Но постойте, а как-же быть когда интернет отвалился? Хм, тогда нам понадобится локальный MQTT-брокер. А для внешнего управления настраиваем специальное соединение - так называемый "мост" - на внешний брокер.
Что дает локальный брокер внутри сети:
- возможность простого способа общения устройство внутри сети практически без переписывания кода прошивки
- большая безопасность - критичные данные можно вообще не передавать за пределы локального брокера и локальной сети
- снижение нагрузки на внешний брокер - лишние данные опять же можно просто не отправлять "наружу"
- нет необходимости поддерживать TLS-подключения внутри сети
- в случае неисправности локального брокера устройства могут легко "перепрыгнуть" на резервный публичный брокер, так как используется один и тот же протокол связи
Локальный MQTT-брокер, конечно же, потребует дополнительных затрат в виде "малинки", но можно поднять локальный MQTT-брокер и на ESP и даже на самом роутере.
Кроме этого, к локальному брокеру можно подключить локальные панели управления в случае необходимости, что позволит управлять умным домом даже в случае отсутствия интернета.
Уведомления в telegram
Протокол MQTT прост, легок, и достаточно удобен. Но и у него есть недостатки. Например с помощью него невозможно отправить срочное уведомление на смартфон или компьютер о тех или иных событиях.
Самый простой и универсальный способ отправки оперативных уведомлений - это telegram bot. Telegram API достаточно прост, работа с ним возможна путем простых html-запросов. К достоинствам этого метода можно отнести следующее:
- Нет необходимости создавать свое приложение-велосипед для push-уведомлений на смартфон.
- Простой и легкий API для отправки уведомлений.
- Уведомления будут практически синхронно доставляются и на смартфоны и на "взрослые" компьютеры.
- Легкая и удобная доставка сообщений в группы, то есть сразу нескольким получателям одновременно (например для всех членов семьи)
Что ж, в этом случае схема будет выглядеть следующим образом:
Нужны уведомления на электронную почту? Штош, это тоже можно реализовать, протокол не сильно сложный.
Шлюз Telegram - MQTT
Описанным выше образом мы можем только отправлять уведомления из ESP в клиент на смартфоне. Но Telegram API позволяет не только отправлять уведомления с устройства на смартфон или компьютер, но и наоборот - отправлять команды управления с телефона на ваши умные устройства.
Пока у вас только одно устройство - с этим не возникает никаких сложностей. Потребуется только добавить код запроса данных из API, распарсить ответ от API и обработать входящие сообщения. Технически в этом нет ничего невозможного.
Но вот устройств стало два. И схема работы ломается.
- Во-первых, Telegram API не позволяет "читать" обновления в чатах с двух устройств одновременно с одного аккаунта бота. Отправить уведомления - пожалуйста. А вот получать команды - только каждый свои. Но вы не сможете создать больше 20 ботов на один аккаунт.
- Во-вторых - как распознать какая команда какому устройству предназначена? Создавать к каждому устройству свой чат - архи не удобно. Разные команды для разных устройств - замучаешься программировать.
В общем, есть у меня идея. Пока на стадии проекта. Создать программу для сервера (или на базе той-же ESP32, я пока обдумываю варианты) шлюз "MQTT <-> Telegram API".
- Шлюз должен подключаться с MQTT брокеру, с одной стороны; и к Telegram API - с другой стороны. При появлении команды она просто транслируется в публикацию соответствующего топика на MQTT-брокере. И наоборот, при запросе данных из MQTT шлюз должен подписаться на топик, считать данные и сформировать из них понятное сообщение.
- Шлюз должен быть полностью настраиваемым через какой-либо интерфейс. То есть не требовать внесения изменений в уже готовую прошивку устройства.
Это позволит не только реализовать не только достаточно гибкую систему, но и переложить основную нагрузку по обмену данными с API на другие плечи. Похожие системы уже появлялись в сети, но почему-то не прижились.
Добавим графики
Ещё одна проблема, которая вытекает из MQTT-протокола - это невозможность фиксации каких-либо данных во времени. MQTT-брокер по сути это простой маршрутизатор, он хранит максимум только самое последнее пересылаемое сообщение.
Но это не проблема. Для накопления данных и построения по ним графиков существует масса готовых к употреблению сервисов, например:
- thingspeak.com
- open-monitoring.online
- narodmon.ru
и многие другие. Есть из чего выбрать. Как правило, отправка необходимых данных на такие сервисы осуществляется так же с помощью простых HTTPS-запросов. Про упомянутые в списке я уже писал на данном канале:
Примеры использования данных сервисов:
Осталось только дополнить нашу схему для лучшей наглядности.
Вместо заключения
Вот таким вот не очень сложным способом и можно построить децентрализованную, масштабируемую и вполне проверенную практикой, систему "типа умного" дома. Или полоумного? Но без регистрации и SMS.
Есть дополнительные идеи? Прошу в комментарии!
________
Обращение к читателям: мой основной сайт: kotyara12.ru. Все статьи, опубликованные на канале, существуют и на сайте. Более того, я поддерживаю статьи в актуальном состоянии (редактирую, дополняю и исправляю замеченные ошибки) только на указанном выше сайте (ибо на это тратится ужасно много времени, а смысла нет). Так что я рекомендую вам читать статьи там - полный архив статей сайта вы найдете по этой ссылке. А дабы не пропустить "новости", вы можете воспользоваться telegram-каналом: https://t.me/kotyara12. До новых встреч!
