Якийсь час тому ми представили Вам . Нинішня стаття спочатку замислювалася як демонстрація його прошивки та системи управління. Але для того, щоб пояснити логіку роботи термостата і те, що ми реалізували, необхідно описати всю концепцію загалом.
Про автоматизацію
Умовно всю автоматизацію можна розділити на три категорії:
Категорія 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 листа:
"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)?
Про проекти
На ринку є різні розподілені системи. Наша система дозволяє інтегруватися із найпопулярнішими.
Нижче наведені проекти, які намагаються змінити ситуацію з несумісністю різних виробників між собою. Це, наприклад, , або . зав'язаний на 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.
Наша система не потребує Сервера, і у разі його відмови не перетворюється на гарбуз. Навіть при відмові одного з компонентів система не починає працювати за аварійним сценарієм. Контролери, датчики, пристрої – кожен елемент є і Сервером, і клієнтом, тому повністю автономен.
Для тих, хто зацікавився, наші соцмережі: , , , , .
Пошта: [захищено електронною поштою]
PS ми не закликаємо відмовлятися від Сервера. У нас також є підтримка MQTT-сервера і є власна хмара. Наша мета – вивести стабільність та надійність системи на якісно новий рівень. Щоб Сервер не був слабким місцем, а доповнював функціонал та робив систему зручнішою.
Джерело: habr.com