MQTT w inteligentnym domu – do czego służy i kiedy warto go używać?

MQTT pozwala czujnikowi temperatury wysłać pomiar do kilku systemów jednocześnie, a sterownikowi oświetlenia odebrać polecenie bez bezpośredniego połączenia z aplikacją użytkownika. Nie jest jednak kolejnym standardem radiowym, takim jak Zigbee, Z-Wave czy Thread. To lekki protokół wymiany wiadomości, który działa w sieciach IP, najczęściej przez Wi-Fi lub Ethernet.

W inteligentnym domu MQTT (Message Queuing Telemetry Transport) przydaje się przede wszystkim do łączenia urządzeń różnych producentów, własnych projektów elektronicznych i systemów automatyki. Może działać całkowicie lokalnie, bez chmury producenta. Wymaga jednak serwera pośredniczącego, prawidłowej konfiguracji i kontroli nad tym, co dzieje się po utracie połączenia.

Jak działa MQTT? Broker, tematy i wymiana wiadomości

Podstawą MQTT jest model publish/subscribe, czyli publikowania i subskrybowania wiadomości. Urządzenia nie muszą znać swoich adresów ani komunikować się bezpośrednio. Wysyłają dane do brokera, który przekazuje je zainteresowanym odbiorcom.

Brokerem może być Eclipse Mosquitto, uruchomiony na Raspberry Pi, mini-PC lub serwerze z Home Assistant. To darmowe oprogramowanie typu open source, więc jego instalacja nie wymaga kupowania licencji.

Komunikacja opiera się na czterech elementach:

• Broker MQTT – serwer odbierający i rozsyłający wiadomości.
• Publisher – urządzenie lub program publikujący dane, np. czujnik temperatury.
• Subscriber – odbiorca subskrybujący wybrane wiadomości, np. Home Assistant.
• Topic – temat wiadomości, czyli jej logiczny adres, np. dom/salon/temperatura.

Przykładowo czujnik ESP32 mierzy temperaturę 22,6°C i publikuje wartość 22.6 w temacie dom/salon/temperatura. Home Assistant subskrybuje ten temat i aktualizuje wskazanie. Jednocześnie te same dane może odbierać Node-RED, zapisujący pomiary lub sterujący wentylacją.

Nie trzeba wysyłać dwóch osobnych wiadomości. Broker przekazuje publikację wszystkim odpowiednim subskrybentom, co szczególnie ułatwia rozbudowę instalacji.

MQTT oferuje trzy poziomy QoS (Quality of Service), określające zasady dostarczania wiadomości:

• QoS 0 – wiadomość jest wysyłana najwyżej raz, bez potwierdzenia odbioru. Wystarcza do cyklicznych pomiarów temperatury, gdy utrata pojedynczego odczytu nie ma znaczenia.
• QoS 1 – wiadomość jest dostarczana co najmniej raz, ale odbiorca może otrzymać duplikat. Sprawdza się tam, gdzie utrata komunikatu byłaby większym problemem niż jego ponowne przetworzenie.
• QoS 2 – protokół zapewnia dostarczenie dokładnie raz na poziomie wymiany MQTT, kosztem dodatkowych komunikatów. Nie oznacza to automatycznie jednorazowego wykonania fizycznej czynności przez urządzenie.

Dla domowego czujnika publikującego dane co 30 sekund QoS 0 zwykle wystarcza. Przy sterowaniu urządzeniem ważniejszy bywa QoS 1, ale wtedy polecenie powinno być odporne na duplikaty. Komunikat „ustaw przekaźnik na ON” jest bezpieczniejszy od „zmień stan przekaźnika”, ponieważ dwukrotne wykonanie drugiego polecenia może dać nieoczekiwany rezultat.

Przydatna jest również funkcja retained message. Broker zachowuje ostatnią wiadomość opublikowaną z flagą retain dla danego tematu i przekazuje ją nowemu subskrybentowi. Dzięki temu Home Assistant po restarcie może od razu otrzymać ostatni stan czujnika, zamiast czekać na kolejny pomiar.

Ma to jednak ograniczenie: zachowana wartość nie musi być aktualna. Czujnik, który odłączył się trzy godziny wcześniej, nadal może mieć ostatni odczyt zapisany na brokerze. Dlatego w bardziej rozbudowanej instalacji należy przewidzieć osobny temat dostępności urządzenia.

