Antecedentes genéricos de MQTT

Con MQTT, el emisor y el receptor no se conocen entre sí: el broker se encarga de la mensajería. Esto permite separar los mensajes en espacio, tiempo e intensidad. El emisor puede enviar a la velocidad que quiera y en el tiempo que desee. El receptor puede recoger los mensajes a la velocidad y en el momento que desee. El emisor y el receptor no tienen por qué conocerse, y no tienen que tener una ruta directa establecida entre ellos (como sería el caso, por ejemplo, de una línea telefónica). MQTT permite diseñar fácilmente configuraciones de multidifusión, en las que un emisor puede enviar a muchos receptores suscritos.

• Los clientes no saben quién ha publicado el mensaje originalmente, a menos que esté claro a partir del tema (y posiblemente reforzado en el corredor por ACLs), o del contenido del mensaje (posiblemente firmado con HMAC)
• MQTT está diseñado para una comunicación de bajo consumo y baja latencia (HMAC, etc., podría ser costoso)
• No se puede obtener una lista de todos los temas de un broker. El broker descarta los mensajes (y los temas) a los que nadie está suscrito (posiblemente sólo sea totalmente cierto si la bandera de retención no está activada)
• No sabe quién se ha suscrito a un tema (utilice las ACL para limitar las suscripciones de clientes no autorizados)

última voluntad / mantener vivo

Los clientes pueden conectarse, publicar un mensaje y desconectarse, o mantener una conexión persistente con el servidor. En el caso de una conexión persistente, se enviarán keep-alives. Si el cliente no envía keep-alives en el plazo acordado durante el establecimiento de la conexión, el servidor (broker) puede enviar un mensaje llamado last-will and testament, que el cliente envió durante el establecimiento de la conexión. Este mensaje puede ser cualquier cosa y puede ser publicado en un solo tema por conexión. El corredor lo enviará a todos los clientes suscritos en este tema.

Si el cliente se desconecta de forma elegante, la última voluntad no se publicará.

El mantenimiento de la vida es especialmente útil para los clientes móviles, en los que la conexión puede interrumpirse (por ejemplo, por una red defectuosa, túneles, etc.)

Vea también:

http://www.steves-internet-guide.com/checking-active-mqtt-client-connections/

http://www.steves-internet-guide.com/mqtt-last-will-example/

https://owntracks.org/booklet/tech/mqtt/

Identificación del cliente / Toma de posesión del cliente

Cada cliente que se conecta a un broker MQTT debe tener un único id de cliente. Los clientes que se conectan con el mismo id de cliente matan la conexión anterior y toman la nueva. Si tienes dos clientes con el mismo id de cliente, esto puede llevar a un ping-pong de conexiones desconectadas.

Mensajes retenidos

El último El mensaje retenido a un tema se guarda y se entrega a todos los nuevos suscriptores de este tema. Esto puede ser utilizado para comunicar el estado del dispositivo / configuración / etc.

El estado retenido se establece como una bandera por mensaje.

Los mensajes retenidos pueden utilizarse para muchas cosas interesantes, por ejemplo, para facilitar la autodetección (véase la sugerencia 4 más abajo).

Calidad de servicio / QoS

Existen tres niveles de calidad de servicio, que determinan la cantidad de sobrecarga durante el procesamiento de un mensaje. Cuanto más alto sea el nivel, mayor será la sobrecarga.

• 0: no hay garantías de ningún tipo
• 1: el mensaje se enviará al menos una vez (es posible que se duplique)
• 2: el mensaje se enviará exactamente una vez (no hay duplicados posibles)

La QoS puede establecerse por mensaje enviado al broker, y durante la suscripción. El menor de los dos valores se utilizará para la entrega real del mensaje.

Para más detalles, vea esto:

https://www.eclipse.org/paho/files/mqttdoc/MQTTClient/html/qos.html

Temas

Datos sobre los temas

Los nombres de los temas distinguen entre mayúsculas y minúsculas, y son cadenas UTF-8. Es aconsejable limitarse a los caracteres ASCII imprimibles para facilitar la depuración.

Los nombres de los temas deben constar de al menos un carácter para ser válidos.

/

ya es un nombre de tema

El $SYS El tema es para el uso de los corredores / estadísticas.

