Archivo de la etiqueta: Node-RED

Diario del Curso IoT, Smart Cities y Node-RED

El diario del curso es una herramienta para seguir los puntos vistos en cada sesión del curso, que permite conocer el avance sesión a sesión.

También sirve para documentar los puntos y dudas que surgen en el curso fuera del temario, pero que es importante tenerlo por escrito como: enlaces interesantes, ampliar un tema de interés, tecnologías relacionadas, etc…

Sesión 1 (3 de mayo) – «Presentación Curso»

Capítulos vistos:

Sesión 2 (4 de mayo) – «Hardware IoT»

Smart Spots: https://smartcities.hopu.eu/index.html

OPA LWM2M: https://en.wikipedia.org/wiki/OMA_LWM2M

Logroño ciudad Inteligente: https://ciudadinteligente.logrono.es/

Soldar Módulos Wemos D1 Mini:

  • Usar espadines hembra en los ESP8266
  • Usar espadines macho en los shields: relé, oled y led.
  • Usar espadines macho/hembra (los más alargados) en el resto de shields: DHT11, DS18B20, BMP180,

Nodos y Firmware: https://aprendiendoarduino.wordpress.com/2021/12/05/material-curso-node-red/

Capítulos vistos:

Sesión 3 (9 de mayo) – «Comunicaciones IoT»

Plataforma Smart cities: https://elliotcloud.com/smart-cities-2/

Acceso a los metadatos: https://sacseguridad.com/auto-entrenamiento-y-aprendizaje-de-las-camaras-de-video-bosch-o-camera-trainer/

Bosch Metadata Publisher
Es una herramienta gratuita que permite al desarrollador de aplicaciones utilizar el protocolo MQTT y así poder trabajar en ambientes de comunicación M2M (Machine to Machine) o IoT (Internet of Things), posibilitando el desarrollo de aplicaciones que involucren dispositivos de automatización industrial o de edificios con base en la generación de metadatos por parte de la cámara.

Metadata y eventos de analíticas vía ONVIF
Con la interfaz de conformidad ONVIF disponible en las cámaras Bosch con FW 6.10 y superior se es compatible para recibir eventos de análisis basados en el motor de reglas de IVA en el borde y la secuencia de metadatos en el formato ONVIF. Use esta funcionalidad para desarrollar interfaces de integración con sistemas VMS de terceros, o para desarrollar sus propias aplicaciones de software que toman como base el foro ONVIF.

Capítulos vistos:

Sesión 4 (11 de mayo) – «Protocolos IoT»

Actualizada parte de SQLite en Instalación de Servicios en Raspberry Pi OS

Actualizada lista de librerías en Sensorización IoT con ESP8266

Listado completo de firmware de shields: https://github.com/jecrespo/Curso-Node-RED/tree/master/Remote%20Nodes%20Firmware/Wemos%20Shields%20Usage

HW LoRaWAN:

LoRa Network Server: https://www.chirpstack.io/

Broker MQTT:

  • Host: aprendiendonodered.com
  • Port: 8883
  • username: cursomqtt
  • Topic Path: cursomqtt/#

Capítulos vistos:

Sesión 5 (16 de mayo) – «MQTT»

Demo LoRa punto a punto: https://www.aprendiendoarduino.com/2018/03/07/demo-lora-con-moteino/

Datos enviados a Broker MQTT

Mosquitto Clients Count. Se quedan las conexiones al hacer un deploy. Probar con netstat -ntp | grep ESTABLISHED.*mosquitto

Configuración mosquitto: https://mosquitto.org/man/mosquitto-conf-5.html

  • message_size_limit
  • max_queued_messages
  • memory_limit
  • max_connections

Capítulos vistos:

Sesión 6 (18 de mayo) – «Instalación y Configuración Node-RED»

Problema en el cierre de socket en nodos MQTT: https://github.com/node-red/node-red/issues/3593

NodeRed 3.0.0-beta.1: https://discourse.nodered.org/t/node-red-3-0-0-beta-1-released/62124

Instalada beta en https://enriquecrespo.com:18809/

Instalar en Docker Node-RED dev: https://hub.docker.com/r/nodered/node-red-dev/tags

Demo Sigfox: https://www.aprendiendoarduino.com/2018/03/05/demo-mkrfox1200/

HW Sigfox:

Capítulos vistos:

Sesión 7 (23 de mayo) – «Node-RED»

TTN: The Things Network (TTN) es una iniciativa basada en la comunidad para establecer una red global de IoT. La iniciativa fue lanzada por Wienke Giezeman en 2015 y actualmente cubre más de 20.000 pasarelas LoRaWAN instaladas en más de 150 países. Los voluntarios se encargan de la construcción, el cuidado y el pago de los portales

Plantilla settings.js para Node-RED: https://github.com/jecrespo/configuracion-node-red

Múltiples instancias Node-RED con inicio mediante systemd:

  • https://nodered.org/docs/faq/customising-systemd-on-pi
  • Copiar el directorio completo .node-red: cp -R .node-red/ .node-red_1
  • Modificar en settings.js: uiPort: process.env.PORT || 1881 y userDir: ‘/home/pi/.node-red_1/’
  • sudo find / -name nodered.service (buscar donde está el servicio generalmente bajo /usr/lib/systemd/system/nodered.service)
  • sudo cp nodered.service nodered2.service
  • Añadir la línea: Environment=”NODE_RED_OPTIONS=-s /home/pi/.node-red2/settings.js”
  • sudo systemctl enable nodered2.service
  • sudo systemctl start nodered2.service

Capítulos vistos:

Sesión 8 (25 de mayo)

Sesión 9 (30 de mayo)

Sesión 10 (1 de junio)

Sesión 11 (9 de junio – presencial)

Otros

Otros puntos:

Presentación Curso Smart Cities

Título: “Fundamentos IoT y Desarrollo con Node-RED para Smart Cities”

El curso semipresencial “Fundamentos IoT y Desarrollo con Node-RED para Smart Cities” ha sido diseñado para conocer los fundamentos de IoT en aplicaciones de Smart Cities para capacitar en nuevas tecnologías. Este curso está enfocado en dar a conocer las nuevas tecnologías utilizadas en Smart Cities, con el fin de operar e integrar las plataformas IoT.

Motivación

Gracias a las herramientas libres/Open Source es posible democratizar el IoT y la industria 4.0. Antes se necesitaba muchísimo dinero no solo en HW y licencias de SW, sino en consultores que hacen un diseño a medida y realizan la integración de los sistemas, ahora no solo el SW libre y el HW libre y barato, sino que la comunidad da soporte a las dudas, hace documentación y tutoriales, así como librerías para facilitar el trabajo.

En la industria conectada e IoT, cada vez se está haciendo más popular el uso de Node-RED debido a su estabilidad, continuo desarrollo y aportaciones externas que hacen de ella una herramienta de programación utilizada para conectar dispositivos de hardware, APIs y servicios de internet.

Node-RED es una herramienta de programación (Low Code Programming) que se utiliza para conectar dispositivos de hardware, APIs y servicios de internet. Adecuado para los equipos dedicados al Internet de las cosas ( IoT) y personal dedicado al diseño y prueba de soluciones para la comunicación de equipos de planta con aplicaciones de IT. Dado que la mayoría de dispositivos IoT para industria 4.0 posibilitan realizar un programa de control con la herramienta de Node-Red, el dominio de dicha herramienta permitirá al equipo IoT explorar y ampliar las soluciones que ofrece.

Objetivos

El objetivo de este curso es conocer las tecnologías necesarias para el desarrollar soluciones IoT/Smart Cities y valiéndonos para ello de herramientas, tecnologías, protocolos y software libre/open source que hay a nuestra disposición, en especial el uso de Node-RED, desarrollo e integración con sistemas externos y plataformas enfocadas IoT/Smart Cities

Con los conocimientos adquiridos, los asistentes aprenderán las tecnologías necesarias para hacer aplicaciones IoT/Smart Cities sencillas o integrar desarrollos propios en sistemas ya implantados.  Se adquirirán conocimientos en cuanto manejo, montaje y parametrización de redes de comunicación IoT, protocolos IoT y hardware IoT.

Se aprenderá a usar Node-RED, un framework enfocado a IoT para programar, automatizar e integrar plataformas IoT.

Metodología Curso On-Line

El curso se realizará entre el 3 de mayo y el 9 de junio de 2022.

El curso semipresencial consiste en 36 horas de formación, repartidas de la siguiente forma:

  • 10 sesiones on-line en directo de 3 horas cada una los lunes y miércoles de 17:00 a 20:00 entre el 3 de mayo y el 1 de junio de 2022. Se realizará un descanso de 10-15 minutos a la mitad de las sesión.
  • Una sesión presencial de 6 horas el 9 de junio de 2022 en las instalaciones del cliente, que se organizará a lo largo del curso.

La plataforma en vídeo usada será https://meet.jit.si/aprendiendoarduino y se grabarán todas las sesiones. En casos de problemas con esta plataforma se podrá usar Google Meet.

Los recursos utilizados para la realización de este curso son:

Toda la documentación será on-line con el objetivo de mantenerla actualizada y no con un documento físico que se queda obsoleto rápidamente. Después de finalizar el curso toda la documentación on-line seguirá estando disponible de forma pública.

Toda la documentación está liberada con licencia Creative Commons.

Reconocimiento – NoComercial – Compartir Igual (by-nc-sa): No se permite un uso comercial de la obra original ni de las posibles obras derivadas, la distribución de las cuales se debe hacer con una licencia igual a la que regula la obra original.

Aprendiendo Arduino by Enrique Crespo is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional License.

Requisitos

Para la realización de este curso es necesario tener conocimientos básicos o experiencia en algunas de estas áreas: programación, redes TCP/IP, redes inalámbricas, protocolos de comunicación, bases de datos, uso de sistemas linux, microcontroladores, autómatas, electrónica, uso de sensores, actuadores, etc…

Es recomendable un conocimiento medio de Inglés puesto que gran parte de la documentación oficial de referencia está en Inglés.

