Archivo de la categoría: IoT

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

Recomendado doble pantalla

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) – «Dashboard Node-RED»

7.1 – Fundamentos Programación Node-RED (Ejercicio final)

OJO: Al importar también importa el nodo de configuración, pero no las contraseñas

Práctica 3: Wifi + MQTT con ESP8266 (poner en funcionamiento nodo DS18B20 + Relé y/o DS18B20 + Oled)

Capítulos vistos:

Sesión 9 (30 de mayo) – «Desarrollo Node-RED I»

Capítulos vistos:

Sesión 10 (1 de junio) – «Desarrollo Node-RED I»

Sesión 11 (9 de junio – presencial)

Otros

Otros puntos:

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:

Qué es Raspberry Pi

Raspberry Pi es un ordenador de placa reducida, ordenador de placa única u ordenador de placa simple (SBC) de bajo costo desarrollado en el Reino Unido por la Raspberry Pi Foundation. Se ha convertido en un hardware muy popular debido a su bajo coste y gran potencia ampliamente utilizado en proyectos IoT e Industria conectada.

Raspberry Pi es un mini ordenador de pequeño tamaño, bajo coste y bajo consumo. Es una placa de desarrollo basada en linux, pero a efectos de todos se trata de un ordenador con linux completo.

Además de un ordenador Raspberry incorpora funciones de electrónica como pines GPIO (General Purpose Input/Output), y de comunicación como UART (Universal Asynchronous Receiver-Transmitter), y SPI (Serial Peripheral Interface), I²C (Inter-Integrated Circuit).

La comunidad de usuarios es uno de los puntos fuertes de Raspberry, porque proporciona una gran cantidad de desarrollos, documentación, tutoriales, que colaboran a la introducción y popularización del dispositivo.

Raspberry nació con un propósito: incentivar la enseñanza de informática en el entorno docente. Es un ordenador muy pequeño, del tamaño de una tarjeta, muy económico y también muy conocido para crear prototipos. Con esta plataforma de desarrollo se gestiona una gran cantidad de datos y es especialmente atractiva para la creación de aplicaciones móviles (Apps) donde el peso de la interfaz gráfica es muy importante. Está muy indicada, además, para proyectos multimedia basados en Linux.

En 2009 se creó la Fundación Raspberry Pi en Reino Unido y dos años más tarde comenzaron a fabricarse las primeras placas prototipo. El éxito fue tan grande que los fundadores trasladaron su producción a Gales, de donde salen miles de dispositivos al día. Existen varios modelos de placas y su popularidad ha generado que salgan al mercado diversidad de accesorios que suman funcionalidades a la placa base, al igual que Arduino.

La placa Raspberry se utiliza, como Arduino, en entornos de robótica o domótica, pero también como servidor de archivos. Es otra opción dentro del IoT y es muy interesante cuando el objetivo es procesar y tratar muchos datos. Cualquiera de ellos, Arduino o Raspberry, ofrece fórmulas eficaces para multitud de proyectos, pero todavía es difícil establecer su límite al estar en constante evolución.

Pero además, la Raspberry Pi viene cargada con tecnología adicional para que podamos conectar nuestros proyectos al mundo de Internet de las Cosas.

  • 11n Wireless LAN
  • Bluetooth 4.0
  • Bluetooth Low Energy (BLE)

Estas nuevas características son precisamente las que nos van a permitir cubrir nuestras necesidades de conexión de forma inalámbrica a nivel de red local LAN y acceso a Internet, gracias al WiFi, y a nivel de comunicación con sensores y actuadores, gracias al Bluetooth. La Raspberry Pi  nos pone en bandeja todo lo necesario para comenzar a construir proyectos para Internet de las Cosas y aprender multitud de cosas, como programación, comunicaciones, electrónica, etc.

Buena introducción a Raspberry Pi:

Magpi es la revista oficial y se puede descargar gratis: https://www.raspberrypi.org/magpi/

Todo lo necesario para empezar con Raspberry Pi: https://xataka.com/makers/cero-maker-todo-necesario-para-empezar-raspberry-pi 

Documentación raspberry Pi: https://www.raspberrypi.org/documentation/

