Archivo de la categoría: MQTT

ESP8266 en IoT

Iniciación ESP8266

https://www.aprendiendoarduino.com/2018/01/23/video-iniciacion-a-esp8266-hardware/

Preparación IDE Arduino para ESP8266

https://www.aprendiendoarduino.com/2018/01/27/video-preparacion-ide-arduino-para-esp8266/

Primeros Pasos con ESP8266

https://www.aprendiendoarduino.com/2018/03/03/video-primeros-pasos-con-esp8266/

Conectar ESP8266 a Internet. WifiClient

https://www.aprendiendoarduino.com/2018/03/22/video-conectar-esp8266-a-internet-wificlient/

Mandar Datos a un Servidor con ESP8266

Vamos a conectar Arduino a un servidor y mandar datos para que los muestre en una gráfica. Mandar datos a https://www.aprendiendoarduino.com/servicios/datos/graficas.html

Conexión:

Usar este código en Arduino: https://github.com/jecrespo/aprendiendoarduino-servicios/blob/master/arduino_code/data_logger_temperatura_DHCP_ESP/data_logger_temperatura_DHCP_ESP.ino

Ver los datos en:

Mandar Datos a una Raspberry Pi con ESP8266

Vamos a usar ESP8266 y mandar datos de luminosidad de la sala usando un LDR a una Raspberry Pi que tiene un servidor LAMP instalado.

Una fotorresistencia o LDR (por sus siglas en inglés “light-dependent resistor”) es un componente electrónico cuya resistencia varía en función de la luz.

Se trata de un sensor que actúa como una resistencia variable en función de la luz que capta. A mayor intensidad de luz, menor resistencia: el sensor ofrece una resistencia de 1M ohm en la oscuridad, alrededor de 10k ohm en exposición de luz ambiente, hasta menos de 1k ohm expuesto a la luz del sol. Aunque estos valores pueden depender del modelo de LDR.

El LDR actúa como una resistencia variable. Para conocer la cantidad de luz que el sensor capta en cierto ambiente, necesitamos medir la tensión de salida del mismo. Para ello utilizaremos un divisor de tensión, colocando el punto de lectura para Vout entre ambas resistencias. De esta forma:

Dónde Vout es el voltaje leído por el PIN analógico del ESP8266 y será convertido a un valor digital, Vin es el voltaje de entrada (5v), R2 será el valor de la resistencia fija colocada (10k ohm generalmente) y R1 es el valor resistivo del sensor LDR. A medida que el valor del sensor LDR varía, obtendremos una fracción mayor o menor del voltaje de entrada Vin.

Instalación:

Más información https://www.luisllamas.es/medir-nivel-luz-con-arduino-y-fotoresistencia-ldr/

Crear una base de datos llamada “DatosArduino” con una tabla llamada “luminosidad” que tenga 4 campos: “id” auto incremental y sea el campo clave, “fecha” de  tipo timestamp y que se actualice al actualizar, un campo “arduino” de tipo entero y un campo “IntensidadLuminosa” que sea de tipo entero.

O con la query:

 

