Archivo de la etiqueta: Conectividad IoT

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:

Gateways IoT

Un Gateway IoT es un dispositivo físico o un programa de software que sirve como punto de conexión entre la nube y los controladores, sensores y dispositivos inteligentes. Todos los datos que se mueven a la nube, o viceversa, pasan por el gateway, que puede ser un dispositivo de hardware dedicado o un programa de software. Un gateway IoT también puede denominarse pasarela inteligente o nivel de control.

Algunos sensores generan decenas de miles de puntos de datos por segundo. Una pasarela proporciona un lugar para preprocesar esos datos localmente en el borde antes de enviarlos a la nube. Cuando los datos se agregan, se resumen y se analizan tácticamente en el borde, se minimiza el volumen de datos que deben ser enviados a la nube, lo que puede tener un gran impacto en los tiempos de respuesta y en los costes de transmisión de la red.

En contraposición con la infraestructura cloud tradicional, basada en grandes centros de datos que centralizan el poder computacional, otros paradigmas como Fog Computing proponen la distribución de esta capacidad de cómputo hacia los extremos de la red. Este paradigma busca solventar los problemas de comunicación de datos entre los dispositivos generadores y consumidores de los mismos al acercar los centros de procesado y análisis de datos hacia ellos, reduciendo de esta forma la latencia y el uso de la infraestructura de red.

Se habla de Edge Computing en referencia a una infraestructura, que se puede entender como un caso específico de Fog Computing. Un escenario típico puede ser el caso de uso de Internet of Things (IoT) en el que los nodos de computación se necesitan estar físicamente cerca de las fuentes de datos, como un robot industrial o un sensor de presión de un tanque de combustible o un indicador de consumo de la red eléctrica. En general se puede definir un nodo de computación Edge como un hardware con capacidad de cómputo situado físicamente cerca de los dispositivos o equipos que hacen uso de sus recursos, bien sea en la propia maquinaria, en una planta de producción o en un almacén.

Más información:

Otra ventaja de una pasarela de IoT es que puede proporcionar seguridad adicional para la red de IoT y los datos que transporta. Dado que el gateway gestiona información que se mueve en ambas direcciones, puede proteger los datos que se mueven hacia la nube de fugas y dispositivos de IoT de ser comprometidos por ataques externos maliciosos con características tales como detección de manipulaciones, cifrado, generadores de números aleatorios de hardware y motores de cifrado.

La pasarela IoT desempeña un papel importante en la gestión de los dispositivos. Cada dispositivo (sensor/actuador) tiene un caso de uso diferente y emite mensajes a través de diferentes canales como Wifi, BLE, Zigbee, Ethernet, RF, LPWAN, LTE, etc. y el gateway realiza varias funciones como conectividad de dispositivos, traducción de protocolos, agregación, filtrado, correlación, seguridad, actualizaciones, administración y más. Se sitúa entre los dispositivos y la plataforma de nube.

Además un Gateway puede hacer conexión VPN segura entre localizaciones diferentes, permitiendo unir de forma segura diferentes puntos a través de Internet.

Routers y Gateways industriales inteligentes https://ewon.biz/es  

Hace no tantos años la conexión remota era por módem o por GSM con conexiones pto a pto. En la actualidad usamos internet para el telecontrol, pero es un problema el tema de la seguridad. Ya existen dispositivos como el router industrial eWON Flexy https://ewon.biz/es/productos/flexy modular que es servidor OPC UA y cliente openvpn, es muy potente para conectar y dar funcionalidades adicionales a unos autómatas.

eWON monta la VPN y al ser servidor modbus TCP y OPC UA, es posible acceder remotamente y de forma segura a los datos del autómata e integrarlo con datos de otras localizaciones.

Ejemplo Gateway LoRa:

Y el código: https://github.com/jecrespo/aprendiendoarduino-lora/blob/master/Demo_LoRa/rf95_server/rf95_server.ino 

Programación de los Gateways IoT:

Gateways Industriales

Los gateways industriales permite la traducción de protocolos típicamente industriales como Modbus RTU/ASCII/TCP a PROFINET o PROFIBUS a protocolos de Internet como HTTP o MQTT, permitiendo actualizar los dispositivos industriales a los nuevos protocolos de comunicación en Internet. 