MQTT w Home Assistant, ESPHome i urządzeniach DIY – kiedy naprawdę się przydaje?

Największą zaletą MQTT jest możliwość połączenia urządzeń, które korzystają z różnych sposobów komunikacji, ale potrafią publikować lub odbierać wiadomości MQTT. Protokół jest szczególnie użyteczny w instalacjach wykorzystujących Home Assistant, Tasmota, Zigbee2MQTT, Node-RED i własne sterowniki ESP32.

Dobrym przykładem jest dom wyposażony w czujniki Zigbee, sterowniki Wi-Fi i własny moduł monitorujący temperaturę kotłowni. Zigbee2MQTT odbiera informacje z urządzeń Zigbee przez kompatybilny koordynator, a następnie udostępnia je brokerowi MQTT. Home Assistant może odbierać stany czujników i wysyłać polecenia sterujące.

W takiej konfiguracji MQTT nie zastępuje Zigbee. Stanowi warstwę wymiany danych pomiędzy bramką Zigbee a pozostałymi systemami.

Uruchomienie MQTT w Home Assistant można przeprowadzić w kilku krokach:

1. W instalacji Home Assistant OS otwórz ustawienia aplikacji i zainstaluj Mosquitto Broker. W innych typach instalacji broker można uruchomić osobno, np. w Dockerze.
2. W sekcji Ustawienia → Urządzenia i usługi dodaj integrację MQTT i połącz ją z brokerem. Przy oficjalnej aplikacji Mosquitto konfiguracja może odbyć się automatycznie.
3. Dodaj urządzenie obsługujące MQTT, podając adres brokera i wymagane dane uwierzytelniające.
4. Włącz MQTT Discovery, jeśli dane urządzenie obsługuje automatyczne wykrywanie. Funkcja jest domyślnie aktywna w integracji MQTT.
5. Sprawdź odbiór komunikatów w narzędziu do nasłuchiwania tematów MQTT, zanim utworzysz automatyzację.

MQTT Discovery pozwala odpowiednio skonfigurowanemu urządzeniu samodzielnie przekazać Home Assistant informacje o swoich encjach. Ogranicza to ręczną konfigurację czujników i przełączników, choć nadal wymaga poprawnie przygotowanych komunikatów konfiguracyjnych.

Inaczej wygląda sytuacja z ESPHome. Ten system udostępnia natywne API do komunikacji z Home Assistant, dlatego nie trzeba instalować MQTT tylko po to, aby obsługiwać czujnik ESP32.

Przykładowo własny czujnik temperatury z ESP32 i DS18B20 może przesyłać pomiary bezpośrednio do Home Assistant przez natywne API ESPHome. To prostsza konfiguracja: mniej usług, mniej danych dostępowych i brak dodatkowego brokera.

MQTT ma sens, gdy ten sam pomiar ma trafiać również do innego programu, niezależnego od Home Assistant. W ESPHome można wtedy skonfigurować klienta MQTT:

mqtt:
  broker: 192.168.1.20
  username: czujnik_salon
  password: !secret mqtt_password

Adres IP musi odpowiadać rzeczywistemu adresowi brokera, a użytkownik powinien mieć odpowiednie uprawnienia.

Istnieje przy tym pułapka konfiguracyjna. Jeśli w ESPHome pozostawiono sekcję api:, ale żaden klient nie łączy się z natywnym API, domyślny mechanizm nadzorujący połączenie może restartować urządzenie co 15 minut. Przy pracy wyłącznie przez MQTT trzeba usunąć niepotrzebną konfigurację API albo świadomie zmienić jej parametr reboot_timeout.

W projektach DIY MQTT szczególnie dobrze sprawdza się przy:

• monitorowaniu kotłowni – publikowaniu temperatur, stanów pomp i sygnałów awaryjnych;
• pomiarach zużycia energii – przekazywaniu odczytów licznika do Home Assistant i niezależnej bazy danych;
• sterowaniu przekaźnikami – odbieraniu poleceń i publikowaniu rzeczywistego stanu wyjść;
• integracji urządzeń Tasmota – lokalnym sterowaniu bez konieczności korzystania z chmury producenta.