CREATE TABLE `luminosidad` (
 `id` int(11) NOT NULL,
 `fecha` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP,
 `arduino` int(11) NOT NULL,
 `IntensidadLuminosa` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

ALTER TABLE `luminosidad`
 ADD PRIMARY KEY (`id`);

ALTER TABLE `luminosidad`
 MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;

Subir por FTP seguro los ficheros Graba_GET.php y Graba_POST.php a Raspberry Pi al directorio /var/www/html

Ejecutar en Arduino estos sketches para GET o POST para mandar cada 5 segundos el dato de luminosidad:

Ver en la web de phpmyadmin los datos que se están subiendo y descargar en formato csv los datos guardados en unos minutos.

NOTA: Para ver los errores de PHP activar en /etc/php/7.0/apache2/php.ini la línea:

  • Development Value: E_ALL

MQTT y ESP8266

Para trabajar con MQTT es interesante instalar primero en el ordenador un cliente como MQTT.fx para hacer debug: https://mqttfx.jensd.de/  

Para conseguir una comunicación MQTT con ESP8266 o Arduino, emplearemos una librería. Existen muchas disponibles gracias a la comunidad que existe alrededor de Arduino. Concretamente, nosotros emplearemos una de las más conocidas y la más estable y flexible, lo que facilita su uso en proyectos que queramos realizar donde intervengan Arduino y MQTT.

Dicha librería es Arduino Client for MQTT y 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 como:

  • Arduino Ethernet
  • Arduino YUN
  • Arduino WiFi Shield
  • Intel Galileo/Edison
  • ESP8266

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

Instalar la librería mediante el gestor de librerías:

PubSubClient es una librería compatible con Arduino y ESP8266. Básicamente hace que nuestra placa se comporte como un cliente MQTT es decir, que podamos publicar mensajes y suscribirnos a un topic o varios para recibir mensajes. Da lo mismo si utilizas un Arduino o un ESP8266, el código es prácticamente el mismo. La diferencia reside en cómo nos conectamos a la red WiFi o Ethernet, cada placa utiliza su propia librería.

Github PubSubClient: https://github.com/knolleary/pubsubclient

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

Enviando un mensaje a través del protocolo MQTT con Wemos D1 Mini

Vamos a partir de uno de los ejemplos que vienen dentro de la librería. Lo encontrarás en Archivo>Ejemplos>PubSubClient>mqtt_esp8266. Esta opción te abre el siguiente código: https://github.com/knolleary/pubsubclient/blob/master/examples/mqtt_esp8266/mqtt_esp8266.ino

Configurar el SSID y el password de la red. En mqtt_server poner la IP de la Raspberry Pi donde se ha instalado el broker Mosquitto.

NOTA: tener en cuenta que si usamos usuario y contraseña debemos usar connect (clientID, username, password) en lugar de connect (clientID) https://pubsubclient.knolleary.net/api.html#connect3   

Código: https://github.com/jecrespo/Curso-IoT-Open-Source/blob/master/mqtt_esp8266/mqtt_esp8266.ino

Este sketch publica un mensaje “hello world #x” consecutivo cada 2 segundos en el topic “outTopic” y se suscribe al topic “inTopic”. Además  cuando se recibe un mensaje se dispara la función callback que si es un 1 enciendo el led integrado y en caso contrario se desactiva.

Probando la aplicación MQTT con ESP8266 y Raspberry Pi

Por último nos queda probar todo el sistema. No te olvides de cargar el código en la placa con las modificaciones necesarias en cada sketch con SSID, password, IP servidor mosquitto, usuario mosquitto y contraseña mosquitto.

Desde mqtt.fx suscribirse a los topic “inTopic” y “outTopic” para recibir los cambios que se producen.

Más información:

Interesante sobre MQTT: http://hackaday.com/2016/06/02/minimal-mqtt-power-and-privacy/

MQTT y ESP8266 https://www.sparkfun.com/news/2111

Anuncios

Node-RED

Node-RED es una herramienta muy potente que sirve para comunicar hardware y servicios de una forma muy rápida y sencilla. Simplifica enormemente la tarea de programar del lado del servidor gracias a la programación visual.

Fue creada por Nick O’Leary y Dave Conway-Jones del grupo de Servicios de Tecnologías Emergentes de IBM en el año 2013. Su objetivo es dar solución a la complejidad que surge cuando queremos integrar nuestro hardware con otros servicios.

Su punto fuerte es la sencillez. Nos permite utilizar tecnologías complejas sin tener que profundizar hasta el más mínimo detalle en todas ellas. Nos quedamos en una capa inicial donde nos centramos en lo importante y dejamos de lado aquello que no es práctico.

Wikipedia: https://en.wikipedia.org/wiki/Node-RED

La estructura mínima son los nodos. Estos se arrastran a través de la interfaz gráfica y nos permiten hacer una tarea concreta. Recibir una llamada HTTP, un mensaje MQTT o la activación de un pulsador.

Todos estos nodos se organizan en flujos o flows que agrupan nodos que se conectan entre ellos. Todo de una forma visual, sin apenas tener que programar.

Node-RED es un motor de flujos con enfoque IoT, que permite definir gráficamente flujos de servicios, a través de protocolos estándares como REST, MQTT, Websocket, AMQP… ademas de ofrecer integración con apis de terceros, tales como Twitter, Facebook, Yahoo!…

Se trata de una herramienta visual muy ligera, programada en NodeJS y que puede ejecutarse desde en dispositivos tan limitados como una Raspberry, hasta en plataformas complejas como IBM Bluemix, Azure IoT o Sofia2 Platform.

Web: https://nodered.org/

Node-RED es una herramienta de código abierto, estando este disponible en github.

Repositorio: https://github.com/node-red/node-red

Una de las características más notables de Node-RED es la sencillez con la que se pueden crear nuevos nodos e instalarlos, en el siguiente enlace disponemos de toda la documentación necesaria: http://nodered.org/docs/creating-nodes/, en él, podemos ver que desarrollar un nuevo nodo es tan sencillo como crear un fichero HTML con el formulario de configuración mostrado en la imagen anterior para el nodo en concreto, y un fichero JS, con la lógica del nodo escrita en NodeJS.

De este modo, cualquier persona u organización puede crearse sus propios nodos, adaptando el motor de flujo a las necesidades de su negocio.

Los flujos programados en Node-RED se almacenan internamente en formato JSON y son portables entre distintas instalaciones de Node-RED, siempre que el Node-RED de destino tenga instalados los nodos utilizados en el flujo.

De este modo un flujo Node-RED consiste en un fichero con este aspecto:

La facilidad de desarrollo de nuevos nodos, así como la portabilidad de los flujos, confieren a Node-RED un marcado enfoque social. Gran parte de su éxito se fundamenta en que los nodos y flujos desarrollados por una persona u organización, pueden ser aprovechados por otras. En este sentido, en el sitio oficial de Node-RED encontramos una sección de contribuciones de terceros, con más de 1000 nodos y flujos subidos por la comunidad y listos para utilizar.

Node-RED Library: https://flows.nodered.org

Getting Started Node-RED: https://nodered.org/#get-started

Comunidad Node-RED: https://nodered.org/#community

Documentación Node-RED: https://nodered.org/docs/

En cuanto a cómo instalar Node-RED, existen dos alternativas:

  • Modo Standalone: Donde se ejecuta como un proceso NodeJS independiente del resto de procesos.
  • Modo Embebido: Donde forma parte de una aplicación mayor, de forma que es responsabilidad de esta controlar el ciclo de vida del propio Node-RED

Ambas instalaciones son securizables tanto a nivel control de acceso con usuario y contraseña, como con certificado SSL para acceder al editor por protocolo seguro HTTPS.

Asimismo dispone de un API Rest de administración y operación (http://nodered.org/docs/api/) de manera que puede interactuar y ser controlado por un sistema externo.

Estas características son las que hacen que Node-RED sea adecuado para ejecutarse casi en cualquier plataforma, ya que le dan la versatilidad de ser instalado tal cual, por ejemplo en una Raspberry. O poder ser administrado por un sistema mayor, como por ejemplo IBM Bluemix.

Instalación: https://nodered.org/docs/getting-started/

  • Localmente
  • En un dispositivo
  • En la nube

Es posible instalar Node-RED en un portátil y controlar el broker desde el mismo.

Configuración node red: https://nodered.org/docs/configuration

Node-RED con Arduino: https://nodered.org/docs/hardware/arduino

API nodered: https://nodered.org/docs/api/

Más información:

Vídeo Introducción IoT: https://www.youtube.com/watch?time_continue=85&v=vYreeoCoQPI

Curso IoT simatic (Siemens con Node red); http://www.infoplc.net/descargas/109-siemens/comunicaciones/2847-manual-simatic-iot2040-node-red

Instalar Node-RED en Raspberry Pi

Node-Red no viene instalado en Raspberry Pi pero se puede hacer desde add/remove software.

La forma recomendada es desde Menú – Preferencias – Software Recomendado. Si se instala de esta manera, se puede actualizar usando sudo apt-get upgrade.

Luego se puede ejecutar manualmente con el comando “node-red-star” o :

Para iniciar Node-RED en el arranque de Raspberry Pi de forma automática usar:

  • sudo systemctl enable nodered.service

Más información https://nodered.org/docs/hardware/raspberrypi

Para comprobar que funciona abrir en un navegador http://ip-raspberry:1880

pantalla node-red

Para encontrar más nodos y ejemplos de flows ver https://flows.nodered.org/

Para añadir nodos adicionales primero debe instalar la herramienta npm, ya que no está incluida en la instalación predeterminada de Raspbian. Esto no es necesario si ha actualizado a Node.js 8.x.

Los siguientes comandos instalan npm y luego lo actualizan a la última versión.

  • sudo apt-get install npm
  • sudo npm install -g npm

Para poder ver la paleta e instalar nodos, reiniciar el servicio:

  • sudo systemctl restart nodered.service

Y luego para instalar un nodo:

  • cd ~/.node-red
  • npm install node-red-{example node name}

Por ejemplo, podemos suscribirnos a un topic de MQTT, recibir un dato de temperatura y mostrarlo en la pantalla de debug:

Pero no sólo podemos hacer esto, también podemos conectar con servicios de terceros como IFTTT, ThingSpeak, Google Home, ThingerIO, etc…

Alternativamente se puede instalar mediante un script con el comando:

Configurar y Securizar Node-RED

Para configurar Node-RED seguir: https://nodered.org/docs/configuration

El fichero de configuración se encuentra normalmente en $HOME/.node-red/settings.js

Para securizar Node-RED seguir: https://nodered.org/docs/security para añadir usuario y password, así como otras configuraciones de seguridad

Para calcular la contraseña uso https://www.dailycred.com/article/bcrypt-calculator

Command line administration: https://nodered.org/docs/node-red-admin

Para usar https con Node-RED seguir estos tutoriales:

Programación Node-RED

Con respecto a Node-RED, se pueden hacer muchas cosas. Desde encender un LED en remoto, crear una API Rest en 5 minutos o conectar con una base de datos InfluxDB para graficar con Grafana. Aunque es visual, se requieren unos conocimientos técnicos en programación y tecnología medios y/o avanzados.

También permite programar en JavaScript funciones que pueden hacer de todo. Node-RED da mucho juego para muchas cosas.

El editor de flujos de Node-RED consiste en una sencilla interfaz en HTML, accesible desde cualquier navegador, en la que arrastrando y conectando nodos entre sí, es posible definir un flujo que ofrezca un servicio.

Como vemos, el editor se estructura como un entorno gráfico sencillo con:

  • Paleta de Nodos: Muestra todos los nodos que tenemos disponibles en nuestra instalación. Como veremos más adelante, existe un repositorio de nodos desarrollados por otros usuarios e incluso podemos crear e instalar nuestros propios nodos.
  • Editor: Nos permite arrastrar nodos desde la paleta y conectarlos. De este modo iremos creado el flujo de operación. El lienzo de node-red no tiene límites y se puede hacer zoom.

secciones principales node-red

Asimismo, seleccionando cada nodo, se muestra a la izquierda su formulario de configuración, donde es posible establecer las propiedades concretas de dicho nodo:

En node-Red los nodos se comunican entre sí mediante msg, que es un objeto con propiedades y que podemos añadir propiedades. La propiedad principal es payload, pero puedo añadir las que quiera. Puedo añadir otras propiedades como temperatura. Los nodos se unen en flujos que se ejecutan en paralelo.

En los nodos con entrada y salida, lo que entra sale y se mantiene la información salvo la que modifiques en el nodo.

Hay tres datos o propiedades que no se pueden modificar.:

  • número de mensaje
  • topic
  • payload

Disponemos de un debug que nos muestra el objeto y la podemos sacar por pantalla.

Los nodos son la unidad mínima que podemos encontrar en Node-RED. En la parte izquierda de la interfaz podemos ver la lista de nodos que vienen instalados por defecto y organizados en categorías según su funcionalidad.

Hay nodos de entrada, salida, funciones, social, para almacenar datos, etc… Esto muestra la capacidad de Node-RED de comunicarse con otros servicios.

Se pueden clasificar en tres tipos de nodos:

  • Nodos que sólo admiten entradas: sólo admiten datos de entrada para ser enviados a algún sitio como pueda ser una base de datos o un panel de control.
  • Nodos que sólo admiten salidas: son los nodos que sólo ofrecen datos tras recibirlos a través de diferentes métodos como por ejemplo un mensaje MQTT.
  • Nodos que admiten entradas y salidas: estos nodos nos permiten la entrada de datos y luego ofrecen una o varias salidas. Por ejemplo, podemos leer una temperatura, transformarla en grados Celsius y enviarla a otro nodo.

Los nodos los arrastramos al flujo o flow, en inglés. Aquí es donde tendremos la lógica para cada dato a base de ir arrastrando nodos.

Algunos de los nodos disponibles en Node-RED, los nodes de core son: https://nodered.org/docs/user-guide/nodes

  • Inject: para disparar un flujo manualmente. Inyecta una payload a un topic.
  • Debug: sirve para mostrar mensajes en la zona de debug de Node-RED. Puede habilitarse o deshabilitarse.
  • Function: permite programar un nodo mediante JavaScript, pero es mejor buscar nodos hechos que hagan la función deseada, por ejemplo un temporizador.
  • Change: se usa para modificar las propiedades de un mensaje sin usar funciones
  • Switch: permite que los mensajes sean enrutados a diferentes ramas de un flujo mediante un conjunto de reglas contra el mensaje.
  • Template: se usa para generar texto usando las propiedades de un mensaje.

Trabajar con mensajes en Node-RED: https://nodered.org/docs/user-guide/messages

Escribir funciones en Node-RED: https://nodered.org/docs/writing-functions

Existen además muchos tipos de nodos que podemos ver en https://flows.nodered.org/?num_pages=1 que son contribuciones de terceros.

Los nodos se organizan en flujos, para organizar los nodos como queramos. Es recomendable agrupar en flujos tareas que tengan relación entre ellos, pero solo a modo organizativo.

En node-red se puede trabajar con variables:

  • Contexto – solo aplica a un nodo
  • Flujo – aplica solo al flujo
  • globales – aplica a todo.

Cookbook de nodered: https://cookbook.nodered.org/

Node-RED programming guide: http://noderedguide.com/

Administración de node red mediante comando: https://nodered.org/docs/node-red-admin

Running node-red: https://nodered.org/docs/getting-started/running

Más información: https://programarfacil.com/blog/raspberry-pi/introduccion-node-red-raspberry-pi/

Node Red en Cloud

Hosting de node-red gratuito FRED (hasta 50 nodos): https://fred.sensetecnic.com/

FRED: Front End For Node-RED

Web principal de FRED

Google cloud: https://medium.com/google-cloud/deploy-your-node-red-environment-onto-kubernetes-clusters-using-google-cloud-platform-2e4775c2e79f

Más información:

Ejemplos Node-RED

Primer Flujo en Node-RED

Vamos a probar un flujo muy simple. Lo que hará es mostrar un texto por el panel de debug. Arrastra un nodo inject de la categoría input y un nodo debug de la categoría output al flujo. Los tienes que conectar entre ellos arrastrando el punto de la parte derecha del nodo inject sobre el punto de la parte izquierda del nodo debug.

A continuación vamos a editar el nodo inject. Si haces doble click sobre el nodo se abrirá un panel donde nos muestra diferentes parámetros. En este panel tienes que seleccionar del menú desplegable donde pone Payload, la opción que pone String.

En el campo de texto pon cualquier cosa como por ejemplo Hola mundo 🙂

Para guardar la aplicación sólo tienes que dar a Deploy que si te has dado cuenta, ha pasado de estar en un color gris oscuro a rojo.

Una vez que lo hayas pulsado, volverá de nuevo al color gris oscuro. Esto quiere decir que ya tenemos guardados todos los cambios del flujo de Node-RED.

Para probar este primer flujo con Node-RED tenemos que abrir el panel de debug que está situado en la parte derecha. Luego, tienes que hacer click sobre la parte izquierda del nodo inject.

Esto hará que en el panel debug aparezca lo que hemos escrito en la configuración del nodo inject.

Como puedes ver, el mensaje se muestra en el panel debug.

Más información: https://programarfacil.com/blog/raspberry-pi/introduccion-node-red-raspberry-pi/

Node-RED y MQTT

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

Ahora hay que configurarlo. Aquí es donde vemos la potencia de Node-RED. Cuando utilizamos una tecnología, nos centramos en lo superficial. 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.

Esto abre un nuevo panel de configuración. Pon un nombre al broker MQTT por ejemplo ALARMA PUERTA. 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.

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.

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.

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.

Nodos Node-RED

Existe una amplia librería de nodos para node-RED que puede consultarse en https://flows.nodered.org/?num_pages=1

Para añadir un nodo: https://nodered.org/docs/getting-started/adding-nodes

Si quieres crear tu propio nodo: https://nodered.org/docs/creating-nodes/first-node

Por defecto vienen unos nodos instalados, pero pueden añadirse otros fácilmente.

Github: https://github.com/node-red/node-red-nodes

Hay más de 1500 nodos, algunos de los más interesantes son:

Más información:

Nodo MySQL

Node de mysql: https://flows.nodered.org/node/node-red-node-mysql

Código del nodo de mysql: https://github.com/node-red/node-red-nodes/tree/master/storage/mysql

Ejemplo: https://flows.nodered.org/flow/13c55d1aa11e864609e24fa534a1fa26

Ejemplo de uso: https://tech.scargill.net/tag/mqtt-and-mysql-on-node-red/

Y nodo interesante para manejo de fechas:

Nodo MongoDB

Nodo MongoDB: https://flows.nodered.org/node/node-red-node-mongodb

Dashboard en Node-RED

Uno de los nodos más populares de Node-RED es el de dashboard, que  permite hacer un dashboard muy sencillo desde Node-RED.

Node dashboard: https://flows.nodered.org/node/node-red-dashboard

Github: https://github.com/node-red/node-red-dashboard

Cómo usarlo: https://randomnerdtutorials.com/getting-started-with-node-red-dashboard/

Más información:

Y se accede al dashboard con http://IP_NodeRED:1880/ui   

Tutoriales node red dashboard

Otro dashboard es el freeboard:

Ejemplo Arduino + MQTT + NodeRed + Dashboard

Hacer un Dashboard como este usando dos sondas o dos potenciómetros que manden datos a varios topic y se muestre en el dashboard, así como un led que pueda encenderse al pulsar un botón del dashboard y dos leds que se enciendan cuando se supere el umbral de temperatura.

Además hacer una pestaña con las gráficas y hacer un flujo de debug para ver los datos.

Todos los datos serán guardarlos en la BBDD MariaDB instalada en las Raspberry Pi

Ejemplo hecho con 4 flujos:

Código node-red: https://github.com/jecrespo/Curso-IoT-Open-Source/blob/master/node-red/node-red.json

Código Arduino: https://github.com/jecrespo/Curso-IoT-Open-Source/blob/master/node-red/arduino-node-red/arduino-node-red.ino

Mosquitto

Eclipse Mosquitto™ es un servidor de mensajes de código abierto (con licencia EPL/EDL) que implementa las versiones 3.1 y 3.1.1 del protocolo MQTT. MQTT proporciona un método ligero para llevar a cabo la mensajería utilizando un modelo de publicación/suscripción. Esto lo hace adecuado para la “Internet de los objetos” de mensajería como con sensores de baja potencia o dispositivos móviles como teléfonos, ordenadores embebidos o microcontroladores como el Arduino.

Mosquitto es un broker MQTT OpenSource ampliamente utilizado debido a su ligereza lo que nos permite, fácilmente, emplearlo en gran número de ambientes, incluso si éstos son de pocos recursos.

Web: https://mosquitto.org/

Testear Mosquitto: https://test.mosquitto.org/

Repositorio: https://github.com/eclipse/mosquitto

A través de esta página puedes descargar y seguir los pasos de instalación según cual sea tu sistema operativo.

Una vez que tenemos instalado Mosquito, podemos proceder a crear nuestro primer emisor y subscriptor siguiendo para ello una jerarquía que podría asemejarse a la empleada en una aplicación real como el de un edificio.

Proyectos Eclipse Open Source for IoT

Más información:

Otro MQTT broker: http://www.hivemq.com/

Para descargar e instalar mosquitto seguir las instrucciones de: https://mosquitto.org/download/

Buen tutorial de Luis del Valle: https://programarfacil.com/esp8266/mqtt-esp8266-raspberry-pi/

Instalar Mosquitto en Raspberry Pi

Mosquitto está disponible en el repositorio principal de Raspberry Pi. También hay repositorios Debian proporcionados por el proyecto mosquitto, tal y como se describe en  https://mosquitto.org/blog/2013/01/mosquitto-debian-repository/

Lo primero es descargar la signing key o clave de firma utilizando el comando wget. Este comando descarga el fichero indicado como parámetro en el directorio en el que te encuentras.

Añadimos la clave para a una lista para autenticar el paquete que vamos a descargar más tarde.

  • sudo apt-key add mosquitto-repo.gpg.key

Después descargamos la lista de repositorios de Mosquitto con wget en la carpeta adecuada.

Actualizamos la lista de paquetes disponibles y sus versiones

  • sudo apt-get update

Y finalmente instalamos Mosquitto y los clientes

  • sudo apt-get install mosquitto
  • sudo apt-get install mosquitto-clients

Si va a utilizar MQTT en un proyecto de Python, tendrá que instalar paho-mqtt, que reemplaza al antiguo módulo de Mosquitto Python. Si python-pip no está instalado tendrá que instalarlo primero:

  • sudo apt-get install python-pip
  • sudo pip install paho-mqtt

Más información:

Configurar mosquito

La configuración de mosquitto está el fichero /etc/mosquitto/mosquitto.conf. Recordar hacer copia del fichero antes de hacer alguna modificación

Para añadir todos los mensajes de log en el fichero de log añadir las líneas:

# Save all log in file
log_dest file /var/log/mosquitto/mosquitto.log
log_type all
log_timestamp true

Para más información sobre las opciones del fichero mosquitto.conf ver /usr/share/doc/mosquitto/examples/mosquitto.conf

Para reiniciar el servicio de mosquito usar:

  • sudo systemctl restart mosquitto

En Linux puede recargar los archivos de configuración sin reiniciar el broker enviando la señal HUP de la siguiente manera:

  • kill -HUP PID # where PID is the process ID

Más información:

Comprobar Funcionamiento de Mosquitto

El último paso es probar nuestra instalación. Vamos a usar dos terminales. Uno se suscribirá al tema “test-mosquitto”, y el otro publicará un mensaje sobre este tema. La prueba tendrá éxito si el mensaje enviado por el editor se registra en el terminal de abonado.

Abrir un terminal en el ordenador con PuTTY y para suscribirse al topic “test-mosquitto” poner el comando:

  • mosquitto_sub -d -t ‘test-mosquitto’ (d = debug mode, t = topic)

Las opciones del comando mosquitto_sub son: https://mosquitto.org/man/mosquitto_sub-1.html

Si quisiéramos conectarnos a otro mosquitto y no el de nuestra raspberry usar:

  • mosquitto_sub -d -h IP_BROKER -t ‘test-mosquitto’ (d = debug mode, t = topic, h = host)

Abrir otro terminal y para publicar en el topic “test-mosquitto” poner el comando:

  • mosquitto_pub -d -t ‘test-mosquitto’ -m ‘This is a test message’

Y recibiremos el mensaje en la consola donde nos hemos suscrito:

Probar a suscribirse o publicar a otros mosquitto. También puedes hacerlo instalando el cliente MQTT.fx de: https://mqttfx.jensd.de/

Más información:

Securizar Mosquitto – Autenticación y Autorización

Tenemos un servidor Mosquitto instalado y funcionando, pero cualquiera que pueda acceder al puerto 1883 de nuestra Raspberry Pi o servidor podrá publicar y suscribirse a topics y además los mensajes no están cifrados.

El objetivo es configurar un broker MQTT con autentificación para securizar un poco el acceso al mismo de forma que podamos exponerlo en un servidor público y aún así tengamos zonas privadas.

Vamos a configurar Mosquitto para que use contraseñas. Mosquitto incluye una utilidad para generar un archivo de contraseña especial llamado mosquitto_passwd. Este comando le pedirá que introduzca una contraseña para el nombre de usuario especificado y coloque los resultados en /etc/mosquitto/passwd. Ejecutar este comando y poner la contraseña.

  • sudo mosquitto_passwd -c /etc/mosquitto/passwd curso_iot

Ahora abriremos un nuevo archivo de configuración para Mosquitto y le diremos que use este archivo de contraseñas para requerir inicios de sesión para todas las conexiones:

  • sudo nano /etc/mosquitto/conf.d/default.conf

Y escribir en el fichero:

password_file /etc/mosquitto/passwd
allow_anonymous false

allow_anonymous false deshabilitará todas las conexiones no autenticadas, y la línea del archivo password_file le indica a Mosquitto dónde buscar información de usuario y contraseña.

Una vez modificado el fichero reiniciar mosquitto:

  • sudo systemctl restart mosquitto

En el directorio /etc/mosquitto/conf.d se guardan los ficheros de configuración adicionales.

Para publicar y suscribirse con usuario y contraseña usar:

  • mosquitto_pub -d -t “test” -m “hola_mundo” -u “curso_iot” -P “password”
  • mosquitto_sub -d -t “test” -u “curso_iot” -P “password”

Securizar Mosquitto – Cifrado SSL

Desafortunadamente, estamos enviando contraseñas sin encriptar a través de Internet. Lo arreglaremos añadiendo cifrado SSL a Mosquitto.

MQTT and TLS

MQTT se basa en el protocolo de transporte TCP. De forma predeterminada, las conexiones TCP no utilizan una comunicación cifrada. Para encriptar toda la comunicación MQTT, muchos Brokers MQTT (como Mosquitto) permiten el uso de TLS en lugar de TCP simple. Si utiliza los campos de nombre de usuario y contraseña del paquete MQTT CONNECT para los mecanismos de autenticación y autorización, debería considerar seriamente el uso de TLS.

El puerto 8883 está estandarizado para una conexión MQTT segura. El nombre estandarizado en IANA es “secure-mqtt”. El puerto 8883 está reservado exclusivamente para MQTT a través de TLS.

TLS Overhead

El uso de MQTT sobre TLS tiene sus inconvenientes: la seguridad tiene un costo en términos de uso de la CPU y gastos generales de comunicación. Mientras que el uso adicional de la CPU es típicamente insignificante en el broker, puede ser un problema para los dispositivos muy restringidos que no están diseñados para tareas de computación intensiva. Técnicas como la reanudación de sesión pueden mejorar drásticamente el rendimiento de TLS.

La sobrecarga de comunicaciones del Handshake de TLS puede ser significativa si se espera que las conexiones de los clientes MQTT sean de corta duración. Aunque la cantidad de ancho de banda que necesita el handshake TLS depende de muchos factores, algunas mediciones muestran que establecer una nueva conexión TLS puede requerir hasta unos pocos kilobytes de ancho de banda. Dado que cada paquete está encriptado en TLS, los paquetes en el cable tienen una sobrecarga adicional en comparación con los paquetes no encriptados.

Si utiliza conexiones TCP de larga duración con MQTT (¡lo que debería hacer!), la sobrecarga de TLS, especialmente la sobrecarga de handshake de TLS, puede ser insignificante. Si trata con muchas reconexiones y no puede utilizar la reanudación de sesión, entonces la sobrecarga puede ser significativa, especialmente si está publicando mensajes MQTTT muy pequeños. Si cada byte del cable cuenta para su caso de uso, TLS puede no ser la mejor opción para usted debido a la sobrecarga. Asegúrese de medir cuánta sobrecarga de TLS crea para su caso de uso.

TLS en dispositivos limitados

A veces, TLS no es factible para dispositivos limitados debido a la insuficiencia de recursos. Dependiendo de las cifras utilizadas, TLS puede ser muy intensivo en el cálculo y puede requerir muchos kilobytes de memoria.

Para hacerlo seguir estos tutoriales:

Más información

Ejemplo con Mosquitto y Arduino

Conectar un Arduino al broker MQTT y suscribirse al topic “inTopic” y sacar por el monitor serie lo que lee.

Usar el código: https://github.com/jecrespo/Curso-IoT-Open-Source/blob/master/mqtt_auth_curso/mqtt_auth_curso.ino

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).

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.

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.

Más información:

MQTT también 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 de cabeza) 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 topis 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 briker (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

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.
  • En el tiempo: El publicador y el suscriptor no tienen porqué estar conectados en el mismo momento.
  • 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.

La comunicación se basa en unos “topics” (temas), que el cliente que publica el mensaje crea y los nodos que deseen recibirlo deben subscribirse 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.

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/#”).

Existen dos comodines en MQTT para suscribirse a varios topics:

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

Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier suscripción de root wildcard. 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:

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 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/)

