Device Scheduling and Automation via Mobile Application
Device scheduling — "turn on light at 07:00, turn off at 23:00 on weekdays". Automation is more complex: "if temperature drops below +18°C and it's between 22:00 and 08:00 — turn on heater". Both are solved on backend but mobile app must provide UI for creation and editing without instructions.
Scheduling: Data Model and UI
Typical Schedule:
{
"device_id": "abc123",
"action": "turn_on",
"days_of_week": [1, 2, 3, 4, 5],
"time": "07:00",
"timezone": "Europe/Moscow",
"enabled": true
}
Timezone is mandatory. Without it, scheduling works wrong after travel or with users in different regions. Store on server in UTC, convert when displaying in device/user timezone.
Time selection UI on Android Compose — Material3 TimePicker or TimePickerDialog. Day selection — horizontal row of chips with multiple selection:
val days = listOf("Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun")
var selectedDays by remember { mutableStateOf(setOf<Int>()) }
Row(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
days.forEachIndexed { index, label ->
FilterChip(
selected = index + 1 in selectedDays,
onClick = {
selectedDays = if (index + 1 in selectedDays)
selectedDays - (index + 1)
else
selectedDays + (index + 1)
},
label = { Text(label) }
)
}
}
Schedule list — LazyColumn with toggle for each via Switch without opening editor. PATCH only enabled = false field — not the whole object.
Automations: Condition and Action Model
Automations use ECA (Event-Condition-Action) model:
- Event (trigger): sensor value crossed threshold, time passed, device status changed
- Condition (condition): current time in range, another device online
- Action (action): send device command, send notification, call webhook
Store as JSON on server:
{
"trigger": {
"type": "sensor_value",
"device_id": "temp_sensor_1",
"parameter": "temperature",
"operator": "lt",
"value": 18
},
"conditions": [
{
"type": "time_range",
"from": "22:00",
"to": "08:00"
}
],
"actions": [
{
"type": "device_command",
"device_id": "heater_1",
"command": "turn_on"
}
]
}
Logic execution — on server. Mobile app only creates and edits automations.
Automation Constructor UI
Drag-and-drop constructor — complex and overkill for most scenarios. Simpler: step-by-step wizard.
Step 1 — Trigger. Device selection → parameter selection → condition (greater/less/equal) → value. Or choose "By schedule".
Step 2 — Conditions (optional). "Add condition" → type selection (time, weekday, another device status).
Step 3 — Action. Device selection → command selection. Ability to add multiple actions.
Step 4 — Name and save.
Each step validates separately. Can't move to next without required fields — show inline error, don't block app.
Automation List and Debug
User creates automation and doesn't understand why it didn't trigger. Execution log — mandatory feature. Each trigger → history entry: fired/didn't fire, why, what action was taken.
14:32 · Temperature dropped to 16.8°C
✓ Condition: time 22:00–08:00 — not met (now 14:32)
✗ Automation didn't trigger
Such log reduces support requests many times over.
Schedule Conflicts
Two schedules on one device can conflict: first turns on at 07:00, second off at 07:30, third on at 07:15. Server needs conflict resolution logic — last command by time wins. In UI — warning when creating overlapping schedules.
Implementing schedules with step wizard: 3–4 weeks. Full automation constructor with conditions and execution log: 6–8 weeks. Pricing calculated individually.