Programación del Curso

FechaTemarioHoras On-line (live)Prácticas
Día 1
3 de mayo
17:00-20:00
Presentación
Fundamentos IoT
Verticales IoT/Smart Cities
1h
1h 30m
30m
0
Día 2
4 de mayo
17:00-20:00
Hardware IoT (1/2)
Comunicaciones IoT (1/2)
1h
1h 
1h – Práctica 1: Instalación y Configuración Raspbian
Día 3
9 de mayo
17:00-20:00
Hardware IoT (2/2)
Comunicaciones IoT (2/2) 
1h
1h
1h – Práctica 2: Sensorización y Comunicación con ESP8266 (1/2)
Día 4
11 de mayo
17:00-20:00
Protocolos IoT (1/2)
2h1h – Práctica 2: Sensorización y Comunicación con ESP8266 (2/2)
Día 5
16 de mayo
17:00-20:00
Protocolos IoT – MQTT (2/2)1h 30m1h 30m – Práctica 3: Wifi + MQTT con ESP8266
Día 6
18 de mayo
17:00-20:00
Administración Node-RED (1/2)1h 30m1h 30m – Práctica 4: Instalar y configurar Node-RED (1/2)
Día 7
23 de mayo
17:00-20:00
Administración Node-RED (2/2)1h 30m1h 30m – Práctica 4: Instalar y configurar Node-RED (2/2)
Día 8
25 de mayo
17:00-20:00
Programación con Node-RED (1/3)2h 1h – Práctica 5: Desarrollo Node-RED: MQTT y Dashboard
Día 9
30 de mayo
17:00-20:00
Desarrollo con Node-RED (2/3)2h1h – Práctica 5: Desarrollo Node-RED: MQTT y Dashboard (1/2)
Día 10
1 de junio
17:00-20:00
Dashboard con Node-RED2h1h – Práctica 5: Desarrollo Node-RED: MQTT y Dashboard (2/2)
Día 11
9 de junio
8:00-14:00
Sesión presencial en las instalaciones del cliente.
Plataformas IoT
2h2h – Práctica 6: Desarrollo Node-RED: BBDD y Tratamiento Datos
2h – Práctica 7: Integración de Datos en Plataforma IoT
TOTAL21h 30m14h 30m

Contenido del Curso

Toda la documentación del curso y el código usado es libre y accesible desde: https://www.aprendiendoarduino.com/cursos/fundamentos-iot-y-desarrollo-node-red-para-smart-cities/ 

Contenido:

  • Fundamentos IoT
  • Hardware IoT
  • Comunicaciones IoT
  • Protocolos IoT
  • Administración Node-RED
  • Desarrollo con Node-RED

Presentaciones

  • ¿Nombre?
  • Breve presentación con el rol/puesto y aplicación de los puntos del curso al trabajo.

Contacto

Para cualquier consulta durante el curso y en cualquier otro momento mediante email: aprendiendoarduino@gmail.com

Twitter @jecrespo: https://twitter.com/jecrespom

Y más información sobre el curso y el autor: http://www.aprendiendoarduino.com/acerca-de/

Ejercicios Node-RED

Ejercicio 01

Mostrar en el dashboard en un mismo grupo 3 widgets text donde cada segundo actualice el timestamp (epoch time), la fecha usando el nodo node-red-contrib-date y el día y hora en formato, usando el nodo moment para transformarlo.

Código: https://github.com/aprendiendonodered/ejercicio01 

Vídeo: https://youtu.be/wS0E1j1q7sM  

Ejercicio 02

Leer el dato de la temperatura publicado en MQTT y hacer que cuando la temperatura esté fuera de un rango entre 18 y 22 grados, ponga el estado de confort en un elemento del dashboard y mande un email.

Código: https://github.com/aprendiendonodered/ejercicio02 

Vídeos:

Imágenes:

Ejercicio 03

Hacer un dashboard para ver la temperatura de todas las Raspberry Pi publicada en MQTT y sus gráficas. Usar MQTT Explorer para explorar qué datos están publicados.

Opcionalmente hacer varias tabs/pestañas para mostrar: temperaturas, CPU y memoria agrupadas en cada pestaña.

Código: https://github.com/aprendiendonodered/ejercicio04

Vídeos:

Flujo:

Dashboard Final:

Ejercicio 04

Sobre el Ejercicio02, añadir de forma dinámica los umbrales máximos y mínimos de alerta mediante dos sliders en el dashboard.

También hacer que los valores de los colores del gauge cambien en función del valor de MAX y MIN introducido por los sliders

Opcionalmente mostrar los mensajes de alerta y los iconos:

  • Todo Correcto: <i class=”fa fa-lightbulb-o fa-2x nr-dashboard-ok”></i>
  • Temperatura Alta: <i class=”fa fa-warning fa-2x nr-dashboard-warning”></i>
  • Temperatura Baja: <i class=”fa fa-exclamation-circle fa-2x nr-dashboard-error”></i>

Para cambiar la configuración de los widgets de dashboard se usa mediante msg.ui_control como se indica aquí: https://github.com/node-red/node-red-dashboard/blob/master/config-fields.md 

En este caso uso un nodo change donde borro payload y pongo las propiedades msg.ui_control.seg1 y msg.ui_control.seg2 a los valores almacenados en las variables de contexto.

Por último no dejar que el valor MIN sea mayor que MAX, ni que MAX sea menor que min en el dashboard, para ello controlar el valor de MIN y MAX al cambiar con un nodo switch y tomar la decisión a hacer.

Código: https://github.com/aprendiendonodered/ejercicio06.git 

Vídeos:

Ejercicio 05

Hacer un dashboard para controlar los wemos D1 Mini con el firmware instalado en el curso: https://aprendiendoarduino.wordpress.com/2021/02/20/mqtt-y-esp8266/

El Dashboard tendrá:

  • Un gauge y una gráfica indicando la temperatura de la sonda DS18B20
  • Un pulsador para encender y apagar el led del Wemos D1 Mini
  • Un pulsador para encender y apagar el relé
  • Un Input text o un formulario para mandar mensajes a la pantalla oled
  • Un slider para encender los 8 niveles de la matriz led.

Código: https://github.com/aprendiendonodered/ejercicio11 

Vídeo Youtube:

Flujo:

Dashboard:

Ejercicio 6 – Seguridad

Poner un pin para encender los Reles, de forma que si no hay pin no se puede encender desde el dashboard. Simular una cerradura de forma que al poner el pin correcto se abre y luego a los 5 segundos se cierra.

Mostrar en el dashboard el estado de la cerradura.

Crear un flujo nuevo en el dashboard llamado pin de seguridad

Basarse en el flujo:

Hacer el flujo como un subflow.

Dashboard

Flujo

Subflow

Código:

Ejercicio 7 – Email y SMS

Hacer un formulario en el dashboard para mandar un correo electrónico y otro para mandar un SMS usando el servicio de Twilio: https://www.twilio.com/

Dashboard

Flujo

Código: https://github.com/jecrespo/Curso-Node-RED/blob/master/04-Ejercicio%20Final/Ejercicio_4/Ejercicio_4.json

Ejercicio 8 – Mapa de Terremotos

Basándose en este flow: https://nodered.org/docs/tutorials/second-flow, hacer un mapa del mundo mostrando los terremotos actuales.

Usar el nodo worldmap: https://flows.nodered.org/node/node-red-contrib-web-worldmap 

Repositorio: https://github.com/aprendiendonodered/EJERCICIO27_Mapa_Terremotos.git

Ejercicio 9 – OwnTracks

Instalar la aplicación owntracks en un móvil: https://owntracks.org/

Configurar un broker MQTT público y que comience a transmitir datos:

  • Host: aprendiendonodered.com
  • Port: 8883
  • username: owntracks
  • Topic: owntracks/#

Programar un dashboard de worldmap y mostrar la posición y el track de los datos que mandamos por MQTT desde la app owntracks.

Adicionalmente guardar los datos en una BBDD InfluxDB. Hay un bucket en enriquecrespo.com llamado owntracks para guardar estos datos.

Repositorio: https://github.com/aprendiendonodered/EJERCICIO30_OWN_TRACKS

Ejercicio 10 – Open Weather Map

Usando el nodo de OpenWeatherMap, hacer un dashboard con la temperatura, humedad y presión donde se actualice el dato en un gauge y se haga una gráfica que muestre los últimos 7 días.

Mandar el dato de la temperatura por MQTT al topic “cursomqtt/raspberrypixx/temperatura”.

Hacer un botón para que mande la predicción de los próximos 5 días al correo electrónico.

Dashboard

Flujo

Código: https://github.com/jecrespo/Curso-Node-RED/blob/master/04-Ejercicio%20Final/Ejercicio_7/Ejercicio_7.json

MQTT y Node-RED

Node-RED y MQTT con Wemos D1 Mini

Capturar los datos mandados por los nodos remotos por MQTT.

Sólo tienes que arrastrar el nodo mqtt que está en la categoría input al flujo.

sistema alarma node-red

Ahora hay que configurarlo. Aquí es donde vemos la potencia de Node-RED. En el caso de MQTT lo único que tenemos que hacer es configurar el broker y el topic.

Al tratarse de un nodo de entrada, lo que hace es recibir los mensajes publicados en un topic es decir, se suscribe al topic. Haz doble click sobre el nodo para que abra el panel de configuración.

En el panel de configuración MQTT vamos a configurar primero el broker MQTT. Haz click en el lápiz que aparece en Server.

sistema alarma node-red

Esto abre un nuevo panel de configuración. Pon un nombre al broker MQTT por ejemplo RASPBERRY PI MOSQUITTO. En Server tienes que poner la IP donde está instalado el broker MQTT y el puerto que utiliza, normalmente es el 1883.

Esta sería la configuración mínima. No te olvides de hacer click en el botón Add.

sistema alarma node-red

Después de esta acción volverás al panel de configuración del nodo mqtt y automáticamente, habrá seleccionado el broker MQTT que acabamos de crear.

