> 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 O protocolo Message Queuing Telemetry Transport (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 constante de dados estão se tornando parte do dia a dia. Esse crescimento intenso leva 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.) redigiram a primeira versão do protocolo em 1999. Ele foi usado para monitorar oleodutos no âmbito da estrutura SCADA. O objetivo era ter um protocolo eficiente em largura de banda, leve e que consumisse pouca bateria, porque os dispositivos eram conectados via link de 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, de publicação e assinatura, que transporta mensagens entre dispositivos. O protocolo normalmente roda sobre TCP/IP; no entanto, qualquer protocolo de rede que forneça conexões ordenadas, sem perda e bidirecionais pode oferecer suporte ao MQTT. Ele foi projetado para conexões com locais remotos nos quais é necessária uma "reduzida ocupação de código" ou a largura de banda da rede é limitada. O protocolo é um padrão aberto da OASIS e uma recomendação ISO (ISO/IEC 20922). Dadas as condições de operação, o protocolo é enxuto e leve. Ele é ideal para dispositivos com baixo consumo de energia e vida útil limitada da bateria. Hoje, isso inclui smartphones, bem como um número cada vez maior de sensores e dispositivos conectados. Assim, o MQTT tornou-se um protocolo para transmissão de dados entre dispositivos com poder de CPU limitado e/ou vida útil de bateria curta, bem como para redes com 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á uma variante do MQTT-SN para funcionar sobre Bluetooth, UDP, ZigBee e em outras redes IoT além de TCP/IP. ## Como funciona ### O modelo de publicação e assinatura Há 2 definições principais no MQTT: corretor MQTT e cliente MQTT. Um corretor MQTT é um servidor que recebe todas as mensagens dos clientes e então encaminha as mensagens para os clientes de destino apropriados. Em termos simples, o corretor 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 se inscreverá nesse tópico. Vários clientes podem receber a mensagem de um único corretor (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 (desde um microcontrolador até um servidor completo) que executa uma biblioteca MQTT e se conecta a um broker MQTT por 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 confidenciais. * O cliente publica Mensagens em um tópico enviando a mensagem e o tópico ao broker. * Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico. Como as Mensagens MQTT são organizadas por tópicos, o desenvolvedor da aplicação tem flexibilidade para especificar que determinados clientes só podem interagir com determinadas Mensagens. Por exemplo, os sensores publicarão suas leituras no tópico “sensor\_data” e assinarão o tópico “config\_change”. As aplicações de processamento de dados que salvam dados de sensores em um banco de dados de backend assinarão o tópico “sensor\_data”. Uma aplicação 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 etapas: 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 Segurança (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 usá-lo para autenticar o cliente. Embora não faça parte especificamente das Especificações MQTT, tornou-se habitual que os brokers ofereçam suporte à autenticação de clientes com certificados SSL/TLS do lado do cliente. Como o protocolo MQTT visa ser um protocolo para dispositivos com recursos limitados e dispositivos IoT, SSL/TLS pode nem sempre 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 uma 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 de mensagem MQTT MQTT é considerado um protocolo leve porque todas as suas mensagens têm uma pequena ocupação de código. 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 estão presentes. ![Formato de mensagem MQTT](/files/7054ec5224c49d4d1e8fb65bf936b3dc8f8187cf) Do cabeçalho fixo de dois bytes, 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 mais significativos são o campo do tipo de comando. Esse tipo determina a ação que será executada: o cliente quer se inscrever no tópico, uma nova mensagem é publicada para os assinantes e outras. 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 comprimento restante, que é a soma do comprimento do cabeçalho variável e do 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 adicionais ou sinalizações, e eles variam dependendo do tipo de pacote. Um identificador de pacote é comum na maioria dos tipos de pacote. No final, o pacote pode conter um payload. Até mesmo o payload é opcional e varia conforme o tipo de pacote. Esse campo normalmente contém os dados que estão sendo enviados. Por exemplo, para pacotes CONNECT, o payload é o ID do cliente e nome de usuário e senha, se estiverem presentes. E, para o pacote PUBLISH, é 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 maior latência e maiores requisitos de largura de banda, portanto os clientes inscritos podem especificar o nível mais alto de QoS que gostariam de 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 encaminha a mensagem aos assinantes uma vez. Não há um 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 fire and forget. * O segundo nível de QoS é o serviço reconhecido. Esse nível de QoS usa uma sequência de pacotes PUBLISH/PUBACK entre o publicador e o seu broker, assim como entre o broker e os assinantes. Um pacote de confirmação verifica se o conteúdo foi recebido, e um mecanismo de retentativa enviará o conteúdo original novamente se uma confirmação não for recebida em tempo hábil. Isso pode resultar no assinante recebendo várias cópias da mesma mensagem. Esse nível de QoS também pode ser chamado de ao menos uma vez ou QoS1. * O terceiro nível de QoS é o serviço assegurado. 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 retentativas, 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](/files/17f9b69415f69448dd22d7d6070b659b300f1109) ## 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 pequenos e pode ser usado em aplicações de baixa largura de banda. * Ele oferece menor consumo de bateria. * É um protocolo confiável, pois 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 independentes. * Um dispositivo publicador pode enviar dados ao servidor a qualquer momento, independentemente de seu estado. * Equipado com a função LWT (Last Will and Testament) para notificar as partes sobre 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 modelos "no máximo uma vez", "pelo menos uma vez" e "exatamente uma vez". ### Desvantagens: * MQTT não oferece suporte à transmissão de vídeo. * Problemas de latência. * Segurança não é integrada. MQTT não é criptografado. Em vez disso, utiliza TLS/SSL (Segurança da Camada de Transporte/Camada de Soquetes Seguros) para criptografia de segurança. * Um broker centralizado pode ser um ponto único de falha, pois as conexões dos clientes com os brokers permanecem abertas o tempo todo. * Não oferece suporte a recursos avançados, como controle de fluxo. ## Onde MQTT pode ser usado Como as aplicações de IoT agora estão sendo implementadas em uma escala enorme, 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 consumidor quanto industrial. * 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 em que 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 de IoT com prioridade relativamente baixa de transferência de dados. * 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 às equipes locais, mesmo antes de essas informações chegarem ao centro de processamento de dados. Em tais situações, a entrega de mensagens "pelo menos uma vez" garante que os sinalizadores apropriados serão percebidos 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 faturamento: 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 faturamento, o sinalizador QoS de transmissão "exatamente uma vez" é útil. Isso elimina a duplicação ou a perda de pacotes em sistemas de cobrança ou faturamento, reduz o número de anomalias e de contradições desnecessárias no acordo. * Aplicativos de mensagens baseados em texto para comunicação em tempo real que se beneficiam do baixo consumo de dados e energia do MQTT. Por exemplo, o Facebook usa MQTT em seu aplicativo Messenger, não apenas porque o protocolo economiza bateria durante as mensagens de celular para celular, mas também porque o protocolo 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 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 corretor 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](/files/42c7f9a1e6774a5be6217ea3be121be12456a315) ### Configuração de dispositivos 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.