MQTT Sobre Websockets

MQTTT es una arquitectura de publicación/suscripción que se desarrolla principalmente para conectar dispositivos con ancho de banda y potencia limitada a través de redes inalámbricas. Es un protocolo simple y ligero que corre sobre sockets TCP/IP o WebSockets.

MQTT sobre WebSockets puede ser asegurado con SSL. La arquitectura de publicación/suscripción se basa en eventos que permiten enviar mensajes a los dispositivos cliente. El broker MQTT es el punto central de comunicación, y se encarga de despachar todos los mensajes entre los remitentes y los destinatarios legítimos. Un cliente es cualquier dispositivo que se conecta al corredor y puede publicar o suscribirse a temas para acceder a la información.

Un tema contiene la información de enrutamiento para el broker. Cada cliente que quiere enviar mensajes publica sobre un tema determinado, y cada cliente que quiere recibir mensajes se suscribe a un tema determinado. El corredor entrega todos los mensajes con el tema correspondiente a los clientes apropiados.

Sólo necesitará ejecutar MQTTT en sockets web si desea publicar/suscribirse a mensajes directamente desde webapps.

Buena web para estar al día de MQTT: https://www.hivemq.com/blog/

Más información:

Para saber más sobre MQTT leer esta serie de Artículos:

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 briker 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 quereis conocer los tipos de mensajes podéis consultarlos en: https://dzone.com/refcardz/getting-started-with-mqtt

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

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

