# Fundamentos de MQTT El protocolo Message Queuing Telemetry Transport (MQTT) se ha utilizado 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 perimetral, 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 buscar formas de transferir datos de manera 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 utilizó para supervisar oleoductos dentro del marco SCADA. El objetivo era contar con un protocolo eficiente en ancho de banda, ligero y de bajo consumo de batería, porque los dispositivos estaban conectados mediante enlace satelital, que en ese momento era extremadamente costoso. En la actualidad, la mayoría de los dispositivos utiliza la versión 5.0. Message Queuing Telemetry Transport (MQTT) es un protocolo de red ligero de publicación-suscripción que transporta mensajes entre dispositivos. Por lo general, el protocolo funciona sobre TCP/IP; sin embargo, cualquier protocolo de red que proporcione conexiones ordenadas, sin pérdida y bidireccionales puede soportar MQTT. Está diseñado para conexiones con ubicaciones remotas en las que se requiere una "pequeña huella de código" 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 funcionamiento, el protocolo se mantiene pequeño y ligero. Es ideal para dispositivos con bajo consumo de energía y duración limitada de la batería. Actualmente, esto incluye a los smartphones, así como a 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 caro o bajo, estabilidad impredecible o alta latencia. Por eso MQTT es conocido como el protocolo ideal para IoT. Está basado en el protocolo TCP/IP, pero existe una rama MQTT-SN para trabajar sobre Bluetooth, UDP, ZigBee y otras redes IoT distintas de TCP/IP. ## Cómo funciona ### El modelo de publicación y suscripción Existen 2 definiciones principales en MQTT: MQTT Broker y cliente MQTT. Un broker MQTT es un servidor que recibe todos los mensajes de los clientes y luego los enruta a los clientes de destino adecuados. En palabras sencillas, el broker actúa como una oficina de correos: MQTT no utiliza la dirección del destinatario previsto, sino el asunto llamado “Topic”, y cualquiera que quiera una copia de ese mensaje se suscribirá a ese topic. Varios clientes pueden recibir el mensaje de un solo broker (capacidad de uno a muchos). Del mismo modo, varios publicadores pueden publicar topics a un solo suscriptor (muchos a uno). Un cliente MQTT es cualquier dispositivo (desde un microcontrolador hasta un servidor completo) 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 “topic” de mensaje en el broker. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada para mensajes sensibles. * El cliente publica mensajes bajo un topic enviando el mensaje y el topic al broker. * Luego, el broker reenvía el mensaje a todos los clientes que se suscriben a ese topic. Como los mensajes MQTT se organizan por topics, 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 topic “sensor\_data” y se suscribirán al topic “config\_change”. Las aplicaciones de procesamiento de datos que guardan datos de sensores en una base de datos de backend se suscribirán al topic “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 topic “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) 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 no cifrada y 8883 para la comunicación cifrada, utilizando Secure Sockets Layer (SSL)/Transport Layer Security (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 específicamente parte de la especificación MQTT, se ha convertido en una costumbre que los brokers admitan la autenticación de clientes con certificados de cliente SSL/TLS. Como el protocolo MQTT pretende ser un protocolo para dispositivos con recursos limitados y dispositivos IoT, SSL/TLS no siempre puede 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 contraseña en texto plano, que el cliente envía al servidor; esto forma 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 ligero porque todos sus mensajes tienen una pequeña huella de código. El paquete consta de una cabecera fija de 2 bytes + una cabecera variable y una carga útil. En estos primeros 2 bytes, la cabecera fija siempre estará presente en todos los paquetes, y las otras dos, la cabecera variable y la carga útil, no siempre estarán presentes. ![Formato de mensaje MQTT](/files/ca61d72645592afb5200da72d090d9161f1eb264) De la cabecera fija 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 topic, se publica un nuevo mensaje para los suscriptores y otros. Los siguientes 4 bits son los bits de bandera de control y se utilizan para el comando publish; para el resto de los comandos están reservados y el valor será 0. El segundo byte de la cabecera fija contiene la longitud restante, que es la longitud de la cabecera variable + la longitud de la carga útil. Una cabecera variable no está presente en todos los paquetes MQTT. Algunos comandos o mensajes MQTT utilizan 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 'username and password' 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. Actúa como una característica clave en MQTT, dando al cliente la capacidad de elegir entre tres niveles de servicio. Los tres niveles distintos de QoS determinan cómo el protocolo MQTT gestiona el contenido. Aunque los niveles más altos de QoS son más fiables, tienen mayores requisitos de latencia y ancho de banda, por lo que los clientes suscritos pueden especificar el nivel más alto de QoS que desean recibir. * El nivel de QoS más simple es un servicio sin acuse de recibo. Este nivel de QoS utiliza 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. A este nivel de QoS también se le puede denominar como como máximo una vez, QoS0 o fire and forget. * El segundo nivel de QoS es el servicio con acuse de recibo. 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 acuse de recibo verifica que el contenido se ha recibido, y un mecanismo de reintento enviará el contenido original de nuevo si no se recibe un acuse de recibo a tiempo. Esto puede provocar que el suscriptor reciba varias copias del mismo mensaje. A este nivel de QoS también se le puede denominar al menos una vez o QoS1. * El tercer nivel de QoS es el servicio asegurado. 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. A este nivel de QoS también se le puede denominar exactamente una vez o QoS2. ![QoS MQTT](/files/2e88ad66a3e6bac486bb6f9945896568d668ee85) ## Ventajas y desventajas ### Ventajas: * MQTT es agnóstico al paquete. La carga útil del protocolo MQTT puede transportar cualquier tipo de datos, como binario, texto ASCII, etc. El receptor necesita interpretar y decodificar según el formato utilizado por el transmisor. * Utiliza un paquete de pequeño tamaño y puede emplearse en aplicaciones de bajo ancho de banda. * Ofrece un menor consumo de batería. * Es un protocolo fiable, ya que utiliza 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. Ideal para comunicaciones distribuidas de uno a muchos y aplicaciones separadas. * 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 anómala del cliente. * Depende de TCP/IP para las tareas básicas de comunicación. * Diseñado para entregar mensajes según las plantillas "maximum once", "minimum once" y "exactly once". ### Desventajas: * MQTT no puede soportar la transmisión de video. * Problemas de latencia. * La seguridad no está integrada. MQTT no está cifrado. En su lugar, utiliza TLS/SSL (Transport Layer Security/Secure Sockets Layer) para el cifrado de seguridad. * Un broker centralizado puede ser el punto de fallo, 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 utilizar MQTT Como las aplicaciones IoT se están implementando ahora a gran escala, MQTT ha cobrado protagonismo como una forma abierta, sencilla y escalable de desplegar computación distribuida 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 utilizando MQTT para crear sistemas de gestión de flotas más inteligentes que mejoran la optimización de la flota, la seguridad del conductor y reducen los costes de combustible. Los nuevos modos de transporte que utilizan 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 telemétrica directa del vehículo y la integración en los sistemas backend de programación y enrutamiento proporciona la visibilidad necesaria para mejorar la operación general de la flota. * Datos de sensores ambientales. 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 a intervalos especificados, esto no es un problema, ya que se reciben nuevas lecturas 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 estado de la máquina: para responder rápidamente a problemas emergentes y evitar tiempos de inactividad. Por ejemplo, para una planta eólica, se necesita una 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 alertas adecuadas sean notadas por los especialistas necesarios de manera oportuna, incluso si llegan duplicadas. 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 empresariales en las que la duplicación de registros es inaceptable, incluidos los sistemas de facturación, resulta útil la bandera QoS de transmisión "exactamente una vez". Esto elimina la duplicación o pérdida de paquetes en sistemas de facturación o de cobro, 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 utiliza MQTT para su aplicación Messenger, no solo porque el protocolo conserva energía de la batería durante la mensajería de teléfono móvil a teléfono móvil, sino también porque permite entregar mensajes de manera eficiente 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 trabajar con Navixy ### Configuración del dispositivo MQTT de Xirgo y BCE Para configurar el dispositivo Xirgo y BCE para trabajar con MQTT: * Dentro de FMSET: Elija connectivity → Telemetry server → MQTT broker address settings) especifique host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) para el servidor de la UE y [mqtt.us.navixy.com](http://mqtt.eu.navixy.com/) para el servidor de EE. UU., puerto 1883. * Y añada el usuario predeterminado en MQTT Security -> Authorization\ ![MQTT device configuration](/files/e8066786ada49d3408663efd56c1c23afd3efcd2) ### 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 * Topic globalmatix/in Para configurar el dispositivo Globalmatix para trabajar con MQTTS: * Especifique el servidor puerto 8883 para la UE y puerto 8883 para EE. UU. * Usuario/contraseña - globalmatix/secretword * Topic globalmatix/in --- # Agent Instructions: 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/es/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.