Hackear una estación meteorológica con rtl_433

Estándar

Hace mucho tiempo que quería tener una estación meteorológica, para saber en todo momento qué temperatura hay, si sopla el viento o si está lloviendo. Es algo muy útil para múltiples temas domóticos. Por ejemplo, sería fantástico que cuando se ponga a llover, o el viento supere un cierto umbral, me llegue un Telegram diciéndome que ojo, que está el tiempo revuelto, mira a ver si tienes todas las persianas cerradas y nada que se pueda mojar.

Pero te pones a rascar, y resulta que la mayoría de estos productos son notablemente cerrados: la mayoría sólo te muestra la información en alguna pantallita, o una aplicación de móvil como mucho. E incluso las que tienen un programa desde el que procesar la información, acostumbra a ser un programa propio, desde el que es difícil exportar la información a otras historias.

Pero un día me encontré un post en Reddit que explicaba algo muy interesante: resulta que la mayoría de estaciones meteorológicas que tienen una unidad exterior (con los sensores) y otra interior (pantallita con los datos) se comunican entre sí mediante una comunicación por radio, que se puede «interceptar» fácilmente con un pincho USB de 15 eur, y que luego, usando el software adecuado, se puede decodificar para extraer la información. Es una cosa que parece muy hacker, pero la verdad es que es todo muy sencillo de montar, y funciona de maravilla. Al lío entonces:

La estación

En lo que respecta a la estación meteorológica que escoger, obviamente hay que elegir una que sea «hackeable». Para eso lo más fácil es ir al final de la cadena, al software que decodifica la información, y ver qué modelos soporta. Yo elegí la Bresser 5in1, primero porque era la que se explicaba en el post de Reddit, pero también porque mide exactamente lo que yo quería (temperatura y humedad, viento y lluvia), y además tengo otros productos de la marca y me gusta.

Mide todo lo que quiero: temperatura, humedad, lluvia, dirección e intensidad del viento… La unidad interior es lo de menos, porque la vamos a hackear

La instalación del aparato ya es un tema aparte, pero en el fondo es sencillo: la unidad exterior se planta en un poste, y la unidad interior es una pantallita que muestra los datos de temperatura, viento, lluvia y demás. Los dos aparatos funcionan con pilas, que ya veremos lo que duran. Tengo en mente un hackeo extra para alimentar al menos la unidad exterior desde la red, porque tener que bajar el aparato del poste, aunque sea cada X meses, no deja de ser una molestia. Pero eso ya es carne para otro post.

El aparato para leer la señal

Una vez esté la estación meteorológica montada y funcionando, ya estamos en disposición de capturar la señal. Para eso lo que necesitamos es simplemente un stick USB sintonizador de TV, pero no uno cualquiera, sino uno con un chipset específico, en concreto un Realtek RTL2832.

Un stick USB para ver la TV, sólo que en este caso sólo lo usaremos para captar la señal de radio

Yo he comprado este, pero porque soy un ansias y lo quería ya. A mí me costó como 15 eur, pero si lo compras en China y no te importa esperar un mes, se puede conseguir por unos 5 euritos fácil.

Ojo, que es importante que venga con la típica antenita moñas, la típica que cuando quieres usar el stick para ver la TV no vale para nada. Para ver la TV no valdrá, pero para captar la señal de radio es ideal.

Siempre me indignaba con esta antena, porque no vale absolutamente para nada, pero resulta que para radio sí va bien

La instalación en cualquier linux moderno es trivial, no hay que hacer nada especial. Lo único es asegurarse que, al enchufar, se establezcan los permisos correctos. Para eso hay que añadir una línea como la siguiente en el fichero /etc/udev/rules.d/20.rtlsdr.rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdrSUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr""

Con esto, sólo hay que asegurarse de que nuestro usuario está en el grupo adm (sudo adduser usuario adm si no es así), y ya debería funcionar bien.

El software

Con la estación montada y el stick USB enchufado y configurado, ya sólo falta leer los datos. Para eso hace falta el comando rtl_433, que es el programa que coge la señal, la interpreta y busca patrones conocidos para decodificarlos. Soporta dispositivos a cascoporro, que se pueden consultar en su página web o desde la misma ayuda del programa.