Calidad de Servicio MQTT (QoS)

Al enviar mensajes MQTT existe la posibilidad 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.

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.

Último deseo y Testamento (MQTT LWT)

Un cliente puede establecer un mensaje Last Will and Testament (LWT) en el momento en el que conecta 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

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, 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

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.

MQTT vs HTTP (REST API)

La diferencia entre una REST API y MQTT es que MQTT mantiene una conexión hacia el servicio abierta y puede responder mucho más rápido a los cambios en el feed. La REST API solo conecta al servicio cuando se hace una petición (request) y es más apropiada para proyecto donde el dispositivo permanece en modo sleep (para reducir el consumo) y despierta solo para mandar o recibir datos. (Push vs pull)

Push = websocket

Pull = REST API

HTTP no tiene estado (stateless), por lo que debe tener una conexión por cada transferencia de datos: una conexión cada vez que desee escribir datos, una conexión para la lectura. HTTP es ideal para grandes cantidades de datos, como los que se utilizan para sitios web, y se puede utilizar para conexiones IoT. Pero no es ligero y no es muy rápido. Otro problema con HTTP es que es sólo pull.

MQTTT es un gran protocolo. Es extremadamente sencillo y ligero. La conexión a un servidor sólo tarda unos 80 bytes. Usted permanece conectado todo el tiempo, cada dato ‘publicación’ (datos push de un dispositivo a otro) y cada dato ‘suscripción’ (datos push de un servidor a otro) es de unos 20 bytes. Ambos ocurren casi instantáneamente.