Más información:

Marca powered by raspberry pi: https://www.hwlibre.com/powered-by-raspberry-pi-el-nuevo-sello-de-calidad-de-raspberry-pi/ 

Webs importantes de Raspberry Pi:

Documentación

Disponemos de una amplia documentación para Raspberry Pi: https://www.raspberrypi.com/documentation/ 

Historia Raspberry Pi

Fechas clave Raspberry Pi:

  • 2006: Eben Upton comienza a trabajar en los primeros conceptos
  • 2011: Estamos cerca del primer lanzamiento, con dispositivos alfa y beta durante este año.
  • Enero de 2012: los primeros 10 dispositivos Raspberry se venden en eBay 
  • 29 de febrero de 2012: Lanzamiento oficial de la primera Raspberry para el público, la Pi B
  • 4 de febrero de 2013: lanzamiento de la Raspberry Pi A
  • Noviembre de 2014: lanzamiento de Raspberry Pi A +
  • 2 de febrero de 2015: Lanzamiento de Raspberry Pi 2 B
  • 26 de noviembre de 2015: lanzamiento de Raspberry Pi Zero
  • 29 de febrero de 2016: Lanzamiento de Raspberry Pi 3 B
  • 28 de febrero de 2017: Lanzamiento de Raspberry Pi Zero W
  • 15 de enero de 2018: Lanzamiento de Raspberry Pi Zero WH
  • 14 de marzo de 2018: Lanzamiento de Raspberry 3 B +
  • Noviembre de 2018: Lanzamiento de Raspberry 3 A +
  • 24 de junio de 2019: Lanzamiento de Raspberry Pi 4
  • 2 de noviembre de 2020: Lanzamiento de Raspberry Pi 400
  • 21 de enero de 2021: Lanzamiento de Raspberry Pi Pico

Décimo aniversario Raspberry Pi: https://www.raspberrypi.com/news/happy-birthday-to-us-3/ 

10 años de Raspberry Pi: https://www.youtube.com/watch?v=eiwm5TMHIy8 

Más información:

Repositorio en Github

El repositorio: https://github.com/raspberrypi

Linux: https://github.com/raspberrypi/linux

Firmware: https://github.com/raspberrypi/firmware

Documentación: https://github.com/raspberrypi/documentation

Para ver los bugs y abrir nuevos: https://github.com/raspberrypi/documentation/issues

Qué puede hacer una Raspberry Pi

Raspberry Pi puede utilizarse en muchos aspectos y realizar diferentes funciones, alguno de los más conocidos son:

  • Servidor Web
  • Servidor BBDD
  • Ordenador de sobremesa
  • Media center
  • Top Table
  • Gateway VPN
  • Placa de desarrollo
  • Lectura sensores
  • Manejar actuadores
  • Home Automation (Domotica)
  • Robótica: https://piwars.org/ 
  • etc…

Como media server http://www.instructables.com/id/Raspberry-Pi-Media-Server-MiniDLNA/

Ideas para usar RPi en casa: http://hipertextual.com/2013/09/ideas-usar-raspberry-pi-casa

Arranque USB

Modos de arranque: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#usb-boot-modes 

Arranque desde disco duro USB: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#usb-mass-storage-boot

Arranque desde red: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#network-booting 

Raspberry Pi vs Arduino

Analogía: Arduino es un Autómata programable y Raspberry Pi es un ordenador o un PAC, así que a la hora de decidir qué utilizar para un proyecto deberíamos pensar si usar un autómata o un ordenador.

Las diferencias principales entre una Raspberry Pi y un Arduino son:

  • Número de entradas y salidas disponibles y sus capacidades de corriente y voltaje.
  • La programación, Arduino se usa para programación en tiempo real, en Raspberry Pi se usa para programación intensiva con gran cantidad de datos sobre un Sistema Operativo.

Estas diferencias se deben a que Arduino tiene un microcontrolador (MCU) y Raspberry Pi tiene un microprocesador. Un microcontrolador es un HW optimizado no para capacidad de cálculo sino para interactuar con el exterior, con sensores y actuadores.

