Під час розробки мобільного IoT-додатку вибір протоколу обміну даними критичний. MQTT — publish/subscribe поверх TCP з гарантіями доставки — став стандартом для пристроїв з обмеженими ресурсами. Проте на iOS/Android налаштування MQTT потребує врахування фонових режимів, економії батареї та нестабільної мережі. У нашій практиці інтеграція MQTT у проект розумного дому на Flutter скоротила затримки телеметрії до 200 мс при 10 000 пристроїв. Ключові рішення — QoS 1, персистентні сесії та mTLS. Ми працюємо з IoT понад 7 років і впровадили MQTT у 50+ проектах — від простих датчиків до промислових контролерів.
Як обрати оптимальний QoS для IoT?
Рівень QoS визначає баланс між надійністю та надлишковістю трафіку. Для мобільних пристроїв з обмеженим каналом це критично.
| Рівень QoS | Гарантія доставки | Трафік | Типове застосування |
|---|---|---|---|
| 0 | Жодної (одноразове надсилання) | Мінімальний | Телеметрія (температура, координати) |
| 1 | At least once (можливі дублікати) | Помірний | Команди (увімкнути/вимкнути) |
| 2 | Exactly once (чотирифазний handshake) | Максимальний | Критичні операції (фінанси, безпека) |
На практиці для IoT-команд найчастіше використовується QoS 1 у поєднанні з ідемпотентністю обробки на стороні пристрою. QoS 2 на мобільному пристрої у фоні може призвести до зависання сесії через переривання handshake — це підтверджують і наші кейси, де частка втрачених команд при QoS 2 становила до 5% через обриви. Порівняйте: для того ж обсягу даних HTTP з довгим опитуванням дає на 80% більше трафіку, що критично для тарифів з лімітом.
Чому Last Will обов'язковий для IoT?
Last Will Message (LWM) — механізм, який дозволяє брокеру автоматично опублікувати повідомлення про нештатне відключення клієнта. Без LWM UI показуватиме пристрій як онлайн до закінчення keep-alive таймауту (20–60 секунд). Ми завжди налаштовуємо LWM з топіком {deviceId}/status та повідомленням {"status":"offline"}. Персистентна сесія (cleanSession: false) доповнює LWM: брокер зберігає чергу повідомлень для офлайн-клієнта. При перепідключенні клієнт отримує всі пропущені команди. Важно налаштувати sessionExpiryInterval (у MQTT 5) або cleanSession (у MQTT 3.1.1), щоб черга не зростала нескінченно — наприклад, для датчиків з рідкісним надсиланням достатньо 1 години.
Що таке персистентна сесія і коли її використовувати?
Персистентна сесія гарантує доставку повідомлень при тимчасовому відключенні пристрою. Вона незамінна для систем, де кожна команда повинна бути виконана, наприклад, для дверних замків або промислових контролерів. Однак на пристроях з обмеженою пам'яттю черга може переповнитися — ми рекомендуємо встановлювати sessionExpiryInterval не більше 24 годин. В одному з проектів на Kotlin Multiplatform налаштування персистентних сесій дозволило знизити втрату команд з 12% до 0.1%.
Вибір клієнтської бібліотеки
Для кожної платформи є оптимальні варіанти.
| Платформа | Рекомендована бібліотека | Підтримка MQTT 5 |
|---|---|---|
| Android | HiveMQ MQTT Client | Так |
| iOS | CocoaMQTT | Ні |
| Flutter | mqtt_client | Ні |
| React Native | react_native_mqtt (обгортка) | Ні |
Android: HiveMQ активно підтримується, працює з Kotlin Coroutines. iOS: CocoaMQTT простий у налаштуванні, але не підтримує MQTT 5. Flutter: mqtt_client популярний, підтримує MQTT 3.1.1 та WebSocket-транспорт. React Native: нативного MQTT немає — використовуйте обгортку над нативними Paho або WebSocket-транспорт з mqtt.js. Для проектів з високочастотним потоком даних (понад 1000 повідомлень/сек) розглядайте MQTTNio на iOS.
TLS та безпека з'єднання
Для продакшну обов'язково використовуйте MQTT over TLS (порт 8883). Взаємна TLS-аутентифікація (mTLS) — стандарт безпеки в IoT, але для мобільного додатка достатньо username/password у парі з серверним сертифікатом. Зберігайте credentials у Keychain (iOS) або EncryptedSharedPreferences (Android). Ніколи не хардкодьте URL брокера — використовуйте remote config. Ми застосовуємо таку схему у всіх проектах, і за 7 років жодного інциденту з витоком облікових даних.
Що входить у нашу роботу з інтеграції MQTT
Ми пропонуємо повний цикл інтеграції:
- Аналіз топік-схеми та вимог до QoS
- Вибір та налаштування брокера (Mosquitto, EMQX, HiveMQ)
- Інтеграція клієнтської бібліотеки з TLS-шифруванням
- Налаштування Last Will та персистентних сесій
- Тестування у фоновому режимі та на нестабільній мережі
- Документація та навчання команди
Термін інтеграції MQTT в існуючий мобільний додаток — 1–3 тижні залежно від складності. Оцініть ваш проект за 2 дні — просто напишіть нам. Отримайте консультацію щодо вибору протоколу та архітектури.
Стандарт MQTT визначено в специфікації OASIS MQTT. Замовте аналіз вашого IoT-проекту — ми допоможемо обрати оптимальний стек та налаштування.