IoT Gate Opener con la placa Ganimede.E12
Con la placa Ganimede.E12, gestionamos la apertura y el cierre de un portón, o de otros dispositivos electrónicos, utilizando una aplicación móvil dedicada. Este proyecto permite integrar hardware tradicional a un ecosistema conectado sin complicaciones.
El problema con los dispositivos IoT DIY actuales
Hoy en día, la atención sobre la domótica y los dispositivos IoT (Internet de las Cosas) es tan amplia que frecuentemente buscamos electrodomésticos o dispositivos eléctricos con software que nos permita gestionarlos de forma eficiente. Sin embargo, controlar un aire acondicionado o persianas de forma remota suele costar más que los dispositivos puramente mecánicos, sin mencionar que para controlarlos desde nuestros celulares tendríamos que reemplazarlos por equipos más modernos, a pesar de que los antiguos funcionan perfectamente.
Además, un aspecto que aquellos menos familiarizados con el tema no consideran es la ciberseguridad. Es cierto que no es necesario implementar medidas de seguridad similares a las de un banco o un automóvil para gestionar electrodomésticos simples, pero también es verdad que muchas personas no tienen problemas en comprar una cámara que permite streaming en vivo desde su celular, sin preocuparse de que esas imágenes pasen por servidores ubicados al otro lado del mundo, donde el GDPR (el reglamento europeo de protección de privacidad) no siempre se respeta al pie de la letra. Los más experimentados optarán por soluciones caseras, como usar su propio servidor o un servicio en la nube, pero todo esto tiene un costo operativo y técnico.
El proyecto: Ganimede.E12 y una aplicación dedicada
En este artículo, proponemos construir un dispositivo apto para controlar la apertura y el cierre de un portón de forma remota, consistente en la placa Ganimede.E12 (ya presentada en una publicación anterior) y una aplicación móvil desarrollada específicamente. Dada la versatilidad del proyecto (se utiliza un relay para el control de carga), será posible extender su uso a otras aplicaciones, como el control de calderas domésticas o calentadores.
La aplicación móvil no recopila ningún dato personal y no transmite información relevante para la privacidad a ningún servidor, como puede verificarse fácilmente con software que analiza el tráfico de datos de su celular. Finalmente, la comunicación entre la app y el abridor del portón ocurre a través del servicio gratuito en la nube ofrecido por dweet.io, de manera totalmente segura.
Diagrama de bloques del sistema
En la Fig. 1, se muestra el diagrama de bloques del sistema. Lo que destaca de inmediato es el tipo de arquitectura: serverless, es decir, sin ningún servidor, ni doméstico ni provisto como servicio por un proveedor externo.
La comunicación es directa, entre el dispositivo abridor del portón conectado a la red WiFi del hogar y la aplicación móvil, a través del servicio en la nube provisto por dweet.io, el cual permite intercambiar mensajes de manera segura y eficiente. Una ventaja tanto económica como ambiental, ya que no hay servidores ni dispositivos de red complejos que gestionar.
Hardware
Como anticipamos, para la implementación del hardware utilizamos la placa Ganimede.E12, equipada con un microcontrolador ESP-12F y las ranuras de expansión necesarias para conectar hardware adicional. En particular, conectaremos el relay de 5 Vdc 10 A al conector Neopixel (CN4), para controlarlo mediante un PIN de gestión de salida digital, y la pantalla OLED miniatura de 0.96” conectada vía I2C al conector CN7 de la placa. La arquitectura de hardware, mostrada en la Fig. 2, es muy simple y permitirá desarrollar un firmware igualmente directo y legible.
Protocolo
dweet.io ha sido mencionado varias veces como proveedor de servicios, pero antes de entrar en los detalles de la arquitectura de software utilizada, es necesario comprender cómo funciona este proveedor. El nombre en sí recuerda a una famosa red social y plataforma de microblogging, y es precisamente del conocido Twitter de donde toma inspiración. Aquí, sin embargo, no son personas intercambiando mensajes, sino dispositivos IoT. Una vez definido un nombre para su dispositivo, el llamado endpoint, cualquiera puede escribir y leer mensajes relacionados con ese endpoint, como si uno o más usuarios estuvieran tuiteando sobre un tema específico usando un hashtag.
Muchos otros servicios permiten la comunicación de dispositivos IoT, pero los dos factores que hacen que dweet.io sea particularmente atractivo son el protocolo utilizado y la naturaleza gratuita del servicio. Los protocolos típicos del mundo embebido no se utilizan para comunicarse (o “dweetear”), sino más bien las APIs web, en particular la sencilla HAPI (Humanized Application Programming Interface). La idea detrás de HAPI es crear un estándar para interfaces de modo que sean autodocumentadas y, por lo tanto, fáciles de interpretar, tanto por las máquinas que las usan, pero especialmente por los desarrolladores.
Los pilares principales de HAPI son, de hecho:
- Accesibilidad a través de una URL, incluso con un navegador web simple.
- Facilidad de lectura de entrada y salida en forma de oraciones normales.
- Facilidad de lectura, de modo que sea comprensible incluso para personas no técnicas.
HAPI utiliza el protocolo de aplicación HTTP, que usamos diariamente para navegar por cualquier sitio web, pero simplifica su uso, ya que solo se utilizan dos de los diferentes métodos disponibles: GET y POST. El primero para leer información, o dweet, el segundo para crearla. Con HAPI, las URLs también están estandarizadas, por lo que las solicitudes y respuestas son fácilmente interpretables para cualquier tipo de comunicación. La idea de limitar la personalización de la URL por parte del diseñador de la API surge de la necesidad de simplificar las operaciones CRUD (Crear, Leer, Actualizar, Borrar) para la gestión de datos, sin la necesidad de consultar repetidamente la documentación.
Al definir un nombre para nuestro dispositivo, por ejemplo “EInApricancello”, el método GET que nos permitirá leer el último dweet será llamado desde la siguiente URL: dweet.io/get/latest/dweet/for/EInApricancello](https://dweet.io/get/latest/dweet/for/EInApricancello). De manera similar, será posible crear un dweet con una solicitud POST a la siguiente URL, insertando un JSON en el cuerpo de la solicitud misma: dweet.io/dweet/for/EInApricancello](https://dweet.io/dweet/for/EInApricancello). Finalmente, es útil echar un vistazo al contenido completo de una solicitud, es decir, el JSON, que se envía cuando publicamos un dweet. Asumiendo que el cuerpo de la solicitud es una cadena de prueba, el dweet completo será:
{ “this”: “succeeded”, “by”: “getting”, “the”: “dweets”, “with”: [ { “thing”: “EInApricancello”, “created”: “2023-05-15T18:41:17.166Z”, “content”: { “test”: “stringa di test!” } } ] }
Analizando el JSON del dweet en detalle, es posible notar cómo la lectura es inmediata gracias a la estructura HAPI. Los campos del objeto son creados y poblados automáticamente por el servicio dweet.io, el cual, además de los valores predeterminados, inserta el nombre del endpoint, la marca de tiempo (timestamp) y el contenido de nuestra solicitud en el campo “content”.
Nos hemos centrado en la facilidad de uso del proveedor y destacado la naturaleza gratuita del servicio. Pero precisamente este último factor implica restricciones que pueden superarse utilizando la versión de pago del proveedor. Las limitaciones principales de la versión gratuita son el límite de tiempo en las solicitudes (no es posible “dweetear” con una frecuencia mayor a 1 Hz) y que no se proporcionan métodos de autenticación y cifrado. El hecho de no poder enviar más de una solicitud por segundo podría ser un problema para aplicaciones de tiempo real estricto, es decir, aquellas que necesitan intercambiar señales con frecuencias muy altas y tiempos de respuesta por debajo de un milisegundo. Para aplicaciones IoT, y en particular para un abridor de portón, tal requisito no es necesario.
Obviamente, esto podría ser una limitación para sistemas embebidos donde las medidas de seguridad son esenciales, como las ECU utilizadas en el mundo automotriz. La falta de autenticación, que nos permitiría saber quién está interactuando con el dispositivo, y la falta de cifrado para ocultar los detalles de los mensajes enviados, constituyen una barrera para usos industriales de alta criticidad, pero resultan ideales para prototipos de hogar inteligente donde la sencillez prima sobre la complejidad criptográfica.
Vía Open Electronics.
