¿Qué es una user property de MQTT?
Una user property es la respuesta de MQTT 5 a una pregunta que todo integrador se hace tarde o temprano: ¿cómo adjunto un poco de metadatos a un mensaje sin contaminar la carga útil? Para el trabajo de control es una forma limpia de llevar unidades, un tag de origen o una versión de esquema junto a una lectura. Esta página explica qué es una user property, cómo viaja en el paquete, y dónde ayuda y dónde no.
User property de MQTT en una línea: Una user property de MQTT es un par de cadenas llave-valor personalizado, agregado en MQTT 5, que un publicador o suscriptor puede adjuntar al encabezado de un paquete. Puede incluir tantas como quiera en un solo mensaje, las llaves pueden repetirse y el broker las pasa intactas. Permite a las aplicaciones llevar metadatos como unidades, un identificador de origen o una versión de contenido fuera de la carga útil del mensaje.
Cómo viaja una user property en el paquete
Una user property es una llave UTF-8 y un valor UTF-8 colocados en la sección de propiedades de un paquete de control de MQTT 5. Es parte del mecanismo de propiedades de MQTT 5, la misma área de encabezado que lleva cosas como el intervalo de expiración de mensajes y el content type. A diferencia de esas propiedades definidas, una user property no tiene significado para el propio MQTT; la especificación la reserva por completo para las aplicaciones. La única obligación del broker es reenviar las user properties de un PUBLISH del publicador al suscriptor sin cambios.
Puede adjuntar más de una user property a un solo mensaje, y la misma llave puede aparecer varias veces, así que la colección se piensa mejor como una lista ordenada de pares que como un mapa estricto. Esto importa si usa una llave repetida para representar, por ejemplo, una lista de etiquetas. El orden que usó el emisor se preserva, así que una aplicación a la que le importe el orden puede confiar en él. En paquetes distintos de PUBLISH, como CONNECT o SUBSCRIBE, las user properties también están permitidas y son igualmente definidas por la aplicación entre cliente y broker.
Como las user properties están separadas de la carga útil, las puede leer middleware que no quiere interpretar el cuerpo. Un enrutador o un puente puede inspeccionar una user property para tomar una decisión sin deserializar una carga binaria Sparkplug o un documento JSON. Esa separación es todo el atractivo: los metadatos que describen el mensaje viven en el encabezado, los datos reales viven en la carga, y los dos pueden evolucionar de forma independiente.
Dónde ayudan las user properties en la telemetría SCADA
Los usos naturales son los pequeños hechos que describen una lectura sin ser la lectura. Las unidades son un ejemplo clásico: publicar un valor numérico y llevar su unidad de ingeniería como user property permite a un consumidor presentarlo o validarlo sin una búsqueda aparte. Un identificador de origen o de gateway como user property permite a un servicio de ingestión saber de dónde se originó un mensaje incluso después de pasar por un puente. Una versión de contenido o de esquema como user property permite al consumidor elegir el parser correcto, lo que se empareja bien con un registro de esquemas.
Hay una frontera importante con Sparkplug. Sparkplug B define su propia carga autodescriptiva, donde las métricas llevan sus nombres, tipos de dato y metadatos dentro del cuerpo protobuf, así que un sistema Sparkplug bien formado no necesita user properties para transmitir esa información y en general no las usa para ello. Las user properties están más en casa en un diseño de MQTT plano o de carga JSON donde usted quiere metadatos a nivel de encabezado sin inventar su propio sobre. Saber en qué mundo está evita agregar metadatos redundantes.
Una precaución que vale declarar: las user properties agregan bytes a cada mensaje que las lleva, y en un enlace de telemetría celular medido esos bytes no son gratis. Una cadena corta de unidades repetida en cada publicación de un segundo se acumula. El patrón eficiente es enviar los metadatos descriptivos una vez, al conectar o en un mensaje birth, y dejar que el flujo constante de mensajes de datos se mantenga esbelto, en lugar de estampar las mismas unidades en cada lectura individual. Es la misma disciplina de overhead que hace a la gente recurrir a los alias en primer lugar.
Preguntas frecuentes
¿El broker hace algo con una user property?
Casi nada. En un PUBLISH, el broker está obligado a reenviar todas las user properties a los suscriptores sin cambios, y no debe reordenarlas ni alterarlas. No las interpreta, no indexa por ellas ni filtra por ellas. Cualquier significado que lleve una user property es enteramente entre las aplicaciones de cada extremo. Si quiere que el broker enrute o filtre según metadatos, esa decisión pertenece a la jerarquía de tópicos, no a una user property, porque los tópicos son lo que el broker realmente compara.
¿Puedo poner muchas user properties en un mensaje?
Sí. Un solo paquete de MQTT 5 puede llevar múltiples user properties, y las llaves pueden repetirse, así que puede adjuntar varias piezas de metadatos o incluso una llave repetida que represente una lista. El orden que usó el emisor se preserva de extremo a extremo. El único límite práctico es el tamaño máximo de paquete negociado para la conexión y, en un enlace medido, su propia tolerancia a los bytes extra en cada mensaje que las lleva.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- MQTT Version 5.0 Specification - OASIS
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.