La instalación del programa es trivial en cualquier linux moderno, ya que suele estar en los repositorios:

sudo apt-get install rtl_433

Y listos. Si lo ejecutamos tal cual, nos mostrará esto:

usuario@maquina:~$ rtl_433
rtl_433 version 20.11-43-g61d24ba9 branch master at 202101281106 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"…
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"…
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"…
Trying conf file at "/etc/rtl_433/rtl_433.conf"…
Registered 147 out of 177 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177 ]
Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers

Aquí se ve como detecta el stick, y empieza a escanear. Pero aquí no encuentra nada, porque probablemente la frecuencia que usa por defecto no es la de nuestro aparato, y además no es muy eficiente porque está escaneando 177 protocolos distintos a la vez, cuando bastaría que buscase el de nuestro aparato (a no ser que queramos hackear la estación del vecino, que también es una opción 🙂 ). En mi caso, el comando mágico para mi estación es el siguiente:

usuario@maquina:~$ rtl_433 -f 868300000 -R 119 -Y classic  -C si
 rtl_433 version 20.11-43-g61d24ba9 branch master at 202101281106 inputs file rtl_tcp RTL-SDR
 Use -h for usage help and see https://triq.org/ for documentation.
 Trying conf file at "rtl_433.conf"…
 Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"…
 Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"…
 Trying conf file at "/etc/rtl_433/rtl_433.conf"…
 New defaults active, use "-Y classic -s 250k" for the old defaults!
 Registered 1 out of 177 device decoding protocols [ 119 ]
 Detached kernel driver
 Found Rafael Micro R820T tuner
 Exact sample rate is: 1000000.026491 Hz
 [R82XX] PLL not locked!
 Sample rate set to 1000000 S/s.
 Tuner gain set to Auto.
 Tuned to 868.300MHz.
 Allocating 15 zero-copy buffers
 
 time      : 2021-01-30 17:16:21
 model     : Bresser-5in1 id        : 106
 Battery   : 1         Temperature: 17.2 C   Humidity  : 63        Wind Gust : 2.0 m/s
 Wind Speed: 2.3 m/s   Direction : 202.5     Rain      : 29.2 mm   Integrity : CHECKSUM
 
 time      : 2021-01-30 17:16:57
 model     : Bresser-5in1 id        : 106
 Battery   : 1         Temperature: 17.2 C   Humidity  : 64        Wind Gust : 4.0 m/s
 Wind Speed: 2.4 m/s   Direction : 157.5     Rain      : 29.2 mm   Integrity : CHECKSUM

Aquí ya hemos restringido la búsqueda sólo al protocolo de nuestra estación, y hemos establecido la frecuencia que toca (que al final es la que pone en las especificaciones del aparato). Así ya vemos que empieza a encontrar información, y por defecto las muestra por pantalla.

Pero esto no es todo, la gracia de rtl_433 es que tiene un montón de formas de procesar la información que decodifica. Y como sólo ver por pantalla los datos tampoco es demasiado útil, lo suyo es sacarlos de otra manera. Y en un contexto domótico, lo mejor es exportar la información por MQTT, porque así es directamente integrable en cualquier otra plataforma, ya sea Home Assistant, NodeRED, o lo que sea. En mi caso, se le añade un parámetro al comando:

rtl_433 -f 868300000 -R 119 -Y classic -F "mqtt://servidor:puerto,user=usuario,pass=contraseña,events=rtl_433/events,states=rtl_433/states,devices=rtl_433/devices[/model]" -C si

Obviamente hay que tener un servidor MQTT montado, pero vamos, montarse un mosquitto son 5 minutos.

Ya para rematar la cuestión, si lo que queremos es dejar esto funcionando las 24h, lo suyo es añadir este comando como un servicio que se arranque automáticamente al inicio de la máquina. Para esto se puede crear un servicio systemd creando un fichero /etc/systemd/system/rtl_433.service con el contenido:

[Unit]
Description=rtl_433
After=network.target

[Service]
Type=simple
User=pi
ExecStart=/usr/local/bin/rtl_433 -f 868300000 -R 119 -Y classic -F "mqtt://servidor:puerto,user=usuario,pass=contraseña,events=rtl_433/events,states=rtl_433/states,devices=rtl_433/devices[/model]" -C si
RestartSec=0
Restart=always
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

