MQTT

MQTT jest dostępny po wybraniu protokołu mqtt w żądaniu WebSocket.

Konfiguracja

Pole	Rola
URL	Adres brokera (mqtt://, mqtts:// lub WebSocket)
Temat	Temat, przenoszony przez pole Zdarzenie
Wiadomość	Publikowany ładunek
QoS	0, 1 lub 2 — używana zarówno przy publikacji, jak i przy subskrypcji
Retain	Oznacza wiadomość jako zachowaną przez brokera
Identyfikator klienta	Rozwiązywany przez Handlebars; generowany automatycznie, jeśli pozostanie pusty
Użytkownik / Hasło	Dane uwierzytelniające brokera; hasło przyjmuje wartość typu Sekret
Keepalive	W sekundach
Subskrybuj przy połączeniu	Włączone domyślnie: po nawiązaniu połączenia Restorm subskrybuje temat danego żądania

Temat przyjmuje {{variables}} — capteurs/{{site}}/{{capteurId}} jest całkowicie poprawnym tematem.

Ostatnia wola (Last Will and Testament)

Cztery pola deklarują wiadomość, którą broker opublikuje, jeśli klient zniknie w sposób nagły: temat, ładunek, QoS i retencja ostatniej woli.

To dokładnie to, czego potrzeba, aby przetestować zachowanie systemu wobec nieprawidłowego rozłączenia: wystarczy skonfigurować ostatnią wolę, przerwać połączenie i sprawdzić, czy subskrybent reaguje.

Ponowne łączenie

Klient MQTT łączy się ponownie automatycznie, z limitem dziesięciu prób.

W scenariuszu

Połączenie MQTT (subskrybuje temat żądania i emituje jedno zdarzenie na każdą odebraną wiadomość), Publikacja MQTT (publikuje, z QoS i retencją pobranymi z żądania) oraz Zamknięcie połączenia MQTT. Zob. Połączenia i strumienie.

Tryb serwera

Restorm potrafi hostować lokalny broker MQTT: jeden broker na port, dostępny przez surowy TCP oraz przez bramę MQTT-na-WebSocket. Zob. Symulowanie WebSocket, Socket.IO i MQTT.

Import z dokumentu AsyncAPI

Dokument AsyncAPI, którego kanały używają protokołu mqtt, tworzy bezpośrednio żądania MQTT (po jednym na kanał, w trybie publikacji i subskrypcji), wraz z przykładowymi ładunkami zbudowanymi na podstawie schematu wiadomości. Zob. Import AsyncAPI.