MQTT puede funcionar sobre cualquier tipo de red, ya sea una red mesh, TCP/IP, Bluetooth, etc.

Si se usa MQTT usando Bluetooth, XBee, Bluetooth LE, LoRA u otro protocolo y dispositivo no conectado a Internet, ¡necesitarás una pasarela!

Ejemplo de gatewaty: https://learn.adafruit.com/datalogging-hat-with-flora-ble/

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.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.

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:

MQTT Lens

MQTT se puede instalar fácilmente a través de Google Chrome App Store. La herramienta tiene una interfaz bastante limpia y soporta todas las opciones de conexión disponibles desde la especificación MQTT, excepto las sesiones persistentes. Acepta conexiones a más de un broker al mismo tiempo y los colorea de manera diferente para facilitar su asociación.

La interfaz para suscribirse, publicar y ver todos los mensajes recibidos es simple y fácil de entender. Lamentablemente no hay posibilidad de publicar mensajes retenidos. Pero aunque esta aplicación se instala a través de Chrome, se ejecuta como una aplicación independiente.

Usando MQTT Lens:

Uso de MQTT lens: http://www.hivemq.com/blog/mqtt-toolbox-mqtt-lens

Descarga: https://chrome.google.com/webstore/detail/mqttlens/hemojaaeigabkbcookmlgmdigohjobjm