Warto jednak odróżnić informację o wysłaniu polecenia od potwierdzenia wykonania. Przy sterowaniu pompą lub zaworem samo opublikowanie ON nie dowodzi, że urządzenie rzeczywiście zadziałało. Potrzebny jest osobny odczyt stanu, a przy istotnych instalacjach również fizyczne sprzężenie zwrotne.

MQTT nie powinien zastępować lokalnych zabezpieczeń kotła, pompy ani instalacji elektrycznej. Zabezpieczenia przed przegrzaniem, suchobiegiem czy przeciążeniem muszą działać niezależnie od sieci i brokera.

Bezpieczeństwo i niezawodność MQTT – kiedy lepiej z niego zrezygnować?

MQTT może działać w sieci lokalnej bez dostępu do internetu, ale nie oznacza to automatycznie bezpiecznej komunikacji. Źle skonfigurowany broker potrafi umożliwić nieautoryzowane sterowanie urządzeniami albo ujawniać dane dotyczące obecności domowników i pracy instalacji.

Standardowe porty MQTT to 1883 dla typowej komunikacji TCP bez TLS oraz 8883 dla połączeń MQTT zabezpieczonych TLS. Są to domyślne, powszechnie stosowane numery, a nie obowiązkowe ustawienia każdego brokera.

W domu najrozsądniej uruchomić brokera na własnym serwerze, ograniczyć dostęp do zaufanej sieci i nie przekierowywać portu 1883 z routera do internetu. Jeśli potrzebny jest zdalny dostęp, lepiej wykorzystać VPN, np. WireGuard, niż wystawiać usługę bezpośrednio do sieci publicznej.

Przy projektowaniu instalacji należy uwzględnić kilka zasad:

• Uwierzytelnianie – osobne konta lub dane dostępowe dla urządzeń i usług, zamiast anonimowego dostępu.
• Uprawnienia ACL – ograniczenie publikowania i subskrybowania do potrzebnych tematów. Czujnik temperatury nie powinien móc wysyłać poleceń do sterownika bramy.
• Szyfrowanie TLS – szczególnie istotne przy komunikacji przez niezaufane sieci. W zamkniętej sieci domowej decyzja zależy od modelu zagrożeń i możliwości urządzeń.
• Kontrola dostępności – wykorzystanie mechanizmu Last Will and Testament (LWT), aby broker mógł ogłosić nieoczekiwane rozłączenie klienta.
• Kopie zapasowe – zachowanie konfiguracji brokera, kont, uprawnień oraz danych potrzebnych do odtworzenia instalacji.

Przydatnym rozwiązaniem jest osobny temat, np. dom/kotlownia/status, w którym urządzenie publikuje online, a broker ma skonfigurowaną wiadomość LWT o wartości offline. Dzięki temu system automatyki może wykryć utratę połączenia po jej stwierdzeniu przez broker. Czas wykrycia zależy między innymi od ustawionego interwału keepalive i warunków sieciowych.

Najbardziej irytująca wada MQTT ujawnia się podczas awarii brokera. Gdy serwer zostanie wyłączony, klienci tracą wspólny punkt wymiany informacji. Czujnik może nadal wykonywać pomiary, a sterownik realizować lokalną logikę, ale wiadomości nie będą przekazywane normalną drogą.

Co ważne, QoS 1 i QoS 2 nie gwarantują zachowania wszystkich wiadomości podczas dowolnie długiej awarii. Znaczenie mają trwałość sesji, ustawienia kolejkowania, czas ważności komunikatów, implementacja klienta oraz konfiguracja brokera. Same poziomy QoS nie zastępują mechanizmów odporności na awarie.

W praktyce trzeba też uważać na zachowane polecenia. Jeśli komenda włączenia przekaźnika zostanie opublikowana z flagą retain, ponownie podłączone urządzenie może ją odebrać i wykonać, mimo że została wydana wcześniej. Dlatego poleceń sterujących zwykle nie należy publikować jako retained, chyba że świadomie zaprojektowano mechanizm odtwarzania stanu docelowego.

