> 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 de MQTT O protocolo Message Queuing Telemetry Transport (MQTT) vem sendo usado há muitos anos, mas agora ele é 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 constante de dados estão se tornando parte da vida cotidiana. Esse crescimento intenso obriga as pessoas a buscar maneiras de transferir dados com eficiência. ## O que é MQTT Andy Stanford-Clark (IBM) e Arlen Nipper (na época trabalhando para a Eurotech, Inc.) foram os autores da primeira versão do protocolo em 1999. Ele foi usado para monitorar oleodutos dentro do framework SCADA. O objetivo era ter um protocolo eficiente em termos de largura de banda, leve e que usasse pouca bateria, porque os dispositivos eram conectados por meio de link via satélite que, naquela época, era extremamente caro. No momento, a maioria dos dispositivos usa a versão 5.0. O Message Queuing Telemetry Transport (MQTT) é um protocolo de rede leve, do tipo publish-subscribe, que transporta mensagens entre dispositivos. O protocolo normalmente é executado sobre TCP/IP; no entanto, qualquer protocolo de rede que forneça conexões bidirecionais, ordenadas e sem perda pode suportar MQTT. Ele foi projetado para conexões com locais remotos em que é necessário um "small code footprint" ou em que 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 operacionais, o protocolo é pequeno e leve. Ele é ideal para dispositivos com baixo consumo de energia e vida útil limitada da bateria. Atualmente, isso inclui smartphones, bem como um número cada vez maior de sensores e dispositivos conectados. Assim, o MQTT tornou-se um protocolo para streaming de dados entre dispositivos com poder de CPU limitado e/ou vida útil limitada da bateria, 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 há um ramo do MQTT-SN para funcionar sobre Bluetooth, UDP, ZigBee e em outras redes IoT que não sejam TCP/IP. ## Como funciona ### O modelo de publicação e assinatura Há 2 definições principais no MQTT: MQTT Broker 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 termos simples, o broker atua como uma agência dos correios, o MQTT não usa o endereço do destinatário pretendido, mas usa o assunto chamado "Topic", e qualquer pessoa que queira uma cópia dessa mensagem se inscreverá nesse tópico. Vários clientes podem receber a mensagem de um único broker (capacidade um para muitos). Da mesma forma, vários publishers podem publicar tópicos para um único subscriber (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 "topic" 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 enviando a mensagem e o tópico ao broker. * Em seguida, o broker encaminha a mensagem para todos os clientes inscritos nesse tópico. Como as mensagens MQTT são organizadas por tópicos, o desenvolvedor da aplicação tem a flexibilidade de especificar que determinados clientes só podem interagir com determinadas mensagens. Por exemplo, sensores publicarão suas leituras sob o tópico "sensor\_data" e se inscreverão no tópico "config\_change". Aplicativos de processamento de dados que salvam dados de sensores em um banco de dados de backend se inscreverão no tópico "sensor\_data". Um aplicativo de console de administração 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 encerramento. Um cliente começa criando uma conexão Transmission Control Protocol/Internet Protocol (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 receber 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 Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Durante o handshake 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 o handshake. O broker pode usar isso para autenticar o cliente. Embora não faça parte especificamente da especificação MQTT, tornou-se costume que os brokers suportem autenticação de cliente com certificados SSL/TLS do lado do cliente. 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 desejado. Nesses casos, a autenticação é apresentada como nome de usuário e senha em texto simples, 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, aceitam 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 um pequeno code footprint. O pacote consiste em um cabeçalho fixo de 2 bytes + um cabeçalho variável e um payload. Nesses primeiros 2 bytes, o cabeçalho fixo estará sempre presente em todos os pacotes e os outros dois, cabeçalho variável e payload, nem sempre estarão presentes. ![Formato da mensagem MQTT](/files/fb47277cf757e91e3a4e4ed28daa5665f6b888b6) Dos dois 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 do tipo de comando. Esse tipo determina a ação que será executada: o cliente quer assinar o tópico, uma nova mensagem é publicada para os subscribers e outros. Os próximos 4 bits são os bits de sinalização de controle e são usados pelo comando publish; para o restante dos comandos, eles são reservados e o valor será 0. O segundo byte do cabeçalho fixo contém o remaining length, que é o comprimento do cabeçalho variável + o comprimento do payload. 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 eles variam dependendo do tipo de pacote. Um identificador de pacote é comum na maioria dos tipos de pacote. Ao final, o pacote pode conter um payload. Até o payload é opcional e varia de acordo com o tipo de pacote. Esse campo normalmente contém os dados que estão sendo enviados. Ex.: para pacotes CONNECT, o payload é o ID do cliente e o 'username and password' se estiverem presentes. E para o pacote PUBLISH, ele é a mensagem a ser publicada. ### Qualidade de Serviço QoS refere-se 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 mais alto 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 publisher envia uma mensagem ao broker uma vez, e o broker repassa a mensagem aos subscribers uma vez. Não há mecanismo para garantir que a mensagem foi 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 fire and forget. * O segundo nível de QoS é o serviço com confirmação. Esse nível de QoS usa uma sequência de pacotes PUBLISH/PUBACK entre o publisher e seu broker, bem como entre o broker e os subscribers. 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 em tempo hábil. Isso pode resultar no subscriber 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 MQTT](/files/e248e03d06aa801e77f89178a4d720e725495766) ## Vantagens e desvantagens ### Vantagens: * O MQTT é agnóstico quanto ao pacote. O payload do protocolo MQTT pode transportar qualquer tipo de dado, como binário, texto ASCII etc. O receptor precisa interpretar e decodificar de acordo com o formato usado pelo transmissor. * Ele usa um pacote de baixo tamanho e pode ser usado para aplicações de baixa largura de banda. * Oferece menor consumo de energia da bateria. * É um protocolo confiável, pois usa opções de QoS para fornecer entrega garantida. * Devido ao seu modelo publish/subscribe, ele é escalável. * 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 separadas. * Um dispositivo publicador pode enviar dados ao servidor a qualquer momento, independentemente do seu estado. * Equipado com a função LWT (Last Will and Testament) para notificar as partes sobre uma desconexão anormal do cliente. * Baseia-se em TCP/IP para tarefas básicas de comunicação. * Projetado para entregar mensagens de acordo com os modelos "maximum once", "minimum once" e "exactly once". ### Desvantagens: * O MQTT não pode oferecer suporte a streaming de vídeo. * Problemas com latência. * A segurança não é integrada. O MQTT não é criptografado. Em vez disso, usa TLS/SSL (Transport Layer Security/Secure Sockets Layer) para criptografia de segurança. * Um broker centralizado pode ser o ponto de falha, pois as conexões dos clientes com os brokers estão abertas o tempo todo. * Não oferece suporte a recursos avançados, como controle de fluxo. ## Onde o MQTT pode ser usado Como as aplicações IoT agora estão sendo implementadas em grande escala, o MQTT ganhou destaque como uma maneira 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 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 usando drones também estão mudando a forma como movimentamos 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 backend fornece a visibilidade necessária para melhorar a operação geral da frota. * Dados de sensores ambientais. O MQTT suporta o modelo de entrega de mensagens "no more than once". 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 de energia, o que torna o MQTT uma solução ideal para sensores IoT com prioridade relativamente baixa de transferência de dados. * Dados de saúde da máquina: para responder rapidamente a problemas emergentes e evitar tempo de inatividade. Por exemplo, para uma usina eólica, é necessário garantir a entrega de indicadores de desempenho atuais às equipes locais, mesmo antes que essas informações cheguem ao centro de processamento de dados. Em tais situações, a entrega de mensagens "at least once" garante que as sinalizações apropriadas sejam observadas 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 comerciais em que a duplicação de registros é inaceitável, inclusive em sistemas de cobrança, o sinalizador de QoS de transmissão "exactly once" é útil. Isso elimina a duplicação ou perda de pacotes em sistemas de cobrança ou faturamento, reduz o número de anomalias e contradições desnecessárias no acordo. * Aplicações de mensagens baseadas em texto para comunicação em tempo real que aproveitam o baixo uso de dados e energia do MQTT. Por exemplo, o Facebook usa MQTT em seu aplicativo Messenger, não apenas porque o protocolo economiza energia da bateria durante mensagens entre celulares, mas também porque ele permite que as mensagens sejam entregues com eficiência em milissegundos, apesar de conexões de internet inconsistentes em todo o mundo. ## Dispositivos MQTT suportados pela 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 do dispositivo MQTT Xirgo & BCE Para configurar o dispositivo Xirgo & BCE para funcionar com MQTT: * Dentro do FMSET: Escolha connectivity → Telemetry server → MQTT broker address settings) especifique host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) para o servidor da UE e [mqtt.us.navixy.com](http://mqtt.eu.navixy.com/) para o servidor dos EUA, porta 1883. * E adicione o usuário padrão em MQTT Security -> Authorization\ ![MQTT device configuration](/files/08a4ebe9d4b020464c028db5fa6bbb39a1eb0448) ### Configuração do 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 * Topic globalmatix/in Para configurar o dispositivo Globalmatix para funcionar com MQTTS: * Especifique o servidor porta 8883 para a UE e porta 8883 para os EUA * Usuário/senha - globalmatix/secretword * Topic 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://navixy.com/docs/expert-center/pt-br/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.