02 abr 22 Monitorización de precios de gasolineras con Node Red y Home Assistant
Con el nivel tan disparatado de precios que están alcanzando los combustibles en estas fechas, es interesante tener una manera rápida de consultar los precios en diferentes estaciones de servicio, a fin de poder reposar en la que más nos convenga. Por razones de trabajo y sus subsecuentes desplazamientos, hay varias gasolineras que nos interesa a Ana y a mí tener monitorizadas. Existe una página del Ministerio para la Transición Ecológica (Geoportal de Gasolineras) que permite acceder a los precios de todas las estaciones de servicio de España, pero que no es especialmente usable para hacer consultas rápidas y recurrentes de las mismas estaciones, ya que lo que hace es desplegar un mapa y un buscador, pero que no proporciona URLs de acceso directo ni nada que se le parezca.
Captura de pantalla del Geoportal de Gasolineras
Al menos, no lo hace a la vista del usuario. Pero si trasteas un poco con el funcionamiento de la página, es posible ver que sí se hace uso a nivel interno de URLs únicas que proporcionan en el mapa los valores de cada una de las gasolineras en formato XML, para poder reflejar dichos valores al pulsar sobre las gasolineras, con un aspecto como este:
Información en XML de una gasolinera de Santiponce
Y ya teniendo esta información, haciendo uso de Node Red es sencillo procesar los parámetros, jugar un poco con ellos, e insertarlos en topics MQTT. En mi caso, me quedo con el valor de la gasolina sin plomo 95, de tres estaciones de servicio determinadas, realizando consultas una vez a la hora para cada una de ellas.
Flujo de procesamiento definido en Node Red
Por último, al existir esta información en un topic MQTT, es sencillo consumirla desde Home Assistant. En mi caso, he optado por mostrarla en tres diales, para que sea sencillo comparar los precios entre estaciones. Además, como valor añadido, me guarda el histórico de cotizaciones y cuándo se produjeron cambios en las mismas.
Precios de la gasolina 95 en tres estaciones, mostrados en Home Assistant
Histórico de cambios
Con todo esto, es sencillo comprobar el precio de los combustibles en nuestro Home Assistant, al que accedemos desde nuestro móvil, de un solo vistazo, y escoger el sitio óptimo para repostar. Estoy pensando en darle una vuelta de tuerca, e integrar un sistema de consulta en los sistemas de infoentretenimiento de los coches, pero eso quedará para otra ocasión.
Etiquetas: home assistant, mqtt, node-red
25 jul 21 Codificación y envío de imágenes por MQTT, y uso de las mismas en WhatsApp
En fechas recientes he realizado un aprovechamiento interesante de las capacidades de comunicación que proporciona el servidor MQTT que tengo instalado para diversos temas: el envío de imágenes a través del mismo. en principio no es algo para lo que esté pensado un servidor MQTT, que actúa como servidor de mensajería, mediante la suscripción a una serie de topics, mediante los cuales clientes del servidor MQTT pueden intercambiar información en formato texto. Pero como al fin y al cabo, las imágenes no dejan de transmitirse como información codificada, es posible ponerse algo creativo para conseguir su procesamiento correcto.
En mi escenario, se trataba de compartir información proveniente de una webcam, para integrarla en mi sistema de domótica. En otras circunstancias, consumiría la información directamente de la webcam, pero el servidor de domótica y la webcam se encuentran en ubicaciones geográficas distintas, y la red de la webcam se encuentra tras un CG-NAT, por lo que no es posible establecer una publicación directa de puertos. Existe la posibilidad de establecer una VPN, pero esta opción me parecía bastante más interesante. La webcam se trata de una ESP32-CAM, con capacidad para publicar imágenes tanto en formato streaming como imágenes individuales, y acceder a ellas a través de una URL concreta. Mi idea era aprovechar la capacidad de Python de convertir imágenes a arrays de bytes, y volcar la información a un topic MQTT específico, para su posterior consumo. Consumo que en una primera instancia sería una publicación directa en Home Assistant, pero que posteriormente se vio complementado con una idea adicional interesante.
Esquema general del envío de imágenes por MQTT
Codificación y envío de la imagen por MQTT
La primera parte de este proyecto consiste en el volcado de la información de la imagen en un topic MQTT. En mi caso, aprovechando que dispongo de un servidor Orange Pi Zero instalada en Forcarey para controlar diversos dispositivos Zigbee, creé un pequeño script en Python que toma una captura de imagen de la ESP32-CAM, la vuelca en un fichero temporal, y posteriormente la codifica como un bytearray, para enviarla a un topic MQTT concreto. El código sería el siguiente:
mport paho.mqtt.publish as publish
from PIL import Image
import requests
from io import BytesIOMQTT_SERVER = “xxx.xxx.xxx.xxx” #Write Server IP Address, or your server FQDN
MQTT_PATH = “path” #Write your MQTT topic pathresponse = requests.get(“http://xxx.xxx.xxx.xxx/capture”) #Write your ESP32-CAM IP address
f=open(“/tmp/image_test.jpg”,”wb”)
f.write(response.content)
f.closef=open(“/tmp/image_test.jpg”, “rb”)
fileContent = f.read()
byteArr = bytearray(fileContent)
publish.single(MQTT_PATH, byteArr, hostname=MQTT_SERVER)
f.close
Bastante sencillo. Para no andarme loco con servicios en linux, me limito a invocarlo desde /etc/crontab una vez cada 5 minutos, aunque se puede programar la frecuencia que se desee.
Captura y publicación en Home Assistant
Una vez tenemos nuestra imagen siendo volcada en el topic MQTT correspondiente, se trata de explotarla de manera adecuada. Y en este caso, Home Assistant nos lo pone bastante sencillo, ya que existe una integración de tipo cámara MQTT directamente incorporada a Home Assistant. Su uso es tan sencillo como indicar el topic del que tendremos que recoger la imagen:
camera:
– platform: mqtt
name: MQTT Cam
topic: MQTT_TOPIC_PATH
El resultado es el que sigue:
Captura de cámara MQTT en Home Assistant
En mi caso, una topa del recibidor del piso de Forcarey.
Otros usos: sistema de alarma mediante correo electrónico con Node-Red
Pero estando ya este sistema montado, y merced a algunos detectores de apertura de puertas y ventanas Zigbee que ya tenía previamente instalados, es posible dar una vuelta de tuerca, y hacer algo más interesante: un sistema que detecte aperturas no deseadas de la puerta de la entrada, que tome varias imágenes, y las envíe por correo electrónico a un buzón previamente definido. El proceso es el siguiente: tengo instalado en la puerta un sensor de apertura Zigbee. La información de este sensor es procesada por un servidor Zigbee2MQTT, que vuelca en un topic MQTT la información de cuándo se activa este sensor. Este topic es procesado mediante una automatización en Home Assistant que, cuando se encuentra activada, envía una señal de alarma mediante un segundo topic MQTT. A su vez, tengo un script en Python en la Orange Pi Zero de Forcarey que se encuentra suscrito a este topic, y que cuando detecta una activación del mismo, toma tres imágenes a intervalos regulares, y las envía codificadas como bytearray por un tercer topic MQTT. Y por último, tengo creado en Node-Red un flujo que está suscrito a este último topic, descodifica las imágenes, y las envía a una cuenta de correo como un adjunto.
Flujo de Node Red de envío de correo
Admito que tiene que haber maneras más sencillas de hacerlo, pero esta resulta bastante instructiva. 
Etiquetas: esp32-cam, home assistant, mqtt, node-red, orange pi zero, python, zigbee, zigbee2mqtt
12 jun 21 Explotación de datos abiertos mediante Node Red: Colegios de Galicia
Estos días he estado jugando un poco con una fuente de datos abiertos proporcionada por el Gobierno de España para resolver un pequeño problema que teníamos en casa: cómo priorizar la elección de centro para el curso que viene que tiene que realizar Ana. El caso es que ha estado este año trabajando de interina en un colegio de la zona de Carballiño, y para el curso que viene tiene que indicar su prioridad de centros. Tiene la posibilidad de escoger cualquiera de las provincias, pero una de las posibilidades es escogerlos de manera individual. Y para nosotros, teniendo en cuenta que tenemos un piso en Forcarey, un criterio bastante importante es el de la proximidad geográfica, y el de la facilidad de desplazamiento en carretera.
El problema a priori se planteaba complicado, ya que en la zona interior de Galicia donde está Forcarey, cerca de los límites de las cuatro provincias, ninguno de los dos teníamos nociones de cuáles podían ser los centros más apropiados. Mirarlos de manera individual podía ser un dolor de cabeza, por lo que me puse a pensar en maneras de optimizar la elección, y di con algo bastante interesante. Existe en el catálogo de datos puestos a disposición por parte del Gobierno una categorización de todos los Centros Educativos de Galicia. Categorización que incluye el tipo de centro (público, privado, CEIP, IES…) así como (y esta era la clave del asunto) sus coordenadas geográficas.
Información XML de los colegios de Galicia
Exactamente lo que estaba buscando. A partir de ahí, la idea era poder representarlos en un mapa, para poder determinar los más convenientes para nuestra ubicación. ¿Y cómo hacerlo? Por suerte, tengo experiencia con Node Red y su estupendo plugin para mapas. No tardé en realizar un flujo, que extrae de las fuentes en XML (una por provincia) la información de cada colegio, clasificarlo, filtrarlos por tipo, y crear una entrada en el mapa para cada colegio, con información relevante:
Flujo de procesamiento en Node Red
¿El resultado? Estupendo. Un mapa en el que se puede observar los centros, clasificados por los tipos que nos interesan, y con la información relativa a código de centro, dirección y algunos datos adicionales.
CEIPS y CPIs en las cercanías de Forcarey
Este ejercicio, aparte de lo obvio, me ha permitido sacar una información derivada adicional bastante interesante, y es el conocer las zonas más despobladas o con población más envejecida de Galicia. Y es que si se observa el mapa completo de la Comunidad, es fácil ver que hay zonas muy extensas en las que no existe colegio alguno de Primaria. Es decir, zonas sin habitantes, o al menos sin niños (lo que suele ser parejo):
CEIPs y CPIs de Galicia
Esta es la maravilla de poder usar datos abiertos.
Etiquetas: datos abiertos, datos.gob.es, node-red, opendata
24 abr 21 Trazabilidad de activos en exterior con LoRaWAN, Chirpstack, Node-Red y una arquitectura de microservicios
Bonito combo el del título de este artículo, ¿verdad? A resultas de algunas actividades que estoy realizando en el trabajo relacionadas con redes IoT industriales, en mi tiempo libre le he dado una vuelta de tuerca al proyecto, para realizar un piloto de trazabilidad de activos en exterior. Cómo no, basado en el uso de LoRaWAN y Chirpstack, como contaba en un artículo anterior.
Arquitectura LoRaWAN
La cosa es que aprovechando que contaba con una pequeña infraestructura local de Chirpstack desplegada mediante microservicios, me hice con un dispositivo de Dragino bastante interesante, el LBT1:
Dragino LBT1
Este dispositivo es bastante interesante: integra un módulo GPS que permite obtener su ubicación precisa, que es trasmitida mediante LoRaWAN para ser posteriormente explotada. Pero cuenta con capacidad Bluetooth, para realizar ubicación en interiores mediante iBeacons; dispone de un acelerómetro, de tal manera que el dispositivo tiene capacidad de enviar la señal LoRaWAN cuando detecta movimiento y no de manera indiscriminada, con el consiguiente ahorro de batería; tiene una batería recargable de 1000 mAh (que he podido probar que da para más de una semana de actividad sin necesidad de recarga); y cuenta con un botón que -en su configuración por defecto- permite pasar al dispositivo a un modo de emergencia, de tal manera que pasa a emitir la señal de manera periódica (y no activada por el acelerómetro, como en el modo normal), y con una codificación del paquete de datos específica, de tal manera que es posible distinguirlo de una transmisión normal, y actuar en consecuencia.
Estas capacidades, junto con la característica de integración HTTP proporcionada por Chirpstack, permiten algo bastante interesante, y es realizar un sistema de monitorización de activos en exterior, si lo combinamos con un procesamiento en segundo plano. Para ello, en mi caso, he utilizado Node-Red.
Flujo Node-Red para trazabilidad de activos
La idea general es la siguiente: se establece un punto de entrada desde donde recibir los POST HTTP provenientes de Chirpstack, que nos harán llegar cada uno de los eventos provenientes de los dispositivos. Aquí realizamos un primer procesado para obtener información relevante de la señal transmitida (básicamente, latitud, longitud, identificador del dispositivo, cantidad de carga de la batería, y si se trata o no de una señal de emergencia). Con esta información realizamos dos acciones: representar cada objeto definido en la aplicación Chirpstack y que esté enviando señal en el mapa, bien con un icono verde si todo va bien, o con un icono rojo si se ha pulsado el botón de emergencia. Además de esto, se mantiene trazabilidad de los movimiento realizados creando una línea con las distintas ubicaciones GPS enviadas por el dispositivo. Todo ello se representa sobre un mapa, que permite definir zonas de calor, y filtrar por cada uno de los objetos que estén enviando señal. El resultado es algo como esto:
Mapa de ubicaciones resultante
El sistema, además, tiene capacidad para integrarse con sistemas de monitorización de terceros, así como con sistemas de alerta específicos. En mi caso he realizado un procesamiento adicional, que consiste en realizar persistencia de datos para su análisis posterior, en este caso, mediante una hoja de Google Spreadsheet, lo que es interesante de por sí, y puede dar para otro artículo.
Este ejemplo de aplicación tiene bastantes aplicaciones prácticas: realizar seguimiento de activos en una zona exterior de una empresa, seguimiento de personas mayores en zonas urbanas sin coste de transmisión de datos, y con la capacidad de que emitar una señal de emergencia en caso de necesidad, o el seguimiento de visitantes en parques naturales y zonas boscosas, ya que como demostré hace algún tiempo, es posible cubrir zonas muy amplias en entorno forestal con un despliegue de infraestructuras mínimo. E incluso, que es lo que tenía en mente, un sistema para seguimiento de ciclistas o senderistas de montaña en zonas de montaña.
Etiquetas: chirpstack, dragino, lora, lorawan, microservicios, node-red
25 ene 20 Integración de una estación meteorológica doméstica en el sistema de domótica
Estas Navidades me han regalado una estación meteorológica casera, de las que tienen capacidad para mostrar temperatura y humedad tanto en interior como en exterior, esto último mediante un módulo externo que se deja a la intemperie, y que transmite la información a la estación mediante señal de radio a 433 MHz. Aparte de por el regalo en sí, este tipo de estaciones me venía interesando desde hace bastante tiempo por el hecho de enviar la información utilizando la banda antes mencionada, de la que dispongo unos cuantos receptores. Así que en cuanto abrí el regalo supe que iba a invertir algo de tiempo en intentar integrar el sensor externo en mi sistema de domótica.
Mi nueva estación meteorológica
Tras investigar un poco sobre este tipo de estaciones, encontré que la mayoría de ellas hacen uso de protocolos de comunicación bien definidos y relativamente estandarizados, lo que hace que sea razonablemente sencillo encontrar información sobre las mismas, e incluso implementaciones de dichos protocolos para entornos linux o arduino. Dicho lo cual, empecé a hacer algunas pruebas de implementación de un sistema que permitiera recibir la información del emisor externo. Las primeras pruebas las hice con un receptor basado en arduino y un módulo 433 MHz, más la librería rc-switch que tan buenos resultados me había dado en el pasado. No fue este el caso, ya que al intentar capturar paquetes enviados por la estación el programa de captura de paquetes basados en esta librería producía un error de desbordamiento, siendo incapaz de recibir correctamente el datagrama. Hice algunas pruebas en bruto con otras librerías, entre las que se incluían algunas diseñadas específicamente para alguno de los protocolos de envío antes mencionados, con resultados igualmente infructuosos.
NodeMCU con receptor a 433 MHz y módulo externo de la estación
Ante ello, no me quedó más remedio que cambiar el enfoque. Tocaba acometer el problema desde una perspectiva más basica. Así que me tocó desempolvar un receptor RTL SDR que compré hace algún tiempo para un proyecto similar, e intentar hacer una captura del datagrama a nivel de onda enviada, e intentar decodificar la misma (tirando para ello de programas como Gqrx, audacity, y algo de tiempo. Sin embargo, tuve algo de suerte, y tras seguir investigando un poco más, encontré una referencia a un proyecto, rtl_433, que se dedica a decodificar el tráfico de dispositivos que envían información en esta banda.
Captura de pantalla de rtl_433 capturando tráfico
Tras una instalación sencilla en mi equipo con Debian (apt install rtl_433), y tras conectar el receptor RTL SDR al mismo, tuve la suerte de que el programa tuviera perfectamente identificado el tipo de protocolo que mi estación estaba utilizando, en concreto el protocolo “Kedsum Temperature & Humidity Sensor, Pearl NC-7415″. Trasteando un poco con el programa, pude tener algo más de información sobre este protocolo, a saber:
Frame structure:
Byte: 0 1 2 3 4
Nibble: 1 2 3 4 5 6 7 8 9 10
Type: 00 IIIIIIII BBCC++++ ttttTTTT hhhhHHHH FFFFXXXX
- I: unique id. changes on powercycle
- B: Battery state 10 = Ok, 01 = weak, 00 = bad
- C: channel, 00 = ch1, 10=ch3
- + low temp nibble
- t: med temp nibble
- T: high temp nibble
- h: humidity low nibble
- H: humidity high nibble
- F: flags
- X: CRC-4 poly 0×3 init 0×0 xor last 4 bits_Modulation = OOK_PULSE_PPM,
-Short_width = 2000,
-Long_width = 4000,
-Gap_limit = 4400,
-Reset_limit = 9400,
Bien, ya tenía identificado claramente el protocolo, y aquí puede verse una captura de la señal recibida:
root@asustinker:/etc/systemd/system# /usr/local/bin/rtl_433 -R 57
rtl_433 version 19.08-147-g639ab8a branch master at 202001210044 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.Consider using “-M newmodel” to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.Registered 1 out of 145 device decoding protocols [ 57 ]
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-01-25 15:24:00
model : Kedsum Temperature & Humidity Sensor ID : 226
Channel : 1 Battery : OK Flags2 : 129 Temperature: 60.20 F Humidity : 78 % Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Bien, esto me planteaba dos problemas: el primero es que la información recibida de temperatura estaba expresada en grados Fahrenheit, por lo que necesitaba hacer una conversión a Celsius. Y por otro lado, el poder transmitir esta información a mi plataforma de domótica, preferentemente a través de MQTT. Este segundo problema quedó solucionado mediante la capacidad del programa rtl_433 de encapsular la información en un JSON, que puede ser retransmitido posteriormente. En mi caso, lo hice mediante un servicio linux que lanza el programa rtl_433 con las opciones adecuadas (formato JSON, protocolo 57 -Kedsum-, e incrustando la hora UTC), que mediante un pipe es procesado por el cliente MQTT mosquitto y enviado a mi servidor MQTT, a un topic específico:
“/usr/local/bin/rtl_433 -R 57 -F json -M utc | /usr/bin/mosquitto_pub -l -h servidor_mqtt -t topic”
…donde posteriormente es procesado gracias a Node Red, en el que se hace la conversión a Celsius, se obtiene también la sensación térmica, y se inyecta la información resultante en formato JSON en un topic específico:
var data=JSON.parse(msg.payload);
//Datagram example: {“time” : “2020-01-22 19:27:58″, “model” : “Kedsum Temperature & Humidity Sensor”, “id” : 226, “channel” : 1, “battery” : “WEAK”, “flags” : 66, “temperature_F” : 54.600, “humidity” : 79, “mic” : “CRC”}
temp_value=((data.temperature_F-32)*5/9).toFixed(2);
humidity=data.humidity;HI = 0.5*(data.temperature_F + 61.0 + ((data.temperature_F-68.0)*1.2) + (humidity*0.094))
HIc = (((HI)-32)*5/9).toFixed(2); // converting to Celsiusvar thing = {
temp: temp_value,
humidity: humidity,
heatindex: HIc
};
msg.payload=thing;return msg;
…y el resultado de todo esto fue un… ¡exito! Pasé a conectar el receptor RTL SDR a mi Asus Tinker Board donde tengo implementado el sistema de domótica, con excelentes resultados. El sistema, emplazado en la segunda planta de casa, es capaz de recibir las señales del receptor externo emplazado en el patio.
Asus Tinker Board con receptor RTL SDR
Por otro lado, quedaba la integración en el sistema de domótica Home Assistant. En este caso, se trataba de alto tan simple como crear los nuevos sensores en base a la suscripción al topic MQTT de salida definido en el flujo Node Red. El resultado, como no podía ser menos, fue perfecto:
Información mostrada en Home Assistant de la estación meteorológica
Gráfica de la información histórica recibida
Este artículo podría haber quedado aquí, pero no me encontraba completamente satisfecho con el resultado, ya que me daba la impresión de que utilizar el receptor RTL SDR solo para este propósito era matar moscas a cañonazos. Mi idea originaria era usar un ESP8266 junto con un módulo RF de 433 Mhz para recibir estas señales, y decodificarlas en el mismo, para inyectar la información directamente en el servidor MQTT, y no tener que dar tantos saltos (RTL SDR -> JSON -> MQTT -> Node Red -> MQTT). No tuve éxito en encontrar una codificación del protocolo bajo el nombre de Kedsum, pero sí la tuve con Pearl NC-7415. Encontré un hilo en un foro de Arduino en alemán, que hablaba precisamente de ello: Dekodieren Temperatursensor von PEARL NC7427(NC7415) 433MHz. Gracias, Google Translate.
En este hilo pude encontrar alguien que había decodificado exitosamente el protocolo, y que compartía el código. Lo descargué y lo probé y… ¡funcionaba perfectamente! Solo tuve que hacer una modificación menor para realizar la conversión de Fahrenheit a Celsius, calcular la sensación térmica, e inyectarlo en el topic MQTT (el original no hacía nada de esto, se limitaba a mostrar la información por pantalla). Y de nuevo, éxito:
Información recibida en ESP8266 y RF, enviada a servidor MQTT
Sin embargo, esta vía tiene un problema: el receptor apenas es capaz de recibir la señal cuando se encuentra a unas pocas decenas de centímetros del emisor externo. Así que en la práctica ahora mismo es inusable. He probado con varios formatos de antena acoplados al módulo (173mm de largo, en hilo recto, en espiral…) con resultados bastante pobres. Tengo encargada en aliexpress una antena específica, pero aún tardará algunas semanas en llegar. Espero poder reportar mejoras una vez la reciba. 
Etiquetas: 433 mhz, arduino, asus tinker board, audacity, debian, esp8266, gqrx, home assistant, kedsum, mqtt, node-red, nodemcu, rtl sdr, rtl_433
Medidor de entropía