Ver artículo: https://aprendiendoarduino.wordpress.com/2017/06/19/arduino-vs-raspberry-pi-3/ 

Raspberry Pi Industria

Pero Raspberry Pi no solo se ha quedado en un placa de desarrollo, sino que se ha extendido su uso en la industria con el uso en PLCs, Paneles HMI, PAC (Programmable Automation Controller), Gateways, etc…

Además Raspberry Pi es una muy buena herramienta de aprendizaje de elementos Industriales con Linux embebido.

Incluso puede hacerse un cluster con varias Raspberry Pi:

​​

Ver artículo: https://aprendiendoarduino.wordpress.com/2020/03/01/raspberry-pi-en-la-industria/

Presentación del Curso: Raspberry Pi y Node-RED para IoT

Título: “Raspberry Pi y Node-RED para IoT”

Motivación

En la industria conectada, 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.

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á a una empresa explorar y ampliar las soluciones que ofrece.

Raspberry Pi es un ordenador de placa reducida, ordenador de placa única u ordenador de placa simple (SBC) de bajo costo muy popular en la industria conectada y con gran apoyo de la comunidad. Es el complemento perfecto para Node-RED en el entorno de trabajo.

Este curso es una introducción práctica para aprender a manejar Raspberry Pi y para aprender a programar en en entorno de IoT/Industria 4.0/digitalización incluso para quien no está familiarizado con la programación por código.

Este curso surge de diversas conversaciones con gente de empresas, alumnos de los cursos de Arduino y especialmente personal del Think TIC en los últimos años donde se ha habla de la necesidad de que las pequeñas y medianas empresas puedan acceder a las ventajas de soluciones IoT o Industria 4.0 con herramientas sencillas de usar y de bajo coste.

Curso: https://www.larioja.org/thinktic/es/cursos-eventos/cursos-comenzados-completos/curso-raspberry-pi-node-red-iot 

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.

Muchas empresas no dan el salto de digitalización porque la inversión inicial puede ser muy alta al necesitar contratar a una empresa externa o herramientas profesionales, pero quién mejor que el personal de la propia empresa que es quien mejor conoce los procesos internos, gracias a la tecnología abiertas, es posible con una pequeña inversión económica y una formación centrada en la digitalización de los procesos.

Propuesta Formativa

Este curso está diseñado para que cualquier trabajador cualificado de una empresa pueda introducir el concepto de IoT y la automatización de tareas  aplicado al sector en que trabaje, usando tecnologías libres y pueda ver resultados rápidos y con una inversión económica mínima.

El curso se basa en la programación mediante Node-RED que es una programación por flujos.

Este curso está enfocado a profesionales cualificados de diversos sectores que deseen hacer una aplicación de IoT en sus empresas y pueda montar un piloto de IoT en sus instalaciones, así como realizar tareas de automatización.

Conceptos:

  • Raspberry Pi es un ordenador de placa reducida, ordenador de placa única u ordenador de placa simple (SBC) de bajo costo desarrollado en el Reino Unido por la Raspberry Pi Foundation. Se ha convertido en un hardware muy popular debido a su bajo coste y gran potencia ampliamente utilizado en proyectos IoT e Industria conectada.
  • Node-RED es una herramienta de programación que se utiliza para conectar dispositivos de hardware, APIs y servicios de internet. Adecuado para los equipos dedicados al Internet de las cosas Industrial( IIoT) 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ía al equipo IIoT explorar y ampliar las soluciones que ofrece a la empresa que lo use.

Objetivo

El objetivo de este curso es que el alumno obtenga un conocimiento de la placa Raspberry Pi basada en linux y sea capaz de instalar, configurar y realizar proyectos sencillos usando Node-RED y la programación visual mediante flujos, para su uso en entornos IoT o de automatización.

Al finalizar el curso el alumno será capaz de:

  • Conocer el HW Raspberry Pi
  • Instalar Raspberry Pi OS
  • Conocer comandos básicos de Linux
  • Conocer de forma básica el lenguaje de programación Python
  • Instalar servicios en Raspberry Pi OS
  • Conocer el protocolo MQTT
  • Instalar Node-RED en diversas plataformas
  • Configurar y usar de forma segura Node-RED
  • Usar la programación de flujos de forma eficiente
  • Hacer debug de los programas Node-RED
  • Instalar y utilizar nodos
  • Configurar un dashboard