Tienes la opción de colocar la información en la estructura del tema, o ponerla en el mensaje. Una estructura JSON para el mensaje le ayudará a poder ampliarlo con más datos.

Considere que en cada llamada al broker, cada publicación del tema será enviada a lo largo de la carga útil del paquete MQTT - por lo tanto, trate de evitar la longitud innecesaria.

Considerar el uso de comodines

• # coincide con todo para una profundidad de nivel arbitraria desde el nivel actual (comodín de varios niveles, sólo puede insertarse al final)
• + coincide con todo en el nivel actual (comodín de un solo nivel)

Por ejemplo, si tienes varios sensores de temperatura, podrías suscribirte fácilmente a los mensajes de todos ellos si diseñas tu árbol de temas correctamente.

Los comodines son sólo para abonarse, no se permite su publicación.

Puede suscribirse a todos los temas utilizando #

excepto el tema $SYS. Utilice $SYS/# para suscribirse a todos los temas de $SYS

Posiblemente, el uso de la parte "función" antes del identificador del dispositivo le permite suscribirse a ciertos canales más fácilmente.

Por ejemplo, si define sus rutas como tele/habitación1/nombre del sensor1 tele/habitación2/nombre del sensor2 etc. y stat/room1/sensorname1 stat/room1/sensorname2 es posible suscribirlo:

tele/#

stat/#

Si lo haces al revés, con sensor1/estado y sensor2/estadoetc. puede utilizar

+/stat

para suscribirse a las estadísticas, pero no coincidirá en profundidad arbitraria como en el ejemplo anterior. Es decir, la ruta de acceso a su sensor debe consistir precisamente en un componente.

De esta manera, si prefijas la acción tus caminos serán más consistentes.

Véase, por ejemplo https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch/

No lo hagas

- No utilices una barra inclinada (por ejemplo, /mytopics ) para iniciar tu árbol de temas - añade una sobrecarga, sin valor

- No utilice $SYS como tema de partida, está reservado para el corredor

- No utilice espacios en el tema

- No utilice caracteres no imprimibles en el tema

- utilizar un tema MQTT para mensajes con diferente significado - crear temas diferentes para ellos

Sugerencias / Hacer

- incrustar el id del cliente en el árbol de temas

- crear temas específicos para el direccionamiento individual (por ejemplo, de los sensores), en lugar de enviar todos los valores a través de un tema - esto evitará el envío de mensajes a destinatarios que no los necesitan

- intenta que los nombres de los temas sean cortos (ya que se enviarán en cada publicación y mensaje)

- considerar qué datos deben enviarse y con qué frecuencia

o Por ejemplo, considerar la posibilidad de separar los metadatos en su propio tema y publicarlos con una bandera de "retención".

- separar los temas de comando/cmd y de estado para un dispositivo - de esta manera la comunicación bidireccional será posible, y el dispositivo no tendrá que filtrar en sus propios mensajes.

- utilizar un mensaje de última voluntad para indicar una desconexión inesperada del cliente

Considerar la multi-tenencia y el bridging

¿Necesita dar soporte a múltiples clientes / organizaciones / aplicaciones independientes? Existe la posibilidad de utilizar, por ejemplo con VerneMQ, diferentes puntos de montaje. Otra alternativa es incluir la multi-tenencia en su árbol de temas (utilizando un prefijo apropiado al principio del árbol de temas).

Prefiero la primera vía, ya que proporciona una capa adicional de separación de ACL, y menos oportunidades de "fastidiar las cosas".

Además, es posible que quieras unir varios brokers MQTT, compartiendo parte de sus árboles de temas (definidos por sus ACLs).

Consulte este https://owntracks.org/booklet/guide/bridge/ para saber más sobre los puentes.

Considere la encriptación

MQTT puede ejecutarse a través de redes encriptadas (por ejemplo, a través de websockets / TLS encriptado) o a través de canales no encriptados. Además, puedes considerar encriptar y/o firmar la carga útil de tus datos.

Considere la descubribilidad

Considere la posibilidad de incorporar temas que ayuden a descubrir los servicios y capacidades de sus dispositivos, por ejemplo, utilizando mensajes retenidos.

Considerar los comentarios sobre los comandos