Y una vez creado el fichero, lo arrancamos y establecemos que se ejecute automáticamente en el arranque:

sudo systemctl start rtl_433
sudo systemctl enable rtl_433

Y ya está todo. Si nos suscribimos al topic de MQTT, veremos cómo van saliendo valores:

usuario@maquina:~$ mosquitto_sub -v -u usuario -P contraseña -t "rtl_433/#"
 rtl_433/events {"time":"2021-01-30 17:55:57","model":"Bresser-5in1","id":106,"battery_ok":1,"temperature_C":18.2,"humidity":63,"wind_max_m_s":3.0,"wind_avg_m_s":2.1,"wind_dir_deg":202.5,"rain_mm":29.2,"mic":"CHECKSUM"}
 rtl_433/devices/Bresser-5in1/time 2021-01-30 17:55:57
 rtl_433/devices/Bresser-5in1/id 106
 rtl_433/devices/Bresser-5in1/battery_ok 1
 rtl_433/devices/Bresser-5in1/temperature_C 18.2
 rtl_433/devices/Bresser-5in1/humidity 63
 rtl_433/devices/Bresser-5in1/wind_max_m_s 3.0
 rtl_433/devices/Bresser-5in1/wind_avg_m_s 2.1
 rtl_433/devices/Bresser-5in1/wind_dir_deg 202.5
 rtl_433/devices/Bresser-5in1/rain_mm 29.2
 rtl_433/devices/Bresser-5in1/mic CHECKSUM

Con todo montado, ya podemos leer los datos desde cualquier plataforma que soporte MQTT (y la que no lo soporte no merece existir), y hacer lo que queramos con los datos. Yo por ejemplo de momento me dibujo cuatro gráficas con Grafana:

Como remate final, en mi caso si ponía el stick USB donde tengo el servidor, no me llegaba bien la señal, por lo que pasé todo el sistema a una Raspberry Pi, para poder ponerla más cerca de la estación exterior. El proceso viene a ser el mismo, la única diferencia es que el comando rtl_433 no está en los repositorios, y hay que compilarlo a mano. Siguiendo las instrucciones es muy sencillo.

Me preocupaba que una Raspberry Pi no tuviera potencia para decodificar la señal, pero teniendo en cuenta que uso la Raspberry Pi Zero, que es la menos potente de la familia, veo que la CPU se queda en un 50%, por lo que va más que sobrada. Si se usa cualquier ordenador normal el consumo de CPU es totalmente irrisorio, en mi servidor no llegaba al 2%, y eso que tiene un Celeron fanless de bajo consumo.

A partir de aquí, a hacer automatizaciones se ha dicho. Tampoco está de más, ya que lo tenemos todo montado, subir nuestros datos a MeteoClimatic y compartirlos con quien los pueda necesitar, pero eso lo dejo para otro post.

Visualizando el consumo energético de casa con Grafana

Estándar

Bueno, en la entrada anterior contaba lo súper fantabuloso que es el Shelly EM como medidor de consumo energético, lo abierto que es y lo fácil que es integrarlo con casi cualquier cosa. Pues ahora falta ver la otra parte: cómo podemos coger los datos de consumo, y visualizarlos de forma bonita y vistosa.

Veamos, esta va a ser una entrada densa, porque hay que introducir muchos conceptos y hay muchas piezas interconectadas. Aunque pueda parecer todo muy complejo, en el fondo no es tan difícil, y la gracia es que, una vez montado el tinglado inicial, luego ir añadiendo cosas es trivial.

Pero al lío. Para poder llegar a ver gráficas chulas, hay que pasar por todas las fases:

  1. Tener un medidor de consumo que nos dé los datos en un formato abierto y procesable: Chachi, eso ya lo tenemos, partiré de que tenemos un Shelly EM publicando los datos por HTTP o MQTT. Obviamente, cualquier otro medidor que proporcione los datos por una vía equivalente es igual de válido.
  2. Ahora hay que recibir los datos de alguna manera. Lo más chulo y versátil para estas cosas domóticas es usar Node-RED (luego más).
  3. Los datos hay que almacenarlos en alguna parte. Podríamos usar cualquier base de datos en plan MySQL, ficheros de texto o lo que sea, pero teniendo en cuenta que este tipo de datos crecen una barbaridad, lo más apropiado es usar una base de datos específica para guardar series temporales, como InfluxDB.
  4. Y ahora que ya tenemos los datos guardaditos, ya podemos hacer gráficas, en este caso con Grafana.