Palabras Clave:

  • Raspberry Pi
  • Node-RED
  • IoT
  • Automatización
  • Low-Code Programming
  • Edge Computing
  • OT vs IT

Requisitos

Para la realización de este curso no es necesario ningún conocimiento previo. Es recomendable un conocimiento medio de Inglés puesto que gran parte de la documentación está en Inglés.

Metodología

El curso es principalmente práctico donde se empieza a instalar, configurar y usar una Raspberry Pi para posteriormente, programar una serie de retos usando Node-RED instalado en Raspberry Pi interactuando en nodos remotos basados en placas ESP8266 con diferentes shields, que hacen de nodos remotos conectados con protocolo MQTT. También desde Node-RED se interactuará con aplicaciones de terceros.

La duración total del curso es de 30 horas.

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

Además están disponibles otros recursos para ampliar información:

Para realizar las prácticas de este curso se usará el material disponible en el Think TIC que veremos a fondo en un apartado posterior.

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.

Todo el material entregado es en préstamo y debe cuidarse al máximo, a la hora del montaje de las prácticas se seguirán las instrucciones para evitar dañar los componentes.

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.

Organización del curso

El curso tiene una duración total de 30 horas. El curso se celebra del 19 al 29 de abril de 2022 de Lunes a Viernes en horario de 18.00 a 21.00 y el sábado 22 de 10:00 a 13:00. Se hará un descanso de 10-15 minutos aproximadamente a mitad de la sesión.

Al principio de la clase se verán durante 10-15 minutos temas relacionados con el curso propuestos por los alumnos o que hayan surgido durante la clase. Se podrán ver en https://aprendiendoarduino.wordpress.com/2022/04/14/saber-mas-raspberry-pi-y-node-red-para-iot/

Contenido del Curso

Toda la documentación del curso y el código usado es libre y accesible desde https://www.aprendiendoarduino.com/cursos/introduccion-a-raspberry-pi-y-node-red-para-uso-en-la-industria-conectada/

Contenido

  • Presentación del Curso
  • Material del Curso
  • Qué es Raspberry Pi
  • HW Raspberry Pi
  • Instalación Raspberry Pi OS
  • Raspberry Pi en la Industria
  • Conceptos básicos de Linux
  • Programación Básica en Python
  • GPIO
  • Instalación de Servicios en Raspberry Pi OS
  • Edge Computing
  • Uso de Raspberry Pi y Node-RED en la convergencia IT-OT
  • Protocolo MQTT
  • Qué es Node-RED
  • Instalación de Node-RED
  • Configurar y securizar Node-RED
  • Paso a Paso: Instalar, Configurar y Securizar Node-RED en Raspberry Pi
  • Fundamentos Programación Node-RED
  • Uso del Editor de Node-RED
  • Mensajes Node-RED
  • Dashboard Node-Red
  • Nodos de Configuración en Node-RED
  • Nodos Node-RED
  • Debug Node-RED

Presentaciones

  • ¿Nombre?
  • ¿Experiencia con Linux y/o Node-RED?
  • ¿Sector de aplicación o aplicaciones que se quieran hacer?

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/

¿Qué es IoT?

Internet de las cosas (en inglés Internet of things, abreviado IoT) es un concepto que se refiere a la interconexión digital de objetos cotidianos con Internet. En el caso que queramos interconectar los elementos de una empresa o una Industria es lo que se denomina IIOT (Industrial Internet of Things) o Industria 4.0

Definición de wikipedia:

¿Qués Internet de las Cosas?: http://www.ticbeat.com/tecnologias/que-es-el-internet-de-las-cosas/