Cuando se publica un comando, no se dispone de un canal de retorno inmediato. Por lo tanto, podría ser útil establecer una jerarquía para la retroalimentación específica sobre comandos específicos - si el dispositivo recibió y fue capaz de ejecutar el comando, para poder proporcionar retroalimentación al usuario.

Un patrón que estaba pensando en aplicar aquí era dar identificadores de comandos únicos como parte de la carga útil del mensaje, a los que se hace referencia en el canal de retroalimentación con un código de estado.

Considere los escenarios de multidifusión

¿Quieres que varios dispositivos reaccionen a un solo mensaje que publiques? Recuerde que no puede publicar en temas comodín, sólo suscribirse a ellos. En este caso, hay que crear temas adicionales que permitan a los clientes reaccionar a los escenarios de multidifusión. Todos los clientes / todos los clientes de un determinado grupo se suscribirían al tema de multidifusión y reaccionarían a los mensajes.

Si se combina esto con mi sugerencia de retroalimentación / referencia a la identificación del comando anterior, se introduce un nuevo requisito de identificación del cliente como carga útil en el canal de retroalimentación (genérico). Otra posibilidad es que los dispositivos respondan en sus canales de retroalimentación individuales, donde el id del dispositivo ya forma parte de la ruta. (Es decir, reciben un comando en la ruta de multidifusión, pero responden en su propia jerarquía de temas de mensajes exclusivos).

Considere el tráfico y la privacidad, los tipos de sensores

Si se trata de un sistema comercial, por ejemplo, que recopila datos de sensores para los usuarios, es posible que éstos quieran tener un grado de control fino sobre los valores de los sensores que se publican.

Además, el simple hecho de publicar automáticamente todas las lecturas de los sensores aumentará el tráfico y la carga en su(s) servidor(es).

Por lo tanto, simplemente empujar todos los valores de los sensores disponibles a su broker MQTT podría no ser la mejor opción. Una posibilidad es crear un tema retenido, con una configuración a la que el cliente pueda suscribirse. Cuando el cliente se conecta, recibirá automáticamente la configuración en el tema retenido, y puede ajustar los valores que publica de acuerdo con la configuración. Además, puede reaccionar a los cambios de configuración reaccionando a cualquier mensaje adicional que llegue a este tema de configuración.

Además, es importante tener en cuenta que existen diferentes tipos de sensores. Por ejemplo, en el caso de un sensor de puerta, le interesaría un cambio de estado (cerrado frente a abierto), mientras que con un sensor de temperatura, podría querer recibir lecturas continuas. Es importante para su diseño considerar qué tipo de valores recibirán los suscriptores cuando el cliente responsable de las lecturas del sensor se desconecte. Recuerde que sólo puede establecer una última voluntad sobre un tema (para dispositivos multisensor). En caso de desconexión, los mensajes retenidos podrían dar una impresión errónea (por ejemplo, de que la puerta está abierta cuando en realidad está cerrada, pero no se ha actualizado, etc.).

Por otro lado, si, por ejemplo, su interfaz web que controla el cliente se conecta sólo después de que el cliente del sensor de puerta haya estado conectado durante un tiempo, y usted utiliza mensajes no retenidos, el mensaje de la última actualización del estado de la puerta se perderá;

Aquí hay dos posibilidades:

• solicitar activamente una actualización del estado de la puerta (por ejemplo, utilizando su propio tema get)
• utilizar mensajes retenidos, y utilizar la lógica del lado del cliente de la interfaz web para descartar el último valor en caso de que el propio cliente no esté conectado / marcarlo como viejo

En cualquier caso, el usuario debe saber si la lectura de un sensor es fiable o si es posiblemente incorrecta debido a un cliente-sensor desconectado.

Ver también http://www.steves-internet-guide.com/mqtt-sensors-traffic-observations/

• Steve señala que la combinación de datos de varios sensores en una carga útil codificada en JSON no disminuye el tráfico, sino que incluso puede aumentarlo ligeramente (¡frente a una carga útil no codificada!)

ruta temática semántica vs. física

las cosas significativas para un humano crean la estructura temática: ("enfoque semántico")

hogar/baño/humedad

rutas de los dispositivos (¿a qué dispositivos están conectados los sensores, cómo se dirigen?) crear la estructura del tema: ("enfoque físico")

pi/00000234898324734/i2c/10/pressure