Kiedy MQTT jest zbędny? Przede wszystkim wtedy, gdy wszystkie urządzenia współpracują już z Home Assistant przez stabilne, natywne integracje. Przykładowo kilka modułów ESPHome połączonych przez natywne API nie zyska automatycznie większej niezawodności po dodaniu brokera MQTT. Pojawi się natomiast kolejna usługa wymagająca konfiguracji i utrzymania.

Podobnie Matter nie wymaga MQTT do sterowania kompatybilnymi urządzeniami. Matter korzysta z własnego mechanizmu komunikacji, a urządzenia mogą działać przez Thread, Wi-Fi lub Ethernet. Dokładanie MQTT wyłącznie dlatego, że dom jest „inteligentny”, nie ma technicznego uzasadnienia.

Wybór jest więc dość prosty: jeśli system ma wymieniać dane między kilkoma niezależnymi aplikacjami, obsługiwać urządzenia Tasmota, Zigbee2MQTT lub niestandardowe projekty DIY, MQTT jest praktycznym rozwiązaniem. Jeśli potrzebna jest tylko bezpośrednia obsługa kilku zgodnych urządzeń, natywna integracja będzie zazwyczaj łatwiejsza w utrzymaniu.

Pierwszym krokiem powinno być sprawdzenie, czy konkretne urządzenie rzeczywiście potrzebuje MQTT. Jeżeli tak, uruchom lokalnego brokera Mosquitto, skonfiguruj uwierzytelnianie i przetestuj pojedynczy czujnik. Dopiero po sprawdzeniu odczytów, ponownego łączenia i zachowania po restarcie warto dołączać kolejne urządzenia. To prostsze niż późniejsze szukanie przyczyny błędów w instalacji obejmującej kilkadziesiąt tematów.

FAQ – najczęstsze pytania o MQTT

Czy MQTT działa bez internetu?
Tak. Broker i urządzenia mogą komunikować się wyłącznie w lokalnej sieci LAN. Internet nie jest potrzebny, jeśli cała instalacja działa lokalnie.

Czy MQTT zastępuje Zigbee lub Z-Wave?
Nie. Zigbee i Z-Wave określają sposób komunikacji urządzeń w swoich sieciach, natomiast MQTT służy do wymiany wiadomości między klientami korzystającymi z sieci IP. Mogą współpracować przez odpowiednią bramkę.

Czy MQTT jest darmowy?
Sam protokół nie wymaga opłat licencyjnych. Broker Eclipse Mosquitto jest darmowy i dostępny jako oprogramowanie open source. Kosztem pozostają sprzęt, energia elektryczna i utrzymanie serwera.

Czy MQTT jest szybszy od Wi-Fi?
To nieporównywalne technologie. Wi-Fi zapewnia łączność sieciową, a MQTT działa na wyższym poziomie, wykorzystując zwykle TCP/IP. Opóźnienia zależą od sieci, brokera, urządzeń i konfiguracji.

Czy Home Assistant wymaga brokera MQTT?
Nie. Broker jest potrzebny do korzystania z integracji MQTT, ale Home Assistant obsługuje wiele urządzeń przez inne integracje, w tym natywne API ESPHome i Matter.

Co się stanie, gdy broker MQTT przestanie działać?
Wymiana wiadomości przez ten broker zostanie przerwana. Urządzenia mogą nadal wykonywać lokalne funkcje, ale automatyzacje zależne od MQTT mogą przestać działać do czasu przywrócenia połączenia.

Ile urządzeń może obsługiwać jeden broker MQTT?
Nie ma jednej uniwersalnej granicy. Limit zależy od brokera, sprzętu, liczby połączeń, częstotliwości publikacji i wielkości wiadomości. Kilkadziesiąt domowych czujników wysyłających krótkie komunikaty co kilkanaście sekund nie stanowi zwykle dużego obciążenia dla poprawnie skonfigurowanego serwera.

Czy MQTT nadaje się do alarmu lub sterowania ogrzewaniem?
Może służyć do przesyłania stanów i poleceń, ale nie powinien być jedynym mechanizmem odpowiedzialnym za bezpieczeństwo. Sterownik ogrzewania musi zachować bezpieczne działanie przy utracie sieci, a system alarmowy powinien mieć niezależne mechanizmy ochrony i sygnalizacji.