Arduino y Raspberry Pi son dos elementos muy populares y abiertos que nos permiten de forma sencilla y económica conectar cualquier cosa a Internet. Con un Arduino y un sencillo módulo ethernet o wifi podemos conectar a Internet sensores para informar, controlar motores o bombillas desde cualquier parte del mundo o mandar un SMS o email cada vez que se abra la puerta de casa. Con una Raspberry Pi disponemos de un ordenador de bolsillo fácilmente conectable a Internet y que puede ejecutar tareas automatizadas, almacenar datos, mostrar información o hacer de pasarela para conectarnos a otras ubicaciones o dispositivos remotos.

Arduino y Raspberry Pi se han convertido en unas figuras destacadas e incluso unos de los impulsores del IoT y no por casualidad, sino que  por sus características son HW con gran capacidad para usar en proyectos de IoT.

Características de Arduino y Raspberry Pi para IoT

  • Barato y rápido prototipado.
  • HW libre y por lo tanto es modificable para que consuma menos y para hacer un HW final de características industriales.
  • Disponibilidad de HW de comunicaciones de todo tipo para conectar con Arduino. Nuevas tecnologías de comunicación llegan antes que para elementos comerciales
  • Librerías y SW públicos para su reutilización o adaptación.
  • Flexibilidad en la programación.
  • Apoyo de la comunidad.

Intersante web con publicaciones sobre IoT: https://iot-analytics.com/ 

Como afecta IoT a nuestro dia a dia: http://socialgeek.co/tecnologia/8-formas-que-the-internet-of-things-impactara-dia-dia

IoT en 5 minutos con Arduino: http://hackaday.com/2016/01/08/internet-of-things-in-five-minutes/ 

Aplicaciones de IoT: https://temboo.com/iot-applications 

7 Lecciones sobre IoT: https://www.greenbiz.com/article/7-essential-lessons-about-internet-things

IoT vs M2M

Una visión del IoT aplicado a la industria es lo denominado como Industria 4.0 o Industria conectada o IIoT que deriva del concepto de M2M (machine to machine) que se refiere al intercambio de información o comunicación en formato de datos entre dos máquinas remotas sin necesidad de conexión a Internet sino que puede ser en una red privada y crear una industria inteligente donde todos los elementos están interconectados y comparten los datos.

Definiciones de wikipedia:

Diferencias entre IoT y M2M: https://www.pubnub.com/blog/2015-01-02-iot-vs-m2m-understanding-difference/

El coche autónomo, en el que trabajan grupos como Google, BMW, Volvo o Tesla, es toda una proeza de la robótica.La conducción autónoma se basa en las comunicaciones máquina a máquina (M2M), por las que los vehículos pueden intercomunicarse con las señales, los semáforos y los otros automóviles. Todo esto también tiene mucho que ver con las smart cities. 

http://www.dr4ward.com/.a/6a00e54fd9f059883301a73dc37274970d-800wi

Interesantes artículos de Basic IoT:

Reflexiones de David Cuartielles sobre IoT en base a un paper de IBM: https://vimeo.com/299112221 

Ontología IoT https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/

Empresas en el Mercado IoT

El artículo de Matt Turck hace un buen desglose de IoT https://mattturck.com/iot2018/, que resume en esta imagen:

Imagen completa: link

Listado de compañías IoT: http://dfkoz.com/iot-landscape/

Divide los mercados o aplicaciones verticales en:

  • Personal
  • Home
  • Vehículos
  • Empresa
  • Industria

Divide las Plataformas Horizontales en:

  • Software
  • Seguridad
  • Conectividad
  • Analítica
  • Desarrollo
  • Pagos
  • Interfaces
  • 3D

Y los Building Blocks de IoT los divide en:

  • Hardware
  • Infraestructura
  • Conectividad
  • Partners

Más información: https://mattturck.com/iot2018/

Mercados Verticales IoT

La Internet de los objetos está unificada por un principio común (extracción y análisis de datos digitales del mundo físico), así como por características comunes (combinación de hardware y software), oportunidades (personalización e inteligencia, servicios en tiempo real) y retos (conectividad, seguridad, etc.).  Más allá de estas, sin embargo, áreas tan diversas como la domótica, los aviones no tripulados comerciales, la maquinaria industrial o los coches autónomos están sujetos a dinámicas industriales muy diferentes.

