Взаємодія з IoT-пристроями через мобільний додаток

Реалізація взаємодії з IoT-пристроями через мобільний додаток

Додаток для розумного замка перестає отримувати оновлення, коли користувач виходить за 50 метрів — Bluetooth зникає, а перехід на Wi-Fi не передбачено. Або датчик температури надсилає дані раз на годину, але MQTT-брокер не підтверджує отримання, і показання втрачаються. Ми стикаємося з такими кейсами регулярно: обриви з'єднання, розсинхронізація стану, проблеми з OTA-оновленнями. В одному проекті 80% втрачених команд виникали через QoS 0 — після міграції на QoS 1 кількість помилок впала в 10 разів. За 5 років роботи з IoT ми реалізували понад 30 проектів, де ключовим завданням був стабільний зв'язок мобільного клієнта з пристроєм. У цій статті розберемо, як правильно реалізувати взаємодію з IoT-пристроями через мобільний додаток, використовуючи перевірені протоколи та патерни. Також розглянемо, як уникнути типових помилок при виборі протоколу та налаштуванні інфраструктури.

Ми пропонуємо інтеграцію під ключ: від вибору протоколу до деплою в магазини додатків. Економія на експлуатації за рахунок правильної архітектури може сягати 40%. Зв'яжіться з нами для оцінки вашого проекту. Замовте консультацію, і ми підберемо оптимальну архітектуру.

Який протокол вибрати для IoT-пристрою?

Мобільний додаток найчастіше виступає в ролі MQTT-клієнта або BLE Central. Пряме керування Zigbee з телефона без хаба — рідкість. BLE використовує в 10 разів менше енергії, ніж Wi-Fi, що критично для батарейних пристроїв.

MQTT: найпоширеніший IoT-транспорт

MQTT — pub/sub протокол поверх TCP, описаний у MQTT. Брокер (Mosquitto, AWS IoT, HiveMQ) приймає повідомлення та роздає підписникам. Мобільний додаток підписується на топіки пристроїв і публікує команди.

iOS — MQTT-Client-Framework або CocoaMQTT:

import CocoaMQTT

let client = CocoaMQTT(clientID: "mobile-\(UUID().uuidString)", host: "broker.example.com", port: 8883)
client.username = "user"
client.password = "pass"
client.enableSSL = true
client.keepAlive = 60
client.delegate = self
client.connect()

// Підписка після connect:
func mqtt(_ mqtt: CocoaMQTT, didConnectAck ack: CocoaMQTTConnAck) {
    guard ack == .accept else { return }
    mqtt.subscribe("devices/sensor-01/temperature", qos: .qos1)
}

// Отримання даних:
func mqtt(_ mqtt: CocoaMQTT, didReceiveMessage message: CocoaMQTTMessage, id: UInt16) {
    if let payload = message.string {
        let temp = Double(payload)
        updateUI(temperature: temp)
    }
}

// Публікація команди:
client.publish("devices/lamp-01/command", withString: "{\"state\":\"on\",\"brightness\":80}")

Android — Paho MQTT Android Service або HiveMQ MQTT Client:

// HiveMQ (більш сучасний, без deprecated API)
val client = MqttClient.builder()
    .useMqttVersion5()
    .serverHost("broker.example.com")
    .serverPort(8883)
    .sslWithDefaultConfig()
    .simpleAuth()
    .username("user")
    .password("pass".toByteArray())
    .applySimpleAuth()
    .buildAsync()

client.connect().whenComplete { _, throwable ->
    if (throwable == null) {
        client.subscribeWith()
            .topicFilter("devices/sensor-01/temperature")
            .qos(MqttQos.AT_LEAST_ONCE)
            .callback { publish ->
                val payload = String(publish.payloadAsBytes)
                // оновлюємо UI через Handler або LiveData
            }
            .send()
    }
}

Як QoS впливає на надійність MQTT?

QoS 0 — at most once. Швидко, без підтвердження. Для частих оновлень (температура кожну секунду) — нормально. QoS 1 — at least once. З підтвердженням, можливі дублі. Для команд (увімкнути/вимкнути) — мінімум. QoS 2 — exactly once. Гарантія доставки без дублів. Для платіжних операцій, критичних команд. Вибір QoS — компроміс між швидкістю та надійністю. Для більшості IoT-сценаріїв достатньо QoS 1.

Last Will Message

MQTT дозволяє задати повідомлення, яке брокер відправить при неочікуваному відключенні клієнта. Для IoT це важливо: якщо телефон пішов в офлайн, інші клієнти повинні про це знати:

client.willMessage = CocoaMQTTMessage(
    topic: "clients/mobile-app/status",
    string: "{\"online\":false}"
)

Синхронізація стану пристроїв

Головна архітектурна проблема: додаток відкрився — який зараз стан усіх пристроїв? MQTT не зберігає історію за замовчуванням. Рішення:

Retained messages — пристрій публікує свій стан з прапорцем retain = true. Брокер зберігає останнє повідомлення і одразу віддає при підписці. Мобільний додаток при старті підписується на devices/+/state і отримує актуальні стани. Retained messages в 5 разів швидше відновлюють стан після перепідключення, ніж відправка запиту через REST API.

Shadow/Digital Twin — AWS IoT Device Shadow, Azure Device Twin — REST API для читання останнього відомого стану пристрою. Підходить, коли станів багато і retained MQTT недостатньо.

OTA-оновлення прошивки

Якщо пристрій підтримує оновлення через мобільний додаток (BLE OTA або MQTT), це окреме завдання. Стандарти: Nordic DFU (для nRF-чипів через BLE), ESP-IDF OTA через HTTP/MQTT, MCU Bootloader через UART-bridge.

Як організувати фонову роботу без батарейних затрат?

Мобільний додаток не може тримати MQTT-з'єднання в фоні постійно. Для сповіщень про події пристроїв — APNS/FCM: брокер або backend відправляє push при зміні стану. Такий підхід економить до 30% заряду батареї телефона порівняно з постійним з'єднанням.

Що входить в роботу

1. Аналіз вимог та вибір протоколів
2. Проектування архітектури взаємодії (топіки, QoS, retained messages)
3. Розробка мобільного клієнта (iOS/Android) з інтеграцією по BLE/MQTT
4. Налаштування брокера та бекенду (якщо потрібно)
5. Реалізація OTA-оновлень через додаток
6. Налаштування push-сповіщень (APNS/FCM) для подій пристроїв
7. Тестування на реальних пристроях та налагодження
8. Підготовка документації та передача доступів

Терміни та вартість

Термін інтеграції: від 1 тижня (базовий MQTT-клієнт) до 3–4 тижнів (повний стек з OTA, синхронізацією стану, push-сповіщеннями). Вартість розраховується індивідуально. Зв'яжіться з нами для точної оцінки термінів та вартості. Отримайте консультацію.