Clientes MQTT para móvil

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

Algunos clientes Android (por orden de descargas):

IOS:

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

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

Otras Librerías MQTT para Arduino

A la hora de elegir una librería MQTT, debemos comprobar que funciona con el dispositivo HW Arduino y el HW de comunicación.

Otras librerías MQTT para Arduino:

Más información de uso librería Adafruit:

Seguridad MQTT con ESP 8266: https://io.adafruit.com/blog/security/2016/07/05/adafruit-io-security-esp8266/

Protocolos IoT Capa Aplicación

En informática y telecomunicación, un protocolo de comunicaciones es un sistema de reglas que permiten que dos o más entidades de un sistema de comunicación se comuniquen entre ellas para transmitir información por medio de cualquier tipo de variación de una magnitud física. Se trata de las reglas o el estándar que define la sintaxis, semántica y sincronización de la comunicación, así como también los posibles métodos de recuperación de errores. Los protocolos pueden ser implementados por hardware, por software, o por una combinación de ambos.

Los sistemas de comunicación utilizan formatos bien definidos (protocolo) para intercambiar mensajes. Cada mensaje tiene un significado exacto destinado a obtener una respuesta de un rango de posibles respuestas predeterminadas para esa situación en particular. Normalmente, el comportamiento especificado es independiente de cómo se va a implementar. Los protocolos de comunicación tienen que estar acordados por las partes involucradas.