Los gateways de IIoT o «nube» se distinguen por su énfasis en servir datos de dispositivos hasta una nube u otros componentes de la Internet industrial. Los factores diferenciadores incluyen el uso de un microprocesador y un sistema operativo estándar, como la plataforma Intel IoT, así como el soporte de APIs de Transferencia de Estado Representacional (REST), Transporte de Telemetría de Colas de Mensajes (MQTT), y otros protocolos de integración y transporte de datos de la IoT. También se puede utilizar para este fin la OPC UA (Arquitectura Unificada).

Estos gateways también pueden añadir una capa adicional de seguridad con el uso de VPNs u otras comunicaciones seguras.

Más información:

Matriz de selección de gateways industriales: https://www.moxa.com/Moxa/media/Resources/DownloadFile/mgate-quick-card-en.pdf

Existen diversas opciones para gateways industriales para conversión de protocolos:

Anybus hace pasarelas y dispositivos de comunicaciones. Las pasarelas permiten hacer un upgrade a Industrial ethernet:

HMS es el distribuidor de anybus: https://www.hms-networks.com/

Seguridad en Gateways

Un Edge Gateway se encuentra en la intersección de los sistemas de borde (edge), entre la Internet externa y la intranet local que está siendo utilizada por los otros dispositivos de su ecosistema. Por lo tanto, es el punto de acceso clave para la conectividad de red, tanto dentro como fuera del ecosistema de dispositivos.

Existen tres principios fundamentales de la seguridad: confidencialidad, integridad y disponibilidad. Deberá asegurarse de que todas las comunicaciones entre el gateway y los dispositivos cumplen cada uno de los tres principios mientras se produce la comunicación en las redes internas y externas.

También vale la pena señalar que la puerta de enlace es a menudo la primera en ser atacada por dos razones:

  • Tiene una mayor potencia de procesamiento, que puede utilizar para ejecutar aplicaciones más intensivas. Más potencia significa mejor software, pero mejor software significa más vulnerabilidades para que un hacker las explote.
  • Debido a su ubicación como dispositivo Edge entre Internet e Intranet, el gateway es el punto de entrada de cualquier vector de amenaza (así como la primera línea de defensa del sistema).

Las recomendaciones sobre la seguridad de un dispositivo de pasarela de la IoT constan de tres pasos.

  • Identidad para el dispositivo Gateway. Dar al gateway una identidad (utilizando un certificado digital X.509). 
  • Habilitar la identidad «sólida» para el dispositivo Gateway
  • Utilizar el Gateway para proporcionar identidad a su ecosistema

Más información:

Comunicaciones Arduino

Una de las principales ventajas de Arduino es que podemos dotarlo de comunicación de una forma sencilla añadiendo un shield o una breakout board y dispondremos de casi cualquier tipo de comunicación tanto de acceso a Internet como de para comunicar arduinos entre sí o con otros dispositivos de una red privada.

Ethernet: la forma más clásica de comunicar arduino mediante el shield de ethernet. https://www.arduino.cc/en/Main/ArduinoEthernetShield

Wifi: Hay múltiples formas de conectar Arduino a internet mediante wifi:

Bluetooth: https://aprendiendoarduino.wordpress.com/2016/11/13/bluetooth-en-arduino/

Conectividad Arduino

Arduino puede comunicarse con cualquier medio usando el HW adecuado. Comunicaciones para Arduino:

Conectividad IoT

Una de las principales ventajas de Arduino es que podemos dotarlo de comunicación de una forma sencilla añadiendo un shield o una breakout board y dispondremos de casi cualquier tipo de comunicación tanto de acceso a Internet como de para comunicar arduinos entre sí o con otros dispositivos de una red privada.

Articulo interesante redes: https://www.artik.io/blog/2015/iot-101-networks

Articulo interesante conectividad: https://www.artik.io/blog/2015/iot-101-connectivity

Leer este white paper: http://www.ti.com/lit/wp/swry017/swry017.pdf

Guía de conectividad de IoT:  https://www.ibm.com/developerworks/library/iot-lp101-connectivity-network-protocols/index.html

Interesante artículo sobre redes para IoT: https://www.redeweb.com/articulos/software/11-redes-inalambricas-fundamentales-para-internet-de-las-cosas/

IOT primeras redes IoT en Holanda y Corea: http://blogthinkbig.com/nace-la-primera-y-la-segunda-red-para-internet-de-las-cosas/

Muy buena explicación de comunicaciones: https://learn.adafruit.com/alltheiot-transports/introduction

Redes Inalámbricas IoT

ZigBee