(los números simbolizan la serie del BCM, y la dirección I2C respectivamente).

reedición de

En esta idea se combinarían ambos enfoques, y se crearía un servicio adicional que se traduce entre los dos mundos.

Ver: https://tinkerman.cat/post/mqtt-topic-naming-convention

Resumen de las sugerencias de diseño en línea

Sugerencia 1: Valle de la Frambuesa

de: https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/

categoría-dispositivo/id-dispositivo/contexto-de-carga-de-pago/diferenciador-de-carga-de-pago

• categoría de dispositivo: por ejemplo, "pi", "arduino", etc.
• device-id: por ejemplo, BCM serial
• contexto de la carga útil: por ejemplo, la temperatura
• diferenciador de la carga útil: por ejemplo, delante/atrás (añadiendo un nivel de medición para un contexto determinado)

Obsérvese la simetría entre categoría de dispositivo/id de dispositivo y contexto de carga útil/diferenciador de carga útil (genérico-> específico; genérico -> específico)

Sugerencia 2: Steve

(Por Steve): http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/

Puede incluir los siguientes elementos en su árbol de temas:

• dispositivos de agrupación de temas de alto nivel
• nombre del sensor asignado
• función (por ejemplo, set / status / get / cmd )

El enfoque de Steve:

• utilizar el nombre del tema para un dispositivo individual (por ejemplo, un sensor)
• utilizar datos payload / JSON para los atributos de este sensor
• utilizar un tema separado para los datos y los comandos

Sugerencia 3: MQTT-Smarthome

Propuesta de MQTT Smarthome

https://github.com/mqtt-smarthome/mqtt-smarthome

un camino se ve así en esta propuesta:

toplevelname/function/item

knxgateway1/estado/cocina/luces/frente izquierda

• primer nivel (knxgateway1) = toplevelname, la pasarela concreta a la que se dirige
• en el caso de varias pasarelas similares, este nombre debe poder establecerse para evitar colisiones en el espacio de nombres
• segundo nivel (estado) = función
• tercer nivel, y otros niveles -> jerarquía de direcciones individuales de la pasarela particular (elemento)

Lo interesante son las funciones, y su posición antes de las rutas más profundas (considere los comodines para la suscripción - ¡así podrá suscribirse a todos los informes de estado de los dispositivos fácilmente!)

Funciones disponibles / definidas en esta propuesta:

• estado - para obtener informes de estado
• set - para solicitar cambios de estado
• get - (opcional) para solicitar activamente una actualización de estado (para las pasarelas que lo soportan)
• el resultado de la lectura se publicará en el estado jerarquía.

Las jerarquías subsiguientes para los verbos individuales deben coincidir entre sí, de manera que se dirija al mismo dispositivo / nodo / parámetro.

Existe un tema especial "conectado" por pasarela, que permite al cliente establecer un mensaje de última voluntad

toplevelname/connected

se definen valores simples para este tema:

• 0 = desconectado del corredor (establecido como última voluntad)
• 1 = conectado a MQTT, desconectado del hardware
• 2 = conectado a MQTT y al hardware (totalmente operativo)

Tenga en cuenta que el valor 0 no distingue entre las desconexiones voluntarias o la pérdida de la conexión (cuando se agotan los tiempos de mantenimiento de la vida).

También hay sugerencias para la carga útil:

La codificación JSON de la carga útil es opcional.

En el caso de la codificación JSON, el valor siempre estará en la clave "val". Además,

ts : timestamp (marca de tiempo, milisegundos desde Epoch)

lc : último cambio de valor (timestamp, milisegundos desde Epoch)

Sugerencia 4: Tinkerman

https://tinkerman.cat/post/mqtt-topic-naming-convention

Considere si desea un enfoque "semántico" (por ejemplo, cosas con significado para los humanos) o un enfoque "físico" (por ejemplo, las rutas reales de los dispositivos en los que se conecta su sistema).

El enfoque físico es más amigable para las máquinas.

(Tenga en cuenta que la comprensión de Tinkerman y la mía sobre los puntos de montaje y su uso difiere - para mí los puntos de montaje son árboles temáticos completamente segregados, por ejemplo, para el multi-tenancy)

Los metadatos pueden codificarse como rutas postfix.

Por ejemplo

