Hola
Como escribí recientemente (
primer artículo corto sobre MQTT / UDP ), MQTT / UDP es un protocolo basado en MQTT, pero:
- Va encima de la transmisión UDP (no se necesita intermediario, casi no se necesita configuración)
- Es indecentemente fácil de implementar (10 líneas en la pila C + UDP / IP, y usted envía datos desde el sensor)
- Todos oyen a todos
En cierto modo, esto es CAN, pero encima de Ethernet.
Por qué
Mi departamento ha estado viviendo durante varios años bajo el control de un sistema como "la casa no es realmente oligofrénica". Sería redundante llamarlo inteligencia, pero la luz y el clima están automatizados. Para imaginar la escala del desastre: el sistema ocupa un estante lleno lleno de aproximadamente 19 pulgadas de ancho y dos metros de altura. Dos paredes del estante están ocupadas casi hasta el piso.
Cuando diseñé todo esto, el tema de la tolerancia a fallas vino primero. Varios años de operación han demostrado: es cierto. Lo niega todo. Tarde o temprano Pero los relés electromecánicos aún no han fallado, y es en ellos el último escalón de protección contra fallas.
El siguiente problema después de la tolerancia a fallas es el zoológico. Debido al curso natural de la vida, mi curiosidad y mis necesidades urgentes, el Unix habitual en una PC normal, Aries PLC, Raspberr + Orange PI, módulos Atmega, módulos basados en NodeMCU (ESP8266) viven en el sistema, y todo esto se aplica a través de Modbus 485, modbus TCP, http, y en el lateral cuelga un corredor de MQTT inquieto, como un legado de un intento fallido de cambiar a él con todo un campamento.
Por qué el intento de cambiar a MQTT no tiene éxito. En primer lugar, para una parte del hierro es pesado o complicado. En el fragmento de Pascal que se esconde en el PLC CodeSys, solo un masoquista puede escribir MQTT. Pero entonces necesitas depurar. Del mismo modo en atmega: puedes abarrotar, pero de cerca. Pero este no es todo el problema.
MQTT tal como es (y es aceptable en todas partes 3.1.1) insiste en enviar un paquete PUBLICAR (es decir, nuestro mensaje al corredor) a todos los destinatarios, incluido el remitente. El efecto de esta locura es encantador: el mismo OpenHAB no puede enviar y recibir datos en MQTT con el mismo nombre. Esto significa que es imposible organizar un bus basado en MQTT (varios módulos que actualizan el valor del mismo objeto y lo usan). Y así es exactamente como debería organizarse la comunicación PLC, en la que vive el control de luz principal, OpenHAB, que controla la luz desde la interfaz web y la aplicación móvil, y los interruptores inteligentes, que me gustaría poder agregar aquí y aquí. Es decir, por supuesto, este problema se puede eludir, pero de hecho significa construir su propio protocolo SURFACE MQTT, y esto ya parece ser demasiado.
Al mismo tiempo, ¿qué necesito? Envíe una actualización del valor del parámetro y consígalo en todos los puntos interesados. Por lo que, de hecho, los abuelos hicieron UDP a la dirección de transmisión.
Después de la última publicación en Habré, uno de los lectores me reprochó durante mucho tiempo la falta de fiabilidad del protocolo UDP. Le respondí especulativamente que para IoT, UDP es MÁS confiable que TCP: con una pérdida de paquetes del 50% en una red, TCP no solo se acostará, sino que generalmente, y el sensor de temperatura que envía mediciones a través de UDP simplemente perderá la mitad del conteo, lo que afectará El funcionamiento del sistema de cualquier manera. En general
Pero fue especulativo. Sin embargo, las vacaciones de Año Nuevo también se le dieron a una persona para terminar de beber champaña y preguntarse: ¿pondremos hoy nuestra LAN en palas? Y pase lo que pase.
Tomé MQTT / UDP y escribí una prueba primitiva. Un lado envía paquetes consecutivos sin pausa entre paquetes tanto como sea posible. El segundo considera la velocidad y la pérdida de paquetes. El experimento fue simple: lanzamos esta burla, y en paralelo dos televisores HD muestran películas desde Internet, y la computadora de escritorio escribe un archivo enorme en el NAS.
Califica el resultado. Esperé todo, pero ... la pérdida máxima de UDP alcanzó el medio por ciento, y ambos televisores dejaron de aparecer. Así que todavía era pesimista. En una red doméstica real, la confiabilidad de la entrega UDP es casi absoluta. Sin embargo, probablemente haré una versión con confirmaciones y volveré a enviar paquetes. Hay pocas dificultades, pero la pregunta se elimina por completo.
La segunda pregunta es la seguridad, pero es cierto, si entran en mi red doméstica, la pérdida de datos de los sensores de temperatura es lo último por lo que me lamentaré. Sin embargo, nuevamente, la tarea de firmar digitalmente paquetes en el rastreador de problemas está presente, y ya entiendo cómo expandir los paquetes MQTT para su implementación.
En general, planeo en el primer par de dispositivos en la red doméstica para cambiar a MQTT / UDP el otro día.
Y le sugiero que lo pruebe en sus programas y dispositivos:
repositorio y
documentación en inglés .
Lo que está disponible:
Implementaciones bastante completas en Java, Python y C. Implementación básica en Lua. Hasta ahora, solo envío para Arduino y CodeSys PLC (probado y funciona en Aries, pero debería hacer cualquier cosa).
Herramienta GUI para ver lo que está sucediendo e intervenir:
Programas para enviar y recibir datos en Python, Lua y Java.
Conectores Python para integración con MQTT regular y directamente con OpenHAB. Resuelven la protección contra los ciclos, prohibiendo la transmisión inversa del mensaje durante 5 segundos después de pasar en dirección hacia adelante. Además, hay una biblioteca para limitar el flujo de datos repetidos. Comprueba si ya ha habido una actualización de este tema durante el tiempo especificado, y si lo hace, omite la nueva actualización solo si los datos han cambiado.
Planeo pasar gradualmente a este protocolo por completo, y aquí hay un ejemplo de lo que quiero obtener con los sensores:
Hay tres sensores en una habitación (bueno, o en la calle, no importa). Envían muestras a través de MQTT / UDP. Estas lecturas son recibidas simultáneamente por el sistema principal inteligente del hogar (OpenHAB), una base de datos histórica y un monitor de pared que muestra la temperatura para los residentes.
Todo el encanto de MQTT / UDP es que en dicho esquema, la falla de cualquier bloque no crea ningún problema para todos los demás. Y esto es con la simplicidad encantadora del protocolo.
Además, los esquemas de control redundantes con duplicación se implementan fácilmente en el mismo esquema. El servidor de bases de datos se puede duplicar sin ningún problema. Será más complicado duplicar los módulos que se ocupan de la gestión. Por ejemplo, escuchar la temperatura produce una acción de control sobre los radiadores. Pero probablemente esta es la próxima historia. Hoy planeo concentrarme en recolectar señales de sensores e intercambiar entre los módulos de una casa inteligente.