Por último, vamos a rellenar el campo de Topic. Debe ser el mismo que hemos puesto en Arduino o el ESP8266, /casa/puerta/alarma. Una vez lo tengas, haz click en Done.

sistema alarma node-red

Ahora sólo nos queda probarlo. Para ello vamos a utilizar el mismo nodo debug de la categoría output que hemos utilizado antes.

Arrástralo al flujo, conecta los dos nodos y haz click en el botón Deploy.

sistema alarma node-red

Para probar el sistema lo podemos hacer de dos formas. Desde una terminal de Raspberry Pi podemos publicar un mensaje en el topic o directamente conectando la placa y simulando que abren la puerta.

El resultado sería el siguiente.

sistema alarma node-red

Otro ejemplo mucho más completo con Lego: http://www.internetoflego.com/lego-train-automation-wifi-controlled-nodemcu-esp8266/ 

Cargar Datos de Raspberry Pi a MQTT

Mandar cada 10 segundos los datos de CPU, Memoria y temperatura de la Raspberry Pi por MQTT al topic: cursomqtt/raspberrypixx/{CPU/Memoria/Temperatura}

Código para obtener los datos de Raspberry Pi, usando en nodo exec: 

[{"id":"af22b399.12614","type":"exec","z":"8a81314e.a0f79","command":"vcgencmd measure_temp","addpay":false,"append":"","useSpawn":"","timer":"","name":"RPi Temp.","x":325.2221908569336,"y":46.33333683013916,"wires":[["14f0a295.59181d"],[],[]]},{"id":"408435c9.447fec","type":"exec","z":"8a81314e.a0f79","command":"top -d 0.5 -b -n2 | grep \"Cpu(s)\"|tail -n 1 | awk '{print $2 + $4}'","addpay":false,"append":"","useSpawn":"","timer":"","name":"CPU Load","x":325.2221908569336,"y":126.33333683013916,"wires":[["2c7475c7.6cc01a"],[],[]]},{"id":"8fbcbdf9.549b7","type":"exec","z":"8a81314e.a0f79","command":"free | grep Mem | awk '{print 100*($4+$6+$7)/$2}'","addpay":false,"append":"","useSpawn":"","timer":"","name":"Free Memory","x":325.2222099304199,"y":190.55557250976562,"wires":[["daf6433c.bad81"],[],[]]},{"id":"14f0a295.59181d","type":"function","z":"8a81314e.a0f79","name":"","func":"str = msg.payload\nmsg.payload = str.substring(5,9);\nreturn msg;","outputs":1,"noerr":0,"x":471.888858795166,"y":33.00000190734863,"wires":[["46daa272.4333ac","334a9ddd.345602"]]},{"id":"daf6433c.bad81","type":"function","z":"8a81314e.a0f79","name":"","func":"str = msg.payload\nmsg.payload = parseInt(str.substring(0,str.length - 1));\nreturn msg;","outputs":1,"noerr":0,"x":530,"y":180,"wires":[["1ba39571.ba75ab"]]}]

Flujo:

Ejemplo con Nodos Remotos

Vamos a usar los Wemos D1 mini, para integrarlos como nodos remotos y programarlos desde Node-RED.

Esquema:

Firmware de uso de cada shield:

El firmware para los nodos remotos:

Probar cada firmware y hacer un programa sencillo para interactuar con ellos.

Firmware de otros nodos remotos: https://github.com/jecrespo/Curso-Node-RED/tree/master/Remote%20Nodes%20Firmware/Firmware%20M5Stack%20Varios 

Completos tutoriales:

Topic Map

El topic map del firmware de los dispositivos es:

  • cursomqtt/nombre}/dato10s – publica mensaje numerado cada 10s
  • cursomqtt/{nombre}/dato60s – publica mensaje numerado cada 60s
  • cursomqtt/{nombre}/reset – publica mensaje cada reset o inicio
  • cursomqtt/{nombre}/led – suscrito (1 led ON, otro valor  led OFF)
  • cursomqtt/{nombre}/text – suscrito (muestra el mensaje por pantalla)
  • cursomqtt/{nombre}/rele – suscrito (1 relé ON, otro valor  relé OFF). Firmware relé
  • cursomqtt/wemos/oled – suscrito (muestra el mensaje por pantalla oled). Firmware oled
  • cursomqtt/{nombre}/temperatura – publica dato temperatura cada 10 segundos. Firmware DS18B20
  • cursomqtt/{nombre}/matrix – suscrito (0 efecto y apaga, de 1 a 8 ilumina de 1 a 8 líneas de matriz ). Firmware matrix.
  • cursomqtt/raspberrypi/{nombre}/CPU – publica Node-RED el datos de CPU 
  • cursomqtt/raspberrypi/{nombre}/Temperatura – publica Node-RED el datos de temperatura procesador
  • cursomqtt/raspberrypi/{nombre}/Memoria – publica Node-RED el datos de memoria libre
  • casa/wibeee/# – datos eléctricos de Wibeee
  • casa/m5atom/enrique/aviso – suscrito (“alarma” – leds rojos, “aviso” – leds amarillos, “ok” – leds verdes, otro mensaje apaga)
  • casa/m5atom/enrique/boton – al pulsar publica “press” o “longpress”
  • casa/m5stack/A – al pulsar botón A publica “press”
  • casa/m5stack/B – al pulsar botón B publica “press” 
  • casa/m5stack/C – al pulsar botón C publica “press”
  • casa/m5stack/led – suscrito (1 dibuja en pantalla círculo rojo, otro valor  dibuja en pantalla círculo verde)
  • casa/m5stack/text – suscrito, muestra por pantalla el texto
  • casa/m5stick/temperatura – publica dato temperatura cada 1 segundo
  • casa/m5stick/humedad – publica dato humedad cada 1 segundo
  • casa/m5stick/presion – publica dato presión cada 1 segundo
  • casa/m5stickplus/distancia – publica dato distancia cuando se activa
  • casa/m5stickplus/button – al pulsar botón publica “press”
  • casa/m5stickplus/led – suscrito (1 led ON, otro valor  led OFF)
  • casa/m5stickplus/label  – suscrito (“red” – circulo rojo, “yellow” – circulo amarillo, “green” – circulo verde, “black” – círculo verde)

Publicar en MQTT desde Node-RED

Publicar desde Node-RED en diversos topics para encender 

Cada firmware ya está configurado para solo configurar el topic donde va a publicar y el topic al que se suscribe:

  • RELE: Paso ON y OFF
  • OLED: Paso el string que va a mostrar por pantalla
  • LEDS: 7 topics donde paso el color en formato RGB y el brillo

Probar diferentes publicaciones en diferentes topics para encender/apagar los relés, encender/apagar leds y mandar mensajes a las pantallas.

Ejemplos a programar con Node-RED

  • Al leer una pulsación un botón de los M5stick, se enciende un relé.
  • Al superar una temperatura mandar un mensaje de alerta
  • Mandar a las pantallas oled los datos de CPU u otras mediciones
  • En función de la distancia encender más o menos leds de wemos
  • Cuando un nodo se desconecte mandar un mensaje a una pantalla

Consola MQTT en Dashboard

Instalar Dashboard de Node-RED: https://flows.nodered.org/node/node-red-dashboard

Crear un dashboard y un grupo.

Usar los siguientes nodos de Dashboard y añadir a los grupos:

  • gauge: para mostrar mediciones como la temperatura o la CPU
  • chart: para mostrar gráfica de mediciones
  • switch: para encender y apagar leds y reles
  • slider: para encender leds y aumentar la intensidad de los leds
  • text input: para mandar mensajes a las pantallas
  • text: para mostrar datos de topics

Protocolo MQTT

MQTT son las siglas de Message Queue Telemetry Transport y tras ellas se encuentra un protocolo ideado por IBM y liberado para que cualquiera podamos usarlo enfocado a la conectividad Machine-to-Machine (M2M).

Web: https://mqtt.org/ 

MQTT fue creado por el Dr. Andy Stanford-Clark de IBM y Arlen Nipper de Arcom — ahora Eurotech — en 1999 como una forma rentable y confiable de conectar los dispositivos de monitoreo utilizados en las industrias del petróleo y el gas a servidores empresariales remotos. Cuando se les planteó el reto de encontrar la manera de enviar los datos de los sensores de los oleoductos en el desierto a sistemas SCADA externos (control de supervisión y adquisición de datos), decidieron utilizar una topología de publicación/suscripción basada en TCP/IP que se basaría en los eventos para mantener bajos los costos de transmisión de los enlaces satelitales.

Aunque MQTTT todavía está estrechamente asociado con IBM, ahora es un protocolo abierto que es supervisado por la Organización para el Avance de los Estándares de Información Estructurada (OASIS).

Web: http://mqtt.org/ 

Está enfocado al envío de datos en aplicaciones donde se requiere muy poco ancho de banda. Además, sus características le permiten presumir de tener un consumo realmente bajo así como precisar de muy pocos recursos para su funcionamiento.

Estas características han hecho que rápidamente se convierta en un protocolo muy empleado en la comunicación de sensores y, consecuentemente, dentro del Internet de las Cosas.

MQTT es un protocolo pensado para IoT que está al mismo nivel que HTTP o CoAP:

Comparativa MQTT y CoAP:

Un aspecto importante a tener en cuenta de los dispositivos IoT no es solamente el poder enviar datos al Cloud/Servidor, sino también el poder comunicarse con el dispositivo, en definitiva la bidireccionalidad. Este es uno de los beneficios de MQTT: es un modelo brokered, el cliente abre una conexión de salida al bróker, aunque el dispositivo esté actuando como Publisher o subscriber. Esto normalmente evita los problemas con los firewalls porque funciona detrás de ellos o vía NAT.

Cómo funciona MQTT

En el caso de que la comunicación principal se base en HTTP, la solución tradicional para enviar información al dispositivo sería HTTP Polling. Esto es ineficiente y tiene un coste elevado en aspectos de tráfico y/o energía. Una manera más novedosa de hacerlo sería con el protocolo WebSocket, que permite crear una conexión HTTP completa bidireccional. Esto actúa de canal socket (parecido al canal típico TCP) entre el servidor y el cliente. Una vez establecido, ya es trabajo del sistema escoger un protocolo para hacer un túnel sobre la conexión.

