Расписание и автоматизация IoT-устройств в мобильном приложении

Реализация расписания и автоматизации IoT-устройств через мобильное приложение

Представьте: умный дом включает свет в 07:00 по Москве, но владелец улетает во Владивосток, и свет включается в 05:00 по местному времени. Частая проблема — отсутствие корректного часового пояса. Мы проектируем мобильные интерфейсы для IoT более 5 лет, реализовали 20+ проектов — от бытовых розеток до промышленных контроллеров. Один из частых запросов — гибкое расписание и автоматизация, которые работают без участия человека.

Расписание для IoT-устройства — «включить свет в 07:00, выключить в 23:00 по рабочим дням». Автоматизация сложнее: «если температура упала ниже +18°C и время между 22:00 и 08:00 — включить обогреватель». Обе задачи решаются на уровне бэкенда, но мобильное приложение должно предоставить UI для их создания и редактирования без инструкции.

Как реализовать расписание для IoT-устройства?

Типичный Schedule:

{ "device_id": "abc123", "action": "turn_on", "days_of_week": [1, 2, 3, 4, 5], "time": "07:00", "timezone": "Europe/Moscow", "enabled": true } 

Часовой пояс — обязательное поле. Без него расписание сработает неправильно после перелёта или при пользователях из разных регионов. Хранить на сервере в UTC, конвертировать при отображении в timezone устройства/пользователя. Согласно Firebase documentation, это стандартная практика.

UI выбора времени на Android Compose — Material3 TimePicker или TimePickerDialog. Выбор дней недели — горизонтальный ряд чипов с множественным выбором:

val days = listOf("Пн", "Вт", "Ср", "Чт", "Пт", "Сб", "Вс") 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) } ) } } 

Список расписаний — LazyColumn с возможностью включить/выключить каждое через Switch без открытия редактора. PATCH-запрос только поля enabled = false — не весь объект.

В чём разница между расписанием и автоматизацией?

Почему автоматизация сложнее простого расписания?

Автоматизации строятся по модели ECA (Event-Condition-Action):

• Event (триггер): значение датчика пересекло порог, наступило время, устройство изменило статус
• Condition (условие): текущее время в диапазоне, другое устройство онлайн
• Action (действие): отправить команду устройству, отправить уведомление, вызвать webhook

Хранить как JSON на сервере:

{ "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" } ] } 

Выполнение логики — на сервере. Мобильное приложение не исполняет автоматизации, только создаёт и редактирует их.

UI конструктора автоматизаций

Drag-and-drop конструктор — сложно и избыточно для большинства сценариев. Проще: пошаговый wizard. Сравним два подхода:

Шаг 1 — Триггер. Выбор устройства → выбор параметра → условие (больше/меньше/равно) → значение. Или выбор «По расписанию».

Шаг 2 — Условия (опционально). «Добавить условие» → выбор типа (время, день недели, статус другого устройства).

Шаг 3 — Действие. Выбор устройства → выбор команды. Возможность добавить несколько действий. Шаг 4 — Название и сохранение.

Каждый шаг валидируется отдельно. Нельзя перейти к следующему без заполнения обязательных полей — показывать inline ошибку, не блокировать всё приложение.

Как отладить автоматизацию?

Пользователь создаёт автоматизацию и не понимает, почему она не сработала. Лог выполнения — обязательная фича. Каждый триггер → запись в историю: сработал/не сработал, почему, какое действие было выполнено.

14:32 · Температура упала до 16.8°C ✓ Условие: время 22:00–08:00 — не выполнено (сейчас 14:32) ✗ Автоматизация не сработала