> 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/es/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md). # Fundamentos de MQTT Protocolo de publicación/suscripción que impulsa la comunicación ligera de dispositivos IoT. Cubre la configuración del broker MQTT, los formatos de mensaje, los niveles de QoS y los casos de uso telemáticos. El protocolo Transporte de telemetría de colas de mensajes (MQTT) se ha usado durante muchos años, pero ahora es especialmente relevante debido al crecimiento explosivo del IoT: tanto los dispositivos de consumo como los industriales están implementando redes distribuidas y computación en el borde, y los dispositivos con transmisión constante de datos se están convirtiendo en parte de la vida cotidiana. Un crecimiento tan intenso obliga a las personas a buscar maneras de transferir datos de forma eficiente. ## Qué es MQTT Andy Stanford-Clark (IBM) y Arlen Nipper (entonces trabajando para Eurotech, Inc.) redactaron la primera versión del protocolo en 1999. Se usó para monitorear oleoductos dentro del marco SCADA. El objetivo era tener un protocolo eficiente en el uso del ancho de banda, ligero y que consumiera poca energía de la batería, porque los dispositivos estaban conectados mediante un enlace satelital que, en ese momento, era sumamente costoso. En este momento, la mayoría de los dispositivos usa la versión 5.0. El Transporte de telemetría de colas de mensajes (MQTT) es un protocolo de red ligero de publicación-suscripción que transporta Mensajes entre dispositivos. El protocolo normalmente se ejecuta sobre TCP/IP; sin embargo, cualquier protocolo de red que proporcione conexiones ordenadas, sin pérdidas y bidireccionales puede admitir MQTT. Está diseñado para conexiones con ubicaciones remotas donde se requiere una «huella de código pequeña» o el ancho de banda de la red es limitado. El protocolo es un estándar abierto de OASIS y una recomendación de ISO (ISO/IEC 20922). Dadas las condiciones de operación, el protocolo se hace pequeño y ligero. Es ideal para dispositivos con bajo consumo de energía y vida útil limitada de la batería. Ahora, esto incluye smartphones, así como un número cada vez mayor de sensores y Dispositivos conectados. Así, MQTT se ha convertido en un protocolo para la transmisión continua de datos entre dispositivos con capacidad limitada de CPU y/o vida útil de la batería, así como para redes con ancho de banda costoso o bajo, estabilidad impredecible o alta latencia. Por eso MQTT se conoce como el protocolo ideal para IoT. Está construido sobre el protocolo TCP/IP, pero existe una variante de MQTT-SN para funcionar sobre Bluetooth, UDP, ZigBee y otras redes IoT distintas de TCP/IP. ## Cómo funciona ### El modelo de publicación y suscripción Hay 2 definiciones principales en MQTT: el broker MQTT y el cliente MQTT. Un broker MQTT es un servidor que recibe todos los Mensajes de los clientes y luego enruta los Mensajes a los clientes destinatarios apropiados. En palabras sencillas, el broker actúa como una oficina de correos, MQTT no usa la dirección del destinatario previsto, sino la línea de asunto llamada «tema», y cualquiera que quiera una copia de ese mensaje se suscribirá a ese tema. Varios clientes pueden recibir el mensaje de un solo broker (capacidad de uno a muchos). Del mismo modo, varios publicadores pueden publicar temas en un solo suscriptor (de muchos a uno). Un cliente MQTT es cualquier dispositivo (desde un microcontrolador hasta un servidor plenamente funcional) que ejecuta una biblioteca MQTT y se conecta a un broker MQTT a través de una red. * El cliente se conecta al broker. Puede suscribirse a cualquier tema de mensajes en el broker. Esta conexión puede ser una conexión TCP/IP sin cifrar o una conexión TLS cifrada para mensajes sensibles. * El cliente publica mensajes en un tema enviando el mensaje y el tema al broker. * Luego, el broker reenvía el mensaje a todos los clientes que se suscriben a ese tema. Dado que los Mensajes MQTT se organizan por temas, el desarrollador de la aplicación tiene la flexibilidad de especificar que ciertos clientes solo puedan interactuar con determinados Mensajes. Por ejemplo, los sensores publicarán sus lecturas bajo el tema «sensor\_data» y se suscribirán al tema «config\_change». Las aplicaciones de procesamiento de datos que guardan Datos del sensor en una base de datos de backend se suscribirán al tema «sensor\_data». Una aplicación de consola de administración podría recibir los Comandos del administrador del sistema para ajustar las configuraciones de los sensores, como la sensibilidad y la frecuencia de muestreo, y publicar esos cambios en el tema «config\_change». ### Tipos de Mensajes MQTT Una sesión MQTT se divide en cuatro etapas: conexión, autenticación, comunicación y terminación. Un cliente comienza creando una conexión del Protocolo de control de transmisión/Protocolo de Internet (TCP/IP) con el broker mediante un puerto estándar o un puerto personalizado definido por los operadores del broker. Al crear la conexión, es importante reconocer que el servidor podría continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada. Los puertos estándar son 1883 para la comunicación sin cifrar y 8883 para la comunicación cifrada, usando Capa de sockets seguros (SSL)/Seguridad de la capa de transporte (TLS). Durante el handshake de SSL/TLS, el cliente valida el certificado del servidor y autentica al servidor. El cliente también puede proporcionar un certificado de cliente al broker durante el handshake. El broker puede usar esto para autenticar al cliente. Aunque no forma parte específicamente de la Especificación MQTT, se ha vuelto habitual que los brokers admitan la autenticación de clientes con certificados de cliente SSL/TLS. Como el protocolo MQTT tiene como objetivo ser un protocolo para dispositivos con recursos limitados y IoT, SSL/TLS puede no siempre ser una opción y, en algunos casos, puede no ser deseable. En tales ocasiones, la autenticación se presenta como un nombre de usuario y una contraseña en texto claro, que el cliente envía al servidor: esto forma parte de la secuencia de paquetes CONNECT/CONNACK. Además, algunos brokers, especialmente los abiertos publicados en Internet, aceptarán clientes anónimos. En tales casos, el nombre de usuario y la contraseña simplemente se dejan en blanco. ### Formato de mensajes MQTT MQTT se considera un protocolo ligero porque todos sus Mensajes tienen una huella de código pequeña. El paquete consiste en un encabezado fijo de 2 bytes + un encabezado variable y una carga útil. En estos primeros 2 bytes, el encabezado fijo siempre estará presente en todos los paquetes y los otros dos, el encabezado variable y la carga útil, no siempre están presentes. ![Formato de mensajes MQTT](https://3386484127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-6ea9b1f21c9f81792c5f2c59d36794c86f4881ab%2Fimagen-20231019-231143.png?alt=media) De los dos bytes del encabezado fijo, el primer byte es el campo de control. Este campo de control de 8 bits se divide en dos campos de 4 bits. Los primeros 4 bits MSB son el campo de tipo de comando. Este tipo determina la acción que se realizará: el cliente quiere suscribirse al tema, se publica un nuevo mensaje para los suscriptores y otros. Los siguientes 4 bits son los bits de bandera de control y los usa el comando de publicación; para el resto de los Comandos, están reservados y el valor será 0. El segundo byte del encabezado fijo contiene la longitud restante, que es la longitud del encabezado variable + la longitud de la carga útil. Un encabezado variable no está presente en todos los paquetes MQTT. Algunos Comandos o Mensajes MQTT usan este campo para proporcionar información adicional o banderas, y varían según el tipo de paquete. Un identificador de paquete es común en la mayoría de los tipos de paquete. Al final, el paquete puede contener una carga útil. Incluso la carga útil es opcional y varía según el tipo de paquete. Este campo normalmente contiene los datos que se están enviando. Por ejemplo, para los paquetes CONNECT, la carga útil es el ID del cliente y «nombre de usuario y contraseña» si están presentes. Y para el paquete PUBLISH, es el mensaje que se publicará. ### Calidad de servicio QoS se refiere a un acuerdo entre el emisor de un mensaje y el destinatario del mensaje. Actúa como una característica clave en MQTT, dando al cliente la capacidad de elegir entre tres niveles de servicio. Los tres niveles diferentes de QoS determinan cómo se gestiona el contenido mediante el protocolo MQTT. Aunque los niveles más altos de QoS son más confiables, tienen más requisitos de latencia y ancho de banda, por lo que los clientes suscritos pueden especificar el nivel de QoS más alto que deseen recibir. * El nivel de QoS más simple es un servicio sin confirmación. Este nivel de QoS usa una secuencia de paquetes PUBLISH; el publicador envía un mensaje al broker una vez, y el broker pasa el mensaje a los suscriptores una vez. No existe ningún mecanismo para asegurar que el mensaje se haya recibido correctamente, y el broker no guarda el mensaje. Este nivel de QoS también puede denominarse como máximo una vez, QoS0 o fire and forget. * El segundo nivel de QoS es el servicio con confirmación. Este nivel de QoS usa una secuencia de paquetes PUBLISH/PUBACK entre el publicador y su broker, así como entre el broker y los suscriptores. Un paquete de acuse de recibo verifica que el contenido se haya recibido, y un mecanismo de reintento enviará el contenido original de nuevo si no se recibe un acuse de recibo a tiempo. Esto puede dar como resultado que el suscriptor reciba varias copias del mismo mensaje. Este nivel de QoS también puede denominarse al menos una vez o QoS1. * El tercer nivel de QoS es el servicio garantizado. Este nivel de QoS entrega el mensaje con dos pares de paquetes. El primer par se llama PUBLISH/PUBREC, y el segundo par se llama PUBREL/PUBCOMP. Los dos pares garantizan que, independientemente del número de reintentos, el mensaje solo se entregará una vez. Este nivel de QoS también puede denominarse exactamente una vez o QoS2. ![QoS de MQTT](https://3386484127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-9ab221645f4cb2fd3ec068c2cbd9aa27a4196e83%2Fchrome_q1ak4noiok-600x466.png?alt=media) ## Ventajas y desventajas ### Ventajas: * MQTT es independiente del tipo de paquete. La carga útil del protocolo MQTT puede transportar cualquier tipo de datos, como binarios, texto ASCII, etc. El receptor necesita interpretar y decodificar de acuerdo con el formato usado por el transmisor. * Usa un paquete de tamaño pequeño y puede usarse para aplicaciones de bajo ancho de banda. * Ofrece un menor consumo de energía de la batería. * Es un protocolo confiable, ya que usa opciones de QoS para proporcionar entrega garantizada. * Debido a su modelo de publicación/suscripción, es escalable. * Ofrece un diseño desacoplado, ya que es fácil desacoplar el dispositivo y el servidor. Es ideal para comunicaciones distribuidas de uno a muchos y aplicaciones separadas. * Un dispositivo publicador puede enviar datos al servidor en cualquier momento, independientemente de su estado. * Equipado con la función LWT (Última voluntad y testamento) para notificar a las partes sobre una desconexión anormal del cliente. * Depende de TCP/IP para las tareas básicas de comunicación. * Diseñado para entregar mensajes de acuerdo con las plantillas «como máximo una vez», «al menos una vez» y «exactamente una vez». ### Desventajas: * MQTT no puede admitir transmisión de video. * Problemas con la latencia. * La Seguridad no está integrada de forma nativa. MQTT no está cifrado. En su lugar, usa TLS/SSL (Seguridad de la capa de transporte/Capa de sockets seguros) para el cifrado de seguridad. * Un broker centralizado puede ser el punto único de fallo, ya que las conexiones de los clientes con los brokers permanecen abiertas todo el tiempo. * No admite funciones avanzadas como el control de flujo. ## Dónde se puede usar MQTT A medida que las aplicaciones de IoT se implementan ahora a una escala enorme, MQTT ha cobrado protagonismo como una forma abierta, simple y escalable de desplegar la computación distribuida y la funcionalidad de IoT para una base de usuarios más amplia, tanto en los mercados de consumo como industriales. * Gestión de flotas. Las organizaciones están usando MQTT para crear sistemas más inteligentes de gestión de flotas que mejoran la optimización de la flota, la seguridad del conductor y reducen los costos de combustible. Los nuevos modos de transporte que usan drones también están cambiando la forma en que movemos mercancías. La conectividad entre un dispositivo móvil usado por el operador, la información de telemetría directa del vehículo y la integración en sistemas de programación y enrutamiento de back-end proporciona la visibilidad necesaria para mejorar la operación general de la flota. * Datos del sensor ambiental. MQTT admite el modelo de entrega de mensajes «no más de una vez». En redes con cobertura parcial del territorio o alta latencia, esto significa que la información puede perderse o duplicarse. En áreas donde los sensores remotos registran y transmiten datos en intervalos específicos, esto no es un problema, ya que se reciben nuevas lecturas con regularidad. Los sensores en entornos remotos suelen ser dispositivos de bajo consumo, lo que convierte a MQTT en una solución ideal para sensores de IoT con una prioridad de transferencia de datos relativamente baja. * Datos de salud de la máquina: para responder rápidamente a problemas emergentes y prevenir el tiempo de inactividad. Por ejemplo, para una planta eólica, usted necesita la entrega garantizada de los indicadores de rendimiento actuales a los equipos locales incluso antes de que esta información llegue al centro de procesamiento de datos. En tales situaciones, la entrega de mensajes «al menos una vez» garantiza que las banderas adecuadas serán notadas por los especialistas necesarios de manera oportuna, aunque lleguen duplicadas. Esto es importante para la comunicación máquina a máquina con una prioridad más alta. * Sistemas de facturación: Hay Mensajes aún más prioritarios y precisos que deben manejarse correctamente. En situaciones de negocio donde la duplicación de registros es inaceptable, incluidos los sistemas de facturación, resulta útil la marca QoS de transmisión «exactamente una vez». Esto elimina la duplicación o pérdida de paquetes en sistemas de facturación o facturación, reduce el número de anomalías y contradicciones innecesarias en el acuerdo. * Aplicaciones de mensajería basadas en texto para comunicación en tiempo real que aprovechan el bajo uso de datos y energía de MQTT. Por ejemplo, Facebook usa MQTT para su aplicación Messenger, no solo porque el protocolo conserva la batería durante la mensajería de teléfono móvil a teléfono móvil, sino también porque el protocolo permite que los Mensajes se entreguen eficientemente en milisegundos, a pesar de las conexiones de internet inconsistentes en todo el mundo. ## Dispositivos MQTT compatibles con 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 ## Cómo configurar dispositivos MQTT para que funcionen con Navixy ### Configuración de dispositivos MQTT de Xirgo y BCE Para configurar el dispositivo Xirgo y BCE para trabajar con MQTT: * Dentro de FMSET: elija **Conectividad** → **Servidor de telemetría** → **Configuración de la dirección del broker MQTT** y especifique el host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) para el servidor de la UE y [mqtt.us.navixy.com](http://mqtt.us.navixy.com/) para el servidor de EE. UU., puerto 1883. * Y agregue el usuario predeterminado en **Seguridad MQTT** -> **Autorización**\ ![MQTT device configuration](https://3386484127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-197f3834a584ce60ef3ef825d645d2e490e2b1b7%2Fimagen-20231019-231034.png?alt=media) ### Configuración de dispositivos MQTT de Globalmatix Para configurar el dispositivo Globalmatix para trabajar con MQTT: * Especifique el servidor puerto 1883 para la UE y puerto 1883 para EE. UU. * **Usuario/contraseña**: globalmatix/secretword * **Tema**: globalmatix/in Para configurar el dispositivo Globalmatix para trabajar con MQTTS: * Especifique **servidor** puerto 8883 para la UE y puerto 8883 para EE. UU. * **Usuario/contraseña**: globalmatix/secretword * **Tema**: 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/es/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.