Сценарії автоматизації (if-then) для IoT у мобільному додатку
Клієнт хоче управляти умним домом з телефона — і це вже не просто «включити світло». Йому потрібно: коли датчик руху сработав після 23:00 — включити прихожу, через 2 хвилини вимкнути, і відправити push. Або: якщо температура у серверній вище 28°C — включити кондиціонер та написати у Telegram. Це й є if-then автоматизація, і реалізувати її правильно у мобільному додатку — нетривіальна задача.
Де ломається типова реалізація
Найчастіший сценарій провалу — зберігати логіку сценаріїв лише на пристрої. Користувач закрив додаток, телефон ліг у режим економії — автоматизація перестала працювати. На Android WorkManager з constraints не вирішує завдання, якщо умова залежить від зовнішнього IoT-брокера (MQTT, WebSocket): WorkManager не тримає постійне з'єднання, він лише запускає завдання за розкладом або при зміні стану мережі.
Друга проблема — конфлікти умов. Користувач створив два сценарії з пересічними триггерами. Без черги та пріоритетів команди йдуть на пристрій у непередбачуваному порядку. Реле щелькає, лампа мигає. Клієнт дзвонить.
Третя — відсутність атомарності. Сценарій запустився, перша команда виконалася, друга упала по timeout. Стан пристроїв рассинхронизувався. Логувати нечого, откатиться некуди.
Архітектура, яка працює
Логіку виконання сценаріїв тримаємо на бекенді — Node.js або Python-сервіс з постійним підключенням до MQTT-брокера (Mosquitto або AWS IoT Core). Мобільний додаток лише створює, редагує та відображає сценарії. Це розграничення критично.
На стороні сервера кожен сценарій — це структура з триггером, умовами та списком дій:
{
"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 paho-mqtt / mqtt.js. При отриманні подій проверяет условия, формує чергу дій з delay та публікує команди. Redis використовуємо як state storage — зберігаємо останнє відоме стану кожного пристрою, щоб не посилати дублюючі команди.
На мобільному клієнті (Flutter або React Native) редактор сценаріїв будується через drag-and-drop блоків. Кожен блок — це окремий віджет/компонент з валідацією. Збереження йде через REST API на бекенд. Реальний статус виконання показуємо через WebSocket або MQTT over WebSocket — підписка на топік home/automation/log.
Зберігання та версіонування сценаріїв
Використовуємо PostgreSQL: таблиця automations з полями trigger_json, conditions_json, actions_json, enabled, last_triggered_at. Версіонування через automation_versions — зберігаємо історію змін, щоб можна було откатить сценарій, який щось зломав ночью.
На Flutter використовуємо flutter_riverpod для стейт-менеджменту списку сценаріїв. AutomationNotifier оновлює UI при зміні статусу через WebSocket. На React Native — Zustand з persist middleware для кешу.
Складні кейси з практики
Проект: управління теплицею. 14 датчиків вологості, 6 зон поливу, автоматизація залежить від показань відразу кількох датчиків одночасно. Стандартний if-then не справлявся — потрібні були складні умови з AND/OR/NOT.
Вирішили через JSON Schema для описування умов та рекурсивний evaluator на сервері. Користувач у додатку будував дерево умов візуально. Під капотом — структура:
{
"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 }
]}
]
}
Evaluator обходив дерево рекурсивно, запрашивая текущие значения из Redis (TTL 30 сек). Если данных нет — условие считалось false, выполнение откладывалось, клиент получал уведомление через FCM/APNs.
Процес роботи
Почнемо з аудиту: які пристрої та протоколи вже є (MQTT, Zigbee, Z-Wave, HTTP), які дані потрібні для триггерів. Проектуємо схему топіків та структуру сценаріїв під конкретну задачу. Потім — API та бекенд-рушій, паралельно UI редактора сценаріїв у додатку. Фінальний етап — інтеграційне тестування з реальними пристроями.
Терміни
Базовий редактор сценаріїв з простими if-then та бекенд-рушієм — 3–5 тижнів. Складні складені умови, візуальний конструктор, історія виконання, push-повідомлення за подіями — 8–12 тижнів. Стоимость рассчитывается после анализа протоколов и количества типов устройств.