Ejemplos de protocolos de red (wikipedia)

Algunos Protocolos de comunicación IoT de capa de aplicación, con los que comunicar el HW con el SW

  • MQTT
  • API REST/HTTP
  • SNMP
  • CoAp
  • Websockets
  • Buses de campo industriales, modbus, etc…

Más información: https://es.wikipedia.org/wiki/Protocolo_de_comunicaciones

El protocolo de red MQ Telemetry Transport (MQTT) sería una buena opción para monitorizar y controlar los paneles solares. MQTT es un protocolo de publicación/suscripción con corredores de mensajes centrales. Cada panel solar puede contener un nodo IoT que publique mensajes de tensión, corriente y temperatura.

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

Para los nodos IoT de los aerogeneradores, preferiría una interfaz más basada en API. El Protocolo de aplicación restringida (Constrained application protocol – CoAP) utiliza el conocido patrón de diseño REST, en el que los servidores ponen recursos a disposición en una URI y los clientes acceden a los recursos utilizando métodos como GET, PUT, POST y DELETE. Los estándares publicados facilitan la interpretación de los formatos de contenido: por ejemplo, XML (ID=41) o JSON (ID=50).

CoAP es un protocolo del IETF (Internet Engineering Task Force) que se ha diseñado para proporcionar aplicaciones RESTful modeladas en la semántica de HTTP, pero más pequeño y binario a diferencia del basado en texto. CoAP es un enfoque tradicional de cliente-servidor en comparación al de brokers, diseñado para correr sobre UDP.