El Transporte de telemetría de cola de mensajes (MQTT) es un protocolo de código abierto que se desarrolló y optimizó para dispositivos restringidos y redes de bajo ancho de banda, alta latencia o poco confiables. Es un transporte de mensajería de publicación/suscripción que es extremadamente ligero e ideal para conectar dispositivos pequeños a redes con ancho de banda mínimo. El MQTT es eficiente en términos de ancho de banda, independiente de los datos y tiene reconocimiento de sesión continua, porque usa TCP. Tiene la finalidad de minimizar los requerimientos de recursos del dispositivo y, a la vez, tratar de asegurar la confiabilidad y cierto grado de seguridad de entrega con calidad del servicio.

El MQTT se orienta a grandes redes de dispositivos pequeños que necesitan la supervisión o el control de un servidor de back-end en Internet. No está diseñado para la transferencia de dispositivo a dispositivo. Tampoco está diseñado para realizar «multidifusión» de datos a muchos receptores. El MQTT es simple y ofrece pocas opciones de control. Las aplicaciones que usan MQTT, por lo general, son lentas en el sentido de que la definición de «tiempo real» en este caso se mide habitualmente en segundos.

Para filtrar los mensajes que son enviados a cada cliente los mensajes se disponen en topics organizados jerárquicamente. Un cliente puede publicar un mensaje en un determinado topic. Otros clientes pueden suscribirse a este topic, y el broker le hará llegar los mensajes suscritos.

Los clientes inician una conexión TCP/IP con el broker, el cual mantiene un registro de los clientes conectados. Esta conexión se mantiene abierta hasta que el cliente la finaliza. Por defecto, MQTT emplea el puerto 1883 y el 8883 cuando funciona sobre TLS.

Para ello el cliente envía un mensaje CONNECT que contiene información necesaria (nombre de usuario, contraseña, client-id…). El broker responde con un mensaje CONNACK, que contiene el resultado de la conexión (aceptada, rechazada, etc).

Para enviar los mensajes el cliente emplea mensajes PUBLISH, que contienen el topic y el payload.

Para suscribirse o desuscribirse se emplean mensajes SUBSCRIBE y UNSUSCRIBE, que el servidor responde con SUBACK y UNSUBACK.

Por otro lado, para asegurar que la conexión está activa los clientes mandan periódicamente un mensaje PINGREQ que es respondido por el servidor con un PINGRESP. Finalmente, el cliente se desconecta enviando un mensaje de DISCONNECT.

Más información:

MQTT Protocolo para IoT

MQTT es un protocolo que está cobrando mucha importancia en la industria (IIoT). MQTT (Message Queuing Telemetry Transport, ‘Cola de mensajes telemetría y transporte’) es un protocolo publicar/suscribir diseñado para SCADA. Se centra en un mínimo encabezado (dos bytes) y comunicaciones confiables. También es muy simple. Tal como HTTP, la carga MQTT es específica para la aplicación, y la mayoría de las implementaciones usan un formato JSON personalizado o binario.

MQTT en PLCs: https://www.youtube.com/watch?v=aX20J-sLyKU 

Comparativa MQTT y Modbus: http://inubo.es/noticia/comparativa-entre-mqtt-y-modbus-como-protocolos-iot 

MQTT es interesante usarlo cuando el ancho de banda bajo y no conozca su infraestructura. Asegúrese de que su proveedor tenga un broker MQTT a quien le pueda publicar información, y siempre asegure la comunicación con TLS (Transport Layer Security, ‘seguridad en la capa de transporte’).

Por ejemplo, MQTT sería una buena opción para monitorizar y controlar los paneles solares. MQTT es un protocolo de publicación/suscripción con brokers de mensajes centrales. Cada panel solar puede contener un nodo IoT que publique mensajes de tensión, corriente y temperatura.

MQTT está diseñado para minimizar el ancho de banda, lo que lo convierte en una buena opción para el monitoreo satelital de la línea de transmisión, pero hay una trampa. La ausencia de metadatos en las cabeceras de los mensajes significa que la interpretación de los mensajes depende completamente del diseñador del sistema.

Para compensar las redes poco fiables, MQTT soporta tres niveles de Calidad de Servicio (QoS):

  • Disparar y olvidar (0) – Fire and Forget – At most once
  • Al menos una vez (1) – At least once
  • Exactamente una vez (2) – Exactly once

Si se solicita el nivel de calidad de servicio 1 ó 2, el protocolo gestiona la retransmisión de mensajes para garantizar la entrega. La calidad de servicio puede ser especificada por los clientes de publicación (cubre la transmisión del publicador al broker) y por los clientes suscriptores (cubre la transmisión de un broker a un suscriptor).

MQTT QoS 2 aumentará la latencia porque cada mensaje requiere dos handshake completos de ida y vuelta del remitente al receptor (cuatro en total del publicador al suscriptor).

En un patrón de publicación/suscripción es difícil saber la diferencia entre «Ha pasado mucho tiempo desde que supe de mi publicador» y «Mi publicador murió». Ahí es donde entra en juego la Última Voluntad y el Testamento (LWT) de MQTT. Los clientes pueden publicar mensajes sobre temas específicos (por ejemplo, aisle15/rack20/panel5/FalloSensor) para que se entreguen si se desconectan sin enviar un mensaje de «desconexión». Los mensajes se almacenan en el broker y se envían a cualquier persona que se haya suscrito al tema.

MQTT de un vistazo

  • Ancho de banda muy bajo
  • TCP/IP
  • Publicar/suscribir transferencia de mensajes
  • Topología de muchos a muchos a través de un broker central
  • Sin metadatos
  • Tres niveles de QoS
  • Última Voluntad y Testamento revela nodos desconectados

Las ventajas de usar el protocolo MQTT son:

  • Es asíncrono con diferentes niveles múltiples de calidad del servicio, lo que resulta ser importante en los casos donde las conexiones de Internet son poco confiables.
  • Envía mensajes cortos que se vuelven adecuados para las situaciones de un bajo ancho de banda.
  • No se requiere de mucho software para implementar a un cliente, lo cual lo vuelve fantástico para los dispositivos como Arduino con una memoria limitada.
  • Podemos cifrar los datos enviados y usar usuario y password para proteger nuestros envíos.

Si quisiera grabar en una BBDD con MQTT, un suscriptor a una serie de topics se encarga de grabar los datos cada vez que cambia un valor o cada cierto tiempo, por ejemplo con un script de python o ejecutando Node-RED en una máquina virtual o en el propio servidor (o Raspberry Pi) donde corre el broker (Mosquitto):

NodeRed no es más que un software que se instala en un nodo aunque se instale en el mismo servidor que el broker.

Cinco cosas a saber de MQTT: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en 

Buen artículo sobre MQTT: https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport 

Software MQTT: https://mqtt.org/software/ 

Recursos MQTT:

Para ampliar información de MQTT en Arduino y Raspberry Pi:

Buenos artículos de MQTT en español:

Arquitectura MQTT

MQTT (Message Queue Telemetry Transport), un protocolo usado para la comunicación machine-to-machine (M2M) en el «Internet of Things». Este protocolo está orientado a la comunicación de sensores, debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos (CPU, RAM, …).

