> 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 de Transporte de telemetría mediante 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.) escribieron la primera versión del protocolo en 1999. Se usó para monitorear oleoductos dentro del marco SCADA. El objetivo era contar con un protocolo eficiente en 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 extremadamente costoso. En la actualidad, la mayoría de los dispositivos usa la versión 5.0. El transporte de telemetría mediante colas de mensajes (MQTT) es un protocolo de red ligero, de publicación y 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 la ISO (ISO/IEC 20922). Dadas las condiciones de operación, el protocolo se vuelve pequeño y ligero. Es ideal para dispositivos con bajo consumo de energía y duración limitada de la batería. Hoy en día, estos incluyen teléfonos inteligentes, así como un número cada vez mayor de sensores y Dispositivos conectados. Así, MQTT se ha convertido en un protocolo para transmitir datos entre dispositivos con potencia de CPU limitada y/o duración limitada 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 trabajar sobre Bluetooth, UDP, ZigBee y en 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 de destino apropiados. En palabras simples, 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). De manera similar, varios publicadores pueden publicar temas para un solo suscriptor (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» del 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 ciertos mensajes. Por ejemplo, los sensores publicarán sus lecturas bajo el tema «Datos del sensor» 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 «Datos del sensor». 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 de Protocolo de control de transmisión/Protocolo de Internet (TCP/IP) al broker, usando ya sea 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 anterior si se le proporciona una identidad de cliente reutilizada. Los puertos estándar son 1883 para la comunicación no cifrada y 8883 para la comunicación cifrada, usando Capa de sockets seguros (SSL)/Seguridad de la capa de transporte (TLS). Durante el protocolo de enlace 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 protocolo de enlace. 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. Debido a que el protocolo MQTT busca ser un protocolo para dispositivos con recursos limitados e IoT, SSL/TLS no siempre puede ser una opción y, en algunos casos, puede no ser deseado. En esas ocasiones, la autenticación se presenta como un nombre de usuario y una contraseña en texto plano, que el cliente envía al servidor; esto, como parte de la secuencia de paquetes CONNECT/CONNACK. Además, algunos brokers, especialmente los brokers 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 mensaje MQTT MQTT se considera un protocolo liviano porque todos sus mensajes tienen un tamaño de código reducido. El paquete consta de 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 mensaje 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) Del encabezado fijo de dos bytes, 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 publish; 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 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 remitente de un mensaje y el destinatario del mensaje. Funciona como una función clave en MQTT, dando al cliente la capacidad de elegir entre tres niveles de servicio. Los tres niveles diferentes de QoS determinan cómo el protocolo MQTT gestiona el contenido. Aunque los niveles más altos de QoS son más confiables, tienen más latencia y requisitos de ancho de banda, por lo que los clientes suscritos pueden especificar el nivel más alto de QoS 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 hay ningún mecanismo para asegurarse de 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 «enviar y olvidar». * El segundo nivel de QoS es un servicio con reconocimiento. Este nivel de QoS utiliza una secuencia de paquetes PUBLISH/PUBACK entre el publicador y su broker, así como entre el broker y los suscriptores. Un paquete de reconocimiento verifica que el contenido se ha recibido, y un mecanismo de reintento enviará de nuevo el contenido original si no se recibe un reconocimiento a tiempo. Esto puede dar lugar a que el suscriptor reciba múltiples copias del mismo mensaje. Este nivel de QoS también puede denominarse al menos una vez o QoS1. * El tercer nivel de QoS es un 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 agnóstico al 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 conforme al formato usado por el transmisor. * Utiliza un paquete de tamaño reducido y puede usarse para aplicaciones de bajo ancho de banda. * Ofrece un menor consumo de batería. * Es un protocolo confiable, ya que utiliza opciones de QoS para proporcionar una 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 para aplicaciones desacopladas. * Un dispositivo emisor puede enviar datos al servidor en cualquier momento, independientemente de su estado. * Equipado con la función LWT (Last Will and Testament) para notificar a las partes de una desconexión anormal del cliente. * Se basa en TCP/IP para tareas básicas de comunicación. * Diseñado para entregar mensajes según las plantillas «máximo una vez», «mínimo una vez» y «exactamente una vez». ### Desventajas: * MQTT no puede admitir la transmisión de video. * Problemas de latencia. * La Seguridad no está integrada. MQTT no está cifrado. En su lugar, utiliza TLS/SSL (Seguridad de la capa de transporte/Capa de sockets seguros) para el cifrado de seguridad. * Un broker centralizado puede ser el punto de falla, ya que las conexiones de los clientes con los brokers están abiertas todo el tiempo. * No admite funciones avanzadas como el control de flujo. ## Dónde se puede usar MQTT A medida que las aplicaciones IoT se implementan ahora a gran escala, MQTT ha cobrado protagonismo como una forma abierta, simple y escalable de desplegar cómputo distribuido y funcionalidad IoT a una base de usuarios más amplia, tanto en los mercados de consumo como en los industriales. * Gestión de flotas. Las organizaciones están usando MQTT para construir 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. 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 utilizado 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 de «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 a intervalos especificados, esto no representa un problema, ya que las nuevas lecturas se reciben de forma regular. Los sensores en entornos remotos suelen ser dispositivos de bajo consumo, lo que convierte a MQTT en una solución ideal para sensores 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 evitar tiempos 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 los indicadores adecuados serán detectados por los especialistas necesarios de manera oportuna, incluso si llegan duplicados. Esto es importante para la comunicación máquina a máquina con mayor prioridad. * Sistemas de facturación: hay mensajes aún más prioritarios y precisos que deben gestionarse correctamente. En situaciones comerciales donde la duplicación de registros es inaceptable, incluidos los sistemas de facturación, el indicador QoS de transmisión «exactamente una vez» resulta útil. Esto elimina la duplicación o la pérdida de paquetes en la facturación o en los sistemas de 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 app Messenger, no solo porque el protocolo conserva la energía de la batería durante la mensajería de celular a celular, sino también porque el protocolo permite que los mensajes se entreguen eficientemente en milisegundos, a pesar de conexiones a 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 Xirgo & BCE Para configurar el dispositivo Xirgo & 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 del dispositivo 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 * **Tópico**: 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 * **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/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 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.