Реалізація розкладу та автоматизації 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/Kyiv", "enabled": true } Часовий пояс — обов'язкове поле. Без нього розклад спрацює неправильно після перельоту або при користувачах з різних регіонів. Зберігати на сервері в UTC, конвертувати при відображенні в timezone пристрою/користувача. Згідно з документацією Firebase, це стандартна практика.
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) |
|---|---|---|
| Тригер | Фіксований час | Подія (датчик, час, статус) |
| Умови | Немає | Дод. перевірки (час, статус інших пристроїв) |
| Дія | Одна команда | Одна або кілька команд |
| Управління | Вкл/Викл | Створення, редагування, видалення |
Чому автоматизація складніша за простий розклад?
Автоматизації будуються за моделлю 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. Порівняємо два підходи:
| Характеристика | Drag-and-drop конструктор | Покроковий wizard |
|---|---|---|
| Час освоєння | 15–20 хвилин | 3–5 хвилин (у 3–4 рази швидше) |
| Помилки користувача | Часті (пропуск обов'язкових полів) | Рідкісні (послідовна валідація) |
| Підходить для | Продвинуті користувачі | Усі користувачі |
Крок 1 — Тригер. Вибір пристрою → вибір параметра → умова (більше/менше/дорівнює) → значення. Або вибір «За розкладом».
Крок 2 — Умови (опціонально). «Додати умову» → вибір типу (час, день тижня, статус іншого пристрою).
Крок 3 — Дія. Вибір пристрою → вибір команди. Можливість додати кілька дій. Крок 4 — Назва та збереження.
Кожен крок валідується окремо. Не можна перейти до наступного без заповнення обов'язкових полів — показувати inline помилку, не блокувати весь додаток.
Як налагодити автоматизацію?
Користувач створює автоматизацію і не розуміє, чому вона не спрацювала. Журнал виконання — обов'язкова фіча. Кожен тригер → запис в історію: спрацював/не спрацював, чому, яка дія була виконана.
Приклад журналу
14:32 · Температура впала до 16.8°C ✓ Умова: час 22:00–08:00 — не виконано (зараз 14:32) ✗ Автоматизація не спрацювала Такий журнал знижує кількість звернень до підтримки — економія до 40% ресурсів на підтримку. При середній вартості розробки модуля від 150 000 грн економія може становити до 200 000 грн на рік.
Конфлікти розкладів
Два розклади на один пристрій можуть конфліктувати: перший вмикає о 07:00, другий вимикає о 07:30, третій вмикає о 07:15. На сервері потрібна логіка вирішення конфліктів — остання за часом команда перемагає. В UI — попередження при створенні пересічних розкладів.
Що входить в роботу
Реалізація розкладів з покроковим wizard: 3–4 тижні. Повний конструктор автоматизацій з умовами та журналом виконання: 6–8 тижнів. Вартість розраховується індивідуально. Зв'яжіться з нами, щоб отримати консультацію та план проєкту.
Процес роботи
- Аналітика — уточнюємо сценарії використання, кількість пристроїв та типи автоматизацій.
- Проєктування — розробляємо модель даних, API та архітектуру UI.
- Реалізація — пишемо бекенд-логіку та мобільний інтерфейс.
- Тестування — перевіряємо на реальних пристроях, емулюємо конфлікти та граничні випадки.
- Деплой — публікація в App Store та Google Play, налаштування push-сповіщень.
Гарантуємо підтримку після запуску та документацію всіх компонентів. Отримайте консультацію інженера, щоб зробити ваш IoT-продукт зручним та надійним.