/home/dormitorio/temperatura -> 21

/home/dormitorio/temperatura/unidades -> °C

/home/bedroom/temperature/timestamp -> 2012-12-10T12:47:00+01:00

Nota: como es poco probable que las unidades y algunos otros metadatos cambien, podrían enviarse como temas retenidos.

Una parte interesante de esta sugerencia es también la agregación (lado del dispositivo):

/home/bedroom/temperature/last -> último valor de temperatura

/home/dormitorio/temperatura/última/hora

/home/bedroom/temperature/last24h/max -> valor máximo en las últimas 24h

/home/bedroom/temperature/last24h/max/timestamp -> marca de tiempo en la que la temperatura fue tan alta

/casa/habitación/temperatura/última24h/min

/home/bedroom/temperature/ever/max -> la temperatura más alta absoluta jamás medida

Una vez más, estos valores podrían establecerse como temas retenidos (específicamente "siempre") para ahorrar tráfico de red - el sistema receptor podría descartar los valores retenidos más antiguos (si el sensor se desconecta, como debería ser evidente por otro tema - posiblemente establecido por el último testamento y voluntad), o el sistema podría mostrarlos como valores "viejos".

Este es un diseño interesante (para la agregación), y podría servir de inspiración para permitir este tipo de flexibilidad.

Sugerencia 5: Convención Homie IoT

https://homieiot.github.io/

Homie IoT se centra en la descubribilidad de los nodos en el entorno de la automatización del hogar IoT. Homie no utiliza mensajes codificados en JSON, sino que utiliza una representación directa de la carga útil de cada nodo. Vea este ejemplo:

Homie define un subconjunto estricto de caracteres que puede utilizar para nombrar sus nodos, ya que los caracteres especiales (por ejemplo, $ y el guión bajo _) se utilizan para fines especiales.

Define los tipos de datos, que se publican como metadatos (retenidos) ("atributos") a $datatype de la propiedad individual (véase más abajo la definición de propiedad):

• Cadena
• Entero
• Flotador
• Booleano
• Enum
• Color

(nótese el uso del $ para marcar temas especiales).

La última voluntad se utiliza para marcar el dispositivo como perdido:

homie/deviceID/$state -> perdido

Homie define 6 posibles afirma para el dispositivo:

• init -> el dispositivo se ha conectado a MQTT pero aún no ha publicado todos los mensajes Homie necesarios
• listo -> el dispositivo está conectado y ha terminado de configurarse: se han enviado todos los mensajes necesarios
• desconectado -> el dispositivo desconectado de forma limpia
• dormir -> autodescriptivo
• perdido -> el dispositivo se ha desconectado inesperadamente (establecido por la última voluntad)
• alerta -> el dispositivo está conectado, pero algo está mal, necesita la intervención humana

Homie recomienda utilizar QoS 1 (ya que la naturaleza de Homie hace que sea seguro para los mensajes duplicados).

Una disposición para extensiones se realiza utilizando una sintaxis de nombre de dominio inversa, por ejemplo, org.miempresa.homiextensión

nodos y dispositivos

En Homie-parlance, un dispositivo es la unidad de hardware básica. Por ejemplo, una Raspberry Pi, una máquina de café, un coche.

A nodo es una unidad lógica e independiente del dispositivo. Por ejemplo, un coche puede tener un nodo de ruedas, un nodo de motor y un nodo de luces.

propiedades representan características básicas del nodo/dispositivo. Un coche, por ejemplo, podría tener una propiedad "velocidad" y otra "temperatura" para el nodo motor. Las propiedades pueden ser retenidas y/o ajustables.

• retenidos + no ajustables: por ejemplo, sensor de temperatura
• retenido + ajustable: el nodo puede publicar una propiedad y recibir comandos para la propiedad (por ejemplo, la potencia de la lámpara)
• no retenidos + no ajustables: por ejemplo, un timbre de puerta (eventos momentáneos)
• no retenido + configurable: el nodo puede recibir órdenes para la propiedad, por ejemplo, preparar café

atributos:

los atributos son importantes para el autodescubrimiento de Homie, se especifican y comienzan con un $ para indicar su importancia particular / evitar colisiones. Se utilizan para almacenar y actualizar los metadatos.

Por ejemplo, el dispositivo publica un mensaje retenido en