Un ejemplo de uso de este protocolo es la aplicación de Facebook Messenger tanto para android y Iphone. La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de servidor o «broker». El broker es el encargado de gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes mandan periódicamente un paquete (PINGREQ) y esperan la respuesta del broker (PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.

En esta forma de comunicación se desacoplan los clientes que publican (Publisher) de los que consumen los datos (Suscribers). Eso significa que los clientes no se conocen entre ellos unos publican la información y otros simplemente la consumen, simplemente todos tienen que conocer al message broker.

El desacoplamiento se produce en tres dimensiones:

  • En el espacio: El publicador y el suscriptor no tienen porqué conocerse. No hace falta saber la dirección IP del contrario, ubicación, ni nada, el publicador manda el dato y lo entrega el broker. Muy interesante si cambio el equipo suscriptor de IP o de ubicación.
  • En el tiempo: El publicador y el suscriptor no tienen porqué estar conectados en el mismo momento. Como el email, que lee el dato publicado cuando el suscriptor está disponible, pero necesita el retained u otro método con persistencia de los admitidos por MQTT.
  • En la sincronización: las operaciones en cualquiera de los dos componentes no quedan interrumpidas mientras se publican o se reciben mensajes.

Es precisamente el broker el elemento encargado de gestionar la red y transmitir los mensajes.

Una característica interesante es la capacidad de MQTT para establecer comunicaciones cifradas lo que aporta a nuestra red una capa extra de seguridad.

MQTT server network Architecture: https://cirrus-link.com/mqtt-server-network-architecture/ 

  • Cloud – Hosted
  • Private – On Premise
  • Híbrido

Topics MQTT

La comunicación se basa en unos «topics» (temas), que el cliente que publica el mensaje crea y los nodos que deseen recibirlo deben suscribirse a él. La comunicación puede ser de uno a uno, o de uno a muchos.

Dentro de la arquitectura de MQTT, es muy importante el concepto «topic» o «tema» en español ya que a través de estos «topics» se articula la comunicación puesto que emisores y receptores deben estar suscritos a un «topic» común para poder entablar la comunicación. Este concepto es prácticamente el mismo que se emplea en colas, donde existen un publicadores (que publican o emiten información) y unos suscriptores (que reciben dicha información) siempre que ambas partes estén suscritas a la misma cola.

Los Broker MQTT aplican un filtrado a los mensajes que son recibidos desde los publicadores, para discriminar a qué clientes suscritos es entregado. En MQTT este filtro se denomina Topic, y simplemente consiste en una cadena de texto UTF-8, y una longitud máxima de 65536 caracteres (aunque lo normal es que sea mucho menor). Se distingue entre mayúsculas y minúsculas.

Este tipo de arquitecturas, lleva asociada otra interesante característica: la comunicación puede ser de uno a uno o de uno a muchos.

Un «topic» se representa mediante una cadena y tiene una estructura jerárquica. Cada jerarquía se separa con ‘/’.

Por ejemplo, «edificio1/planta5/sala1/raspberry2/temperatura» o «/edificio3/planta0/sala3/arduino4/ruido«. De esta forma se pueden crear jerarquías de clientes que publican y reciben datos, como podemos ver en la imagen:

De esta forma un nodo puede subscribirse a un «topic» concreto («edificio1/planta2/sala0/arduino0/temperatura»)  o  a varios («edificio1/planta2/#»).

El funcionamiento de los Topcis en MQTT es sencillo y transparente. Por un lado el Broker acepta todos los Topics. No es necesario crearlo explícitamente antes de publicar o suscribirse al Broker. Los clientes pueden suscribirse a uno o varios Topic. Para ello, el cliente puede establecer varias suscripciones y/o emplear Wildcards.

Finalmente, los clientes publican mensajes indicando un único Topic. El Broker recibe el mensaje y, si encuentra alguna suscripción que cumpla con el filtro del Topic, transmite el mensaje a los clientes suscritos.

Un broker no necesita mantener una lista de los temas a los que se han publicado los mensajes, sólo comprueba la lista de temas a los que está suscrito cada cliente cuando llega un mensaje.

Un topics especiales son los topics de sistema, que son aquello que publica el propio broker para mandar información de su estado. Estos están bajo la jerarquía de $SYS: https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics

Existen dos comodines en MQTT para suscribirse a varios topics (no se pueden usar para publicar):

  • Multi-level Wildcard: # (se suscribe a todos los hijos bajo esa cola)
  • Single Level Wildcard: + (se suscribe solo a ese nivel)

No se puede publicar con wildcards:

Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier suscripción de root wild card. Normalmente, el $ se utiliza para transportar mensajes específicos del servidor o del sistema.

Ejemplos de Topics MQTT Válidos:

  • casa/prueba/topic
  • casa/+/topic
  • casa/#
  • casa/+/+
  • +/#
  • #

Explicación del comodín de single level:

Entender los topics de MQTT: http://www.steves-internet-guide.com/understanding-mqtt-topics/

Diseño de Estructura de Topics

El éxito de un sistema de IoT depende enormemente de la arquitectura que diseñemos para la mensajería. En el caso de MQTT es esencial planear y organizar los Topic que vamos a emplear en el proyecto.

Es importante diseñar el sistema de Topics para que sea ampliable y mantenible. Queremos poder añadir más dispositivos a nuestra red o nuevas funcionalidades, y evitar darnos cuenta en el futuro de que el sistema que elegimos es insuficiente.

Mantener los Topic lo más pequeños y claros posible. Un topic debe dar la información clara del dato que publica. Es recomendable usar Topics lo más específicos posibles, evitando enviar mensajes a varios dispositivos y discriminar por el contenido del mensaje.

Emplear únicamente caracteres ASCII estándar en los topics, evitando caracteres especiales e incluso espacios. Esto hará más sencillo la interpretación de Topics desde los dispositivos, y la interoperabilidad entre lenguajes de programación y dispositivos.

En el caso de grandes estructuras de dispositivos o conectividad entre aplicaciones, el siguiente esquema de división de Topics funciona muy bien en múltiples aplicaciones: 

protocol_prefix/src_id/dest_id/message_id/extra_properties

  • protocol_prefix se usa para diferenciar entre diferentes protocolos/aplicaciones que se pueden usar al mismo tiempo
  • src_id es el ID del cliente mqtt que publica el mensaje. Se espera que sea el mismo que el «ID de cliente» que se usa para conectarse al broker MQTT. Permite un control rápido de ACL para verificar si el cliente puede publicar un tema específico.
  • dest_id es el ID de cliente de la unidad de «destino», es decir, a quién está destinado el mensaje. También permite un control rápido de ACL en el broker para determinar si el cliente puede suscribirse a un tema en particular. Puede haber topics de «destino» reservados para especificar que el mensaje se transmite a cualquier interesado. Por ejemplo el topic “todos”.
  • message_id es el ID real del mensaje dentro del protocolo utilizado. Por lo general, usa un valor numérico (como una cadena, por supuesto), porque el dispositivo IoT u otro sistema embebido que está conectado al broker MQTT puede tener otros enlaces de E/S y usar el mismo protocolo (pero con un marco de transporte diferente) para controlar el dispositivo utilizando estos otros enlaces de E/S. Usualmente usar ID de mensajes numéricos en tales enlaces de comunicación.
  • extra_properties es un subtema opcional que se puede utilizar para comunicar otra información adicional específica de MQTT (por ejemplo, pares clave=valor separados por comas). Un buen ejemplo sería informar la marca de tiempo del mensaje cuando realmente fue enviado por el cliente. En el caso de mensajes «retenidos», puede ayudar a identificar la relevancia del mensaje recibido. Con el protocolo MQTTv5, la necesidad de este subtema puede desaparecer porque habrá otra forma de comunicar propiedades adicionales.

En otros casos para dispositivos IoT que queramos controlar, el dispositivo (dev) podría suscribirse (sub) al tema de control y publicar (pub) al tema de estado.:

  • pub: clients/dev/dev_id/status
  • sub: clients/dev/dev_id/control

De esta manera, la lógica sub, pub es muy simple tanto para clientes como para dispositivos.

Más información: https://www.luisllamas.es/que-son-y-como-usar-los-topics-en-mqtt-correctamente/ 

Escalado MQTT 

MQTT me permite gran escalabilidad. Añadir un nuevo Arduino o un suscriptor es muy sencillo dentro de la jerarquía vista

Con escalable me refiero a la capacidad que tiene un sistema para ser ampliado. Los sistemas de sensores en general, particularmente en nuestro caso hablamos del mundillo del Internet de las Cosas, se caracterizan por enviar muchos datos de pequeño tamaño en tiempo real ya que hay muchos sensores transmitiendo simultáneamente y cada breves periodos de tiempo, cuya información necesita ser consumida por otros elementos en tiempo real.

En una Arquitectura basada en Broker es fundamental evitar el SPOF (punto único de fallo). 

En el contexto MQTT hay 2 estrategias principales:

  • Bridging: hace forward de mensajes a otro bróker MQTT. Es la solución de HiveMQ, Mosquitto, IBM MQ
  • Clustering: soportando el añadido dinámico de nodos al cluster. Lo usa ActiveMQ, HiveMQ o RabbitMQ.

Cuando un sistema de estas características se empieza a saturar se bloquean las comunicaciones y se pierde la característica de «tiempo real».

Hasta ahora, todos los sistemas que habíamos visto se basaban en un cliente que se comunicaba con un servidor. Si cualquier cliente se intenta comunicar con un servidor que está procesando tanta información que, en ese momento, no es capaz de trabajar con más contenido, el sistema entero fallará, o bien porque se satura y bloquea a nivel global o porque empieza a descartar aquella información que no puede procesar (lo que es inadmisible en muchos caso, imagina una alarma de Riesgo de Explosión en tu cocina porque se ha detectado una fuga de gas…).

Existen varias formas de abordar esta problemática pero, a día de hoy, una de las más empleadas es usar sistemas de colas donde se deja toda la información y el encargado de procesarla va «sacando» de esta cola la información. De esta manera, si ponemos más «encargados de procesamiento» son capaces de vaciar más rápido la cola si viésemos que está se está empezando a llenar y, de cara a los sensores, no sería necesario hacer ningún cambio, ya que ellos siempre envían al mismo sitio.

MQTT no hace exactamente lo mismo ya que, para empezar, no hay colas sino «topics» pero la filosofía es muy parecida, permitiendo a grandes sistemas operar con total fluidez y, junto con sus optimizaciones que buscan entre otras cosas reducir consumos y tamaños de trama para poder operar en elementos embebidos, es el motivo por el que es un protocolo tan empleado en comunicaciones M2M.

Además, nos permite una gestión de la seguridad razonablemente sencilla que facilita que nuestros sistemas se comporten de una forma más robusta.

MQTT será el nexo entre hardware (sensor) y todos los elementos típicos del mundo software (servidores, bases de datos, Big Data). En esta capa nos preocupamos de que la información llegue a un sistema que posteriormente se ocupa de distribuirlo entre las demás partes y nos da igual lo que haya a partir de ese momento y su tamaño. Puede que no tengamos nada más que una web de visualización o puede que tengamos un complejo sistema de Machine Learning y Big Data. Puede que seamos un particular enviando un dato de temperatura a un panel de visualización en su Raspberry o puede que seamos una multinacional que controla en tiempo real su producción de amoniaco a nivel global bajando y subiendo la carga de producción en sus diferentes fábricas según los costes de transporte y el consumo de sus diferentes centros de distribución. Nos es lo mismo a este nivel porque nosotros hacemos sólo una cosa y la hacemos bien: enviar datos de un dispositivo hardware a un sistema mucho mayor. Es lo que se llama microservicios que ha popularizado netflix (http://enmilocalfunciona.io/arquitectura-microservicios-1/

Interesante artículo a la hora de usar MQTT sobre la escalibilidad: https://www.iotforall.com/mqtt-broker-iot-scalability/

Las cargas de la plataforma basada en MQTT aumentan en n al cuadrado. Por ejemplo, supongamos un escenario extremo en el que hay dos clientes en los que cada uno se suscribe a todos los temas posibles. Cuando un cliente publica un mensaje, el broker necesita recibir un mensaje y otro cliente también necesita recibir el mensaje. Esto significa que un mensaje enviado podría resultar en dos transmisiones. Lo mismo ocurre con el otro cliente, por lo que son cuatro mensajes en total para un sistema de dos clientes.

Para un sistema de tres clientes, este número se convierte en nueve mensajes en total (es decir, tres mensajes por cliente). El simple hecho de tener 10 dispositivos conectados significa que el intermediario de mensajes debe ser capaz de manejar 10*10 (es decir, 100 mensajes, etc.).

Cuando la cantidad de clientes MQTT comience a crecer, la carga en el broker de mensajes, el sistema general y la plataforma crecerán casi exponencialmente.

Siempre tener esto en cuenta cuando escale cualquier plataforma IoT que se base en MQTT en las etapas posteriores o agregue más dispositivos.

Protocolo MQTT

MQTT está diseñado para requerir una sobrecarga mínima del protocolo para cada paquete con el fin de preservar el ancho de banda para los dispositivos embebidos con recursos limitados. Es un marco de trabajo realmente sencillo para la gestión de redes mesh de dispositivos habilitados para TCP.

Los mensajes MQTT se entregan asincrónicamente («push») a través de la arquitectura publish subscribe. El protocolo MQTTT funciona intercambiando una serie de paquetes de control MQTT de una manera definida. Cada paquete de control tiene un propósito específico y cada bit del paquete se crea cuidadosamente para reducir los datos transmitidos a través de la red. 

Publish and subscribe:

MQTT specificaction: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html 

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 TCP/IP con el broker utilizando 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 puede continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada.

Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor.

MQTT es llamado un protocolo ligero porque todos sus mensajes tienen una pequeña huella de código. Cada mensaje consta de una cabecera fija, una cabecera variable opcional, una carga útil de mensaje limitada a 256 MB de información y un nivel de calidad de servicio (QoS).

MQTTT soporta BLOBS (Binary Large Object) de mensajes de hasta 256 MB de tamaño. El formato del contenido es específico de la aplicación. Las suscripciones de temas se realizan utilizando un par de paquetes SUBSCRIBE/SUBACK. La anulación de la suscripción se realiza de forma similar utilizando un par de paquetes UNSUBSCRIBE/UNSUBACK.

Durante la fase de comunicación, el cliente puede realizar operaciones de publicación, suscripción, cancelación (unsuscribe) y ping. La operación de publicación envía un bloque binario de datos, el contenido, a un topic  definido por el publisher.

La operación de ping al servidor del broker usando una secuencia de paquetes PINGREQ/PINGRESP, que se usa para saber si está viva la conexión. Esta operación no tiene otra función que la de mantener una conexión en vivo y asegurar que la conexión TCP no ha sido apagada por una pasarela o un router.

Cuando un publicador o suscriptor desea finalizar una sesión MQTT, envía un mensaje DISCONNECT al broker y, a continuación, cierra la conexión. Esto se denomina “graceful shutdown” porque le da al cliente la posibilidad de volver a conectarse fácilmente al proporcionarle su identidad de cliente y reanudar el proceso donde lo dejó.

Si la desconexión ocurre repentinamente sin tiempo para que un publisher envíe un mensaje DISCONNECT, el broker puede enviar a los suscriptores un mensaje del publisher que el broker ha almacenado previamente en caché. El mensaje, que se llama testamento, proporciona a los suscriptores instrucciones sobre qué hacer si el editor muere inesperadamente.

MQTT tiene 14 tipos de mensajes, normalmente un usuario sólo usa los mensajes de CONNECT, PUBLISH, SUBSCRIBE Y UNSUBSCRIBE. Si queréis conocer los tipos de mensajes podéis consultarlos en: https://dzone.com/refcardz/getting-started-with-mqtt

El identificador de cliente (ClientId) identifica a cada cliente MQTT que se conecta a un broker MQTT. El broker usa el ClientID para identificar al cliente y el estado actual del cliente. Por lo tanto, este ID debe ser único por cliente y broker. En MQTT 3.1.1, puede enviar un ClientId vacío, si no necesita que el broker mantenga un estado. El ClientId vacío da como resultado una conexión sin ningún estado. En este caso, el indicador “clean session” debe establecerse en verdadero o el broke rechazará la conexión.

El parámetro de ClientId es muy importante cuando queremos tener persistencia en datos y que el cliente pueda recuperar datos no obtenidos mientras estaba desconectado, usado junto la QoS2.

Recordar que cada cliente que se conecte a un broker debe tener un ClientId diferente.

Glosario MQTT: https://www.hivemq.com/mqtt/ 

Más información: https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport 

Para saber más sobre el protocolo MQTT y aplicaciones:

MQTT V5

MQTT se ha convertido en un protocolo popular para conectar dispositivos de Internet de las cosas (IoT) a la nube. MQTT se desarrolló originalmente en 1999 para monitorear oleoductos y oleoductos a través de redes satelitales. En ese momento, la necesidad era un protocolo que fuera eficiente para dispositivos remotos con fuentes de energía limitadas, que tuviera un uso eficiente del ancho de banda y que pudiera operar a través de conexiones de red poco confiables. Cuando se desarrolló MQTT, el término IoT no se había acuñado, la computación en la nube no existía y el conjunto diverso de aplicaciones para IoT no había surgido.

Por estos motivos, era necesario actualizar el protocolo MQTT para abordar algunas de las características faltantes necesarias para alojar MQTT en plataformas en la nube a gran escala y para manejar aplicaciones IoT adicionales. En 2015/2016, se comenzó a trabajar dentro de OASIS en una nueva versión de la especificación, denominada MQTT 5. En marzo de 2019, MQTT 5 fue ratificado como estándar oficial de OASIS.

Mosquitto soporta MQTT V5 

Hay 5 características clave que mejoran el manejo de errores, la escalabilidad y la flexibilidad del despliegue de los sistemas MQTT:

  • Sesión y caducidad del mensaje: MQTT 5 permite ahora que cada sesión y mensaje especifique un límite de tiempo. Si un mensaje no se entrega en un período de tiempo determinado, se borrará. Esto puede ser muy importante para los casos de uso crítico de seguridad si un mensaje necesita llegar dentro de un cierto período de tiempo.
  • Suscripciones compartidas: Las suscripciones compartidas permiten que varias instancias del cliente MQTT compartan las suscripciones del mismo tema de un broker MQTT. Esta característica es muy útil si un cliente MQTT ha sido configurado para transmitir datos MQTT en un sistema empresarial back-end, como una base de datos. Diferentes clientes MQTT que comparten las mismas suscripciones pueden ser desplegados a través de diferentes nodos del clúster para ayudar con la escalabilidad y la alta disponibilidad.
  • Reconocimientos negativos: Un broker MQTT que soporta MQTT 5 puede ahora enviar lo que se llama un acuse de recibo negativo para rechazar ciertos tipos de mensajes, tales como la máxima calidad de servicio, el tamaño máximo de los mensajes y las características no soportadas en el broker. El rechazo de un mensaje que excede el tamaño máximo del mensaje es útil para identificar a los clientes MQTT que podrían haberse convertido en maliciosos.
  • Indicadores de formato de carga útil (Payload): MQTT siempre ha sido agnóstico en cuanto a la carga útil, pero MQTT 5 ahora permite la adición de indicadores de formato de carga útil, valores binarios o texto. Esto facilitará el procesamiento del mensaje MQTT.
  • Propiedades del usuario: Además de los indicadores de formato de carga útil, los mensajes MQTT 5 pueden ahora incluir propiedades de usuario que añaden una propiedad clave-valor al encabezamiento del mensaje. Estas propiedades permiten que se añada información específica de la aplicación a cada cabecera de mensaje.

Aspectos más relevantes en MQTT V5:

  • Clean Sessions pasa a llamarse Clean Start y además al poner clean start a falso, debe darse un “session expiry value”, en caso contrario es 0 y se comporta como siempre. Más información en http://www.steves-internet-guide.com/mqttv5-clean-start-clean-sessions-and-session-expiry/ 
  • Restricción de tamaño de mensaje en cliente. El cliente le dice al servidor el tamaño máximo del mensaje
  • Se puede especificar un delay del envío de mensaje de ultimo deseo (will message) para que no mande mensajes el microcortes
  • Propiedades de usuario: http://www.steves-internet-guide.com/examining-mqttv5-user-properties/, se manda información fuera del payload con información del usuario en formato json. Está disponible en todos los mensajes, incluidos los de acknoledge
  • Server Redirect, en la conexión permite al servidor redireccionar a otro broker.
  • Expiración de mensajes. Se puede establecer un periodo máximo de retención de un mensaje en el broker.
  • Indicador de formato de payload: binary o utf-8
  • Topic aliases: http://www.steves-internet-guide.com/mqttv5-topics-aliases/ 
  • Request/Response: http://www.steves-internet-guide.com/mqttv5-request-response/, básicamente en el mensaje de publicación, indica al que recibe en que topic debe mandar la respuesta, dando así una información del cliente que publica.
  • Non Local Publishing, si se usa esta opción el broker no mandará los mensajes del topic al que mandas si también estás suscrito. Es una opción de suscripción.
  • Suscripciones compartidas, se usar el topic reservado $SHARE y se usa para balanceo de carga, de forma que los clientes suscritos a ese topic compartido no lo reciben todos sino de forma alternativa: http://www.steves-internet-guide.com/mqttv5-shared-subscriptions/
  • Reason Codes en todos los mensajes de ACK excepto PINGRESP

Diferencias entre MQTT versión 3 y versión 5:

Calidad de Servicio MQTT (QoS)

Al enviar mensajes MQTT existe la posibilidad de que los mensajes no lleguen al destinatario.

El envío de mensajes sin saber con seguridad que fueron recibidos se llama «QoS 0» (cero).

Es posible que también desee QoS 1, que le permite saber que el mensaje fue recibido. Básicamente, después de cada publicación, el suscriptor dice «OK». En el lenguaje MQTT se llama «PUBACK» (Reconocimiento de publicación).

También está QoS 2, que no sólo garantiza que su mensaje fue recibido, sino que sólo fue recibido una vez. Esto es un poco más complejo porque necesitas empezar a rastrear los IDs de los paquetes, así que lo dejaremos para más adelante.

Usar un nivel u otro depende de las características y necesidades de fiabilidad de nuestro sistema. Lógicamente, un nivel de QoS superior requiere un mayor intercambio mayor de mensajes de verificación con el cliente y, por tanto, mayor carga al sistema.

Los niveles de calidad de servicio (QoS) determinan cómo se entrega cada mensaje MQTT y deben especificarse para cada mensaje enviado a través de MQTT. Es importante elegir el valor de QoS adecuado para cada mensaje, ya que este valor determina la forma en que el cliente y el servidor se comunican para entregar el mensaje. Con el uso de MQTT se podrían lograr tres niveles de calidad de servicio para la entrega de mensajes:

  • QoS 0 (A lo sumo una vez – at most once) – donde los mensajes se entregan de acuerdo con los mejores esfuerzos del entorno operativo. Puede haber pérdida de mensajes. Confía en la fiabilidad del TCP. No se hacen retransmisiones.
  • QoS 1 (Al menos una vez – at least once) – donde se asegura que los mensajes lleguen, pero se pueden producir duplicados. El Receiver recibe el mensaje por lo menos una vez. Si el receiver no confirma la recepción del mensaje o se pierde en el camino el sender reenvía el mensaje hasta que recibe por lo menos una confirmación. Pueden duplicarse mensajes.
  • QoS 2 (Exactamente una vez – exactly once) – donde se asegura que el mensaje llegue exactamente una vez. Eso incrementa la sobrecarga en la comunicación pero es la mejor opción cuando la duplicación de un mensaje no es aceptable.

Existe una regla simple cuando se considera el impacto del rendimiento de la QoS. Es «Cuanto mayor sea la QoS, menor será el rendimiento«. MQTT proporciona flexibilidad a los dispositivos de IoT para elegir la calidad de servicio apropiada que necesitarían para sus requisitos funcionales y ambientales.

Entender QoS

Entender QoS MQTT: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

Sesiones persistentes: https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/

Para que el broker mantenga/retenga los mensajes publicados para el cliente, si este está momentáneamente desconectado, ocurre cuando un mensaje es publicado con QoS 1 o 2 y el cliente que recibe comple estas condiciones:

  • Conectado con clean session a falso
  • Suscrito con QoS 1 o 2

Desde la V5 de MQTT se puede establecer un expiry interval para que no se retengan los mensajes de forma indefinida en el broker.

Cuando habla de QoS en MQTT, deben considerar los dos lados de la entrega de mensajes:

  • Envío de mensajes desde el cliente de publicación al broker.
  • Entrega de mensajes del broker al cliente suscriptor.

Examinaremos los dos lados de la entrega del mensaje por separado porque existen diferencias sutiles entre los dos. El cliente que publica el mensaje para el broker define el nivel de QoS del mensaje cuando envía el mensaje al broker. El broker transmite este mensaje a los clientes suscriptores utilizando el nivel de calidad del servicio que cada cliente suscriptor define durante el proceso de suscripción. Si el cliente suscriptor define una QoS más baja que el cliente de publicación, el broker transmite el mensaje con la calidad de servicio más baja.

Todos los mensajes enviados con QoS 1 y 2 se ponen en cola para clientes sin conexión hasta que el cliente vuelve a estar disponible. Sin embargo, esta cola solo es posible si el cliente tiene una sesión persistente. Solo el cliente puede solicitar una sesión persistente cuando se conecta al broker (clean session es false)

Las sesiones persistentes guardan toda la información relevante para el cliente en el broker. El ID de cliente que proporciona el cliente cuando establece la conexión con el broker identifica la sesión.

En una sesión persistente, el broker almacena la siguiente información (incluso si el cliente está fuera de línea). Cuando el cliente se vuelve a conectar, la información está disponible de inmediato.

  • Existencia de una sesión (incluso si no hay suscripciones).
  • Todas las suscripciones del cliente.
  • Todos los mensajes en un flujo de calidad de servicio (QoS) 1 o 2 que el cliente aún no ha confirmado.
  • Todos los mensajes nuevos de QoS 1 o 2 que el cliente perdió mientras estaba desconectado.
  • Todos los mensajes de QoS 2 recibidos del cliente que aún no se han reconocido por completo.

Cuando el cliente se conecta al broker, puede solicitar una sesión persistente. El cliente usa un indicador cleanSession para decirle al intermediario qué tipo de sesión necesita.

Cuando el indicador de cleanSession se establece en falso, el broker crea una sesión persistente para el cliente. Toda la información y los mensajes se conservan hasta la próxima vez que el cliente solicite una sesión limpia. Si el indicador de sesión limpia se establece en falso y el broker ya tiene una sesión disponible para el cliente, utiliza la sesión existente y entrega los mensajes previamente en cola al cliente.

Al igual que el broker, cada cliente MQTT también debe almacenar una sesión persistente. Cuando un cliente solicita al servidor que contenga datos de sesión, el cliente es responsable de almacenar la siguiente información:

  • Todos los mensajes en un flujo de QoS 1 o 2, que aún no han sido confirmados por el broker.
  • Todos los mensajes de QoS 2 recibidos del intermediario que aún no se han reconocido por completo.

Por lo tanto para que haya una persistencia lo debe solicitar el suscriptor y el publicador debe mandar con una QoS 1 o 2.

MQTT Clean Session:

Último deseo y Testamento (MQTT LWT)

Un cliente puede establecer un mensaje Last Will and Testament (LWT) en el momento en el que se conecta con el Broker MQTT. Si el cliente no desconecta correctamente el Broker envía el mensaje LWT.

Cuando un cliente MQTT se conecta al servidor MQTT puede definir un tema y un mensaje que necesita ser publicado automáticamente sobre ese tema cuando se desconecta inesperadamente. Esto también se llama «Ultima voluntad y testamento» (LWT). Cuando el cliente se desconecta inesperadamente, el temporizador keep alive del lado del servidor detecta que el cliente no ha enviado ningún mensaje o el PINGREQ keep alive. Por lo tanto, el servidor publica inmediatamente el mensaje Will en el tema Will especificado por el cliente.

La función LWT puede ser útil en algunos escenarios. Por ejemplo, para un cliente MQTT remoto, esta función se puede utilizar para detectar cuando los dispositivos IoT salen de la red. La función LWT se puede utilizar para crear notificaciones para una aplicación que esté supervisando la actividad del cliente.

Paquete:

Ver explicación completa en: https://learn.adafruit.com/mqtt-adafruit-io-and-you/qos-and-wills 

Más información: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en 

Mensajes con Retención

Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.

Normalmente, si se envía un mensaje sobre un topic y nadie está suscrito a ese tema, el mensaje es simplemente descartado por el broker. Sin embargo, el publisher puede decirle al broker que mantenga el último mensaje en ese tema fijando el indicador de mensaje retenido.

Esto puede ser muy útil, como por ejemplo, si tiene un sensor que publica su estado sólo cuando se cambia, por ejemplo, el sensor de puerta. ¿Qué sucede si un nuevo suscriptor se suscribe a este estado?. Sin los mensajes retenidos, el suscriptor tendría que esperar a que el estado cambie antes de recibir un mensaje, sin embargo, con el mensaje retenido, el suscriptor vería el estado actual del sensor.

Lo que es importante entender es que sólo se retiene un mensaje por topic, el siguiente mensaje publicado sobre ese tema reemplaza al último mensaje retenido para ese tema.

NOTA: Si no usas clean sessions, entonces podrías ver mensajes que han sido almacenados pero no retenidos.

Tabla resumen:

Más información:

Otros Conceptos MQTT

  • Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.
  • Cuando un cliente conecta con el Broker puede solicitar que la sesión sea persistente (clean session = false), en ese caso el Broker almacena todas las suscripciones del cliente, todos los mensajes QoS 1 y 2 no procesados o perdidos por el cliente
  • Un mensaje MQTT CONNECT contiene un valor keepAlive en segundos donde el cliente establece el máximo tiempo de espera entre intercambio de mensajes

Seguridad MQTT

Ya sabemos lo importante que es la seguridad, y más en escenarios IoT en el que comunican objetos entre sí.  MQTT confía en tecnologías estándares para esto:

  • Autenticación usuario/Password
  • Seguridad SSL/TLS
  • ACLs

Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor. El cliente también puede proporcionar un certificado de cliente al broker durante el handshake, que el broker puede utilizar para autenticar al cliente. Aunque no forma parte específica de la especificación MQTT, se ha convertido en habitual que los broker admitan la autenticación de clientes con certificados SSL/TLS del lado del cliente.

Dado que el protocolo MQTTT pretende ser un protocolo para dispositivos con recursos limitados y de IoT, el SSL/TLS puede no ser siempre una opción y, en algunos casos, puede no ser deseable. En estos casos, la autenticación se presenta como un nombre de usuario y contraseña de texto claro que el cliente envía al servidor como parte de la secuencia de paquetes CONNECT/CONNNACK. Algunos brokers, especialmente los brokers abiertos publicados en Internet, aceptan clientes anónimos. En tales casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.

Reto MQTT: Seguridad, Interoperabilidad y Autenticación

Debido a que el protocolo MQTT no fue diseñado con la seguridad en mente, el protocolo ha sido tradicionalmente utilizado en redes back-end seguras para propósitos específicos de la aplicación. La estructura temática de MQTT puede fácilmente formar un árbol enorme, y no hay una manera clara de dividir un árbol en dominios lógicos más pequeños que puedan ser federados. Esto dificulta la creación de una red MQTT globalmente escalable porque, a medida que crece el tamaño del árbol temático, aumenta la complejidad.

Otro aspecto negativo de MQTT es su falta de interoperabilidad. Debido a que las cargas útiles de mensajes son binarias, sin información sobre cómo están codificadas (sin metadatos), pueden surgir problemas, especialmente en arquitecturas abiertas en las que se supone que las diferentes aplicaciones de los diferentes fabricantes funcionan a la perfección entre sí.

MQTT tiene características de autenticación mínimas incorporadas en el protocolo. El nombre de usuario y las contraseñas se envían en texto claro y cualquier forma de uso seguro de MQTT debe emplear SSL/TLS, que, lamentablemente, no es un protocolo ligero.

Autenticar clientes con certificados del lado del cliente no es un proceso simple, y no hay manera en MQTT, excepto el uso de medios propietarios fuera de banda, para controlar quién posee un topic y quién puede publicar información sobre él. Esto hace que sea muy fácil inyectar mensajes dañinos, ya sea intencionadamente o por error, en la red.

Además, no hay forma de que el receptor del mensaje sepa quién envió el mensaje original a menos que esa información esté contenida en el mensaje real. Las características de seguridad que tienen que ser implementadas sobre MQTT de forma propietaria aumentan la huella de código (footprint) y hacen que las implementaciones sean más difíciles.

Ventajas MQTT

Son varias las ventajas del protocolo MQTT como sistema de comunicación IoT. Por un lado, tenemos todas las ventajas del patrón pub/sub como son escalabilidad, asincronismo y desacoplamiento entre clientes.

Además, MQTT aporta una serie de características que le han hecho sobresalir sobre otros competidores.:

  • Sencillez y ligereza. Esto lo hace adecuado para aplicaciones IoT, donde frecuentemente se emplean dispositivos de escasa potencia.
  • Menor necesidad de recursos se traduce en un menor consumo de energía, lo cual es interesante en dispositivos que funcionan 24/7 y muy especialmente en dispositivos alimentados por batería.
  • Requiere un ancho de banda mínimo, lo cual es importante en redes inalámbricas, o conexiones con posibles problemas de calidad.
  • Medidas adicionales importantes, como la seguridad y calidad del servicio (QoS).
  • Es una solución largamente testada y consolidada, que aporta robustez y fiabilidad.

Clientes MQTT

Existen muchos clientes y librerías para MQTT, puesto que se trata de un protocolo libre sencillo de implementar.

Una aplicación de cliente MQTT se encarga de recopilar información del dispositivo de telemetría, conectar con el servidor y publicar la información en el servidor. También puede suscribirse a temas, recibir publicaciones y controlar el dispositivo de telemetría.

Cliente online: http://www.hivemq.com/demos/websocket-client/

Los mejores clientes MQTT: https://www.hivemq.com/blog/seven-best-mqtt-client-tools 

Tres herramientas MQTT y como simular MQTT: https://dzone.com/articles/top-3-online-tools-to-simulate-an-mqtt-client 

Herramientas MQTT: https://www.hivemq.com/blog/overview-of-mqtt-client-tools 

MQTT Explorer (Recomendado)

MQTT Explorer es un cliente MQTT integral que proporciona una descripción general estructurada de sus topics MQTT y hace que trabajar con dispositivos/servicios en su broker sea muy simple.

Web http://mqtt-explorer.com/

​​

Características:

  • Visualizar los topics y la actividad del topic.
  • Eliminar topics retenidos
  • Buscar / filtrar topics
  • Eliminar topics de forma recursiva
  • Vista diferente de los mensajes recibidos actuales y anteriores
  • Publicar topics
  • Graficar topics numéricos
  • Conservar un historial de cada topic
  • Temas oscuros/claros

Vídeo: http://mqtt-explorer.com/video.mp4 

Más Información:

MQTT.fx

Uno de los clientes MQTT más populares para instalar en ordenador es MQTT.fx hecho en java y basado en Eclipse Paho http://www.eclipse.org/paho/

Está disponible para Windows, Linux y MAC

Web: https://mqttfx.jensd.de/ 

Descarga: http://www.jensd.de/apps/mqttfx/1.7.1/ 

Referencias: http://mqttfx.jensd.de/index.php/references 

Más información:

MQTT-Spy

MQTT-spy es una utilidad de código abierto destinada a ayudarle a monitorear la actividad sobre temas de MQTTT. Ha sido diseñado para tratar con grandes volúmenes de mensajes, así como con publicaciones ocasionales.

Web: https://www.eclipse.org/paho/components/mqtt-spy/

mqtt-spy es probablemente una de las utilidades de código abierto más avanzadas para publicar y monitorear actividades sobre temas de MQTT. Está dirigido a dos grupos de usuarios:

  • Innovadores que necesitan una herramienta para crear prototipos de IO o proyectos de integración
  • Usuarios avanzados que necesitan una utilidad avanzada para sus entornos de trabajo

Web: https://kamilfb.github.io/mqtt-spy/ 

Wiki: https://github.com/eclipse/paho.mqtt-spy/wiki

Descarga: https://github.com/eclipse/paho.mqtt-spy/wiki/Downloads 

Getting Started: https://github.com/eclipse/paho.mqtt-spy/wiki/GettingStarted 

Ver mqtt-spy como aplicación para probar un mosquitto: https://github.com/kamilfb/mqtt-spy/wiki/Overview 

Resumen: https://github.com/kamilfb/mqtt-spy/wiki/Overview 

Más información:

Clientes MQTT en Autómatas

Para Siemens S7-1200/1500:

Unitronics: https://www.unitronicsplc.com/Download/SoftwareHelp/UniLogic_Knowledgebase/Communications/MQTT.htm

Clientes MQTT para móvil

Eclipse Paho Android Service: https://www.eclipse.org/paho/clients/android/

El que me gusta es https://play.google.com/store/apps/details?id=goliath.mobile.device.iotonoff

La web: https://www.iot-onoff.com/ 

Otro interesante es MQTT Dash: https://play.google.com/store/apps/details?id=net.routix.mqttdash&hl=es_419&gl=US 

Ejemplo de uso: https://www.hackster.io/fabiosouza/use-mqtt-dash-to-control-a-lamp-over-the-internet-97fa63 

Algunos clientes Android (por orden de descargas):

IOS:

Una app que es cliente MQTT, pero enfocada a domótica: https://www.andreas-binner.de/english/projects/visual/ 

Clientes MQTT en Dispositivos embebidos

MQTT se puede usar desde diversos dispositivos como cliente mediante el uso de librerías:

  • Arduino 
  • Python
  • Clientes MQTT
  • Raspberry Pi
  • Autómatas (ver PLC de Unitronics y otros)
  • Otros sistemas embebidos

Cliente MQTT para Python (Paho)

Documentación: https://www.eclipse.org/paho/clients/python/docs/  

Cliente MQTT python que está disponible en python. El proyecto Eclipse Paho proporciona implementaciones de cliente de código abierto de los protocolos de mensajería MQTT y MQTT-SN destinados a aplicaciones nuevas, existentes y emergentes para Internet de las cosas (IoT).

MQTT-SN:

Para usar la librería:

  • import paho.mqtt.client as mqtt # MQTT communication

Guia de MQTT: http://www.steves-internet-guide.com/mqtt/

Guia para novatos: http://www.steves-internet-guide.com/into-mqtt-python-client/

El cliente python de paho es asíncrono, lo que significa que si lanzo un script y finaliza antes de publicar o recibir fallará. Para ello se debe usar los loops y las funciones de callback

Trabajar con conexiones: http://www.steves-internet-guide.com/client-connections-python-mqtt/

Publicar mensajes con paho: http://www.steves-internet-guide.com/publishing-messages-mqtt-client/

Entender las callbacks: http://www.steves-internet-guide.com/mqtt-python-callbacks/

Callbacks: https://pypi.org/project/paho-mqtt/#callbacks

Suscripción a topics con paho: http://www.steves-internet-guide.com/subscribing-topics-mqtt-client/

Manejar multiples conexiones: http://www.steves-internet-guide.com/multiple-client-connections-python-mqtt/

Entender el loop: http://www.steves-internet-guide.com/loop-python-mqtt-client/

Documentación: https://www.eclipse.org/paho/clients/python/docs/

Tutorial: http://www.steves-internet-guide.com/into-mqtt-python-client/

MQTT y Arduino

MQTT ha surgido como un protocolo de mensajería estándar para la IoT. Se puede utilizar en redes TCP/IP y es muy ligero. La norma sigue un modelo de publicación-suscripción («pub/sub»).

Como habrás imaginado, para conseguir una comunicación MQTT, emplearemos una librería. Existen muchas disponibles gracias a la gran (tanto en tamaño como en calidad) comunidad que existe alrededor de Arduino.

Una de las librerías más conocidas y la más estable y flexible es Arduino Client for MQTT http://pubsubclient.knolleary.net/ que nos provee de un sencillo cliente que nos permite tanto subscribirnos como publicar contenido usando MQTT. Internamente, usa la API de Arduino Ethernet Client lo que lo hace compatible con un gran número de shields y placas.

Web: https://pubsubclient.knolleary.net/ 

Repositorio: https://github.com/knolleary/pubsubclient 

Esta librería está disponible en el gestor de librerías.

Documentación: https://pubsubclient.knolleary.net/api.html 

Hardware compatible:

  • Arduino Ethernet
  • Arduino Ethernet Shield
  • Arduino YUN – use the included YunClient in place of EthernetClient, and be sure to do a Bridge.begin() first
  • Arduino WiFi Shield – if you want to send packets greater than 90 bytes with this shield, enable the MQTT_MAX_TRANSFER_SIZE option in PubSubClient.h.
  • Sparkfun WiFly Shield – when used with this library
  • Intel Galileo/Edison
  • ESP8266
  • ESP32

Getting started con esa librería: https://ricveal.com/blog/arduino-mqtt/ 

Más info de esta librería: https://www.hivemq.com/blog/mqtt-client-library-encyclopedia-arduino-pubsubclient/ 

Tutorial con esta librería MQTT, Arduino y bluemix:: https://www.ibm.com/developerworks/ssa/cloud/library/cl-bluemix-arduino-iot2/index.html 

Uso de la librería: http://www.steves-internet-guide.com/using-arduino-pubsub-mqtt-client/ 

MQTT Publish en callback: https://codebender.cc/example/PubSubClient/mqtt_publish_in_callback#mqtt_publish_in_callback.ino

MQTT en Node-RED

Para integrar Node-RED con servicios MQTT existen los nodos de MQTT de publish y suscribe.

Más información: http://www.steves-internet-guide.com/configuring-the-mqtt-publish-node/

MQTT Recipes: