Реализация сценариев автоматизации (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 недель. Стоимость рассчитывается после анализа протоколов и количества типов устройств.