¿Más fácil que MQTT? MQTT / UDP

Quería escribir un artículo detallado sobre este tema, pero, obviamente, mis manos no llegan. Por lo tanto, un mensaje corto. Desarrollé e implementé en varios idiomas como código prototipo una versión del protocolo MQTT bajo el nombre de trabajo MQTT / UDP. Para impacientes y aquellos que ya entienden todo y, obviamente, el código en Github

Porque

Vivo en un departamento que está controlado casi por completo por mi propio sistema de hogar inteligente durante varios años. Luz, control climático, sensores, automatización fácil, eso es todo.

Durante este tiempo, descubrí (sí, por cierto, ya lo entendí) que la propiedad principal de los sistemas UD es la confiabilidad.

Todos los sistemas con un nodo central son, por definición, poco confiables. De ahí el deseo de obtener la interconexión de los componentes del sistema (y hay muchos de ellos en un hogar inteligente real) sin usar ningún concentrador central.

Al mismo tiempo, procedemos del hecho de que, en general, el tráfico de los sistemas UD es pequeño: los sensores rara vez necesitan actualizarse más de una vez por minuto, el resto de los datos se basa en eventos (enciende la luz) y el tráfico es completamente insignificante. Incluso cada segunda actualización de todos los datos en el sistema no es solo un desastre, sino incluso un problema importante.

La conclusión lógica es que UDP Broadcast es una herramienta ideal.

(Sí, supongo que la red interna del apartamento está cerrada por un firewall).

¿Qué hay en las ventajas?

Increíblemente simple implementación. Un microcontrolador mínimo con poca memoria puede enviar un paquete UDP. Para el sensor, incluso la recepción UDP no es necesaria.

Latencia extremadamente baja. No hay reenvío en el concentrador central, el tiempo de entrega de paquetes UDP es prácticamente el intervalo de tiempo mínimo en un sistema moderno.

No hay un punto central de falla en el hub / broker. Considere un esquema simple: dos sensores de temperatura, un controlador de piso calentado, un controlador de batería calefactora. Con el uso de MQTT / UDP, la falla de cualquier parte de dicho sistema no conduce a una falla del sistema en su conjunto.

Bajo tráfico de red. Debajo de la nada. TCP y los reconocimientos solo agregan tráfico, pero no agregan confiabilidad. Un sensor fallido no funcionará al recibir un TCP ACK. E identificamos el fracaso por la ausencia de actualizaciones.

La confiabilidad del protocolo UDP en sí es insignificante: los sensores aún actualizan los datos regularmente, y la desaparición del conteo es completamente invisible, y la desaparición de un comando de, por ejemplo, un interruptor se confirma visualmente por la falla del sistema de destino. ¿Qué hace una persona? Clics nuevamente. Sin embargo, esta es una limitación importante en la aplicabilidad del protocolo. Ideal para encuestas recurrentes.

No se necesita configuración del sistema. Nadie necesita registrar la dirección de un corredor, centro, etc. Sin embargo, la configuración del sensor todavía es necesaria; debe registrar la ID del sensor. Pero cuando se transfieren otras partes del sistema a otros servidores, no se requiere la reconfiguración de los componentes de respuesta.

Es particularmente interesante que este modelo de intercambio de datos se ajuste bien en medios de transmisión natural como un canal de radio o RS / 485. No he experimentado con esto, y el protocolo en tales entornos necesita ser controlado. Aquí es lógico aplicar CRC16 desde Modbus, por cierto.

Las desventajas también son obvias: la confiabilidad de la entrega está determinada solo por el hardware y el tráfico en la red, bueno, si el enemigo ingresó a la red, entonces el protocolo es derrotado de inmediato. Es cierto, seremos francos, piratear otros protocolos típicos de hogares inteligentes es cuestión de segundos, por lo que este es un inconveniente controvertido de MQTT / UDP. Otro inconveniente no obvio es un máximo de un receptor por dirección IP.

Lo que se ha hecho y se encuentra en el repositorio de código fuente:

• Implementaciones cliente / servidor en varios idiomas. Hay C, Python y Java. No dominaba Lua (no podía poner todo lo que necesitaba, ¿cómo vive en esto?) Y Codesys (no podía compilar el paquete, ¿quién inventó este lenguaje?).
• Puerta mínima a MQTT tradicional en Python
• Una herramienta primitiva para mostrar el tráfico MQTT / UDP en una red

¿Qué haría si tuviera más tiempo?

• Escribiría un módulo para openHUB.
• Haría una variante de protocolo en JSON en otro puerto y un convertidor al formato y puerto principal. O una puerta en ambas direcciones.
• Haría espacios en blanco de implementación para las plataformas principales. Para Arduino, hice un acercamiento al peso y realmente probé el código, pero no diseñé todo correctamente. Para Raspberry, los casos de prueba en Python son adecuados.
• Firmaría y cifraría digitalmente, pero no está claro cómo.
• Multicast

Gracias por eso, bienvenido al repositorio

PD: En este artículo se describe un enfoque similar, pero con multidifusión.