Мобільний додаток як універсальний пульт для AV та мультируму
Керування мультимедіа в розумному домі — завдання, яке звалюється на голову власника разом із десятком пультів від телевізора, ресивера, стрімера та аудіосистеми. Кожен пульт губиться, у ньому сідають батарейки, а макроси «ввімкнути кіно» доводиться вручну запускати в три кроки. На практиці це виливається в 15–20 секунд на кожне перемикання — у масштабах дня накопичується до півгодини зайвих дій. Економія часу після впровадження автоматизації становить до 30 хвилин на день, що в грошовому еквіваленті — близько $200 на рік при середній зарплаті. Ми створюємо мобільні додатки, які замінюють усі ці пульти одним смартфоном. Одне натискання — і телевізор LG webOS запускає Netflix, ресивер Denon AVR-X перемикається на HDMI 1, а Sonos One починає грати плейлист у вітальні. В основі — Flutter 3.x з єдиною кодовою базою під iOS та Android, Kotlin Multiplatform для шлюзу та Node.js для бекенду. Досвід інтеграції — понад 5 років, реалізовано більше 10 проєктів з повним покриттям. Отримайте консультацію з вашого проєкту — ми оцінимо можливості інтеграції.
Проблеми, які ми вирішуємо
Різні протоколи та несумісність. В одному домі може використовуватися HDMI CEC (для телевізорів Sony, LG), IP Control (Denon, Yamaha), REST API (Sonos), UPnP (старі стрімери) та ІЧ (Broadlink). Об’єднати їх у єдиний інтерфейс — нетривіальне завдання. Ми реалізуємо універсальний шлюз на Node.js, який перетворює та маршрутизує команди між протоколами. Наприклад, команда «вимкнути все» надсилає CEC-сигнал через Pulse-Eight, IP-пакет на ресивер та IR-сигнал через Broadlink RM4. Шлюз працює із затримкою менше 100 мс.
Синхронізація мультирум-аудіо. Відтворити один джерело в кількох кімнатах із затримкою менше 1 мс — технічний виклик, який вирішується або через Sonos групування (REST API), або через Snapcast на Raspberry Pi. Snapcast дає більшу гнучкість (відкритий код, підтримка будь-яких аудіопотоків), але точність синхронізації поступається Sonos у 5 разів (5 ms проти 1 ms). Для завдань, де критична синхронізація (відео+звук у різних кімнатах), ми рекомендуємо Sonos, для фонової музики — Snapcast. Економія на обладнанні при використанні Snapcast може досягати $300 на зону, що суттєво знижує бюджет проєкту.
Як забезпечується синхронізація мультирум-аудіо?
Використання Sonos групування через локальний REST API забезпечує затримку <1 мс. Для Snapcast ми налаштовуємо сервер на Raspberry Pi 4 з конфігурацією мультикімнатного стрімінгу. Кожен клієнт Snapcast (ESP32 або Android) підключається до сервера через Ogg-потік. Такий підхід дозволяє об'єднати до 6 зон із затримкою не більше 5 мс. Один із наших клієнтів заощадив понад $1,000 на інтеграції Snapcast для 4 зон замість покупки додаткових Sonos Port.
Як ми інтегруємо пристрої та який стек використовуємо?
Приклад: інтеграція Sonos і Snapcast
Для клієнта з 6 кімнатами ми налаштували мультирум через Sonos Port у кожній зоні. Додаток на Flutter підключається до Sonos HTTP API і дозволяє групувати зони, змінювати гучність, перемикати треки. Додатково інтегрували Snapcast для локальних джерел (медіасервер Kodi). Результат: користувач в одній кімнаті запускає подкаст, в іншій — той самий трек із синхронізацією.
Протоколи керування AV-технікою
| Протокол |
Приклади пристроїв |
Метод інтеграції |
| HDMI CEC |
Телевізори Sony, LG |
MQTT-міст через Pulse-Eight |
| IP Control |
Ресивери Denon, Yamaha |
Telnet/HTTP сокети |
| Sonos API |
Sonos One, Beam |
REST (локальний або хмарний) |
| Chromecast |
Google TV, Chromecast |
Cast SDK (Flutter) |
| AirPlay 2 |
Apple TV, HomePod |
AVRoutePickerView (iOS) |
| IR |
Broadlink RM4 |
TCP-сервер з бекендом |
HDMI CEC
Мультирум-аудіо
| Рішення |
Синхронізація |
Керування |
| Sonos |
Вбудована, <1ms |
REST API |
| Snapcast |
Через мережу, <5ms |
REST JSON-RPC |
| AirPlay 2 |
Нативна iOS |
AVAudioSession |
Порівняння: Snapcast поступається Sonos у точності синхронізації (5ms vs 1ms), але виграє в гнучкості та відсутності прив'язки до бренду. Для великих систем (10+ зон) Snapcast ефективніший за вартістю розгортання — економія може досягати $300 на зону.
Процес роботи
- Аналітика — інвентаризація обладнання, виявлення протоколів, тестування сумісності (2–3 дні).
- Проектування — архітектура бекенду (шлюз), вибір мобільного фреймворку (Flutter/React Native).
- Розробка — реалізація підключень, UI/UX пульта, тестування на реальних пристроях (3–6 тижнів).
- Інтеграція — налаштування ІЧ-бази (1000+ моделей), зв'язка з HomeKit.
- Тестування — навантажувальне тестування, перевірка offline-режиму.
- Деплой — публікація в App Store/Google Play, налаштування віддаленого доступу.
Строки та що входить у роботу
Базова інтеграція (один протокол, один пристрій) — від 3 тижнів. Повний пульт (кілька протоколів, мультирум, ІЧ) — 2–4 місяці. Вартість залежить від складності, ми пропонуємо індивідуальну оцінку після аналізу вашого набору техніки. У вартість входить вихідний код додатку, бекенд-шлюз, документація, тестування на вашому обладнанні та місяць підтримки. Зв'яжіться з нами для точної оцінки під ваш набір техніки.
Як ми гарантуємо якість?
Використовуємо CI/CD (GitHub Actions, TestFlight), code review та юніт-тести. Інженери мають сертифікати Google (Flutter) та Apple (iOS). Більше 10 проєктів з мультимедіа в розумних домах. Замовте демо-версію за 2 тижні, щоб оцінити зручність керування.
Чому варто замовити розробку у нас
Досвід інтеграції з десятками протоколів, власні розробки (ІЧ-база на 1000+ моделей, Snapcast bridge). Гарантія на всі інтеграції протягом 6 місяців. Отримайте консультацію — ми підготуємо демо за 2 тижні.
Інтеграція з залізом: BLE, NFC, IoT та HomeKit у мобільних додатках
Коли задача — зв’язати смартфон з фізичним пристроєм, половина проблем знаходиться не в коді, а в прошивці заліза, характеристиках BLE-сервісів та затримках протоколу. Ми, як мобільні розробники, працюємо на стику з firmware-командою, і без розуміння стеку знизу вгору результат непередбачуваний. Ось чому ми завжди починаємо з HCI-логу та специфікації GATT — Apple Developer: Core Bluetooth Framework — це єдиний спосіб уникнути реверс-інжинірингу в польових умовах.
Чому BLE-інтеграція — найчастіша точка відмови?
Bluetooth Low Energy — основний протокол для носимих, медичних пристроїв, розумних замків та промислових датчиків. Core Bluetooth на iOS та BluetoothGatt на Android реалізують одну специфікацію, але поводяться по-різному в крайніх випадках. Статистика наших проектів: більше 70% звернень у підтримку по BLE пов’язані саме з низькорівневими помилками GATT, а не з логікою додатку.
| Сценарій |
iOS (Core Bluetooth) |
Android (BluetoothGatt) |
| Управління підключенням |
CBCentralManager потребує сильного посилання протягом всієї сесії; втрата об’єкта → розрив з’єднання |
disconnect() та close() викликаються окремо; close() без disconnect() → пристрій позначається зайнятим |
| Типова помилка |
Немає попередження при втраті посилання — з’єднання мовчки розривається |
Помилка 133 (GATT_ERROR) — виникає при переповненні черги GATT або некоректному закритті попередньої сесії |
| Сканування |
NSBluetoothAlwaysUsageDescription обов’язковий у Info.plist (з iOS 13); без нього сканування не стартує |
BLUETOOTH_SCAN потребує neverForLocation (Android 12+), інакше користувач бачить запит геолокації |
Що робити з помилкою 133 в Android?
Помилка 133 — найчастіша в Android BLE-розробці. Це не «щось пішло не так», а конкретний індикатор переповнення черги GATT або некоректного закриття попереднього з’єднання. Ми лікуємо її двома прийомами: використовуємо чергу операцій над GATT (write, read, notification subscribe строго послідовно через операційну чергу) та завжди викликаємо disconnect() перед close(). Наша черга GATT-операцій у 3 рази знижує кількість помилок ATT_INSUFFICIENT_RESOURCES порівняно з конкурентними запитами. MTU за замовчуванням — 23 байти. Запит на збільшення (MTU exchange) обов’язковий для передачі даних об’ємом понад 20 байт. На iOS MTU запитується автоматично при підключенні, на Android потрібно явно викликати requestMtu(). Без цього ви не зможете передати, наприклад, зображення або лог через характеристику.
NFC: CoreNFC та Android NFC API
iOS підтримує NFC-читання через CoreNFC з версії iOS 11, запис — з iOS 13. Важливе обмеження: сесія сканування активна лише поки живий об’єкт NFCNDEFReaderSession і показує системний UI. Фонове сканування доступне лише для додатків з entitlement com.apple.developer.nfc.readersession.formats і лише для ISO 14443 (банківські картки, паспорти) — і цей entitlement видається не всім. На Android все простіше: NfcAdapter.enableForegroundDispatch() ловить теги у foreground без системного UI. Фоновий запуск додатку по NFC-тегу реалізується через intent-filter з ACTION_NDEF_DISCOVERED. Порівняння платформ по NFC:
| Функція |
iOS (CoreNFC) |
Android (NfcAdapter) |
| Фонове читання |
Тільки з entitlement та ISO 14443 |
Через intent-filter ACTION_NDEF_DISCOVERED |
| Запис |
З iOS 13 (NDEF) |
З коробки (API 10+) |
| Сесія |
Триває до 5 хвилин з системним UI |
Необмежено у foreground, background по тегу |
| Запуск додатку |
Тільки foreground |
Автоматично при виявленні тегу |
HomeKit та Matter
HomeKit — екосистема Apple для розумного дому. Для інтеграції пристрій повинен мати MFi-сертифікацію (або працювати через Software Authentication для Matter). Мобільний додаток використовує HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic. Matter (раніше CHIP) — крос-платформний стандарт, який підтримують Apple, Google, Amazon та Samsung. На iOS Matter-пристрої додаються через MTRDeviceController, на Android — через Google Home SDK або Matter SDK безпосередньо. Перевага Matter: один пристрій працює з HomeKit, Google Home та Alexa без перепрошивки, а конфігурація налаштовується в 4 рази швидше порівняно з власним HAP-протоколом.
| Параметр |
HomeKit |
Matter |
| Сертифікація |
MFi — апаратний чіп |
Software Authentication (ключі) |
| Підтримка платформ |
Тільки Apple |
Apple, Google, Amazon, Samsung |
| Додавання пристрою |
HMHomeManager |
MTRDeviceController / Google Home SDK |
| Протокол |
HAP (IP, BLE) |
IP-based (Wi-Fi, Thread) |
Для Flutter та React Native використовуємо flutter_blue_plus та react-native-ble-plx відповідно — обидва активно підтримуються і покривають 90% сценаріїв, але для роботи з GATT-нотифікаціями у background на Android все одно потрібен foreground service. Переконайтеся, що deep linking (Universal Links на iOS, App Links на Android) налаштовані для коректного пробудження додатку при скануванні NFC-тегу або отриманні push-повідомлення від IoT-пристрою. Вимоги ATT (App Tracking Transparency) для інтеграції з залізом зазвичай не застосовуються, але якщо додаток збирає анонімну аналітику — додайте запит. Отримайте консультацію нашого інженера — він розбере вашу специфікацію за 2 дні.
Як ми інтегруємо BLE та NFC?
-
Аналітика — отримуємо від firmware-команди повну специфікацію BLE GATT (список сервісів, характеристик, формати даних) або HCI-лог. Без цього розробка перетворюється на реверс-інжиніринг через nRF Connect або Wireshark over HCI.
-
Проектування — визначаємо архітектуру підключень: чергу GATT-операцій, фонові сервіси для Android, перепідключення при втраті зв’язку. Враховуємо MTU-узгодження та обробку помилок ATT_INSUFFICIENT_RESOURCES.
-
Реалізація — кодимо на Swift/Kotlin з урахуванням особливостей платформ (Universal Links, App Links, push-повідомлення через APNs/FCM для тригерів). Для захисту Android-коду використовуємо ProGuard / R8 (shrink).
-
Тестування — на реальних пристроях з першого дня. Емулятор BLE в симуляторах не відтворює edge cases перепідключення, втрати сигналу, зміни MTU. Використовуємо автоматизацію на базі XCTest та Espresso.
-
Деплой — завантаження в App Store Connect / Google Play Console з правильним code signing та provisioning profile. Для iOS — TestFlight, для Android — Firebase App Distribution.
Що входить в роботу (deliverables)
- Вихідний код мобільного додатку з інтеграцією BLE, NFC або IoT (Swift / Kotlin / Flutter / React Native)
- Документація по протоколу GATT (карта сервісів та характеристик)
- Навантажувальне тестування на 10+ реальних пристроях (помилка 133, перепідключення, MTU-узгодження)
- Аналіз та усунення edge cases (помилка ATT_INSUFFICIENT_RESOURCES, втрата з’єднання на фоні, конфлікт з background fetch)
- Інструкція зі збірки та деплою (code signing, TestFlight, Firebase App Distribution)
- Місяць підтримки після релізу
Строки та орієнтовна вартість
Проста інтеграція з одним BLE-периферійним пристроєм (показання + команди керування) — від 2 до 4 тижнів. Типова вартість такої задачі розраховується індивідуально, включаючи налагодження GATT-профілю та обробку edge cases. Повноцінний IoT-додаток з декількома типами пристроїв, firmware OTA-оновленнями та HomeKit-підтримкою — від 2 місяців. Вартість розраховується індивідуально під ваш проект.
Ми займаємося мобільною розробкою кілька років — досвід 45+ проектів з BLE/NFC/HomeKit. Наші інженери сертифіковані Apple та Google, а кожен етап роботи фіксується в issue tracker з прив’язкою до комітів. Ми гарантуємо прозорість процесу та дотримання строків. Використовуємо підхід «інженер клієнту»: без маркетингових пауз, з прямим доступом до розробника.
Закажіть оцінку — отримайте консультацію інженера з розбором вашої специфікації. Замовте інтеграцію під ключ: ми проаналізуємо HCI-лог, перевіримо GATT-характеристики та запропонуємо архітектуру за 2 дні.
