MQTT

O MQTT está disponível escolhendo o protocolo mqtt num pedido WebSocket.

Configuração

Campo	Função
URL	O endereço do broker (mqtt://, mqtts:// ou WebSocket)
Tópico	O tópico, indicado no campo Evento
Mensagem	O payload publicado
QoS	0, 1 ou 2 — utilizada na publicação e na subscrição
Retain	Marca a mensagem como retida pelo broker
Identificador de cliente	Resolvido pelo Handlebars; gerado automaticamente se ficar vazio
Utilizador / Palavra-passe	Credenciais do broker; a palavra-passe aceita um valor do tipo Segredo
Keepalive	Em segundos
Subscrever ao ligar	Ativado por predefinição: ao ligar-se, o Restorm subscreve o tópico do pedido

O tópico aceita {{variables}} — capteurs/{{site}}/{{capteurId}} é um tópico perfeitamente válido.

Última vontade (Last Will and Testament)

Quatro campos declaram a mensagem que o broker publicará se o seu cliente desaparecer de forma abrupta: tópico, payload, QoS e retenção da última vontade.

É exatamente o que é preciso para testar o comportamento do seu sistema face a uma desconexão suja: configure uma última vontade, corte a ligação e verifique que o subscritor reage.

Nova ligação

O cliente MQTT volta a ligar-se automaticamente, com um limite de dez tentativas.

Num cenário

Ligação MQTT (que subscreve o tópico do pedido e emite um evento por mensagem recebida), Publicação MQTT (publica, com a QoS e a retenção do pedido) e Fecho da ligação MQTT. Consulte Ligações e fluxos.

Modo servidor

O Restorm sabe alojar um broker MQTT local: um broker por porta, acessível em TCP em bruto e através de um gateway MQTT-sobre-WebSocket. Consulte Simular WebSocket, Socket.IO e MQTT.

Importar a partir de AsyncAPI

Um documento AsyncAPI cujos canais utilizem o protocolo mqtt produz diretamente pedidos MQTT (um por canal, em publicação e em subscrição), com payloads de exemplo construídos a partir do esquema das mensagens. Consulte Importar AsyncAPI.