Arduino enviando datos (MQTT)

MQTT es un poderoso protocolo que se ha convertido en el líder dentro de la conectividad M2M (Machine to Machine), es particular dentro del IoT o Internet de las Cosas. De echo, no es la primera vez que hablamos de él en este blog y te recomiendo que, antes de leer este post, te leas detenidamente Primeros Pasos con MQTT ya que esta entrada se puede considerar como una continuación.

Primeros Pasos con MQTT

En esta entrada vamos a explicar las diferentes motivaciones que nos llevarán en la siguiente semana a emplear este protocolo y Arduino de forma conjunta, estableciendo una arquitectura muy poderosa que tiene todas las posibilidades para convertirse en nuestra arquitectura de referencia en todo aquello relacionado con Internet de las Cosas.

Además, intentaremos dejar todo preconfigurado para poder, en el siguiente post, ir directamente a la comunicación en sí.

Configuración inicial

Como decía con anterioridad, este post no va a empezar de cero sino que se apoya en los conceptos que ya habíamos comentado con anterioridad. Por tanto supondremos que contamos con un 'broker' previamente configurado en un PC u otro dispositivo (una Raspberry Pi es una excelente opción).

Concretamente, en mi caso, tengo Mosquitto configurado en una Raspberry Pi y aceptando conexiones de toda mi red local.

Por otra parte, necesitamos un Arduino con un sensor conectado y configurado. Aunque todo el contenido de la configuración de Arduino, ya te puedo adelantar que usaremos nuestro "archiconocido" sensor de temperatura DHT22. Puedes leer más sobre esta configuración en DHT22, unamos sensores, Arduino, Ethernet y Android.

Sabiendo que tenemos un Broker disponible, la idea es publicar mensajes a través de él empleando un Arduino y, mediante otro Arduino, subscribirnos al mismo "topic" en el que publicábamos para recibir esa información.

Vamos a necesitar por tanto dos Arduinos diferentes y vamos a ver como comunicarlos entre de ellos de forma completamente escalable. Si sólo tienes uno, podrás realizar los pasos descritos en el siguiente post, pero de algún modo tendrás que emular la emisión o recepción de información empleando por ejemplo el propio Mosquitto tal y como veíamos en la entrada de Primeros Pasos con MQTT.

Por qué quiero escalabilidad

Como te decía en la introducción, en esta entrada vamos a intentar entender los porqués de usar MQTT y Arduino en un entorno semejante al del Internet de las Cosas, dejando para la siguiente entrada el cómo. Creo que es muy importante entender las motivaciones que se encuentran detrás de este uso, para después poder ser capaz de seleccionar el método que más nos convenga entre las distintas opciones disponibles.

Gracias a esta entrada teórica y la posterior práctica no sólo conseguiremos la comunicación en sí, ampliando nuestro número de herramientas disponibles para enviar/recibir información relacionada con el Internet de las Cosas, sino que también aprenderemos cómo esta solución destaca por ser una manera muy escalable de realizar esta operación.

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.

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

Por último, permite separar la capa hardware un poco más. Soy un firme defensor de generar arquitecturas / estructuras formadas por componentes y sistemas atómicos intentando que cada uno haga una sola cosa pero la haga bien. Creo que esta aproximación permite una reutilización del esfuerzo en proyectos posteriores y facilita de forma considerable su evolución y mantenimiento. Dependiendo del entorno del que vengas, es posible que te suene el patrón de Software basado en Microservicios que ha popularizado Netflix y que cada día gana más terreno en todos los ámbitos. Personalmente creo que es un patrón de diseño perfecto para todo aquello que se refiere con tecnologías de la información y considero que en nuestro caso (envío de información de sensores) estamos en un caso de uso donde podemos explotarlo.

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.

Esa es la potencia real que se esconde detrás de esta filosofía y el motivo por el cual considero tan ventajosa su utilización.

La próxima semana, con toda esta información procesa, nos pondremos manos a la obra y construiremos paso a paso esta comunicación (recuerda tener los deberes hechos a.k.a "Configuración inicial"). Verás que aunque aporta unas ventajas que hacen un sistema mucho más completo, no lleva asociado ningún tipo de complicación.

¡Nos vemos la próxima semana!