W automatyce często trzeba połączyć czujniki, sterowniki, panele operatorskie i system nadrzędny, nie prowadząc osobnego połączenia między każdą parą urządzeń. MQTT rozwiązuje ten problem za pomocą lekkiej wymiany komunikatów przez brokera. Wyjaśniam, jak działa ten protokół, czym są topic i QoS, gdzie sprawdza się w automatyce oraz na jakie błędy uważać przy jego wdrażaniu.
MQTT upraszcza wymianę danych między urządzeniami automatyki
- MQTT to lekki protokół komunikacyjny oparty na modelu publish-subscribe.
- Broker pośredniczy w przesyłaniu wiadomości między urządzeniami.
- Dane są kierowane do tematów, czyli topiców, a nie bezpośrednio do konkretnego odbiorcy.
- Poziomy QoS 0, 1 i 2 pozwalają dobrać kompromis między szybkością a pewnością dostarczenia.
- MQTT dobrze nadaje się do telemetrii i sterowania, ale nie zastępuje deterministycznych magistral w obwodach bezpieczeństwa.
Co to jest MQTT i jak działa w praktyce
MQTT, czyli Message Queuing Telemetry Transport, jest lekkim protokołem przesyłania wiadomości przeznaczonym między innymi dla Internetu Rzeczy, systemów telemetrycznych i automatyki. Działa zazwyczaj nad TCP/IP, dlatego może korzystać z sieci Ethernet, Wi-Fi, LTE albo połączeń VPN.
Najważniejsza różnica w porównaniu z klasyczną komunikacją punkt-punkt polega na tym, że urządzenia nie wysyłają danych bezpośrednio do siebie. Wszystkie łączą się z pośrednikiem, czyli brokerem. Nadajnik publikuje wiadomość, a odbiorca wcześniej zapisuje się na interesujący go temat.
Trzy elementy komunikacji
- Publisher publikuje dane, na przykład temperaturę z czujnika.
- Subscriber subskrybuje wybrany temat i odbiera wiadomości.
- Broker MQTT przyjmuje komunikaty i przekazuje je właściwym odbiorcom.
Jedno urządzenie może pełnić obie role jednocześnie. Sterownik może publikować aktualną temperaturę, a równocześnie subskrybować temat z poleceniami uruchomienia wentylatora. Właśnie ta dwukierunkowość sprawia, że MQTT pasuje zarówno do monitoringu, jak i prostego sterowania.
Topic działa jak adres logiczny
Wiadomość trafia do określonego topicu, czyli hierarchicznej nazwy opisującej rodzaj danych. Przykładowy temat może wyglądać tak:
zaklad/linia-1/szafa-sterownicza/temperaturaUrządzenie może subskrybować dokładnie ten temat albo użyć symboli wieloznacznych. Znak + zastępuje jeden poziom hierarchii, a znak # obejmuje dany poziom i wszystkie kolejne. Dzięki temu system nadrzędny może odebrać dane z całej linii produkcyjnej, podczas gdy panel lokalny będzie obserwował tylko jedną szafę.
Jak wygląda wymiana danych przez brokera
Załóżmy, że czujnik temperatury jest podłączony do mikrokontrolera albo sterownika PLC. Urządzenie łączy się z brokerem, publikuje wartość w wybranym topicu, a broker przekazuje ją wszystkim klientom, które mają odpowiednią subskrypcję. Publisher nie musi znać adresów odbiorców ani wiedzieć, ilu ich aktualnie jest.
W praktyce przepływ może wyglądać następująco:
- Czujnik publikuje komunikat 23,6°C w temacie dotyczącym temperatury.
- Broker sprawdza listę aktywnych subskrypcji.
- System SCADA odbiera dane do wizualizacji.
- Moduł archiwizacji zapisuje pomiar w bazie.
- Telefon technika może otrzymać alarm, jeśli wartość przekroczy ustalony próg.
Treść wiadomości, czyli payload, nie musi mieć narzuconego formatu. Może to być pojedyncza liczba, tekst albo obiekt JSON. Ja preferuję, aby w danych automatyki oprócz wartości umieszczać także jednostkę, znacznik czasu i identyfikator urządzenia. Ułatwia to późniejsze diagnozowanie problemów.
{
"value": 23.6,
"unit": "C",
"device": "czujnik-07",
"timestamp": "2026-08-13T10:15:00Z"
}Retained message i Last Will
MQTT oferuje kilka funkcji, które mają duże znaczenie w praktycznych instalacjach. Retained message pozwala brokerowi przechować ostatnią wiadomość na danym topicu. Gdy nowy panel połączy się z systemem, może od razu otrzymać ostatni znany stan, bez czekania na kolejny pomiar.
Przy komendach sterujących z retencją trzeba jednak uważać. Zapamiętane polecenie „włącz” może zostać wykonane przez urządzenie po ponownym uruchomieniu, jeśli projekt nie przewiduje bezpiecznego kasowania lub wygasania komendy.
Funkcja Last Will and Testament pozwala opublikować ustalony komunikat, gdy klient rozłączy się nieoczekiwanie. Dzięki temu system może szybko oznaczyć urządzenie jako niedostępne, zamiast bez końca wyświetlać jego ostatni poprawny pomiar.
QoS, czyli jak pewnie dostarczyć wiadomość
MQTT udostępnia trzy poziomy jakości dostarczenia. Nie należy jednak traktować QoS jako prostego ustawienia „szybko” albo „bezpiecznie”. Wyższy poziom oznacza dodatkową wymianę potwierdzeń, większy narzut i często dłuższy czas obsługi wiadomości.
| Poziom | Zasada działania | Typowe zastosowanie |
|---|---|---|
| QoS 0 | Wiadomość jest wysyłana najwyżej raz. Może zostać utracona. | Częste pomiary temperatury, wilgotności lub ciśnienia. |
| QoS 1 | Wiadomość powinna dotrzeć co najmniej raz, ale może pojawić się duplikat. | Alarmy, polecenia i dane, których nie powinno się łatwo zgubić. |
| QoS 2 | Protokół zapewnia dostarczenie dokładnie raz na poziomie wymiany MQTT. | Rzadkie operacje, w których duplikat ma poważne konsekwencje. |
W typowej telemetrii najczęściej wystarcza QoS 0. Jeżeli czujnik wysyła pomiar co kilka sekund, utrata jednej próbki zwykle nie ma znaczenia, bo za chwilę pojawi się następna. Dla komendy otwarcia zaworu rozsądniejszy może być QoS 1, ale aplikacja musi umieć bezpiecznie obsłużyć powtórzoną wiadomość.
QoS 2 nie gwarantuje, że fizyczne wykonanie operacji nastąpi tylko raz. Jeśli odbiornik za każdym razem uruchamia procedurę bez sprawdzenia identyfikatora polecenia, problem może powstać poza samym protokołem. Dlatego ważna jest także idempotencja, czyli zaprojektowanie operacji tak, aby ponowne otrzymanie tej samej komendy nie powodowało niepożądanych skutków.
Gdzie MQTT sprawdza się w automatyce
MQTT dobrze pasuje tam, gdzie trzeba zbierać dane z wielu rozproszonych punktów i udostępniać je kilku systemom. Nie trzeba tworzyć osobnego połączenia między każdym czujnikiem, panelem i bazą danych. Wystarczy wspólny broker oraz przemyślana struktura topiców.
Monitoring maszyn i energii
Sterownik może publikować temperaturę szafy, stan napędu, liczbę cykli, pobór energii albo sygnał alarmowy. Te same dane mogą równocześnie trafić do SCADA, systemu raportowego i aplikacji serwisowej. To ogranicza liczbę integracji i ułatwia rozbudowę instalacji.
Budynki i instalacje techniczne
W automatyce budynkowej MQTT może łączyć sterowniki HVAC, liczniki energii, czujniki jakości powietrza i system wizualizacji. Przy dużej liczbie urządzeń szczególnie wygodna jest możliwość filtrowania topiców według budynku, piętra, pomieszczenia lub rodzaju instalacji.
Przeczytaj również: Robot przegubowy - jak wybrać i wdrożyć, by zwiększyć zysk?
Zdalna diagnostyka
Urządzenie może publikować stan połączenia, kody błędów, czas pracy i wartości diagnostyczne. Technik otrzymuje wtedy nie tylko informację, że maszyna przestała działać, ale także dane potrzebne do znalezienia przyczyny. W mojej ocenie to jedno z bardziej praktycznych zastosowań MQTT, bo dobrze zaprojektowana telemetria często skraca pierwszą diagnozę bez wizyty na miejscu.
MQTT a Modbus i OPC UA
MQTT nie jest uniwersalnym zamiennikiem wszystkich protokołów przemysłowych. Każde z tych rozwiązań odpowiada na trochę inny problem, dlatego wybór powinien wynikać z architektury instalacji.
| Protokół | Najmocniejsza strona | Ograniczenie |
|---|---|---|
| MQTT | Rozproszona wymiana zdarzeń i telemetrii przez brokera. | Brak gwarancji deterministycznego czasu reakcji. |
| Modbus | Prosta komunikacja z licznikami, falownikami i sterownikami. | Mniej wygodny przy dużej liczbie odbiorców i rozproszonych systemach. |
| OPC UA | Rozbudowany model danych, diagnostyka i integracja przemysłowa. | Większa złożoność i wymagania sprzętowe niż w lekkim MQTT. |
Często najlepsza jest architektura mieszana. Sterownik komunikuje się lokalnie z falownikiem przez Modbus, a do systemu nadrzędnego publikuje wybrane dane przez MQTT. Taki podział zachowuje prostotę warstwy polowej i jednocześnie ułatwia przesyłanie informacji do wielu aplikacji.
Nie używałbym MQTT do funkcji awaryjnego zatrzymania, blokad bezpieczeństwa ani szybkiej regulacji wymagającej ściśle określonego czasu reakcji. W tych obszarach potrzebne są rozwiązania przeznaczone do sterowania deterministycznego i bezpieczeństwa maszyn, a MQTT może co najwyżej przekazywać stan lub informację diagnostyczną.
Jak bezpiecznie wdrożyć MQTT
Sam fakt użycia MQTT nie oznacza, że instalacja jest bezpieczna. Broker wystawiony bezpośrednio do Internetu, z anonimowym dostępem i wspólnym hasłem dla wszystkich urządzeń, jest poważnym ryzykiem. W automatyce konsekwencje nie kończą się na utracie danych, bo nieautoryzowana komenda może wpłynąć na pracę maszyny.
Przy wdrożeniu stosuję następujące minimum:
- TLS do szyfrowania połączenia, szczególnie poza zaufaną siecią lokalną.
- Osobne konta i hasła dla urządzeń, operatorów oraz systemów integracyjnych.
- ACL, czyli listę uprawnień ograniczającą dostęp do konkretnych topiców.
- Wyłączenie anonimowego logowania.
- Oddzielenie sieci urządzeń od zwykłej sieci biurowej.
- Rejestrowanie połączeń, błędów i prób dostępu.
Dobrym zwyczajem jest rozdzielenie topiców z pomiarami od topiców sterujących. Odbiorca, który ma prawo czytać temperaturę, nie powinien automatycznie otrzymywać prawa publikowania komend do napędu. Najmniejsze potrzebne uprawnienia są tu ważniejsze niż wygoda konfiguracji.
Najczęstsze błędy przy projektowaniu instalacji
Pierwszy błąd to chaotyczne nazewnictwo topiców. Nazwy typu „dane1”, „test” i „nowy_czujnik” szybko przestają być czytelne. Lepiej od początku ustalić stały schemat, na przykład obiekt/obszar/urządzenie/parametr, oraz zdecydować, czy nazwy będą pisane małymi literami i bez polskich znaków.
Drugi problem to publikowanie zbyt dużych pakietów i zbyt częstych komunikatów. MQTT jest lekki, ale broker, sieć i system archiwizacji nadal mają ograniczoną wydajność. Dla wolno zmieniającej się temperatury wysyłanie danych kilka razy na sekundę zwykle nie daje żadnej wartości, a tylko zwiększa ruch.
Trzeci błąd dotyczy polegania na ostatnim pomiarze bez kontroli aktualności. Jeżeli urządzenie utraciło zasilanie, broker może nadal przechowywać jego ostatnią wiadomość retained. Dlatego razem z wartością trzeba sprawdzać stan połączenia, czas pomiaru i komunikat Last Will.
Początkujący często ustawiają QoS 2 wszędzie, sądząc, że zapewni najlepszą jakość. W praktyce może to zwiększyć narzut bez realnej korzyści. Dla każdego rodzaju danych lepiej osobno określić, czy ważniejsza jest szybkość, brak duplikatów, czy odporność na chwilową utratę sieci.
Jak zacząć z MQTT bez komplikowania projektu
Na początku nie trzeba budować rozbudowanej platformy. Wystarczy jeden broker działający na komputerze przemysłowym, serwerze lokalnym albo odpowiednio zabezpieczonej usłudze chmurowej, jeden klient publikujący dane i drugi klient odbierający wiadomości.
- Wybierz jeden rzeczywisty przypadek, na przykład monitoring temperatury szafy.
- Zaprojektuj topic i format danych przed rozpoczęciem programowania.
- Uruchom uwierzytelnianie oraz szyfrowanie, nawet jeśli test odbywa się w sieci lokalnej.
- Sprawdź zachowanie po restarcie urządzenia, utracie sieci i ponownym połączeniu.
- Dodaj alarmy, zapis historii i diagnostykę dopiero po potwierdzeniu poprawnej komunikacji.
Do testów przydają się proste programy klienckie MQTT, które pozwalają ręcznie publikować i obserwować wiadomości. Dzięki nim można szybko wykryć literówkę w topicu, zły poziom QoS albo problem z uprawnieniami, zanim zacznie się szukać błędu w kodzie sterownika.
Jeżeli projekt ma działać długo, od razu zaplanuj wersję protokołu. MQTT 5.0 rozwija między innymi obsługę błędów, właściwości wiadomości, limitów i komunikacji request-response, natomiast MQTT 3.1.1 wciąż pozostaje popularne w wielu bibliotekach i urządzeniach. Najważniejsza jest zgodność brokera, bibliotek oraz sprzętu, a nie sama numeracja wersji.
Od prostego czujnika do sprawnej architektury
Na pytanie, co to jest MQTT, najkrócej odpowiem tak: to lekki sposób przekazywania wiadomości między urządzeniami, w którym broker rozdziela dane według topiców. Jego siła nie wynika z tego, że zastępuje każdy protokół, lecz z tego, że pozwala łatwo połączyć wiele różnych systemów.
W małej instalacji MQTT może obsługiwać kilka czujników i panel operatorski. W większej staje się warstwą wymiany telemetrii między automatyką lokalną, SCADA, bazą danych i aplikacjami serwisowymi. Jeśli dobrze zaprojektujesz topic, uprawnienia, QoS i reakcję na utratę połączenia, otrzymasz rozwiązanie lekkie, elastyczne i wygodne w dalszej rozbudowie.