En este curso vamos a ver IoT desde un punto general para poder ser aplicable en cualquier sector, pero cuando se va a acometer un proyecto IoT suele ser adecuado hacer un enfoque vertical en función del sector en el que se vaya a aplicar puesto que cada sector tienen unas características concretas.

Conceptos como Industria 4.0, Smart Cities, Agricultura 2.0, Smart Home, Smart factory, etc… al final son etiquetas y en lugar de especializarse en áreas tecnológicas como sensores, comunicaciones, protocolos, sistemas, etc… pensamos como especialistas de sectores porque un mismo concepto como el de IoT se puede aplicar a muchos sectores de de una forma distinta.

El vino y el IoT http://www.elmundo.es/economia/2016/11/03/5819d37346163f9c528b45c9.html

Visión horizontal IoT

Algunos mercados verticales IoT:

  • Sanidad/Salud
  • Retail
  • Construcción
  • Gobierno/Servicios Públicos
  • Smart Cities
  • Defensa
  • Manufactura y Cadena de Suministro
  • Fabricación
  • Industria
  • Robótica Industrial
  • Automoción/Coche Conectado/Coche Autónomo
  • Movilidad Urbana (BIcis/Patinetes)
  • UAV (Vehículos Aéreos no Tripulados)
  • Logística/Transporte/Almacenes
  • Agricultura/Medio ambiente/Agricultura Vertical
  • Energía/Smart Metering y Eficiencia Energética
  • Hogar Inteligente/Domótica/Inmótica y Robótica Doméstica.
  • Hoteles/Turismo
  • eHealth/Deporte
  • Smart Grid
  • Alimentación
  • Seguridad (Alarmas)
  • Wearables
  • Fitness/Sports
  • Educación/Juguetes
  • Asistentes de voz/Plataformas de voz

Más verticales en el artículo de Matt Turck: https://mattturck.com/iot2018/

Encuesta: https://www.forbes.com/sites/louiscolumbus/2016/11/27/roundup-of-internet-of-things-forecasts-and-market-estimates-2016/#28e2ea4d292d 

Smart Cities

El objetivo de las Smart Cities es aprovechar al máximo el desarrollo tecnológico para mejorar la calidad de vida de sus habitantes. Y su desarrollo se centra en 5 ejes principales: infraestructura, tecnología, economía, medioambiente y personas; por esto, este tipo de ciudades contribuyen a brindar seguridad a la ciudadanía, automatizar labores del día a día, reducir el tránsito en las calles…..

Los casos aplicables para ciudades inteligentes son numerosos: control del estado de los semáforos en función del volumen de tráfico en cada instante o del número de peatones que frecuentan la calle, supervisión del nivel de llenado de contenedores de basura para optimizar la recogida de residuos urbanos, o monitorización del número de aparcamientos libres en un parking, por citar algunos ejemplos de casos reales.

Puntos importante de las Smarts Cities:

Mercado Vertical Seguridad

El sector de la seguridad es uno de los más avanzados en IoT. Por ejemplo Securitas Direct:

Minut, startup sueca:

¿Qué Dispositivos podemos conectar a Internet?

La respuesta es: Cualquier cosa que podamos imaginar.

IoT en su amplio concepto es conectar a Internet cualquier cosa, teniendo sentido o sin tenerlo. Por ejemplo, podríamos conectar a internet un sofá con un Arduino y unos pocos sensores, este sofá podría tuitear que nos acabamos de sentar a ver nuestra serie favorita, simplemente detectando el peso de la persona y conectándose a una API de un servidor de streaming como netflix y comprobando que acabo de poner un capítulo de westworld.

Puede parecer una idea sin sentido, pero esta idea para Netflix podría ser muy interesante, monitorizar a la gente que ve su canal, cuántas veces se levanta el espectador o si se queda dormido.

Un ejemplo más serio de IoT es aplicar las nuevas tecnologías a elementos cotidianos que no imaginarías que tuviera sentido conectar a Internet, pero que pensándolo puede ser muy útil. Por ejemplo, pensemos en conectar a Internet un cortacésped. Con un Arduino podríamos conectar diversos sensores de temperatura del motor, temperatura externa, revoluciones del motor, consumo eléctrico (cortacésped eléctricos), gps, logs, etc… que podrían ser mandados a una plataforma del fabricante y le permitiría analizar esos datos para mejorar sus futuros productos o detectar averías de forma precoz. Podría mandar una desconexión remota en caso que en una determinada partida de fabricación se haya detectado un fallo que podría provocar daños al usuario o actualizar on-line el firmware si se detecta un fallo sin necesidad de llevar al servicio técnico.

Ejemplos de cortacesped conectados:

También podemos conectar a Internet un bastón o una botas de seguridad:

Otra aplicación de IoT usando Arduino o Raspberry Pi como herramienta, es la de obtener información externa disponible mediante APIs del open data. Un ejemplo es el de un sistema de riego automático que podemos tener en una ciudad. En los inicios de la automatización se usaron programadores conectados a una electroválvula donde indicamos las horas entre las que deseamos regar. El siguiente paso fue poner detectores de lluvia para no regar si estaba lloviendo. Otro paso fue poner sensores de temperatura y humedad ambientales y sensores de humedad de suelo que nos indican cuándo debemos regar y en qué áreas de la ciudad.

El paso más avanzado que ofrece el IoT es poder conectar todo este sistema, ya de por sí muy eficiente, a los opendata meteorológicos disponibles en Internet como el de la aemet http://www.aemet.es/es/datos_abiertos/AEMET_OpenData y que nuestro sistema obtenga datos de prediciones meteorológicas y decida no regar si la predicción de lluvia es mayor del 80% en los próximos dos días o simplemente ajustar el algoritmo de riego en función los valores de los sensores + es de los datos meteorológicos. También puede recibir alertas de tormenta o pedrisco y tomar determinadas acciones o simplemente mandar un email o SMS al propietario del huerto. ¿Podríamos hacer esto con un sistema comercial?

Esto podría extenderse a explotaciones agrícolas usando un servicio como el sistema de información agroclimática de La Rioja:

Un ejemplo práctico de esto es el proyecto Aggrofox: 

Aggrofox: IoT sensing, notifications and analytics platform for urban and large-scale agriculture with automated irrigation, using Sigfox technology: https://www.hackster.io/107329/aggrofox-large-scale-and-urban-agriculture-iot-solution-8155fe 

IoT no es que un coche se pueda conectar a Internet para ver videos de youtube, sino que este coche esté conectado a Internet para que pueda actualizar su firmware automáticamente para dotar de nuevas funcionalidades sin necesidad de ir al concesionario, pueda ser inmovilizado en caso de robo o pueda mandar datos de los parámetros internos del coche para que sean analizados y poder detectar alertas precoces de fallo y actualizar automáticamente ese fallo sin que el usuario tenga que hacer nada o avisar al usuario para que lleve el coche a reparar y parar el coche si el usuario no ha llevado a revisión al cabo de unos kms para evitar males mayores.

Interesantes reflexiones sobre IoT: 

Ejemplo de Aplicaciones IoT

El conectar dispositivos a Internet puede tener muchos usos y aplicaciones que hasta ahora no hubiéramos imaginado.

Aplicaciones de IoT: https://temboo.com/iot-applications 

http://www.dragino.com/media/k2/galleries/119/LG01-40.jpg 

Algunos ejemplos

  • Monitorización en Tiempo real
  • Avisos precoces
  • Control remoto de instalaciones
  • Eficiencia energética
  • Automatización de procesos
  • Automatización de informes/Cuadros de mando
  • Mantenimientos Predictivos
  • PRL (Prevención de Riesgos Laborales)
  • análisis de datos (data mining, etc…)
  • Monitorización y notificación
  • Business intelligence (detectar problemas comunes, medir cuellos de botella, etc…) y ayudar en el mantenimiento predictivo.
  • Integrar con el software corporativo. ERP, CRM, GMAO (Gestión del Mantenimiento Asistido por Ordenador), CMMS
  • Recoger datos y tenerlos en tiempo real por ejemplo datos para sanidad en cámaras frigoríficas.
  • Automatizar todo el papeleo siendo recogidos los datos y guardados y generados los informes.

Ejemplos de uso:

  • Estación meteorológica: medidas de temperatura y humedad exterior (tiempo real)
    • Posible caso de uso 1:controlar la temperatura interior (encender/apagar el aire acondicionado, los radiadores, etc.)
    • Posible caso de uso 2: jardinería (urbanizaciones, comerciales o incluso smart cities que gestionan grandes jardines comunitarios) el riego fácil gracias a las previsiones.
  • Sistema de alarma: basado en la detección de personas, la seguridad del edificio puede ser más fácil.
    • Posible caso de uso 1: despliegue de varias aplicaciones de alarma, sensores de personas o de llama/calor en combinación con aplicaciones para smartphones, para estar siempre conectados a edificios públicos o locales comerciales.
  • Previsión del tráfico: a partir de medidas de tráfico regulares, se pueden construir ciudades inteligentes.
    • Posible caso de uso 1: escenarios para comunicarse con la gente que está en la calle -> tráfico potencial en la carretera con sugerencias directas de alternativas -> muy útil para los servicios de entrega de alimentos en las grandes ciudades.
  • Servicios de entrega (por ejemplo, servicio de pizza): seguimiento de los vehículos de entrega, búsqueda de las rutas más rápidas y posterior análisis de marketing (basado en datos históricos) para centrar las futuras actividades de marketing en las «zonas calientes».

Interesante web donde sacar más información de IoT: https://www.insight.tech/ 

Ejemplo real de uso empresa riojana: https://www.encore-lab.com/es/proyectos/humecfol 

Buen artículo de Luis del Valle sobre Proyectos IoT: https://programarfacil.com/podcast/proyectos-iot-con-arduino/

Ejemplo Práctico IoT

Riego automático de un jardín personal, explotación agrícola o ciudad. Fases:

  • Riego manual
  • Riego automatizado por horario y remoto → Temporizador
  • Riego bajo demanda con sensores de humedad, etc… → PLCs
  • Riego sostenible aprovechando las lluvia y las previsiones → IoT

Conectar a Internet los sistemas de riego para obtener las previsiones de lluvia y programar en función de los sensores de lluvia y las previsiones de lluvia ¿cómo?:

Para ello hay que leer la documentación de la API, buscar el “comando” que nos interesa, darse de alta en el servicio para obtener la API key (contraseña) y ejecutar en nuestro sistema.

Y un paso más, predecir enfermedades de los cultivos: http://apisiar.larioja.org/help 

AEMET

Llamada desde acceso: https://opendata.aemet.es/opendata/api/prediccion/especifica/municipio/diaria/39075/?api_key=111111111111

Obtengo:

{
  "descripcion" : "exito",
  "estado" : 200,
  "datos" : "https://opendata.aemet.es/opendata/sh/b904851e",
  "metadatos" : "https://opendata.aemet.es/opendata/sh/dfd88b22"
}

Visores JSON:

Predicción diaria por municipio: https://opendata.aemet.es/dist/index.html?#!/predicciones-especificas/Predicci%C3%B3n_por_municipios_diaria_Tiempo_actual 

Ejemplo con Node-RED: https://github.com/aprendiendonodered/AEMET_Prediccion_Dias 

OpenWeatherMap

Llamada: https://api.openweathermap.org/data/2.5/forecast?q=santander&units=metric&appid=1111

Ejemplo con Node-RED: 

[{"id":"ceb7af605b6e347f","type":"tab","label":"Flow 3","disabled":false,"info":""},{"id":"4f69f0089f144b46","type":"openweathermap","z":"ceb7af605b6e347f","name":"","wtype":"forecast","lon":"","lat":"","city":"santander","country":"ES","language":"en","x":260,"y":60,"wires":[["0ecd1ae54f3fc616"]]},{"id":"4a4ee3087a02a1bb","type":"inject","z":"ceb7af605b6e347f","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":110,"y":60,"wires":[["4f69f0089f144b46"]]},{"id":"0ecd1ae54f3fc616","type":"debug","z":"ceb7af605b6e347f","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":410,"y":60,"wires":[]}]