Madre del amor hermoso, menuda movida para ver cuatro gráficas. ¿De verdad vale la pena? ¿No sería más feliz viendo las gráficas en el típico cacharrín propietario mientras dure su app? Afortunadamente, instalar todo esto es 1.000 veces más fácil que si lo hiciéramos a pelo, gracias a…

Docker

¿Ein? ¿No hablábamos de medir energía, de domótica y de instalar programas? Pues ahí andamos, porque resulta que Docker es una forma de instalar en dos patadas programas que serían tremendamente complicados de instalar si se hiciera a pelo.

El concepto de los contenedores Docker reconozco que es espinoso. Para el que esté familiarizado con el concepto de máquina virtual, se podría decir que un contenedor Docker es una especie de máquina virtual, pero «aligerada». Porque si una máquina virtual viene a ser un «miniordenador», con un sistema operativo entero y las aplicaciones que hagan falta, un contenedor Docker vendría a ser el resultado de «podar» esta máquina virtual y dejarla estrictamente con lo que necesita para ejecutar una aplicación concreta. Por eso con las máquinas virtuales hablamos de sistemas operativos (una máquina virtual con Ubuntu, o con Windows) pero con contenedores hablamos de aplicaciones (un contenedor con MySQL, o con Transmission).

La gracia extra de los contenedores es que, a diferencia de las máquinas virtuales, para las que se reserva una porción de memoria y unas cuantas CPUs, los contenedores se ejecutan todos sobre la misma máquina, compartiendo kernel, memoria y recursos. La argucia técnica que permite hacer eso aislando al mismo tiempo unos contenedores de otros lo dejo para otro día, pero el caso es que esta diferencia hace que arrancar o parar contenedores sea rapidísimo, comparado con una máquina virtual.

Otra ventaja de los contenedores es que tenemos dos cosas:

  • Un repositorio en internet (Docker Hub) de contenedores ya hechos, para casi cualquier aplicación que se nos ocurra.
  • Herramientas para orquestar el arranque de varios contenedores enchufados entre ellos, simplemente escribiendo un ficherito de texto.

O sea, que al final es raro que hagamos contenedores a pelo. Más bien cogeremos contenedores ya hechos, con los programas que nos interesen, y los configuraremos e interconectaremos para conseguir lo que queramos.

Como esto es muy teórico, se ve mucho mejor con un ejemplo. Pongamos que quiero montarme un blog con WordPress. Tradicionalmente, empezaríamos a instalar todos los requisitos: que si un Apache, que si el soporte de PHP, una base de datos MySQL… Y luego ponte a configurar todo.

Usando contenedores, bastaría crear un ficherito llamado docker-compose.yaml, tal que asín:

version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress
   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {}

Con esto le estoy diciendo que quiero dos contenedores, uno con una BD MySQL, y otro con un WordPress. Y luego para cada uno configuro cuatro cosas: que si usuarios/passwords de la BD, que si en qué puerto servirá… El caso es que, una vez tengo esto, basta ejecutar:

docker-compose up

Y él solo ya se encargaría de bajarse los contenedores que le he indicado (wordpress y MySQL), configurarlos según mis instrucciones y ejecutarlos, con lo que ya puedo abrir el navegador, apuntar al puerto que corresponda, y ya tengo mi WordPress en marcha.

Chachi, ¿no? Pues después de la introducción, vamos a utilizar esto mismo para montarnos en dos patadas nuestro tinglado domótico.

Primer paso: Node-RED

Node-RED es… una cosa difícil de describir. Se podría decir que es una plataforma para interconectar diferentes sistemas de forma visual, a base de unir cajitas con líneas. Es una descripción poco científica, pero de verdad que es más fácil verlo y probarlo que intentar describirlo con palabras.

En nuestro caso, lo vamos a usar para coger lo que nos envíe el medidor de consumo, y enviarlo a nuestra base de datos.

Como hemos dicho, vamos a montarlo todo con Docker. Nos vamos a cualquier directorio, y editamos el fichero docker-compose.yaml, con el siguiente contenido:

version: "3.3"
services:
  nodered:
    image: nodered/node-red
    container_name: nodered
    restart: unless-stopped
    user: "1000"
    volumes:
      - $PWD/data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/TZ:ro
    environment:
      - TZ=Europe/Madrid
    ports:
      - 1880:1880

Con esto le estamos diciendo que queremos un Node-RED en el puerto 1880, que queremos que guarde los datos en el subdirectorio data, y luego le hemos añadido un par de cosas para que tenga bien los permisos de los ficheros, coja bien la hora y esté siempre arrancado aunque reiniciemos el servidor.

Y ya está. Ejecutamos «docker-compose up», y ya deberíamos tener Node-RED en marcha.

Como la idea de Node-RED es enganchar el medidor con la base de datos, vamos a instalar esta última antes de configurar nada.

InfluxDB

InfluxDB es una base de datos como tantas, pero con una particularidad: está optimizada para guardar series temporales. ¿Qué quiere decir eso? Pues que si una base de datos normal guarda todos los datos en un registro de tamaño fijo, y tenemos muchos datos, eso va a ocupar un montón con el tiempo. Lo que hace InfluxDB es guardar las diferencias entre un dato y otro, de una forma muy compacta, de manera que lo que en otra base de datos ocuparía GB, aquí ocupa MB. Ideal para nuestro caso de guardar consumos eléctricos ad-infinitum.

Para instalarlo, volvemos a abrir el docker-compose.yaml, y añadimos un servicio nuevo, para InfluxDB:

version: "3.3"
services:
  nodered:
    image: nodered/node-red
    container_name: nodered
    restart: unless-stopped
    user: "1000"
    volumes:
      - $PWD/data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/TZ:ro
    environment:
      - TZ=Europe/Madrid
    ports:
      - 1880:1880
  influxdb:
    image: influxdb:latest
    container_name: influxdb
    environment:
      - TZ=Europe/Madrid
      - INFLUXDB_DB=energia
      - INFLUXDB_ADMIN_USER=influxdb
      - INFLUXDB_ADMIN_PASSWORD=influxdb
      - INFLUXDB_WRITE_USER=influxdb_w
      - INFLUXDB_WRITE_PASSWORD=influxdb_w
      - INFLUXDB_HTTP_FLUX_ENABLED=true
    ports:
      - 8086:8086
      - 8083:8083
      - 2003:2003
    volumes:
      - $PWD/influxdb:/var/lib/influxdb
    restart: unless-stopped

Y ya está. Sólo le hemos indicado el nombre de la base de datos («energia») y hemos indicado que cree dos cuentas de usuario: una para administrar, y otra sólo con permisos de escritura, que será la que usemos para cargar los consumos.

Si volvemos a ejecutar docker-compose, veremos cómo se descarga y arranca la BD.

Enviar consumos a InfluxDB con Node-RED

Ahora que ya tenemos la BD en marcha, vamos a usar Node-RED para leer los consumos del medidor, y enviarlos a InfluxDB. Para esto abrimos Node-RED, y tenemos que añadir dos nodos al tablero: uno para leer del medidor, y otro para escribir en InfluxDB. Los unimos con una flechita, y listos:

Hay que clicar en cada uno de los nodos, y configurar ahí lo que haga falta.

En el caso del medidor, yo leo los valores por MQTT, por lo que habría que indicar a qué «topic» escribe el medidor. Si se quisiera hacer por HTTP, habría que usar otro tipo de nodo, e indicar la URL y la frecuencia de lectura. Es un poco más complicado, sería algo así:

En vez de esperar a que llegue el valor, al leerlo por una web hay que leer periódicament (nodo timestamp, configurado para leer cada 10 segundos o así), luego hacer la petición (nodo http request) y luego, de entre todo lo que nos llega, sacar el consumo en W (nodo tipo Change, cogiendo el valor «power»).

