Protokół MQTT w IoT: QoS, wiadomości retained i Last Will w praktyce

MQTT to podstawowy protokół komunikacji IoT. Lekki, binarny, zaprojektowany dla zawodnych sieci — działa na mikrokontrolerach z 64 KB RAM i skaluje się do milionów połączeń w Azure IoT Hub.

Poziomy QoS

• QoS 0 — co najwyżej raz: Wyślij i zapomnij. Bez ACK. Dla telemetrii o wysokiej częstotliwości, gdzie sporadyczne pominięte odczyty są akceptowalne.
• QoS 1 — co najmniej raz: Broker wysyła PUBACK; urządzenie retransmituje aż do ACK. Może dostarczać duplikaty — zaprojektuj przetwarzanie w chmurze tak, aby było idempotentne.
• QoS 2 — dokładnie raz: Czterofazowy handshake. Używaj tylko wtedy, gdy duplikaty wyrządzają realną szkodę (transakcje finansowe).

Last Will and Testament (LWT)

// Przy połączeniu: konfiguracja LWT (wysyłana przy nieoczekiwanym rozłączeniu)
.lwt_topic  = "devices/dev-001/status",
.lwt_msg    = "{"online":false,"reason":"unexpected"}",
.lwt_qos    = 1,
.lwt_retain = 1,
// Po połączeniu: publikacja statusu online (retained)
mqtt_publish(“devices/dev-001/status”,
”{“online”:true,“firmware”:“2.1.0”}”, QOS_1, RETAIN);

Projektowanie tematów pod skalę

Dobrze zaprojektowana hierarchia tematów upraszcza routing, filtrowanie i kontrolę dostępu. Źle zaprojektowana staje się obciążeniem w utrzymaniu wraz ze wzrostem floty. Nasza rekomendowana struktura używa ID urządzenia jako klucza głównego, z typem wiadomości jako pod-tematem:

devices/{deviceId}/telemetry        # odczyty sensorów (QoS 0/1)
devices/{deviceId}/status           # online/offline (retained, QoS 1)
devices/{deviceId}/commands/{cmd}   # polecenia z chmury do urządzenia
devices/{deviceId}/responses/{cmd}  # odpowiedzi urządzenia na polecenia
fleet/{productLine}/config          # rozgłoszenie konfiguracji na całą flotę

Unikaj głębokich hierarchii tematów przekraczających 4–5 poziomów. Unikaj umieszczania zawartości ładunku w ścieżkach tematów — utrzymuj strukturę tematów statyczną, a dane zmienne umieszczaj w ładunku. Dzięki temu reguły routingu są prostsze, a wydajność brokera lepsza.

MQTT kontra HTTPS w IoT

Niektóre urządzenia IoT używają HTTPS zamiast MQTT — zwykle gdy urządzenie jedynie wysyła dane (bez potrzeby poleceń), a prostota jest ceniona ponad efektywność. HTTPS ma większy narzut na wiadomość (handshake TLS + nagłówki HTTP), ale działa przez zapory blokujące port 8883. MQTT po WebSocketach (port 443) łączy semantykę MQTT z przyjaznością dla zapór.

Azure IoT Hub obsługuje zarówno MQTT, jak i HTTPS, a także AMQP dla scenariuszy o wysokiej przepustowości. Dla większości produktów łączonych właściwym wyborem jest MQTT na porcie 8883 z uwierzytelnianiem mTLS — jest efektywny, dobrze wspierany i wystarczająco bogaty semantycznie, aby w jednym połączeniu obsłużyć telemetrię, polecenia, wyzwalacze OTA i śledzenie obecności urządzeń.

Dobór brokera

Do developmentu i wdrożeń on-premises Mosquitto jest branżowym standardem open-source wśród brokerów MQTT — lekkim, niezawodnym i łatwym w konfiguracji. Do produkcyjnych wdrożeń w chmurze usługi zarządzane, takie jak Azure IoT Hub, AWS IoT Core czy HiveMQ Cloud, automatycznie obsługują terminację TLS, uwierzytelnianie i skalowanie poziome. Do produkcji rekomendujemy usługi zarządzane — samodzielne prowadzenie brokera MQTT na dużą skalę wprowadza złożoność operacyjną, która rzadko uzasadnia oszczędności.

Oceniając brokery, sprawdź: maksymalną liczbę połączeń, limity przechowywania wiadomości retained, wsparcie QoS 2 (jeśli potrzebne), limity rozmiaru wiadomości oraz kontrolę dostępu per urządzenie (czy urządzenie A może czytać tematy urządzenia B?). Azure IoT Hub domyślnie wymusza namespacing tematów per urządzenie — urządzenia mogą publikować tylko do własnej ścieżki tematu, co eliminuje całą klasę podatności bezpieczeństwa.