homie/device ID/$nodes

con una lista separada por comas de los nodos. Para indicar que un nodo es una matriz (puede utilizarse para agrupar, por ejemplo, las luces delanteras y las traseras de un coche), el nombre se especifica con corchetes al final, por ejemplo

luces[]

Un ejemplo para el subárbol de identificación de dispositivos:

Homie especifica diferentes estadísticas para el dispositivo, la mayoría de ellas opcionales (excepto el tiempo de actividad). Por ejemplo:

En el caso de los nodos, también es posible el autodescubrimiento de las propiedades, especificándolas en el atributo $properties:

De esta manera, usted, como suscriptor, no tiene que adivinar / suscribir todos los eventos - puede suscribirse selectivamente a los que le interesan.

En Homie, los metadatos (atributos) se publican como un sufijo de la ruta. Por ejemplo, para una propiedad concreta:

Control en Homie

Homie se basa en el estado. Esto significa que no se "enciende la luz", sino que se establece el estado de energía de un dispositivo.

entonces el dispositivo actualiza su estado de energía para comunicar que el comando ha sido ejecutado:

Difusión

la alerta es una elección arbitraria - la difusión puede ser a cualquier otro tema, que los dispositivos pueden filtrar. Los mensajes se emiten a todos los dispositivos - los dispositivos pueden reaccionar si lo desean.

Esta es la especificación más completa que he podido encontrar en mi investigación en línea. Personalmente, creo que tiene una ingeniería muy elegante.

Lea más:

https://homieiot.github.io/specification/

Sugerencia 6: Pistas propias

https://owntracks.org/booklet/tech/json/

http://owntracks.org/booklet/guide/topics/

Owntracks es una aplicación de código abierto, para permitir el seguimiento de su propia ubicación física, para compartir con los amigos, etc. La ubicación se publica a través de HTTP o MQTT, idealmente a su propio corredor.

" También puede detectar cuándo se entra o se sale de una región determinada para la que se establece un llamado waypoint. La gente utiliza esto, por ejemplo, para controlar algún aspecto de su sistema de automatización del hogar. (¿Se han ido todos de casa? Podemos apagar las luces)".

Si quiere leer más sobre OwnTracks, vaya a este sitio web: https://owntracks.org/booklet/

Sobre el diseño del tema owntracks:

https://owntracks.org/booklet/guide/topics/

"Los principios durante el diseño del esquema de denominación de temas de OwnTracks fueron

• legibilidad humana
• minimización del tráfico
• control de acceso granular

“

Nombre del tema base (son posibles otros):

owntracks/peter/iPhone

aquí owntracks es un prefijo, para permitir otras aplicaciones sin colisiones en el broker MQTT.

peter es el propietario de dispositivos de seguimiento, y el iPhone es uno de sus dispositivos.

los comandos a los dispositivos se envían en: owntracks/peter/iPhone/cmd

la salida de los comandos se publica, por ejemplo, en nombres de temas relativos paso, vaciar etc.

se definen otros temas (info, waypoint, evento). Los eventos se publican, por ejemplo, cuando un usuario entra en una zona definida.

De esta manera, la suscripción a owntracks/+/+/event te permitirá ver (para los usuarios que estés autorizado a ver) cuando entran o salen de una zona definida.

Owntracks publica sus mensajes en formato JSON:

https://owntracks.org/booklet/tech/json/

como puede ver las funciones son después de el dispositivo.

Dado que existe una "profundidad" fija para el usuario/dispositivo conocida de antemano, la suscripción a múltiples usuarios y dispositivos puede realizarse mediante comodines:

En el JSON, el tipo del JSON particular se pasa en el mensaje:

Es una buena idea. De esta manera, puedes verificar que tu aplicación entiende el evento correctamente, puede hacer comprobaciones de tipo, etc.

Los elementos individuales se especifican de manera no verbosa. Esto ayuda a ahorrar tráfico, especialmente para los mensajes que se publicarán con frecuencia.

Por ejemplo:

• acc: precisión de la ubicación notificada en metros (sin unidad)

muchos de los elementos son opcionales.

Curiosamente, el tipo de localización se define para diferentes dispositivos, que admiten distintos elementos.

Se publica un simple mensaje de última voluntad. Simplemente incluye una marca de tiempo tst, en la que el dispositivo se conectó por primera vez.

