Розробка мобільного застосунку розумний дім: де ламається керування
Користувач веде повзунок на 30% — і нічого не відбувається. Через кілька секунд штори доїжджають до кінця, а на екрані весь цей час висить «виконується».
Затримка відгуку застосунку в пару секунд ламає сам сенс керування шторами зі смартфона: людина натискає вдруге, отримує зворотний хід і перестає довіряти системі.
Команда проходить чотири стики: застосунок, хмара, локальний контролер, привод. На кожному — своя черга, свій тайм-аут і свій повтор, тому одна команда приходить до приводу двічі або не приходить узагалі.
Під час втрати зв'язку з контролером застосунок показує оптимістичне «відчинено», хоча привод не зрушив: стан узято з останнього підтвердження, а не з факту.
Корінь у тому, що логіку сценарію розмазали по шарах. Розклади живуть у хмарі, позиціонування й затримки — у застосунку, частина логіки дублюється в контролер, і три копії стану розходяться. Після перезапуску контролера або обриву мережі розходження лише зростає.
Розробка мобільного застосунку розумний дім рідко впирається в інтерфейс — вона впирається в те, хто володіє станом приводу. В експлуатації це виглядає як потік звернень «штори живуть своїм життям», який не лікується перевстановленням застосунку. Розбираємо, де саме губиться команда і як це закривається.
Що змінюється після впровадження: відгук, сценарії, відмови
Після впровадження змінюються три вимірювані речі: частка команд, що доходять до приводу з першого разу, час реакції інтерфейсу на жест і поведінка сценаріїв під час обриву зв'язку. Раніше це перевіряли «на око» — тепер є журнал команд і зрозуміла межа між нормою та дефектом.
Швидкість реакції інтерфейсу та передбачуваність жесту
Слайдер положення та жест «потягнути штору» обробляються оптимістично: інтерфейс показує нове положення одразу, а команда йде в чергу з підтвердженням від приводу.
Якщо підтвердження немає за відведене вікно, стан відкочується до фактичного — користувач бачить правду, а не завислу половину. Частка команд, що доходять з першого разу, тримається вище 99%: повторні натискання та «дребезг» жесту гасяться на боці застосунку.
Сценарії, які переживають обрив зв'язку
Розклади й реакції на датчики світла, присутності та температури тримаються локально на шлюзі, а не лише в хмарі: під час падіння каналу штори продовжують закриватися за часом і рівнем освітленості.
Коли зв'язок повертається, застосунок звіряє фактичне положення кожної групи з очікуваним і добудовує пропущені кроки. Так іде клас відмов «сценарій спрацював наполовину», коли одна штора поїхала, а друга залишилася в отворі.
Інтеграція із зовнішніми екосистемами йде через Apple Home: сценарії та групи штор видно ззовні, а логіка й розклади залишаються в застосунку.
Режими керування: хмарний, локальний і гібридний
Режим керування визначає, що станеться зі шторами, коли інтернет зникне або хмара відповість із затримкою.
Вибір між повністю хмарним керуванням, локальним керуванням через контролер на об'єкті та гібридним режимом — це не про зручність інтерфейсу, а про те, які сценарії виживають в аварійній ситуації.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повністю хмарне керування | Швидкий запуск, контролера на об'єкті немає | Робота за відсутності зовнішньої мережі припиняється, відгук залежить від каналу |
| Локальний контролер у квартирі | Пріоритет — швидкість реакції та автономність | Віддалений доступ лише через зовнішній канал, синхронізація сценаріїв вручну |
| Гібрид із пріоритетом локального контуру | Потрібні й автономність, і віддалений доступ | Складніше налаштування: два контури та правила вирішення конфліктів |
| Через наявний будинковий контролер | Контролер уже встановлено й він покриває приводи | Залежність від його можливостей і темпу оновлень |
Коли хмара неминуча
Хмарний контур потрібен там, де сценарії зав'язані на зовнішні дані: голосові асистенти, геолокація, розклади за сходом сонця, доступ для гостей. Якщо контролера на об'єкті немає, а приводи підключаються напряму, хмара залишається єдиною точкою збору стану.
Гібрид: що вирішується на об'єкті, а що в мережі
На об'єкті вирішується все, що потребує миттєвої реакції: команди з пульта та із застосунку в тій самій мережі, групи штор, крайні положення. У мережу виносимо розклади, сценарії за світлом і температурою, історію подій та віддалене керування. Під час втрати каналу застосунок перемикається на локальну адресу й продовжує працювати.
Етапи впровадження: від аудиту об'єкта до передачі
Мобільний застосунок для штор і жалюзі керує не екраном, а приводами через контролер: помилка в сценарії проявляється у фізиці — стулка не доїхала, група моторів пішла врозбіч. Тому маршрут робіт будуємо від об'єкта, а не від макета інтерфейсу.
- Аудит об'єкта автоматизації — типи приводів, живлення, слабкострумові лінії, якість зв'язку в товстих стінах, що залишаємо з наявного.
- Проєктування сценаріїв і ролей — групи штор за приміщеннями, добові та сценарні режими, права мешканця, гостя, служби експлуатації.
- Налаштування контролерів і локальної логіки — розклади та базові команди виконуються на місці, без зовнішньої мережі.
- Реалізація застосунку — інтерфейс під конкретні групи та зворотний зв'язок за фактичним положенням полотна, а не «відчинено — зачинено».
- Стендова перевірка на реальних приводах — прогін сценаріїв до монтажу: хід, крайні положення, синхронність групи.
- Прогін відмов — зникнення живлення, втрата зв'язку, заклинювання, ручне втручання та повернення в робочий режим.
- Передача й навчання служби експлуатації — документація, регламент обслуговування, розбір типових несправностей.
Що уточнюємо під час обстеження
Тип і хід приводів, кількість груп і вимоги до їхньої синхронності, точки живлення, наявність ручного керування та аварійних режимів. Окремо — де штори працюють як перепона і що має статися за сигналом тривоги.
Як виглядає приймальний прогін
Ідемо за списком перевірок: кожен сценарій в автоматичному й ручному режимі, затримки, групові команди, відмова каналу зв'язку, знеструмлення та повернення. Приймання підписуємо на реальних приводах і в присутності тих, хто буде експлуатувати об'єкт.
Що передаємо на руки: конфігурації, схеми, регламенти
Передаємо не «застосунок», а комплект, за яким систему можна розвивати й обслуговувати без нас. Нижче — що фізично залишається у замовника в його репозиторії та документообігу.
- Конфігурація сценаріїв: опис кожної автоматизації за схемою «подія → умова → дія» — ранковий підйом, реакція на вітер, режим «нікого немає» — з пріоритетами й тайм-аутами.
- Схема автоматизації: розміщення контролерів, приводів і датчиків за приміщеннями з адресацією. Монтажник знаходить вузол за схемою, без виїзду розробника.
- Матриця ролей і прав: хто і що може — мешканець, керуючий, сервісний інженер.
- Інструкція для мешканця: додати штору, перейменувати приміщення, що робити під час втрати зв'язку з приводом.
- Документація на застосунок: збірка, середовища, порядок оновлень і відкат на попередній реліз.
- Регламент обслуговування: періодичність перевірок, критерії відмови приводу, порядок ескалації.
- Порядок розширення: як додати приміщення або пристрій, не переписуючи ядро сценаріїв.
Матриця ролей і прав доступу
Ролі розділено за рівнем ризику: мешканцю доступні лише його приміщення та сценарії, керуючому — групові режими, сервісному інженеру — діагностика вузлів і журнали подій.
Права описано декларативно й вони лежать у конфігурації, тому новий співробітник отримує доступ зміною одного запису, а не правкою коду.
Регламент обслуговування та точка входу для служби експлуатації
У регламенті зафіксовано періодичність перевірок, ознаки деградації приводу та порядок ескалації: хто приймає заявку, за який час реагує, які журнали додає. Точка входу одна — служба експлуатації: їй передаємо доступи та контакт для ескалації до наших інженерів.
Кейс: застосунок для штор і жалюзі в житловому комплексі
Що показували заміри до переробки
Застосунок ставив задачу напряму на контролери квартир: команда йшла в зовнішній сервіс, чекала підтвердження і лише потім доїжджала до приводу. За нестійкого зв'язку в під'їзді частина команд не доходила з першого разу, і штори залишалися прочиненими на третину. На замірах у трьох корпусах частка команд, що спрацювали з першої спроби, становила 78%.
Жест «потягнути штору» оброблявся лише після мережевого відгуку, тому реакція займала від секунди до п'яти. Користувач повторював натискання, і зустрічні команди розводили приводи в протилежні положення.
Звернення до служби експлуатації накопичувалися навколо двох сценаріїв: штори, що заклинили на середині ходу, і жалюзі в кімнатах, де ніхто не жив. Диспетчер не бачив, яка команда прийшла останньою.
Що змінилося після перенесення логіки на об'єкт
Логіку сценаріїв перенесли на локальний контролер і шину KNX, закладену в проєкт комплексу.
Застосунок надсилає намір, а не послідовність команд: розклади, датчики освітленості та кінцевики приводу обробляються на місці, тому штори доводять хід до кінця навіть під час втрати зв'язку із зовнішнім сервером.
Реакція на жест рахується локально: екран показує рух одразу, приводу йде одна команда з фінальним положенням, повтори відсікаються. Частка команд з першої спроби зросла до 99,6%, відгук скоротився із секунд до десятих часток секунди.
Контролер ловить розходження кінцевих положень, ставить сценарій на паузу й пише в журнал квартиру, канал і останнє положення. Потік звернень про заклинені та наполовину відчинені штори впав майже в шість разів, решту розбирають за журналом без виїзду.
Що робити, якщо локальний контролер уже встановлено?
Встановлений контролер — не перешкода й не привід починати з нуля. Спочатку інвентаризація: які групи штор підключено, що ними керує — реле всередині наявного контролера або зовнішні модулі, де зберігаються сценарії та розклади. Від цього залежить, що переноситься логікою, а що залишається на залізі.
Сумісність приводів перевіряємо за способом керування, а не за маркою. Привод із дискретним входом або сухим контактом залишається на місці — новий шар подає ті самі команди, що й раніше.
Закрита шина вендора теж не глухий кут: між нею й контролером ставиться міст, привод продовжує працювати у своїй мережі.
Перенесення сценаріїв іде поетапно, без зупинки об'єкта. Спочатку новий шар підключається лише на читання: бачить фактичні положення груп і пише журнал спрацювань.
За цими даними звіряємо калібрування крайніх положень і час ходу — розходження спливають до того, як щось почне рухатися.
Потім групи переводяться по одній, починаючи з найменш значущої. Тиждень спостережень на групу показує, як поводяться сценарії світанку, що відбувається під час втрати зв'язку, чи спрацьовують кінцеві вимикачі.
Якщо поведінка розходиться з очікуваною, група повертається на попередній контур одним перемиканням.
Наявний контролер залишається другим контуром: ручні вимикачі та місцеві сценарії продовжують працювати. Поетапна заміна перестає бути разовим ризиком — відкат займає хвилини й не зачіпає вже перенесені групи.
Часті технічні питання: інтеграція, ролі, підтримка
Замовник приходить із працюючим об'єктом: контролер, приводи штор і пульти стоять, розклади налаштовані, міняти їх не хочеться. Звідси перші питання — сумісність, права, оновлення.
Ми будуємо застосунок так, що логіка сценаріїв живе в конфігурації на сервері, а сам застосунок залишається пультом. Змінювати поведінку штор можна без випуску нової версії, а ролі й доступи не переписуються на кожному пристрої.
Обладнання вже стоїть — застосунок із ним заробить?
Так, якщо у приводів і контролера є відкритий інтерфейс керування. Інженери знімають карту об'єкта: групи штор, пульти, чинні сценарії — і піднімають шар сумісності. Закриті системи підключаємо через штатний контролер, наприклад Home Assistant, не підміняючи заводську логіку.
Як розмежовуються ролі користувачів?
Ролі — власник, члени сім'ї, гість, сервісний інженер — задаються на боці сервера. Власник бачить усі приміщення й править сценарії, гість керує лише відведеними кімнатами й на заданий час. Сервісний доступ видається окремо, щоб налаштування не змінював випадковий користувач.
Що відбувається з налаштуваннями після оновлення застосунку?
Сценарії та прив'язки зберігаються поза застосунком, тому оновлення їх не затирає.
Перед випуском перевіряємо міграцію структури між версіями й тримаємо відкат на попередню збірку: якщо перевірки не пройшли, користувачі залишаються на робочій версії, а підтримка мобільного застосунку йде за журналом змін.
Обговоримо задачу: що потрібно знати про ваш об'єкт
Точність оцінки проєкту автоматизації напряму залежить від вихідних даних: чим менше припущень на старті, тим рідше сюрпризи на етапі монтажу й налаштування. Нижче — те, що знімає більшу частину невизначеності й дозволяє порахувати обсяг робіт без «плюс-мінус».
- Склад приміщень і зон: скільки кімнат, які керуються незалежно, де створки нестандартної ширини або похилі.
- Моделі приводів і спосіб керування — сухий контакт, шина або радіоканал: від цього залежить логіка команд у застосунку.
- Що вже встановлено на об'єкті: контролер, шлюз, блоки живлення, чи є відкритий інтерфейс для інтеграції.
- Ролі користувачів: власник, члени сім'ї, гості, обслуговуючий персонал — хто що бачить і що може змінювати.
- Поведінка під час обриву зв'язку: штори залишаються на місці, доїжджають до крайнього положення або утримують останню команду.
- Сценарії: розклади за часом і сонцем, групові команди, ручні сцени, прив'язка до датчиків світла й температури.
- Обмеження об'єкта: покриття радіозв'язку, доступ до мережі, вимоги до прихованої проводки та точок монтажу.
Із цим набором ми повертаємося з оцінкою та планом робіт: етапи, склад застосунку, схема інтеграції з обладнанням.
Передача документації — частина здачі проєкту: опис протоколу обміну, інструкції для монтажників і власника, порядок підключення нових приводів без перезбирання застосунку. Опишіть задачу — звіримо вхідні дані й запропонуємо формат роботи.
