If-Then Automation Scenarios for IoT in Mobile Applications
Client wants smart home control from phone — and it's not just "turn on light" anymore. He needs: when motion detector triggers after 11 PM — turn on hallway, after 2 minutes turn off, and send push. Or: if server room temperature above 28°C — turn on AC and message Telegram. This is if-then automation, implementing it correctly in mobile — non-trivial task.
Where Typical Implementation Breaks
Common failure scenario — storing scenario logic only on device. User closes app, phone enters battery saver — automation stops. Android WorkManager with constraints doesn't solve this if condition depends on external IoT broker (MQTT, WebSocket): WorkManager doesn't keep persistent connection, only schedules tasks or reacts to network state.
Second problem — condition conflicts. User creates two scenarios with overlapping triggers. Without queue and priorities, commands go to device unpredictably. Relay clicks, light flickers. Client calls.
Third — lack of atomicity. Scenario started, first command executed, second timed out. Device states out of sync. Nothing to log, nothing to rollback.
Architecture That Works
Keep scenario execution logic on backend — Node.js or Python service with persistent MQTT broker connection (Mosquitto or AWS IoT Core). Mobile app only creates, edits, and displays scenarios. This separation is critical.
On server side, each scenario is a structure with trigger, conditions, and action list:
{
"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 }
]
}
Service subscribes to all trigger topics via MQTT paho-mqtt / mqtt.js. On event, checks conditions, queues actions with delay, publishes commands. Use Redis for state storage — hold last known state of each device, avoid duplicate commands.
On mobile client (Flutter or React Native), scenario editor built with drag-and-drop blocks. Each block is separate widget/component with validation. Saving via REST API to backend. Real execution status shown via WebSocket or MQTT over WebSocket — subscribe to home/automation/log topic.
Storing and Versioning Scenarios
Use PostgreSQL: automations table with trigger_json, conditions_json, actions_json, enabled, last_triggered_at. Versioning via automation_versions — keep change history, rollback if scenario broke something.
On Flutter use flutter_riverpod for state management. AutomationNotifier updates UI on status change via WebSocket. On React Native — Zustand with persist middleware for caching.
Complex Cases from Practice
Project: greenhouse management. 14 humidity sensors, 6 irrigation zones, automation depends on readings from multiple sensors simultaneously. Standard if-then wasn't enough — needed composite conditions with AND/OR/NOT.
Solved via JSON Schema for condition description and recursive evaluator on server. User visually built condition tree in app. Under the hood — structure:
{
"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 traversed tree recursively, querying current values from Redis (TTL 30 sec). Missing data — condition false, execution deferred, user got FCM/APNs notification.
Workflow
Start with audit: what devices and protocols exist (MQTT, Zigbee, Z-Wave, HTTP), what data needed for triggers. Design topic scheme and scenario structure for the task. Then — API and backend engine, parallel UI scenario editor. Final stage — integration testing with real devices.
Timeline
Basic scenario editor with simple if-then and backend engine — 3–5 weeks. Complex composite conditions, visual constructor, execution history, push notifications on events — 8–12 weeks. Pricing calculated after analyzing protocols and device types.