tst es una marca de tiempo de época Unix.

Un aspecto interesante de este tipo de evento/carga útil es que se especifican varias marcas de tiempo:

• wtst: Marca de tiempo de la creación del waypoint
• tst: Marca de tiempo en la que se produjo el evento.

Un punto de ruta es un punto de interés, por ejemplo, su garaje: si entra o sale de su garaje se activará un evento de transición:

• evento: (entrar|salir)

Un evento de configuración. Si se activa, las aplicaciones también aceptan mensajes de configuración remota.

Este evento incluye muchos elementos posibles, que son más verbosos (por ejemplo, validatecertificatechain) - esto es sensato, ya que la configuración puede ser almacenada como JSON (! -> esto puede ser pasado como mensaje MQTT y almacenado!), y también ya que no se envía a menudo, la verbosidad no es un gran problema, sino más bien una ventaja para los usuarios.

Por ejemplo, una acción con la "acción": "dump" desencadenará una publicación del mensaje de configuración en la ruta relativa dump

Se pueden dar sub parámetros opcionales para una acción, por ejemplo, un periodo de tiempo a considerar:

Otra idea de diseño interesante es que mediante una determinada variación de este mensaje cmd se pueda abrir un navegador a una determinada URL. Por ejemplo, si se entra en el garaje, se podría abrir un sitio de control del garaje, ...

un matriz de un tipo de mensaje diferente puede / debe ser pasado como parámetro aquí.

Lo interesante de este mensaje es que también tiene un campo para una imagen PNG codificada en Base64:

la idea interesante aquí es que un Creador que identifica a la entidad que creó estos puntos de ruta.

Tenga en cuenta también que owntracks utiliza el guión bajo _ para los parámetros "especiales".

opcionalmente todos estos mensajes pueden ser encriptado para el transporte con una clave simétrica compartida.

La carga útil cifrada (el mensaje original) estará en el elemento "data", codificado en Base64.

Mensajes

La carga útil de los mensajes es binaria y puede ser cualquier cosa, no es necesario que los mensajes sean válidos en UTF-8.

Por lo tanto, también puede publicar datos digitales, por ejemplo, imágenes, como carga útil sobre determinados temas.

Muchos de los actuales cuadros de mando del IoT toman los datos codificados como JSON.

En general, parece haber dos escuelas de pensamiento: donde los mensajes son realmente valores crudos, y los metadatos están codificados en el árbol de temas, y los valores codificados JSON que llevan los metadatos como la carga útil.

sugerencias

• Utilizar el formato JSON para la carga de los mensajes
• agrupar los atributos en los mensajes, en lugar de crear temas individuales para ellos
• incluyen:
• datos de la carga útil
• sensor / id de dispositivo (si no forma parte del árbol de temas)
• función
• marca de tiempo

Recursos interesantes

Awesome MQTT: Colección de enlaces relacionados con MQTT:

• https://github.com/hobbyquaker/awesome-mqtt

proyectos individuales:

twitter-to-mqtt - Un demonio de python que utiliza la API de streaming de Twitter para acceder a los tweets y volver a publicarlos en un tema MQTT.

• https://github.com/knolleary/twitter-to-mqtt

fritz2mqtt - Conecta el FRITZ!Box a MQTT.

• https://github.com/akentner/fritz2mqtt

Ref:

• https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/
• https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
• https://homieiot.github.io/
• https://github.com/homieiot/convention
• https://github.com/mqtt-smarthome/mqtt-smarthome
• http://www.steves-internet-guide.com/mqtt/
• http://www.steves-internet-guide.com/understanding-mqtt-topics/
• http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/
• https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch
• https://tinkerman.cat/post/mqtt-topic-naming-convention
• https://github.com/mqtt-smarthome/mqtt-smarthome/blob/master/howtos/homematic.md (mostrando el flujo con el Nodo ROJO)
• https://owntracks.org/booklet/tech/json/

Reedición:

• https://lodge.glasgownet.com/2012/09/23/mqtt-republishing-itch/
• https://github.com/kylegordon/mqtt-republisher

Señal K para el uso de Marine (como posible inspiración para el formato JSON):

• http://signalk.org/specification/1.3.0/doc/signalk.pdf