En el caso del nodo de influxdb, hay que indicar el host y el puerto en los que tenemos la base de datos (son los valores que hemos indicado en docker-compose.yaml), así como el usuario y contraseña definidos antes.

Con esto ya tenemos los consumos eléctricos guardados en nuestra base de datos. Ahora sólo queda hacer gráficas.

Grafana

Grafana es una aplicación web para hacer gráficas chulas en tiempo real. Permite recuperar los datos de un montón de fuentes diferentes, entre ellas InfluxDB. Para añadir una instancia de Grafana a nuestro Docker, simplemente habría que añadir un servicio más a nuestro docker-compose.yaml:

version: "3.3"
services:
  nodered:
    image: nodered/node-red
    container_name: nodered
    restart: unless-stopped
    user: "1000"
    volumes:
      - $PWD/data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/TZ:ro
    environment:
      - TZ=Europe/Madrid
    ports:
      - 1880:1880
  influxdb:
    image: influxdb:latest
    container_name: influxdb
    environment:
      - TZ=Europe/Madrid
      - INFLUXDB_DB=energia
      - INFLUXDB_ADMIN_USER=influxdb
      - INFLUXDB_ADMIN_PASSWORD=influxdb
      - INFLUXDB_WRITE_USER=influxdb_w
      - INFLUXDB_WRITE_PASSWORD=influxdb_w
      - INFLUXDB_HTTP_FLUX_ENABLED=true
    ports:
      - 8086:8086
      - 8083:8083
      - 2003:2003
    volumes:
      - $PWD/influxdb:/var/lib/influxdb
    restart: unless-stopped
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    depends_on:
      - influxdb
    environment:
      - TZ=Europe/Madrid
      - GF_SERVER_ROOT_URL=https://midominio/grafana
      - GF_SERVER_SERVE_FROM_SUB_PATH=true
      - GF_SECURITY_ADMIN_USER=miusuario
      - GF_SECURITY_ADMIN_PASSWORD=passadmin
      - GF_ENABLE_ALPHA=true
      - GF_INSTALL_PLUGINS=grafana-influxdb-flux-datasource,grafana-piechart-panel
    volumes:
      - $PWD/grafana-storage:/var/lib/grafana
    ports:
      - 3000:3000
    restart: unless-stopped

Que viene a ser más de lo mismo que ya hemos visto: cuatro configuraciones sobre usuarios y compañía, puertos y directorio donde ser guardarán los datos. Aquí hay un par de cosas adicionales que no son imprescindibles: unos cuantos plugins extras que no vienen de serie, y un par de configuraciones en las que le indico un dominio, para poder acceder a la instancia de Grafana desde fuera de mi red local. Pero vamos, que no hacen falta.

Con esto arrancamos Grafana, y ya podríamos configurar un datasource de tipo InfluxDB e ir añadiendo gráficas con lo que nos apetezca. En esto no voy a entrar porque esta entrada ya queda demasiado larga, hay guías a patadas sobre cómo usar Grafana, cada cuál tiene sus gustos y en el fondo el interfaz es muy intuitivo y amigable. Sólo pongo un pantallazo de cómo queda mi configuración de monitorización de energía:

Mi dashboard en Grafana

Chulo, ¿verdad? Y actualizado en tiempo real y totalmente interactivo para cambiar el intervalo de tiempo a analizar, hacer zoom o quitar o poner medidas. Bueno, en mi caso es un poco trampa, porque no tengo un solo Shelly EM, sino dos, midiendo cuatro circuitos, más un Shelly 1PM para medir las luces, más dos Shelly Plug S para medir los calefactores del baño, más un TP-Link HS-110 (este no es tan abierto como los Shellys, pero se puede usar con Node-RED Home Assistant mediante) para medir el termo… Si es que esto de ponerse a monitorizar es empezar, y no querer parar 🙂

En definitiva, que en dos patadas y gracias a Docker nos hemos montado un tinglado considerable, muy fácil de instalar y mantener. ¿Que mañana cambiamos el servidor? Pues cogemos el docker-compose.yaml, lo copiamos al nuevo, y con un docker-compose up lo tenemos todo de nuevo en marcha en segundos. Así da gusto instalar cosas.