ZigBee es una tecnología inalámbrica más centrada en aplicaciones domóticas e industriales. Los perfiles ZigBee PRO y ZigBee Remote Control (RF4CE) se basan en el protocolo IEEE 802.15.4, una tecnología de red inalámbrica que opera a 2,4GHz en aplicaciones que requieren comunicaciones con baja tasa de envío de datos dentro de áreas delimitadas con un alcance de 100 metros, como viviendas o edificios.

IEEE 802.15.4 es un estándar que define el nivel físico y el control de acceso al medio de redes inalámbricas de área personal con tasas bajas de transmisión de datos (low-rate wireless personal area network, LR-WPAN). El grupo de trabajo IEEE 802.15 es el responsable de su desarrollo. También es la base sobre la que se define la especificación de ZigBee, cuyo propósito es ofrecer una solución completa para este tipo de redes construyendo los niveles superiores de la pila de protocolos que el estándar no cubre.

ZigBee/RF4CE tiene algunas ventajas significativas como el bajo consumo en sistemas complejos, seguridad superior, robustez, alta escalabilidad y capacidad para soportar un gran número de nodos. Así, es una tecnología bien posicionada para marcar el camino del control wireless y las redes de sensores en aplicaciones IoT y M2M.

  • Estándar: ZigBee 3.0 basado en IEEE 802.15.4
  • Frecuencia: 2.4GHz
  • Alcance: 10-100m
  • Velocidad de transferencia: 250kbps

XBee

es el nombre comercial del Digi de una familia de módulos de comunicación por radio y están basados en el estándar zigbee, pero digi tiene muchos Xbee y algunos son zigbee estándar y otros son propietarios o modificaciones del estándar. Existen muchos módulos Xbee basados en el estándar IEEE 802.15.4

Más información: https://aprendiendoarduino.wordpress.com/2016/11/16/zigbeexbee/

WiFi

Normalmente la conectividad WiFi es la opción obvia elegida por los desarrolladores dada la omnipresencia de WiFi en entornos domésticos y comerciales: existe en la actualidad una extensa infraestructura ya instalada que transfiere datos con rapidez y permite manejar grandes cantidades de datos. Actualmente, el standard WiFi más habitual utilizado en los hogares y en muchas empresas es el 802.11n, ofreciendo un rendimiento significativo en un rango de cientos de megabits por segundo, muy adecuado para la transferencia de archivos, pero que consume demasiada potencia para desarrollar aplicaciones IoT.

  • Estándar: Basado en 802.11n
  • Frecuencia: 2,4GHz y 5GHz
  • Alcance: Aproximadamente 50m
  • Velocidad de transferencia: hasta 600 Mbps, pero lo habitual es 150-200Mbps, en función del canal de frecuencia utilizado y del número de antenas (el standard 802.11-ac ofrece desde 500Mbps hasta 1Gbps)

Bluetooth

Bluetooth es una de las tecnologías de transmisión de datos de corto alcance más establecidas, muy importante en el ámbito de la electrónica de consumo. Las expectativas apuntan a que será clave para desarrollar dispositivos wearable, ya que permitirá el establecimiento de conexiones IoT, probablemente a través de un smartphone.

El nuevo Bluetooth de baja energía, también conocido como Bluetooth LE o Bluetooth Smart, es otro protocolo importante para desarrollar aplicaciones IoT. Se caracteriza por ofrecer un alcance similar al de la tecnología Bluetooth normal pero con un consumo de energía significativamente reducido.

Es importante destacar que la versión 4.2, gracias a la incorporación del Internet Protocol Support Profile, permite conectarse directamente a internet mediante IPv6/6LoWPAN. Esto facilita el utilizar la infraestructura IP existente para gestionar dispositivos Bluetooth Smart basado en “edge computing”.

  • Estándar: Bluetooth 4.2
  • Frecuencia: 2,4GHz (ISM)
  • Alcance: 50-150m (Smart/LE)
  • Velocidad de transferencia: 1Mbps (Smart/LE)

Thread

En la actualidad, el protocolo de red más innovador basado en IPv6 es Thread. Diseñado para domótica, está basado en 6LowPAN, y del mismo modo que aquel, no es un protocolo de aplicaciones IoT como Bluetooth o ZigBee. Se diseñó como un complemento WiFi, puesto que aunque la tecnología Wi-Fi funciona muy bien en dispositivos de consumo, tiene limitaciones al utilizar en configuraciones de domótica.

Lanzado a mediados del 2014 por Thread Group, este protocolo sin canon de uso se basa en varios protocolos como IEEE 802.15.4, IPv6 y 6LoWPAN.

Es una solución resistente basada en IP para aplicaciones IoT.

Diseñado para trabajar sobre chips IEEE 802.15.4 ya existentes de fabricantes como Freescale y Silicon Labs, Thread es compatible con redes de topología de malla al utilizar radio transceptores IEEE802.15.4, siendo capaz de manejar hasta 250 nodos con altos niveles de autenticación y cifrado.

Una actualización de software relativamente sencilla permite a los usuarios utilizar thread en dispositivos ya compatibles con IEEE 802.15.4.

  • Estándar: Thread, basado en IEEE802.15.4 y 6LowPAN
  • Frecuencia: 2,4GHz (ISM)
  • Alcance: N/A
  • Velocidad de transferencia: N/A

Red de telefonía móvil

Cualquier aplicación IoT que necesite funcionar en grandes áreas puede beneficiarse de las ventajas de la comunicación móvil GSM/3G/4G.

La red de telefonía móvil es capaz de enviar grandes cantidades de datos, especialmente a través de 4G, aunque el consumo de energía y el coste económico de la conexión podrían ser demasiado altos para muchas aplicaciones.

Sin embargo, puede ser ideal para proyectos que integren sensores y que no requieran un ancho de banda muy grande para enviar datos por Internet.

  • Estándares: GSM/GPRS/EDGE (2G), UMTS/HSPA (3G), LTE (4G)
  • Frecuencias: 900 / 1800 / 1900 / 2100
  • Alcance: hasta 35km para GSM; hasta 200km para HSPA
  • Velocidad de transferencia (descarga habitual): 35-170kps (GPRS), 120-384kbps (EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-10Mbps (LTE)

Neul

El concepto de este sistema es similar al de Sigfox y funciona en la banda sub-1GHz. Neul aprovecha pequeños fragmentos de la “banda blanca” de las estaciones de TV para ofrecer alta escabilidad, amplia cobertura y bajo costes.

Este sistema se basa en el chip Iceni, que se comunica utilizando los “banda blanca” de la radio para acceder al espectro UHF de alta calidad. Ya está disponible debido a la transición analógica a la televisión digital.

La tecnología de comunicaciones que utiliza se llama Weightless, que es una nueva tecnología de red inalámbrica ampliada diseñada para aplicaciones IoT que compite contra las soluciones GPRS, 3G, CDMA y LTE WAN.

La velocidad de transferencia de datos puede ir de unos bits por segundo hasta 100 Mbps en el mismo enlace. Desde el punto de vista del consumo, los dispositivos consumen tan solo de 20 a 30 mA, es decir, de 10 a 15 años de autonomía con 2 pilas AA.

Para poder emplear esta tecnología hay que tener en cuenta la decisión que se haya tomado acerca del uso de las frecuencias de la banda blanda.

  • Estándar: Neul
  • Frecuencia: 900MHz (ISM), 458MHz (UK), 470-790MHz (espacios en blanco)
  • Alcance: 10km
  • Velocidad de transferencia: Desde unos pocos bps hasta 100kbps

6LoWPAN

6LowPAN (IPv6 Low-power wireless Personal Area Network) es una tecnología inalámbrica basada en IP muy importante. En vez de tratarse de una tecnología de protocolos de aplicaciones IoT, como Bluetooth o ZigBee, 6LowPAN es un protocolo de red que permite mecanismos de encapsulado y compresión de cabeceras. Esta tecnología ofrece libertad de banda de frecuencia y capa física, por lo que se puede utilizar a través de múltiples plataformas de comunicaciones, como Ethernet, Wi-Fi, 802.15.4 y sub-1GHz ISM.

Una característica clave es la introducción de la pila IPv6 (protocolo de internet versión 6), una innovación clave en el avance de IoT en los últimos años, ya que con IPv6 se ofrecen aproximadamente 5 x 10E28 direcciones IP a nivel global, permitiendo que cualquier objeto o dispositivo embebido tenga su propia dirección IP única para conectarse a Internet.

Ha sido diseñada especialmente para el hogar y la automatización de edificios proporcionando un mecanismo de transporte básico para producir sistemas de control complejos e interconexión de dispositivos de un modo económico a través de una red inalámbrica de bajo consumo.

Diseñada para enviar paquetes IPv6 sobre redes IEEE 802.15.4, para luego implementar protocolos superiores como TCP, UDP, HTTP, COAP, MQTT y websockets, 6LowPAN es una red de topología en malla robusta, escalable y auto-regenerativa. Los routers pueden encaminar datos enviados a otros dispositivos, mientras que los hosts permanecen inactivos mucho tiempo.

  • Estándar: RFC6282
  • Frecuencia: adaptable a múltiples capas físicas como Bluetooth Smart (2.4GHz), ZigBee o comunicación RF de bajo consumo (sub-1GHz)
  • Alcance: N/A
  • Velocidad de transferencia: N/A

LoRaWAN

Es una especificación de una red LPWAN (Low Power Wide Area Network) propuesta por la LoRa Alliance y pensada para comunicar dispositivos de bajo coste y bajo consumo alimentados por baterías. La especificación cubre las capas PHY y MAC de la red, dejando a las aplicaciones el resto de capas. En la banda ISM de 868MHz (915 MHz en otras regiones), con un bitrate de hasta decenas de kbps (de 0.3 kbps hasta  50 kbps).

Enlaces:

Esta tecnología se parece en algunos aspectos a Sigfox y a Neul. LoRaWAN está diseñada para implementar redes de área amplia (WAN) con características específicas para soportar comunicaciones móviles, bidireccionales, económicas y seguras para aplicaciones de IoT, M2M, ciudades inteligentes y aplicaciones industriales.

Optimizada para bajo consumo de energía y para ofrecer amplias redes con millones y millones de dispositivos, sus velocidades de transferencia de datos van desde 0,3 kbps hasta 50 kbps.

  • Estándar: LoRaWAN
  • Frecuencia: Varias
  • Alcance: 2-5km (entorno urbano), 15km (entorno rural)
  • Velocidad de transferencia: 0,3-50 kbps.

Z-Wave

Z-Wave es una tecnología RF de bajo consumo diseñada inicialmente para productos de domótica como controladores de iluminación y sensores. Optimizado para la comunicación fiable de baja latencia de pequeños paquetes de datos, alcanza velocidades de datos de hasta 100kbit/s, opera en la banda de sub-1 GHz y es robusta frente a interferencias de Wi-Fi y otras tecnologías inalámbricas en el rango 2,4 GHz como Bluetooth o ZigBee. Es totalmente compatible con redes de topología de malla, no necesita un nodo coordinador y es muy escalable, permitiendo controlar hasta 232 dispositivos.

Z-Wave utiliza un protocolo más simple que otras tecnologías lo que permite una mayor rapidez en el desarrollo, pero el único fabricante de chips compatibles es la empresa Sigma Design, en comparación con la multitud de empresas que ofrecen productos de otras tecnologías inalámbricas como ZigBee o Bluetooth.

  • Estándar: Z-Wave Alliance ZAD12837 / ITU-T G.9959
  • Frecuencia: 900MHz (Banda ISM)
  • Alcance: 30m
  • Velocidad de transferencia: 9,6/40/100kbit/s

NFC

NFC (Near Field Communication) es una tecnología que permite dos vías simultáneas de interacción segura entre dispositivos electrónicos, siendo especialmente adecuada para smartphones, permitiendo a los consumidores realizar transacciones de pago, acceder al contenido digital y conectar dispositivos electrónicos, todo ellos sin contacto. Esencialmente, amplía la capacidad de la tecnología contacless de las tarjetas inteligentes permitiendo conexiones punto a punto y modos de funcionamiento activos y pasivos.

  • Estándar: ISO/IEC 18000-3
  • Frecuencia: 13.56MHz (ISM)
  • Alcance: 10cm
  • Velocidad de transf.: 100–420kbps

nRF24

Este dispositivo NRF2401, integra en un único chip, toda la electrónica y bloques funcionales precisos, para establecer comunicaciones RF (Radio Frecuencia) entre dos o más puntos a diferentes velocidades, (Hasta 2  Mb/seg) con corrección de errores y protocolo de reenvío cuando es necesario, sin intervención del control externo, lo que nos permite aislarnos de todo el trabajo sucio y complicado relacionado con la transmisión física.

Información de producto: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01

Sigfox

Es una solución de conectividad celular mundial para el Internet of Things pensada para comunicaciones de baja velocidad que permite reducir los precios y el consumo de energía para los dispositivos conectados. La solución de conectividad SIGFOX se basa en una infraestructura de antenas y de estaciones de base totalmente independientes de las redes existentes.

En la red SIGFOX se transmiten mensajes de 12 bytes, pudiendo enviar 140 mensajes al día.

Sigfox trabaja con fabricantes como Texas Instruments, Atmel, Silicon Labs y otros para poder ofrecer distintos tipos de SOC, transceptores y componentes de conexión a su red. En el caso de smartphones y tablets, actualmente no son compatibles con esta red, pero, al no tener licencia de uso, su inclusión sería realmente económica y sencilla.

Es una alternativa de amplio alcance es Sigfox, que en términos de alcance está entre Wi-Fi y la comunicación móvil. Utiliza bandas ISM, que se pueden utilizar sin necesidad de adquirir licencias.

Sigfox responde a las necesidades de muchas aplicaciones M2M que funcionan con una batería pequeña y solo requieren niveles menores de transferencia de datos, allí donde WiFi se queda demasiado corto y la comunicación móvil es muy cara y consume demasiada energía.

Sigfox utiliza una tecnología llamada Ultra Narrow Band (UNB) diseñada para funcionar con bajas velocidades de transferencias de 10 a 1.000 bits por segundo.

Solo consume 50 microvatios (la comunicación móvil consume 5.000 microvatios) además de poder mantenerse en stand-by 20 años con una batería 2.5Ah (0,2 años para comunicaciones móviles).

Esta tecnología es robusta, energéticamente eficiente y funciona como una red escalable que puede comunicarse con millones de dispositivos móviles a lo largo de muchos kilómetros cuadrados. Así pues, es adecuada para aplicaciones M2M como: contadores inteligentes, monitores médicos, dispositivos de seguridad, alumbrado público y sensores ambientales.

El sistema Sigfox utiliza los transceptores inalámbricos que funcionan en la banda sub-1GHz ofreciendo un rendimiento excepcional, mayor alcance y un consumo mínimo.

  • Estándar: Sigfox
  • Frecuencia: 900MHz
  • Alcance: 30-50km (ambientes rurales), 3-10km (ambientes urbanos)
  • Velocidad de transferencia: 10-1000bps

Más información: https://www.rs-online.com/designspark/eleven-internet-of-things-iot-protocols-you-need-to-know-about

Retos de IoT

Algunos de los retos de IoT:

  • Bajo consumo
  • Diseño de HW eficiente
  • Compatibilidad electromagnética
  • Seguridad
  • Conectividad y redes adecuadas
  • Escalabilidad
  • Sistemas robustos

Actualmente el reto de IoT es marcar un estándar de comunicación entre el HW y las plataformas que generalmente se encuentran en la nube de forma que todos los dispositivos se puedan comunicar con todas las plataformas de IoT. Otro reto es la integración de todos los sistemas/elementos de los que disponemos.

A nivel de hardware el reto es el uso eficiente de energía para tener dispositivos remotos que puedan funcionar con baterías por años. En esta web tienen productos para recoger energía del entorno y pulsadores sin baterías: https://www.enocean.com/en/

El tener dispositivos con una autonomía de uso de varios años también dependerá de la tecnología usada y del desarrollo de las baterías. Un buen artículo sobre baterías:

Además el propio dispositivo IoT tiene que tener una gestión de energía eficiente. En estos artículos da unos consejos:

También es muy importante un buen diseño de la placa para IoT. En este documento da información de ellos: https://www.artik.io/blog/2016/11/printed-circuit-boards-for-iot/

Si desarrollamos nuestro propio hardware IoT, hay que tener en cuenta la compatibilidad electromagnética (EMC): https://www.artik.io/blog/2016/11/iot-201-emc-compliance/

Otro reto de IoT  es la seguridad:

Encontrar una conectividad y redes adecuada es un reto al que cualquiera que quiera hacer un proyecto IoT se va a enfrentar:

También es importante crear sistema escalables que puedan crecer fácilmente y que sean sistemas robustos y resistentes, esto se pondrá a prueba por el enorme volumen de datos que se generará. Problemas de tráfico de red, almacenamiento, procesamiento, aprendizaje y explotación serán algunos puntos a tener muy en cuenta al diseñar una solución IoT.

Por último IoT debe ser fácil de adoptar por personas/empresas sin experiencia previa si queremos que se adopte la digitalización de las empresas.

Barreras de IoT

  • ciberseguridad
  • retorno de la inversión
  • integrar máquinas antiguas
  • precio

Más información: