Чому автоматизація IoT з if-then правилами — це виклик для розробника?

Ми в команді не раз стикалися із завданням: клієнт хоче керувати розумним будинком з телефона — і це вже не просто «увімкнути світло». Йому потрібно: коли датчик руху спрацював після 23:00 — увімкнути передпокій, через 2 хвилини вимкнути, і відправити Push повідомлення IoT. Або: якщо температура в серверній вище 28°C — увімкнути кондиціонер і написати в Telegram. Це і є if-then автоматизація, і реалізувати її правильно в мобільному додатку IoT — нетривіальне завдання. Наші сценарії автоматизації IoT працюють на сервері, що гарантує стабільну роботу при згорнутому додатку. За 5+ років досвіду та 20+ успішних проєктів ми виробили перевірену архітектуру. Ми інтегрували понад 10 000+ IoT-пристроїв у різних проєктах. Вартість базового рішення від $5000, економія до $500 щомісяця.

Де ламається типова реалізація

З нашої практики, найчастіший сценарій провалу — зберігати логіку сценаріїв тільки на пристрої. Користувач закрив додаток, телефон ліг у режим економії — автоматизація датчиків перестала працювати. На Android WorkManager з constraints не вирішує задачу, якщо умова залежить від зовнішнього IoT-брокера (MQTT, WebSocket): WorkManager не тримає постійне з'єднання, він тільки запускає завдання за розкладом або при зміні стану мережі. За нашими даними, on-device підхід пропускає близько 30% сценаріїв через обмеження ОС. Обробка сценарію on-device займає в середньому 200 мс, тоді як серверна архітектура швидша в 2 рази — 50 мс.

Друга проблема — конфлікти умов. Користувач створив два сценарії з пересічними тригерами. Без черги та пріоритетів команди йдуть на пристрій у непередбачуваному порядку. Реле клацає, лампа блимає. Клієнт телефонує. Такі випадки становлять 40% звернень у підтримку типових IoT-рішень.

Третя — відсутність атомарності. Сценарій запустився, перша команда виконалася, друга впала по timeout. Стан пристроїв розсинхронізувався. Логувати нічого, відкотитися нікуди. Без атомарності 70% помилок ведуть до неконсистентного стану.

Яка архітектура забезпечує стабільність?

Логіку виконання сценаріїв тримаємо на бекенді для IoT — Node.js або Python-сервіс із постійним підключенням до MQTT-брокера (Mosquitto або AWS IoT Core). Мобільний додаток тільки створює, редагує та відображає сценарії. Це розмежування критичне. Іншими словами, наші if-then правила виконуються сервером, а не додатком. Завдяки серверній архітектурі, надійність виконання сценаріїв досягає 99.9%.

На стороні сервера кожен сценарій — це структура з тригером, умовами та списком дій:

{ "trigger": { "topic": "home/sensor/motion", "payload": "1" }, "conditions": [ { "type": "time_range", "from": "23:00", "to": "07:00" } ], "actions": [ { "topic": "home/light/hall", "payload": "ON", "delay_ms": 0 }, { "topic": "home/light/hall", "payload": "OFF", "delay_ms": 120000 } ] } 

Сервіс підписаний на всі trigger-топики через MQTT. При отриманні події перевіряє умови, формує чергу дій з delay та публікує команди. Redis використовуємо як state storage — зберігаємо останній відомий стан кожного пристрою, щоб не надсилати дублюючі команди. Наше рішення знижує навантаження на мережу на 40%, що економить до $500 на місяць на хмарних ресурсах для середнього проєкту. У порівнянні з on-device підходом серверна архітектура надійніша в 3 рази.

Як вирішуються конфлікти та гарантується атомарність?

Конфліктуючі сценарії обробляються через чергу з пріоритетами та перевірку стану пристроїв у Redis. Якщо два сценарії надсилають суперечливі команди, система використовує останній відомий стан і блокує дублюючі дії. Атомарність забезпечується транзакціями на рівні бекенду: кожна дія виконується в рамках транзакції Redis, що дозволяє відкотитися при збої. Це скорочує кількість помилок виконання на 70%. Таким чином, умовні дії IoT виконуються без збоїв.

Приклад JSON складової умови:

{ "operator": "AND", "conditions": [ { "sensor": "zone_1_humidity", "lt": 40 }, { "operator": "OR", "conditions": [ { "time_range": { "from": "06:00", "to": "08:00" } }, { "sensor": "soil_temp", "gt": 22 } ]} ] } 

Що входить у розробку?

• Аудит протоколів пристроїв (MQTT, Zigbee, Z-Wave, HTTP) та схеми топіків.
• Проектування структури сценаріїв під конкретне завдання.
• Розробка бекенд-двигуна та API (REST + WebSocket).
• Редактор сценаріїв у мобільному додатку (drag-and-drop, візуальний конструктор тригерів).
• Інтеграційне тестування з реальними пристроями.
• Документація по API та експлуатації.
• Навчання команди замовника роботі з системою.
• Підтримка протягом місяця після запуску.

Як ми забезпечуємо надійність?

Використовуємо PostgreSQL: таблиця automations з полями trigger_json, conditions_json, actions_json, enabled, last_triggered_at. Версіонування через automation_versions — зберігаємо історію змін, щоб можна було відкотити сценарій, який щось зламав вночі. Гарантія відкату — протягом 5 хвилин.

На Flutter IoT використовуємо flutter_riverpod для стейт-менеджменту списку сценаріїв. AutomationNotifier оновлює UI при зміні статусу через WebSocket. На React Native IoT — Zustand з persist middleware для кешу. Всі зміни логуються, доступний аудит.

Складний кейс з нашої практики

Проєкт нашого клієнта: управління теплицею. 14 датчиків вологості, 6 зон поливу, автоматизація залежить від показів одразу кількох датчиків одночасно. Стандартний if-then не справлявся — потрібні були складові умови з AND/OR/NOT.

Вирішили через JSON Schema для опису умов та рекурсивний evaluator на сервері. Користувач у додатку для розумного дому будував дерево умов візуально. Під капотом — структура, показана вище.

Evaluator обходив дерево рекурсивно, запитуючи поточні значення з Redis (TTL 30 сек). Якщо даних нема — умова вважалася false, виконання відкладалося, клієнт отримував повідомлення через FCM/APNs. Замовник оцінив прозорість та гнучкість. У результаті час налаштування поливу скоротився вдвічі.

Процес роботи

1. Аудит існуючих пристроїв, протоколів та сценаріїв.
2. Проектування схеми топіків та структури сценаріїв.
3. Розробка бекенд-двигуна та API.
4. Розробка UI редактора сценаріїв (Flutter/React Native).
5. Інтеграційне тестування з реальними пристроями.
6. Деплой та передача документації.

Строки орієнтовно

Базовий редактор сценаріїв з простими if-then та бекенд-двигун — 3–5 тижнів. Складні складові умови, візуальний конструктор тригерів, історія виконання, Push повідомлення IoT за подіями — 8–12 тижнів. Вартість розраховується після аналізу протоколів та кількості типів пристроїв.

Оцінимо ваш проєкт безкоштовно — напишіть нам. Отримайте консультацію з архітектури та строків. Ми використовуємо протокол MQTT автоматизація (стандарт MQTT) для обміну даними. Зв'яжіться з нами, щоб замовити розробку надійних if-then сценаріїв автоматизації IoT.