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

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

IoT-інтеграція — це не один протокол, а вибір між кількома залежно від фізичної дистанції, вимог до задержки та енергоспоживання. Додаток для управління розумною лампою в сусідній кімнаті та додаток для моніторингу промислових датчиків на виробництві використовують різні стеки, але стикаються з одинаковими проблемами: обриви з'єднання, синхронізація стану та оновлення прошивки.

Вибір транспорту

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

MQTT: найбільш розповсюджений IoT-транспорт

MQTT — pub/sub протокол поверх TCP. Брокер (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 та його вплив на надійність

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

Last Will Message

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

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

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

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

Retained messages. Пристрій публікує свій стан з флагом retain = true. Брокер зберігає останнє повідомлення й одразу віддає при підписці. Мобільне додаток при старті підписується на devices/+/state й отримує актуальні стани.

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.

Nordic DFU на iOS — iOSDFULibrary, на Android — Android-DFU-Library. Обидві офіційні бібліотеки від Nordic Semiconductor.

Фонова робота та сповіщення

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

На Android WorkManager + ForegroundService дозволяють тримати MQTT-з'єднання при необхідності. На iOS — Background App Refresh з обмеженням часу виконання.

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