> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/pt-br/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md). # Fundamentos do MQTT Protocolo de publicação/assinatura que possibilita a comunicação leve de dispositivos IoT. Aborda a configuração do broker MQTT, formatos de mensagem, níveis de QoS e casos de uso de telemática. O protocolo de Transporte de Telemetria por Filas de Mensagens (MQTT) vem sendo usado há muitos anos, mas agora é especialmente relevante devido ao crescimento explosivo da IoT: tanto dispositivos de consumo quanto industriais estão implementando redes distribuídas e computação de borda, e dispositivos com transmissão contínua de dados estão se tornando parte do cotidiano. Esse crescimento intenso força as pessoas a buscar maneiras de transferir dados com eficiência. ## O que é MQTT Andy Stanford-Clark (IBM) e Arlen Nipper (então trabalhando para a Eurotech, Inc.) escreveram a primeira versão do protocolo em 1999. Ele foi usado para monitorar oleodutos dentro da estrutura SCADA. O objetivo era ter um protocolo eficiente em termos de largura de banda, leve e que consumisse pouca energia da bateria, porque os dispositivos eram conectados por um link via satélite que, naquela época, era extremamente caro. Atualmente, a maioria dos dispositivos usa a versão 5.0. O Transporte de Telemetria por Filas de Mensagens (MQTT) é um protocolo de rede leve, de publicação e assinatura, que transporta mensagens entre dispositivos. O protocolo normalmente é executado sobre TCP/IP; no entanto, qualquer protocolo de rede que forneça conexões ordenadas, sem perdas e bidirecionais pode oferecer suporte ao MQTT. Ele foi projetado para conexões com locais remotos em que é necessária uma “pequena pegada de código” ou a largura de banda da rede é limitada. O protocolo é um padrão aberto da OASIS e uma recomendação da ISO (ISO/IEC 20922). Dadas as condições de operação, o protocolo é mantido pequeno e leve. Ele é ideal para dispositivos com baixo consumo de energia e vida útil limitada da bateria. Hoje em dia, isso inclui smartphones, bem como um número cada vez maior de sensores e Dispositivos conectados. Assim, o MQTT se tornou um protocolo para streaming de dados entre dispositivos com poder de CPU limitado e/ou vida útil da bateria limitada, bem como para redes com largura de banda cara ou baixa, estabilidade imprevisível ou alta latência. É por isso que o MQTT é conhecido como o protocolo ideal para IoT. Ele é baseado no protocolo TCP/IP, mas existe um ramo do MQTT-SN para funcionar sobre Bluetooth, UDP, ZigBee e em outras redes IoT além do TCP/IP. ## Como funciona ### O modelo de publicação e assinatura Há 2 definições principais no MQTT: broker MQTT e cliente MQTT. Um broker MQTT é um servidor que recebe todas as mensagens dos clientes e depois encaminha as mensagens aos clientes de destino apropriados. Em palavras simples, o broker atua como uma agência de correios; o MQTT não usa o endereço do destinatário pretendido, mas usa a linha de assunto chamada “tópico”, e qualquer pessoa que queira uma cópia dessa mensagem assinará esse tópico. Vários clientes podem receber a mensagem de um único broker (capacidade de um para muitos). Da mesma forma, vários publicadores podem publicar tópicos para um único assinante (muitos para um). Um cliente MQTT é qualquer dispositivo (de um microcontrolador até um servidor completo) que executa uma biblioteca MQTT e se conecta a um broker MQTT por meio de uma rede. * O cliente se conecta ao broker. Ele pode assinar qualquer tópico de mensagem no broker. Essa conexão pode ser uma conexão TCP/IP simples ou uma conexão TLS criptografada para mensagens sensíveis. * O cliente publica mensagens sob um tópico ao enviar a mensagem e o tópico ao broker. * O broker então encaminha a mensagem para todos os clientes que assinam esse tópico. Como as mensagens MQTT são organizadas por tópicos, o desenvolvedor da aplicação tem a flexibilidade de especificar que certos clientes só podem interagir com certas mensagens. Por exemplo, sensores publicarão suas leituras sob o tópico “sensor\_data” e assinarão o tópico “config\_change”. Aplicações de processamento de dados que salvam dados de sensores em um banco de dados de retaguarda assinarão o tópico “sensor\_data”. Uma aplicação de console administrativo poderia receber comandos do administrador do sistema para ajustar as configurações dos sensores, como sensibilidade e frequência de amostragem, e publicar essas alterações no tópico “config\_change”. ### Tipos de mensagens MQTT Uma sessão MQTT é dividida em quatro estágios: conexão, autenticação, comunicação e término. Um cliente começa criando uma conexão do Protocolo de Controle de Transmissão/Protocolo de Internet (TCP/IP) com o broker usando uma porta padrão ou uma porta personalizada definida pelos operadores do broker. Ao criar a conexão, é importante reconhecer que o servidor pode continuar uma sessão antiga se lhe for fornecida uma identidade de cliente reutilizada. As portas padrão são 1883 para comunicação não criptografada e 8883 para comunicação criptografada — usando Camada de Soquetes Seguros (SSL)/Segurança da Camada de Transporte (TLS). Durante a negociação SSL/TLS, o cliente valida o certificado do servidor e autentica o servidor. O cliente também pode fornecer um certificado de cliente ao broker durante a negociação. O broker pode usar isso para autenticar o cliente. Embora não faça especificamente parte da especificação MQTT, tornou-se costume os brokers oferecerem suporte à autenticação de cliente com certificados de cliente SSL/TLS. Como o protocolo MQTT tem como objetivo ser um protocolo para dispositivos com recursos limitados e IoT, SSL/TLS nem sempre pode ser uma opção e, em alguns casos, pode não ser desejável. Nessas ocasiões, a autenticação é apresentada como um nome de usuário e senha em texto simples, que são enviados pelo cliente ao servidor — isso, como parte da sequência de pacotes CONNECT/CONNACK. Além disso, alguns brokers, especialmente brokers abertos publicados na internet, aceitarão clientes anônimos. Nesses casos, o nome de usuário e a senha são simplesmente deixados em branco. ### Formato da mensagem MQTT O MQTT é considerado um protocolo leve porque todas as suas mensagens têm uma pequena pegada de código. O pacote consiste em um cabeçalho fixo de 2 bytes + um cabeçalho variável e uma carga útil. Nesse cabeçalho fixo de 2 bytes, essa parte fixa estará sempre presente em todos os pacotes, e as outras duas — o cabeçalho variável e a carga útil — nem sempre estarão presentes. ![Formato da mensagem MQTT](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-6ea9b1f21c9f81792c5f2c59d36794c86f4881ab%2Fimagen-20231019-231143.png?alt=media) Dos 2 bytes do cabeçalho fixo, o primeiro byte é o campo de controle. Esse campo de controle de 8 bits é dividido em dois campos de 4 bits. Os primeiros 4 bits MSB são o campo de tipo de comando. Esse tipo determina a ação que será executada: o cliente deseja assinar o tópico, uma nova mensagem é publicada para os assinantes e outras ações. Os próximos 4 bits são os bits de sinalização de controle e são usados pelo comando de publicação; para o restante dos comandos, eles são reservados e o valor será 0. O segundo byte do cabeçalho fixo contém o comprimento restante, que é o comprimento do cabeçalho variável + o comprimento da carga útil. Um cabeçalho variável não está presente em todos os pacotes MQTT. Alguns comandos ou mensagens MQTT usam esse campo para fornecer informações ou sinalizações adicionais e elas variam dependendo do tipo de pacote. Um identificador de pacote é comum na maioria dos tipos de pacote. No fim, o pacote pode conter uma carga útil. A carga útil também é opcional e varia conforme o tipo de pacote. Esse campo geralmente contém os dados que estão sendo enviados. Por exemplo, para pacotes CONNECT, a carga útil é o ID do cliente e “nome de usuário e senha” se eles estiverem presentes. E para o pacote PUBLISH, é a mensagem a ser publicada. ### Qualidade de serviço QoS se refere a um acordo entre o remetente de uma mensagem e o destinatário da mensagem. Ele atua como um recurso-chave no MQTT, dando ao cliente a capacidade de escolher entre três níveis de serviço. Os três diferentes níveis de QoS determinam como o conteúdo é gerenciado pelo protocolo MQTT. Embora níveis mais altos de QoS sejam mais confiáveis, eles têm mais latência e requisitos de largura de banda, portanto os clientes assinantes podem especificar o nível máximo de QoS que desejam receber. * O nível de QoS mais simples é um serviço sem confirmação. Esse nível de QoS usa uma sequência de pacotes PUBLISH; o publicador envia uma mensagem ao broker uma vez, e o broker passa a mensagem aos assinantes uma vez. Não há nenhum mecanismo em vigor para garantir que a mensagem tenha sido recebida corretamente, e o broker não salva a mensagem. Esse nível de QoS também pode ser chamado de no máximo uma vez, QoS0 ou envia e esquece. * O segundo nível de QoS é o serviço confirmado. Esse nível de QoS usa uma sequência de pacotes PUBLISH/PUBACK entre o publicador e o seu broker, bem como entre o broker e os assinantes. Um pacote de confirmação verifica se o conteúdo foi recebido, e um mecanismo de repetição enviará o conteúdo original novamente se uma confirmação não for recebida a tempo. Isso pode resultar no assinante recebendo várias cópias da mesma mensagem. Esse nível de QoS também pode ser chamado de pelo menos uma vez ou QoS1. * O terceiro nível de QoS é o serviço garantido. Esse nível de QoS entrega a mensagem com dois pares de pacotes. O primeiro par é chamado PUBLISH/PUBREC, e o segundo par é chamado PUBREL/PUBCOMP. Os dois pares garantem que, independentemente do número de tentativas, a mensagem será entregue apenas uma vez. Esse nível de QoS também pode ser chamado de exatamente uma vez ou QoS2. ![QoS do MQTT](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-9ab221645f4cb2fd3ec068c2cbd9aa27a4196e83%2Fchrome_q1ak4noiok-600x466.png?alt=media) ## Vantagens e desvantagens ### Vantagens: * O MQTT é agnóstico ao tipo de pacote. A carga útil do protocolo MQTT pode transportar qualquer tipo de dado, como binário, texto ASCII etc. O receptor precisa interpretar e decodificar conforme o formato usado pelo transmissor. * Ele usa pacotes de pequeno tamanho e pode ser usado para aplicações de baixa largura de banda. * Ele oferece menor consumo de energia da bateria. * É um protocolo confiável porque usa opções de QoS para fornecer entrega garantida. * Devido ao seu modelo de publicação/assinatura, ele é escalável. * Ele oferece um design desacoplado, pois é fácil desacoplar o dispositivo e o servidor. Ideal para comunicações distribuídas de um para muitos e aplicações desacopladas. * Um dispositivo publicador pode enviar dados ao servidor a qualquer momento, independentemente do seu estado. * Equipado com a função LWT (Última Vontade e Testamento) para notificar as partes envolvidas de uma desconexão anormal do cliente. * Depende do TCP/IP para tarefas básicas de comunicação. * Projetado para entregar mensagens de acordo com os padrões "no máximo uma vez", "no mínimo uma vez" e "exatamente uma vez". ### Desvantagens: * O MQTT não oferece suporte a streaming de vídeo. * Problemas de latência. * A segurança não é integrada. O MQTT não é criptografado. Em vez disso, ele usa TLS/SSL (Segurança da Camada de Transporte/Camada de Soquetes Seguros) para criptografia segura. * Um broker centralizado pode ser o ponto único de falha, já que as conexões dos clientes com os brokers ficam abertas o tempo todo. * Ele não oferece suporte a recursos avançados, como controle de fluxo. ## Onde o MQTT pode ser usado À medida que as aplicações de IoT estão sendo implementadas em grande escala, o MQTT ganhou destaque como uma forma aberta, simples e escalável de implantar computação distribuída e funcionalidades de IoT para uma base de usuários mais ampla, tanto nos mercados de consumo quanto nos industriais. * Gestão de Frotas. As organizações estão usando MQTT para criar sistemas de Gestão de Frotas mais inteligentes que melhoram a otimização da frota, a segurança do motorista e reduzem os custos de combustível. Novos modos de transporte que usam drones também estão mudando a forma como movemos mercadorias. A conectividade entre um dispositivo móvel usado pelo operador, informações de telemetria diretamente do veículo e a integração com sistemas de agendamento e roteamento de back-end fornece a visibilidade necessária para melhorar a operação geral da frota. * Dados de sensores ambientais. O MQTT oferece suporte ao modelo de entrega de mensagens “no máximo uma vez”. Em redes com cobertura parcial do território ou alta latência, isso significa que as informações podem ser perdidas ou duplicadas. Em áreas onde sensores remotos registram e transmitem dados em intervalos especificados, isso não é um problema, já que novas leituras são recebidas regularmente. Sensores em ambientes remotos geralmente são dispositivos de baixo consumo, o que torna o MQTT uma solução ideal para sensores de IoT com uma prioridade de transferência de dados relativamente baixa. * Dados de integridade da máquina: para responder rapidamente a problemas emergentes e evitar tempo de inatividade. Por exemplo, em uma usina eólica, você precisa da entrega garantida de indicadores de desempenho atuais para as equipes locais, mesmo antes de essas informações chegarem ao centro de processamento de dados. Em situações como essa, a entrega de mensagens “ao menos uma vez” garante que os sinalizadores apropriados serão notados pelos especialistas necessários em tempo hábil, mesmo que cheguem como duplicatas. Isso é importante para a comunicação máquina a máquina com prioridade mais alta. * Sistemas de cobrança: há mensagens ainda mais prioritárias e precisas que precisam ser tratadas corretamente. Em situações de negócios em que a duplicação de registros é inaceitável, inclusive em sistemas de cobrança, o sinalizador QoS de transmissão “exatamente uma vez” é útil. Isso elimina a duplicação ou perda de pacotes em sistemas de faturamento ou cobrança, reduz o número de anomalias e contradições desnecessárias no acordo. * Aplicativos de mensagens baseados em texto para comunicação em tempo real que aproveitam o baixo uso de dados e energia do MQTT. Por exemplo, o Facebook usa o MQTT para seu aplicativo Messenger, não apenas porque o protocolo conserva a energia da bateria durante mensagens de celular para celular, mas também porque o protocolo permite que as mensagens sejam entregues de forma eficiente em milissegundos, apesar das conexões de internet inconsistentes ao redor do mundo. ## Dispositivos MQTT compatíveis com a Navixy * Xirgo Global FMS500 Light MQTT (IOTM) * Xirgo Global FMS500 Light+ MQTT (IOTM) * Xirgo Global FMS500 StCAN MQTT (IOTM) * BCE FMS500 Light MQTT (IOTM) * BCE FMS500 Light+ MQTT (IOTM) * BCE FMS500 StCAN MQTT (IOTM) * GlobalmatiX xTCU ## Como configurar dispositivos MQTT para funcionar com a Navixy ### Configuração de dispositivos MQTT Xirgo & BCE Para configurar o dispositivo Xirgo & BCE para funcionar com MQTT: * No FMSET: escolha **Conectividade** → **Servidor de telemetria** → **Configurações do endereço do broker MQTT** e especifique o host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) para o servidor da UE e [mqtt.us.navixy.com](http://mqtt.us.navixy.com/) para o servidor dos EUA, porta 1883. * E adicione o usuário padrão em **Segurança MQTT** -> **Autorização**\ ![MQTT device configuration](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-197f3834a584ce60ef3ef825d645d2e490e2b1b7%2Fimagen-20231019-231034.png?alt=media) ### Configuração de dispositivo MQTT Globalmatix Para configurar o dispositivo Globalmatix para funcionar com MQTT: * Especifique o servidor porta 1883 para a UE e porta 1883 para os EUA * **Usuário/senha**: globalmatix/secretword * **Tópico**: globalmatix/in Para configurar o dispositivo Globalmatix para funcionar com MQTTS: * Especifique **Servidor** porta 8883 para a UE e porta 8883 para os EUA * **Usuário/senha**: globalmatix/secretword * **Tópico**: globalmatix/in --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/expert-center/pt-br/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.