Las turbinas podrían consultarse entre sí para optimizar el rendimiento de la matriz. Por ejemplo, una turbina podría consultar a la turbina adyacente para determinar si el viento estaba aumentando o disminuyendo. El vecino podría a su vez consultar a su vecino y así sucesivamente. Esta simple regla podría permitir a una turbina anticiparse a los cambios de viento y prepararse en consecuencia. Si todo el array tiene acceso a la web (vía HTTP) y un servidor DNS, es fácil traducir el URI a: http:// turbine20.domain.tld/speed y monitorizar el campo remotamente.

El CoAP de un vistazo

  • Transferencia de documentos cliente/servidor REST
  • Fácil de traducir a HTTP para la integración web
  • Topología uno a uno con conexiones directas
  • Metadatos para diferenciar clases de documentos
  • UDP
  • Seguridad a través de DTLS

En entornos industriales OPC UA (Unified Architecture, ‘arquitectura unificada’) es el estándar de nueva generación que le sigue a OPC Foundation. OPC clásico es bien conocido en la industria y provee una interfaz estándar para comunicarse con los PLC (Programmable Logic Controller, ‘controlador lógico programable’). OPC UA pretende expandir la compatibilidad de OPC al nivel de los dispositivos y de las empresas.

OPC UA es un protocolo cliente/servidor. Los clientes se conectan, navegan, leen y escriben al equipamiento industrial. UA define la comunicación desde la aplicación hacia la capa de transporte, lo que lo hace muy compatible entre vendedores. También es muy seguro, y usa mensajes bidireccionales firmados y encriptación de transporte.

OPC UA tiene una amplia base instalada en el mundo industrial. Es una buena solución para conectar información de sensores y PLC en aplicaciones industriales ya existentes como sistemas MES (Manufacturing Execution System, ‘sistema de ejecución de manufactura’) y SCADA (Supervisry Control and Data Acquisition, ‘supervisión, control y adquisición de datos’), en donde la conectividad OPC y OPC UA ya estén disponibles.

Sin embargo, OPC UA es nuevo para las tecnologías de información. Algunas personas de TIC (tecnologías de la información y comunicación) se asustan ante la complejidad de UA en comparación con otros protocolos TIC. Bastante de esta complejidad reside en el hecho de que OPC UA sea un protocolo industrial, pero esta percepción ha llevado a ralentizar su adopción para plataformas IoT y la comunidad de código abierto.

Pero la cosa están cambiando: hace muy poco, OPC Foundation abrió el código del estándar OPC UA para hacerlo más accesible y colaborar a que se incremente su adopción.

Más información:

Comparativa de protocolos IoT:

Conclusión

OPC UA, HTTP, MQTT, CoAP, DDS, AMQP, etc.. todos tienen lugar en IoT. Cuál de estos protocolos tiene la mayor parte del mercado no está claro, pero cada uno tiene sus pros y sus contras. Es importante elegir el protocolo que mejor se adapte a sus necesidades, y seleccionar los socios tecnológicos que se puedan adaptar a tales protocolos. Esto asegurará el éxito para sus aplicaciones IoT y lo protegerá de las guerras de protocolos.

Muy buen resumen de protocolos de IoT: https://www.postscapes.com/internet-of-things-protocols/

Otro Buen resumen de protocolos IoT de la capa de aplicación: https://www.14core.com/the-iot-protocols-the-base-of-internet-of-things-ecosystem/