Некоторое время назад мы представили Вам умный термостат. Нынешняя статья изначально задумывалась как демонстрация его прошивки и системы управления. Но для того, чтобы объяснить логику работы термостата и то, что мы реализовали, необходимо обрисовать всю концепцию в целом.
Условно, всю автоматизацию можно разделить на три категории:
Категория 1 — отдельные “умные” устройства. Вы приобретаете у разных производителей лампочки, чайники и т.д. Плюсы: каждое устройство расширяет возможности и повышает комфорт. Минусы: для каждого нового производителя необходимо свое приложение. Протоколы устройств разных производителей зачастую не совместимы между собой.
Категория 2 — установка одноплатного ПК или х86 совместимого. Это снимает ограничения по вычислительной мощности, и на данную машину устанавливается MajorDoMo или любой другой серверный дистрибутив для управления умным домом. Таким образом, устройства большинства производителей соединяются в едином информационном пространстве. Т.е. появляется свой Сервер для умного дома. Плюсы: совместимость под единым центром, что дает расширенные возможности для управления. Минусы: при поломке\отказе сервера вся система возвращается в стадию 1, т.е. становится разрозненной, или делается бесполезной.
Категория 3 — самый хардкорный вариант. На стадии ремонта закладываются все коммуникации и дублируются все системы. Плюсы: все доведено до идеала и тогда дом становится действительно умным. Минусы: крайняя дороговизна по сравнению с категориями 1 и 2, необходимость продумывания наперед всего и учета каждой мелочи.
Большинство пользователей выбирают вариант один, а затем плавно переходят в вариант два. А в дальнейшем самые стойкие доходят до варианта 3.
Но существует вариант, который можно назвать распределенной системой: каждое отдельное устройство будет и сервером, и клиентом. По сути, это попытка взять и объединить вариант 1 и вариант 2. Взять все их плюсы и исключить минусы, поймать золотую середину.
Возможно, кто-то скажет, что такой вариант уже разработан. Но такие решения — узконаправленные; для людей, подкованных в программировании. Наша цель — снизить порог входа в подобные распределенные системы как в виде конечных устройств, так и в виде интеграции существующих устройств в нашу систему. В случае с термостатом, пользователь просто снимает свой старый термостат, устанавливает умный, и подключает имеющиеся у него датчики к нему. Без каких-либо дополнительных действий.
Рассмотрим интеграцию в нашу систему на примере.
Представим, что у нас в сети имеется 8 модулей Sonoff. Некоторым пользователям будет достаточно управления через облако Sonoff (категория 1). Некоторые станут использовать стороннюю прошивку и плавно перейдут в категорию 2. Основная масса сторонних прошивок работает по одинаковому принципу: передача данных на MQTT-сервер. OpenHub, Majordomo или любой другой служат одной цели – объединить разрозненные устройства в единое информационное пространство, расположенное либо в Интернете, либо в локальной сети. Следовательно, наличие Сервера является обязательным. Отсюда возникает главная проблема – при отказе Сервера вся система перестает работать автономно. Для предотвращения этого, системы усложняются, добавляются ручные способы управления, которые дублируют автоматику в случае отказа Сервера.
Мы же пошли по другому пути, где каждое устройство является самодостаточным. Таким образом, Сервер не играет решающей роли, а лишь расширяет функционал.
Вернёмся к мысленному эксперименту. Снова возьмём те же самые 8 модулей Sonoff и установим в них прошивку Lytko. Во всех прошивках Lytko реализована функция SSDP. SSDP — сетевой протокол, основанный на наборе протоколов Интернета, служащий для объявления и обнаружения сетевых сервисов. Ответ на запрос может быть как стандартный, так и расширенный. Мы заложили в этот ответ помимо стандартных функций создание списка устройств в сети. Таким образом, устройства сами находят друг друга, и у каждого из них будет такой список. Пример SSDP листа:
Как видно из примера, список включает в себя id устройств, ip-адрес в сети, тип блока (в нашем случае — термостат на основе Sonoff). Данный список обновляется один раз в две минуты (этого промежутка достаточно для реагирования на динамическое изменение количества устройств в сети). Таким образом, мы отслеживаем добавление, изменение и отключение устройств без каких-либо действий со стороны пользователя. Этот список отправляется в браузер или мобильное приложение, и скрипт сам формирует страницу с заданным количеством блоков. Каждый блок соответствует одному устройству/сенсору/контроллеру. Визуально список выглядит так:
Но если к esp8266/esp32 подключены другие радио-сенсоры через cc2530 (ZigBee) или nrf24 (MySensors)?
На рынке присутствуют различные распределенные системы. Наша система позволяет интегрироваться с самыми популярными.
Ниже приведены проекты, которые так или иначе стараются изменить ситуацию с несовместимостью разных производителей между собой. Это, например, SLS Gateway, MySensors или ZESP32. ZigBee2MQTT завязан на MQTT-сервере, поэтому не подходит для примера.
Одним из вариантов реализации MySensors является шлюз, основанный на ESP8266. Остальные примеры — на ESP32. И в них можно внедрить наш принцип работы по обнаружению и созданию списка устройств.
Проведём ещё один мысленный эксперимент. Имеем шлюз ZESP32 или SLS Gateway, или MySensors. Как можно их объединить в едином информационном пространстве? К стандартным функциям данных шлюзов добавим библиотеку протокола SSDP. При обращении к данному контроллеру по SSDP, он к стандартному ответу добавит список устройств, которые подключены к нему. На основе этой информации браузер сформирует страницу. В общем виде это будет выглядеть так:
Web-интерфейс
PWA-приложение
Из примера видно, что устройства добавляются независимо друг от друга. Подключены 3 термостата с собственными ip-адресами и 5 разных сенсоров с уникальными id. Если сенсор подключен к Wi-Fi сети, то он будет иметь свой ip, если подключен к шлюзу, то ip-адрес устройства будет являться ip-адресом шлюза.
Для связи с устройствами мы применяем WebSocket. Это позволяет минимизировать затраты ресурсов по сравнению с get-запросами и получать информацию динамически при подключении или изменении.
Данные берутся напрямую с того устройства, которому принадлежит блок, минуя сервер. Таким образом, при отказе любого из устройств система продолжает работать. На web-интерфейсе лишь не отображается пропавшее из списка устройство. Но сигнал о пропаже, при необходимости, придёт в виде уведомления в приложении пользователя.
Первой попыткой реализации такого подхода было PWA-приложение. Это позволяет хранить базу блоков на устройстве пользователя и запрашивать только необходимые данные. Но ввиду особенностей структуры такой вариант неполноценен. И выход один — нативное приложения для Android и IOS, которое сейчас находится в активной разработке. По умолчанию, приложение будет работать только во внутренней сети. При необходимости можно перевести всё на внешнее управление. Так, когда пользователь покидает локальную сеть, приложение автоматически переключается на облако.
Внешнее управление — полное дублирование страницы. При активации страницы пользователь может залогиниться на сервере и управлять устройствами через личный кабинет. Таким образом, Сервер расширяет функционал, позволяя управлять устройствами, находясь за пределами дома, и не быть привязанным к пробросу портов или выделенному ip.
Таким образом, вышеописанный вариант лишен недостатков серверного подхода, а также имеет ряд преимуществ в виде гибкости подключения новых устройств.
Рассмотрим систему управления на примере нашего термостата.
Предусмотрено:
Кроме управления посредством web-интерфейса, предусмотрели классическое — нажатиями по дисплею. На борту стоит монитор Nextion NX3224T024 2.4 дюйма. Выбор пал на него ввиду простоты работы с девайсом. Но в разработке находится собственный монитор на основе STM32. Его функционал ничуть не хуже, чем у Nextion, но стоить будет он дешевле, что положительно скажется на конечной цене устройства.
Как и любой уважающий себя экран термостата, наш Nextion умеет:
Кроме того, с помощью монитора можно:
По клику на бар WiFi пользователь узнает информацию о подключенной сети. QR код используется для сопряжения устройства в прошивке HomeKit.
Демо работы с дисплеем:
Мы разработали демо-страницу с тремя подключенными термостатами.
Вы спросите: “В чём особенность вашего термостата?” Сейчас на рынке существует множество термостатов с функцией Wi-Fi, работой по расписанию, сенсорным управлением. А энтузиасты написали модули для взаимодействия с большинством популярных систем умный дом (Majordomo, HomeAssistant и т.п.).
Наш термостат совместим с такими системами и обладает всем вышеперечисленным. Но отличительная особенность в том, что термостат постоянно дорабатывается, благодаря гибкости системы. С каждым обновлением функционал будет расширяться. К стандартному способу управления системой (по расписанию), мы добавим адаптивный. Приложение позволяет получать геолокацию пользователя. Благодаря этому, система будет динамически менять режимы работы в зависимости от его местоположения. А модуль погоды позволит подстраиваться к погодным условиям.
И расширяемость. Любой желающий сможет заменить установленный у него обычный термостат на наш. С минимальными усилиями. Мы выбрали 5 самых популярных датчиков, представленных на рынке, и добавили их поддержку. Но даже в случае эксклюзивных характеристик датчика, пользователь сможет подключить его к нашему термостату. Для этого понадобится произвести калибровку термостата для работы с конкретным сенсором. Инструкции мы предоставим.
Подключая термостат или любое другое устройство, оно одновременно появляется везде: и в web-интерфейсе, и в PWA-приложении. Добавление устройства происходит автоматически: достаточно лишь подключить его к Wi-Fi сети.
Наша система не нуждается в Сервере, и в случае его отказа не превращается в тыкву. Даже при отказе одного из компонентов система не начинает работать по аварийному сценарию. Контроллеры, датчики, устройства — каждый элемент является и Сервером, и клиентом, поэтому полностью автономен.
Для заинтересовавшихся — наши соцсети: Telegram, Instagram, Telegram News, VK, Facebook.
Почта: shop@lytko.com
P. S. мы не призываем отказываться от Сервера. У нас также присутствует поддержка MQTT-сервера и есть собственное облако. Наша цель — вывести стабильность и надёжность системы на качественно новый уровень. Чтобы Сервер не являлся слабым местом, а дополнял функционал и делал систему удобнее.
Про автоматизацию
Условно, всю автоматизацию можно разделить на три категории:
Категория 1 — отдельные “умные” устройства. Вы приобретаете у разных производителей лампочки, чайники и т.д. Плюсы: каждое устройство расширяет возможности и повышает комфорт. Минусы: для каждого нового производителя необходимо свое приложение. Протоколы устройств разных производителей зачастую не совместимы между собой.
Категория 2 — установка одноплатного ПК или х86 совместимого. Это снимает ограничения по вычислительной мощности, и на данную машину устанавливается MajorDoMo или любой другой серверный дистрибутив для управления умным домом. Таким образом, устройства большинства производителей соединяются в едином информационном пространстве. Т.е. появляется свой Сервер для умного дома. Плюсы: совместимость под единым центром, что дает расширенные возможности для управления. Минусы: при поломке\отказе сервера вся система возвращается в стадию 1, т.е. становится разрозненной, или делается бесполезной.
Категория 3 — самый хардкорный вариант. На стадии ремонта закладываются все коммуникации и дублируются все системы. Плюсы: все доведено до идеала и тогда дом становится действительно умным. Минусы: крайняя дороговизна по сравнению с категориями 1 и 2, необходимость продумывания наперед всего и учета каждой мелочи.
Большинство пользователей выбирают вариант один, а затем плавно переходят в вариант два. А в дальнейшем самые стойкие доходят до варианта 3.
Но существует вариант, который можно назвать распределенной системой: каждое отдельное устройство будет и сервером, и клиентом. По сути, это попытка взять и объединить вариант 1 и вариант 2. Взять все их плюсы и исключить минусы, поймать золотую середину.
Возможно, кто-то скажет, что такой вариант уже разработан. Но такие решения — узконаправленные; для людей, подкованных в программировании. Наша цель — снизить порог входа в подобные распределенные системы как в виде конечных устройств, так и в виде интеграции существующих устройств в нашу систему. В случае с термостатом, пользователь просто снимает свой старый термостат, устанавливает умный, и подключает имеющиеся у него датчики к нему. Без каких-либо дополнительных действий.
Рассмотрим интеграцию в нашу систему на примере.
Представим, что у нас в сети имеется 8 модулей Sonoff. Некоторым пользователям будет достаточно управления через облако Sonoff (категория 1). Некоторые станут использовать стороннюю прошивку и плавно перейдут в категорию 2. Основная масса сторонних прошивок работает по одинаковому принципу: передача данных на MQTT-сервер. OpenHub, Majordomo или любой другой служат одной цели – объединить разрозненные устройства в единое информационное пространство, расположенное либо в Интернете, либо в локальной сети. Следовательно, наличие Сервера является обязательным. Отсюда возникает главная проблема – при отказе Сервера вся система перестает работать автономно. Для предотвращения этого, системы усложняются, добавляются ручные способы управления, которые дублируют автоматику в случае отказа Сервера.
Мы же пошли по другому пути, где каждое устройство является самодостаточным. Таким образом, Сервер не играет решающей роли, а лишь расширяет функционал.
Вернёмся к мысленному эксперименту. Снова возьмём те же самые 8 модулей Sonoff и установим в них прошивку Lytko. Во всех прошивках Lytko реализована функция SSDP. SSDP — сетевой протокол, основанный на наборе протоколов Интернета, служащий для объявления и обнаружения сетевых сервисов. Ответ на запрос может быть как стандартный, так и расширенный. Мы заложили в этот ответ помимо стандартных функций создание списка устройств в сети. Таким образом, устройства сами находят друг друга, и у каждого из них будет такой список. Пример SSDP листа:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Как видно из примера, список включает в себя id устройств, ip-адрес в сети, тип блока (в нашем случае — термостат на основе Sonoff). Данный список обновляется один раз в две минуты (этого промежутка достаточно для реагирования на динамическое изменение количества устройств в сети). Таким образом, мы отслеживаем добавление, изменение и отключение устройств без каких-либо действий со стороны пользователя. Этот список отправляется в браузер или мобильное приложение, и скрипт сам формирует страницу с заданным количеством блоков. Каждый блок соответствует одному устройству/сенсору/контроллеру. Визуально список выглядит так:
Но если к esp8266/esp32 подключены другие радио-сенсоры через cc2530 (ZigBee) или nrf24 (MySensors)?
Про проекты
На рынке присутствуют различные распределенные системы. Наша система позволяет интегрироваться с самыми популярными.
Ниже приведены проекты, которые так или иначе стараются изменить ситуацию с несовместимостью разных производителей между собой. Это, например, SLS Gateway, MySensors или ZESP32. ZigBee2MQTT завязан на MQTT-сервере, поэтому не подходит для примера.
Одним из вариантов реализации MySensors является шлюз, основанный на ESP8266. Остальные примеры — на ESP32. И в них можно внедрить наш принцип работы по обнаружению и созданию списка устройств.
Проведём ещё один мысленный эксперимент. Имеем шлюз ZESP32 или SLS Gateway, или MySensors. Как можно их объединить в едином информационном пространстве? К стандартным функциям данных шлюзов добавим библиотеку протокола SSDP. При обращении к данному контроллеру по SSDP, он к стандартному ответу добавит список устройств, которые подключены к нему. На основе этой информации браузер сформирует страницу. В общем виде это будет выглядеть так:
Web-интерфейс
PWA-приложение
"ssdpList":
{
"id": 94967291, // уникальный идентификатор устройства
"ip": "192.168.x.x", // ip адрес в сети
"type": "thermostat" // тип устройства
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
Из примера видно, что устройства добавляются независимо друг от друга. Подключены 3 термостата с собственными ip-адресами и 5 разных сенсоров с уникальными id. Если сенсор подключен к Wi-Fi сети, то он будет иметь свой ip, если подключен к шлюзу, то ip-адрес устройства будет являться ip-адресом шлюза.
Для связи с устройствами мы применяем WebSocket. Это позволяет минимизировать затраты ресурсов по сравнению с get-запросами и получать информацию динамически при подключении или изменении.
Данные берутся напрямую с того устройства, которому принадлежит блок, минуя сервер. Таким образом, при отказе любого из устройств система продолжает работать. На web-интерфейсе лишь не отображается пропавшее из списка устройство. Но сигнал о пропаже, при необходимости, придёт в виде уведомления в приложении пользователя.
Первой попыткой реализации такого подхода было PWA-приложение. Это позволяет хранить базу блоков на устройстве пользователя и запрашивать только необходимые данные. Но ввиду особенностей структуры такой вариант неполноценен. И выход один — нативное приложения для Android и IOS, которое сейчас находится в активной разработке. По умолчанию, приложение будет работать только во внутренней сети. При необходимости можно перевести всё на внешнее управление. Так, когда пользователь покидает локальную сеть, приложение автоматически переключается на облако.
Внешнее управление — полное дублирование страницы. При активации страницы пользователь может залогиниться на сервере и управлять устройствами через личный кабинет. Таким образом, Сервер расширяет функционал, позволяя управлять устройствами, находясь за пределами дома, и не быть привязанным к пробросу портов или выделенному ip.
Таким образом, вышеописанный вариант лишен недостатков серверного подхода, а также имеет ряд преимуществ в виде гибкости подключения новых устройств.
Про термостат
Рассмотрим систему управления на примере нашего термостата.
Предусмотрено:
- Регулирование температуры каждого термостата (отображается в виде отдельного блока);
- Настройка расписания работы термостата (утро, день, вечер, ночь);
- Выбор Wi-Fi сети и подключения к ней устройства;
- Обновление устройства “по воздуху”;
- Настройка MQTT;
- Настройка сети, к которой подключено устройство.
Кроме управления посредством web-интерфейса, предусмотрели классическое — нажатиями по дисплею. На борту стоит монитор Nextion NX3224T024 2.4 дюйма. Выбор пал на него ввиду простоты работы с девайсом. Но в разработке находится собственный монитор на основе STM32. Его функционал ничуть не хуже, чем у Nextion, но стоить будет он дешевле, что положительно скажется на конечной цене устройства.
Как и любой уважающий себя экран термостата, наш Nextion умеет:
- выставлять необходимую пользователю температуру (кнопками справа);
- включать и выключать режим работы по расписанию (кнопка Н);
- отображать работу реле (стрелка слева);
- имеет защиту от детей (блокируются физические нажатия, пока замок не снят);
- отображает уровень сигнала WiFi.
Кроме того, с помощью монитора можно:
- выбрать тип установленного у пользователя датчика;
- управлять функцией защиты от детей;
- обновить прошивку.
По клику на бар WiFi пользователь узнает информацию о подключенной сети. QR код используется для сопряжения устройства в прошивке HomeKit.
Демо работы с дисплеем:
Мы разработали демо-страницу с тремя подключенными термостатами.
Вы спросите: “В чём особенность вашего термостата?” Сейчас на рынке существует множество термостатов с функцией Wi-Fi, работой по расписанию, сенсорным управлением. А энтузиасты написали модули для взаимодействия с большинством популярных систем умный дом (Majordomo, HomeAssistant и т.п.).
Наш термостат совместим с такими системами и обладает всем вышеперечисленным. Но отличительная особенность в том, что термостат постоянно дорабатывается, благодаря гибкости системы. С каждым обновлением функционал будет расширяться. К стандартному способу управления системой (по расписанию), мы добавим адаптивный. Приложение позволяет получать геолокацию пользователя. Благодаря этому, система будет динамически менять режимы работы в зависимости от его местоположения. А модуль погоды позволит подстраиваться к погодным условиям.
И расширяемость. Любой желающий сможет заменить установленный у него обычный термостат на наш. С минимальными усилиями. Мы выбрали 5 самых популярных датчиков, представленных на рынке, и добавили их поддержку. Но даже в случае эксклюзивных характеристик датчика, пользователь сможет подключить его к нашему термостату. Для этого понадобится произвести калибровку термостата для работы с конкретным сенсором. Инструкции мы предоставим.
Подключая термостат или любое другое устройство, оно одновременно появляется везде: и в web-интерфейсе, и в PWA-приложении. Добавление устройства происходит автоматически: достаточно лишь подключить его к Wi-Fi сети.
Наша система не нуждается в Сервере, и в случае его отказа не превращается в тыкву. Даже при отказе одного из компонентов система не начинает работать по аварийному сценарию. Контроллеры, датчики, устройства — каждый элемент является и Сервером, и клиентом, поэтому полностью автономен.
Для заинтересовавшихся — наши соцсети: Telegram, Instagram, Telegram News, VK, Facebook.
Почта: shop@lytko.com
P. S. мы не призываем отказываться от Сервера. У нас также присутствует поддержка MQTT-сервера и есть собственное облако. Наша цель — вывести стабильность и надёжность системы на качественно новый уровень. Чтобы Сервер не являлся слабым местом, а дополнял функционал и делал систему удобнее.
Arevik
Савсибо. Интересно! Буду следить за развитием.