Перейти к содержимому

Умный дом: принципы функционирования и используемые технологии

Добрый день, уважаемый читатель! В данной очень небольшой статье я опишу основные принципы функционирования моего “дома с зачатками разума” (далее: ДсЗР) (© не мое, но мне очень нравится эта фраза), а так же используемый стек технологий и сервисов. Я осваиваю ESP-IDF уже несколько лет, и уже успел получить некоторый опыт и наработки, которыми и хотел бы поделиться с вами на этом канале. Я отнюдь не призываю вас строго следовать тем же самым принципам, но большинство дальнейших статей будет посвящено описанным технологиям. Использовать только что-то из этого или все – ваш выбор.

 


Базовые принципы моего ДсЗР

Сейчас я выскажу одну очень крамольную мысль, прошу сильно тапками не кидать. Но я действительно считаю, что всякие исскуственные интеллекты типа Алексы, Алисы и Гугла – это чистой воды “понты“. Знаю, что считается очень круто сделать голосовое управление “Алиса, прибавь на 1 градус теплее” или “Алиса, включи свет попугаям”. Извините, но мне не составляет труда проделать все то же самое руками, да это зачастую и быстрее. И уж тем более передавать управление домом какому-то внешнему мифическому существу (ИИ) я тем более не собираюсь. Простое дистанционное управление типа “нажал на телефоне кнопку – включился котёл”, а также беспроводные кнопки и выключатели без какой-либо логики так же меня не восхищают. Я считаю что “умный дом” может считаться таковым, когда устройства, его составляющие, действуют по своим собственным сценариям. То есть “умное” устройство должно выполнять действия, которые человеку выполнять регулярно затруднительно или вовсе невозможно. Например:

  • управление проветриванием теплицы по датчикам температуры
  • автоматический полив комнатных цветов в отсутствие хозяев
  • управление проветриванием погреба по датчику влажности
  • включение вытяжки в санузле после принятия душа
  • управление освещением по датчикам движения и расписанию
  • управление насосной станцией
  • гидропоника

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

То есть, все автоматические сценарии управления должны быть зашиты только “внутри” самого устройства. Центральные устройства с “внешними” сценариями управления (на каком-то сервере), вроде Алисы или Home Assistant, в эту схему вписываются плохо.

Но вместе с этим, устройство должно иметь возможность удаленного управления и контроля через сеть интернет. Об этом я уже писал в предыдущей статье. Варианты управления только в локальной сети (типа Home Assistant и прочие) – лично для меня не годятся принципиально. Предупреждая возможные комментарии: я таки знаю, что можно открыть доступ к Home Assistant “наружу”, но это не совсем безопасно и не очень легко. В итоге Parspberry Pi 3 c Home Assistant на борту лежит в коробочке уже несколько лет без дела. Побаловался и хватит.

Ну например, представим задачу: создать устройство удаленной телеметрии дачи с функциями охранно-пожарной сигнализации. Устройство только одно в доме. Как эту задачу решать с помощью Home Assistant? Покупать малинку только ради этой задачи? А на одной-единственной ESP32 – легко. “И зверей убивать не надо” (с) Простоквашино.

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

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

Почему именно так? Чтобы использовать только уже готовые приложения из Google Play, а не писать что-то свое.

 


MQTT

Основным протоколом для удаленного контроля и управления является MQTT. Простой, легкий и надежный. Приложений для смартфона – масса, выбирай на вкус. С помощью MQTT свести на одну панель данные с разных устройств – это вообще не проблема. Главное, чтобы все устройства были подключены к одному брокеру. Да и в случае разных брокеров свести данные воедино достаточно просто.

Не сочтите за рекламу, но я уже давно пользуюсь Mqtt Dash. Очень крутое приложение, и работает даже на Android 4, что позволяет использовать старые планшеты или телефоны в качестве панелей управления.

Пример панели управления из старого смартфона с отслоившимся экраном

Как я уже упоминал выше, я использую свой личный локальный MQTT-брокер, с которым непосредственно контактируют устройства. Его можно установить на микрокомпьютер Raspberry Pi или на некоторые роутеры например Keenetic. Дабы иметь возможность управлять устройствами со смартфона в любой точке пространства, на локальном брокере настраивается мост на любой из удобных публичных брокеров, список вы найдете тут. Последние несколько лет я пользуюсь wqtt.

 


HTTPS cервисы построения графиков

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

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

  • ThingSpeak– забугорный сервис с достаточно жесткими ограничениями в бесплатном режиме, но есть приложения для смартфона с удобными виджетами. В платном режиме есть возможность управления устройствами

  • Open Monitoring– российский бесплатный сервис, очень удобен для работы на компьютере, но клиента для смартфона пока не предвидится

  • NarodMon– достаточно известный российский сервис для отображения данных на картах, если клиенты и для смартфонов. Есть возможность управления, широкие возможности, но лимиты на количество устройств очень жесткие

Данные на указанные выше сервисы очень легко отправлять самым простым GET-запросом, поэтому добавляем в наш список HTTPS-протокол. Работать с TLS-шифрованием ESP32 умеет легко, так что проблем с HTTPS-запросами не возникает.

 


Уведомления в Telegram

Кроме вышеперечисленного, очень часто возникает ситуация, когда нужно как можно скорее уведомить всех заинтересованных пользователей об каком-либо событии. Например это может быть отключение котла или срабатывание какой-либо сигнализации. Самое простое, что можно сделать в этом случае – использовать готовый мессенджер. В этой роли Telegram подходит как нельзя лучше. Можно организовать уведомления со звуковыми уведомлениями, можно смотреть их как на смартфоне, так и на компьютере.

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

Кроме того, существует возможность сделать полноценное управление устройствами непосредственно из telegram с помощью команд и кнопок, но это пока находится в стадии проектирования.


SNTP и получение времени

Поскольку каждое устройство практически постоянно подключено к сети интернет, нет смысла встраивать в каждое из них часы реального времени. Гораздо проще получать точное время с серверов в интернете, что очень не сложно – ESP-IDF имеет все необходимые функции.

PING

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

OTA-обновления

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *