Hace ya unos cuantos años que vengo trasteando con dispositivos basados en el chip ESP8266 para utilizarlos en el sistema de domótica que tengo implementado en casa. Siempre me ha gustado trastear a nivel de código directamente con estos dispositivos, más que comprarlos ya configurados, y el ESP8266, programable como un Arduino y con conectividad WiFi, han sido la base de mis desarrollos. Y dentro de esta variedad de dispositivos tuve la oportunidad de hacerme, hace ya algunos años también, con una variante muy particular: los ESP01.
Estos dispositivos son una modalidad muy compacta de los ESP8266, con un número limitado de puertos de E/S, que se alimentan sólo a 3.3v, pero que por su tamaño permiten realizar sistemas extremadamente compactos. Anduve trasteando con ellos para realizar un pulsador WiFi que, en combinación con Node Red, pudiera realizar acciones programadas. Y si bien el concepto funcionó bastante bien, no acabé por sacarle partido, ya que esas mismas acciones acabé por realizarlas con un sistema de etiquetas NFC, que tenían la ventaja de que no necesitaban ningún tipo de alimentación. Así que acabé con un grupo de ESP-01 sin uso, rondando por la casa.
No me había acordado mucho de ellos, hasta que hace poco me encontré con un empaquetado del ESP-01 conjunto con un relé, así como las borneras necesarias para realizar las conexiones con la alimentación y con el cableado que quieras controlar con el relé. Y eso despertó mi interés por aprovecharlo para algunas cosas más. Sobre todo, porque esa placa venía equipada con un regulador eléctrico que permite alimentar al dispositivo con un rango de voltajes algo más amplio, de 5 a 12 voltios en continua, lo que facilita el uso de la placa.
Pero lo que verdaderamente me hizo tener todo el interés por esta placa fue el hecho de que es completamente compatible con el firmware Tasmota. He venido haciendo uso de este firmware desde hace tiempo como base del sistema de iluminación de mi casa, específicamente para los dispositivos Sonoff, pero admite su uso en una gran variedad de dispositivos basados en Arduino, lo cual es una ventaja para realizar un prototipado rápido. De hecho, es tan rápido que ni siquiera es necesario programarlos con el IDE de Arduino, basta con bajar un firmware ya compilado y utilizar Tasmotizer para grabarlo. Tremendamente práctico.
Sin embargo, en mi caso he decido dar un paso más allá. Hago uso de la v4 de la placa de relé para el ESP-01. Esta placa dispone de un botón externo para resetear el dispositivo. En versiones anteriores de esta placa este botón podía ser programado para actuar como un pulsador externo, pero no en el caso de la v4. Pensando en hacer uso de esta placa como control de encendido de luces en la domótica, esta limitación es bastante importante. Sin embargo, es posible hacer algo al respecto: dado que hay puertos libres en el ESP-01, es posible programar alguno de estos puertos como un interruptor externo, añadiendo un interruptor al mismo, y conectando el otro puerto a GND. Además, el firmware Tasmota permite activar las resistencias internas de pull-up en los pines GPIO del ESP-01, con lo que ni siquiera es necesario hacer uso de resistencias pull-up externas, lo que complicaría el cableado de manera innecesaria.
También es posible configurar el modo de funcionamiento de este interruptor, tanto como un interruptor clásico, como de tipo pulsador. En el primer caso es cuestión de configurar el GPIO como “Switch”, y en el segundo como “Button”. Esto se hace accediendo al menú de configuración de Tasmota (Configuration → Configure Module), y asigna el GPIO correspondiente como Switch
Sin embargo, hay que modificar ligeramente el hardware para poder utilizar de manera sencilla este interruptor, ya que la placa no viene configurada para poder hacer uso de estos GPIO. En mi caso, opté simplemente por soldar una bornera al GPIO 3 y a GND, que son las conexiones que estoy usando:
Y con esto, lo tenemos listo. En las imágenes he utilizado una batería de 9V para alimentar al conjunto, con un resultado perfecto, pero lo ideal es usar un transformador externo, de cualquier voltaje entre 5 y 12v.
En las últimas semanas he estado realizando una serie de cambios bastante importante en mi sistema informático. Desde hace muchos años tengo desplegado en casa un servidor que históricamente ha contenido mi sitio web, pero que con el paso del tiempo ha ido ganando en funcionalidades: domótica, servicio de mensajería, automatización, almacenamiento, VPN, streaming de vídeo… Todo empezó en la Universidad, con unas prácticas de alguna asignatura que ni siquiera recuerdo, pero ha persistido con el paso del tiempo.
En un momento dado tuve una serie de sistemas aislados que complementaban al servidor: un Mini-ITX, un par de Raspberry Pi, una Asus Tinker Board, una NAS… Pero con el paso del tiempo fui simplificando. Un paso trascendental fue la consolidación de las máquinas físicas separadas en un único servidor de virtualización. Para ello escogí realizar un despliegue de ProxMox, virtualización basada en KVM, pero que proporcionaba una interfaz de usuario vía web bastante amigable, lo que hacía la administración del entorno fuera sencilla. Para ello utilicé un viejo PC de oficina con un procesador Intel y 4 GB de RAM. Todo bastante ajustado para contener tres máquinas virtuales: un frontal web NGINX que además desplegaba un servidor MQTT y VPN, un backend con el servidor web WordPress, securizado por el frontal antes comentado, y una máquina separada para el entorno de domótica. Durante años ha funcionado bien, pero hace unos meses el servidor, ya veterano cuando lo desplegué, empezó a presentar fallos hardware. El principal fue que se estropeó uno de los módulos de RAM, quedando reducida la cantidad disponible a 3 MB. Además, presentaba fallos de encendido en caso de que se fuera la luz, lo que hacía que la recuperación del sistema fuera bastante complicado.
Ante ello, decidí renovar el hardware, para lo que me puse a mirar precio de módulos RAM para añadirle el módulo faltante al PC, y también precios de PCs nuevos. Tanto lo uno como lo otro tenían precios elevados (la RAM por tener que adquirirla a través de Ebay y sitios así), y el PC nuevo por el hecho de comprarlo nuevo. Y en ello andaba cuando se me ocurrió una idea disparatada:
Hacerme con un servidor. Uno de verdad. No un viejo PC reconvertido. Un ser-vi-dor. Y resultó que la idea no era tan disparatada. Encontré un servidor HP DL360p Gen8 con doble fuente de alimentación, dos procesadores de 12 núcleos cada uno, 96 GB de RAM, 4 discos de 2 TB a 7200 RPM y controladora RAID, 4 puertos de red a giga, y un año de garantía por la ridícula cifra de 100€. Resultaba que la idea no era tan disparatada. Así que me hice con él. Pero es un servidor, claro. Está optimizado para el rendimiento. Y eso suele tener algunos problemillas cuando lo metes en una casa. Y no es el menor de ellos el que puede ponerse a sonar como un MIG 21 despegando.
Estas semanas he estado lidiando para poner el servidor de manera funcional, adaptarlo a un uso doméstico, volver a instalar un entorno de virtualización, y migrar las máquinas desde el viejo servidor. Por el camino he aprendido una serie de cosas bastante interesantes, y creo que vale la pena recopilarlas por si a alguien más le resultan interesantes, así que espero escribir unos cuantos artículos al respecto.
Etiquetas: domótica, home assistant, hp dl360p gen8, mqtt, nginx, proxmox, virtualización, vpn
En fechas recientes he implementado un elemento adicional de interacción con la domótica. No es algo especialmente nuevo (de hecho, ya en Irlanda empecé a trastear con ellos), pero sí es algo que he recuperado recientemente: el uso de tags NFC para interactuar con la domótica, usando teléfonos inteligentes. La idea es bastante sencilla: desplegar una serie de tags desplegados por la casa, allí donde quiera que se dispare una acción concreta, para escanearlo con el teléfono, y ejecutar la acción. Y el elemento más obvio para ello es el control de luces inteligentes.
En mi caso, tengo desplegadas dos tecnologías diferentes para el control de luces inteligentes: interruptores WiFi (básicamente, diversas variedades de Sonoff) y luces Zigbee, que controlo mediante sendas plataformas zigbee2MQTT que tengo tanto en Santiponce como en Forcarey. Todo ello integrado en mi servidor MQTT, que se utiliza también con la plataforma HomeAssistant. La gracia del asunto es que toda la interacción con ellas se realiza desde el propio HomeAssistant, independientemente de la tecnología subyacente. Y siempre usando MQTT como elemento de mensajería.
Para poner en marcha el sistema de interacción basado con NFC he optado por lo siguiente: codificar en los NFC el envío de un datagrama UDP. La razón de hacerlo así es que es que de esta manera se evita, como es el caso de conexiones HTTP o similar, el tener que hacer uso de un programa específico en el teléfono, ya que mediante el envío del datagrama se evita que el usuario tenga que interactuar con ninguna aplicación, haciéndose el envío siempre en segundo plano. Esto implica que es preciso tener abierto en algún lugar un puerto UDP al que enviar los mensajes. Y la opción obvia en mi caso es hacer uso de Node-Red.
Así pues, he hecho un flujo bastante simple, que lo que hace es exponer un puerto UDP, a donde el teléfono envía la mensaje del datagrama. Este mensaje, en líneas generales, es un alfanumérico que me permite identificar qué luz quiero encender (por ejemplo, santiponceSalon1, para identificar la luz principal del salón de Santiponce). Una vez recibido el mensaje, se procesa en un switch, con tantas entradas como luces a controlar (en mi caso, de momento, 4), y se incluye en el payload el mensaje de encendido/apagado. Aquí hay dos opciones:
Una vez publicado el flujo, el servidor donde tengamos desplegado Node-Red abrirá un puerto UDP para escuchar conexiones (aconsejo hacer uso de un puerto alto, para evitar tener que asignar permisos de root). En mi caso, dado que publico Node-Red mediante un contenedor docker, es por lo que tenía que realizar una publicación de puertos del contenedor, de lo que hablaba en el artículo anterior. Y con esto, estaremos listos para controlar las luces con un móvil NFC.
Un par de comentarios adicionales:
Etiquetas: android, domótica, homeassistant, mqtt, nfc, node-red, sonoff, tasmota, udp, wifi, zigbee, zigbee2mqtt
Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.
Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.
Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.
Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:
Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.
Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.
Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.
¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:
…y en el caso de Forcarey:
No está mal, ¿no?
Etiquetas: aldi, aqara, aqara cube, arduino, asus tinker board, debian, domótica, home assistant, ikea, lidl, mqtt, nodemcu, orange pi zero, proxmox, raspberry pi, zigbee, zigbee2mqtt
Hace cosa de un año escribí un artículo sobre cómo actualizar de manera manual el firmware de los Sonoff Mini, cambiándolo al firmware Tasmota. Recientemente he adquirido una nueva remesa de Sonoffs Mini, y he comprobado que el manual ya no es válido, debido a un cambio en el firmware de casa que traen los dispositivos. En la práctica, se ha simplificado el proceso, que paso a describir:
…y como siempre, mucho ojo con no cargar la versión tasmota-minimal, ya que esta versión no carga la interfaz web de administración, y puede dejar el dispositivo inservible.
Etiquetas: domótica, ota, sonoff, sonoff mini, tasmota