Llevo ya un par de artículos sobre las pruebas que he estado efectuando con enlaces soportados con tecnología LoRa, y no podía postergar más el hablar sobre una tecnología que va un paso más alla: LoRaWan. LoRaWan, en líneas generales, es un protocolo de comunicaciones que, haciendo uso de tecnología LoRa, permite proporcionar conectividad a múltiples dispositivos que se basan en LoRa. La idea básica es que LoRa proporciona los enlaces punto a punto, mientras que LoRaWan proporciona una red de comunicaciones. Para ello se apoya en la definición de dos tipos de dispositivos, los nodos y los gateways. Los primeros son los dispositivos individuales -por lo general IoT- que actúan como clientes, enviado y recibiendo información de la red. Los segundos, por su lado, conforman la infraestructura que enlaza los clientes individuales con el resto del sistema, actuando como pasarela con redes convencionales como puede ser Internet.
En toda esta introducción la palabra importante es red. Mientras que en mis pruebas anteriores hacía uso de un par de dispositivos enlazados, aquí se trata de dar un paso más allá. ¿Y cómo haces uso de una red? Bueno, hay dos maneras: o la construyes, o usas una ya existente. La primera opción es viable en el caso de querer construir una red privada, para algún cliente o un proyecto concreto, pero en la mayoría de los casos no es un escenario realista. Pero en cuanto a la segunda, es esta la parte realmente interesante de los sistemas LoRaWan. Existen redes, tanto públicas como privadas, a las que es posible conectarse y hacer uso de las mismas. Y una de las redes abiertas más conocidas a nivel mundial es The Things Network, también conocida como TTN.
Cuando, de nuevo hace ya un par de años largos, adquirí mis dispositivos LoRa, cometí un error de novato. Pedí un dispositivo de 868 MHz y otro de 433. Algo que hacía perfectamente inútiles los intentos de comunicación entre ellos. Esa fue la razón para adquirir un segundo dispositivo de 433 MHz para mis pruebas de enlace punto a punto. ¿Pero qué hacer con el kit de 868 MHz? Podía comprar un segundo y hacer lo mismo, pero fue entonces cuando tuve noticias de TTN. Una red LoRaWan que permite el acceso gratuito a la misma para la transmisión y recepción de mensajes (aunque con límites de capacidad -fair use-), pero que para una transmisión de pruebas de un sistema IoT era más que sobrado. La pregunta es: ¿existía un despliegue de esa red en Sevilla? Y la respuesta es que sí.
Como se puede ver en el mapa de gateways, hay un buen nivel de cobertura de la red TTN en Sevilla capital y el Aljarafe… salvo en Santiponce. En efecto, hice algunas pruebas en casa, con resultados completamente infructuosos. Pero en la Isla de La Cartuja, donde está mi oficina, había cobertura teórica, y dos gateways en las inmediaciones, a unos 1500 y 1700 metros de distancia. Cerca del límite teórico del alcance de los Heltec, y más dentro de un edificio. Pero era cuestión de hacer la prueba. Así que aprovechando un día, al comienzo del confinamiento, en que tuve que desplazarme a la oficina por razones de continuidad de negocio, aproveché para hacer algunas pruebas de conexión.
Para ello hice uso de una librería específica que Heltec ha desarrollado para las conexiones LoraWan, además de registrar -paso obligado- mi dispositivo para obtener una licencia de uso de Heltec. Además de esto, es necesario registrarse en TTN y configurar una aplicación para poder hacer uso de la red, además de registrar tu dispositivo a fin de obtener una serie de identificadores únicos para los dispositivos que se habrán de conectar a la red. Se pueden seguir los pasos en el siguiente artículo: Heltec ESP32 Board + The Things Network. Y tras algunas pruebas, ajustes y apretar -metafórico- de tuercas…
…conseguí establecer de manera exitosa sendos enlaces con dos de los gateways cercanos a la Isla de La Cartuja. En concreto, a los ubicados en la Alameda de Hércules y la Plaza de la Encarnación, con una distancia máxima de algo más de 1700 metros desde mi ubicación, como se puede apreciar en la siguiente imagen:
La prueba no dio para mucho más, ya que tenía otros menesteres de los que ocuparme en la oficina, pero sirvió para demostrar que era posible trabajar con TTN y dispositivos Heltec, incluso haciendo uso de la antena de fábrica en condiciones adversas. En fechas posteriores, visto el éxito de la prueba en la oficina, realicé algunas nuevas pruebas de larga distancia desde Santiponce, tanto con antenas de fabricación propia (hasta la base está sacada con la impresora 3D)…
…como con antenas fabricadas por terceros:
En ninguno de los casos logré un enlace con ninguna de las redes de TTN en Sevilla o el Aljarafe. No es sorprendente, ya que la más cercana se encuentra a 7 km. de distancia de mi domicilio, y obstaculizadas por la orografía del terreno, y edificios que se interponen en la línea de visión directa. Además, en todos los casos he usado antenas omnidireccionales. Queda por realizar una prueba con antenas direccionales (estoy pensando en una tipo yagi), pero antes de eso, aún tengo que hacer pruebas con línea directa de visión y las antenas de las que actualmente dispongo. El lugar perfecto es el cerro de Santa Brígida, en Camas. Estoy deseando que podamos realizar más deplazamientos para acercarme con la bici y hacer estas pruebas.
Etiquetas: 868 MHz, esp32, heltec, impresora 3d, lora, lorawan, santiponce, sevilla, the things network, ttn, yagi
Después de las pruebas de comunicación LoRa realizadas el pasado día 2, el 3 volví a salir en los ratos en los que hay autorización para salir de casa por el coronavirus, con el objeto de realizar una prueba que complementara a las realizadas el día anterior. Según había comentado, la primeras pruebas las realicé hacia el norte y el sureste de mi domicilio en Santiponce, ya que esas ubicaciones se encuentran relativamente libres de obstáculos propios de la orografía del terreno, pero que albergaba mis dudas sobre el alcance de los enlaces hacia el oeste, debido a que las colinas donde se ubican Itálica y la propia Santiponce se interponen en cualquier línea de visión directa. Es más, las edificaciones del propio casco urbano bloquean en gran manera las señales entre emisor y receptor. Teniendo en cuenta estos condicionantes, no quería que la primera de las pruebas se desvirtuara con este entorno tan desfavorable, por lo que opté por hacer las pruebas de alcance en otras ubicaciones.
Sin embargo, también resultaba interesante en sí probar el alcance de la señal en entornos más adversos, y en el caso particular de Santiponce, me interesaba hacer la prueba porque hacia el oeste desde mi domicilio transcurre la Vía Verde de Itálica. Esta vía verde, antiguo ferrocarril minero entre el cargadero de mineral existente en Camas y la mina de Aznalcóllar, permite circular entre campos de labranza por la campiña sevillana, por lo que es bastante interesante para hacer pruebas de dispositivos IoT en zonas rurales y agrícolas. Ante todo esto, el domingo me dispuse a hacer una nueva prueba. Además, para llegar a la vía verde, es preciso atravesar parte del casco urbano del pueblo, lo que me daba oportunidad de probar el alcance de la señal en una zona con la visión directa completamente bloqueada por edificios.
Realicé la prueba a las 8:00h del domingo, y de nuevo, los resultados fueron mucho mejores de lo esperado. En la zona urbana no llegó a perderse la señal en ningún momento, pese a la falta de visión directa, discurrir entre edificios, y con la propia ladera de Santiponce bloqueando la señal. Una vez en campo abierto, donde existe vegetación densa en la cerca de Itálica que bloquea la visión, y donde el propio cerro de Itálica se interpone entre mi receptor y la vía verde, la señal se recibió en todo momento, salvo en dos pérdidas puntuales en la zona más alejada del recorrido, a 1300 metros del receptor. Incluso en el camino de vuelta, de nuevo con la arboleda de Itálica y un cerro bloqueando completamente la visión, la señal no se interrumpió en ningún momento. A continuación dejo una vista con Google Earth de la prueba efectuada y el recorrido realizado.
Como comentario adicional, me llamó la atención la gran cantidad de gente que se encontraba en esos momentos en la vía verde, aprovechando el tiempo permitido de salida por el coronavirus. Algo que he podido constatar los dos días posteriores, cuando he salido a hacer algo de bici.
Etiquetas: iot, itálica, lora, santiponce, vía verde de itálica
En estas semanas en las que el coronavirus nos ha trastornado la vida a todos, he aprovechado para retomar algunos viejos proyectos que por diversas razones había dejado aparcados hasta mejor ocasión. Uno de estos proyectos (ya habrá tiempo para hablar de otros) era el de lograr un sistema que permitiera recibir información de sensores distribuidos en zonas abiertas. En pocas palabras, sensorización IoT en el ámbito rural. No es exactamente una idea nueva, y era algo que me rondaba la cabeza cuando volví de Irlanda. Ya en su momento me hice con un par de dispositivos Heltec LoRa 32, que disponen de pantalla OLED incorporada, para hacer mis pinitos con ellos. Unos cacharros bastante interesantes, ESP32, con conectividad WiFi y Bluetooth Low Energy además de LoRa. Y aquí la parte importante es LoRa. LoRa (Long Range) es un protocolo de comunicación de larga distancia (WAN) y bajo consumo energético, que haciendo uso de frecuencias libres, permite crear enlaces de datos entre distintos dispositivos, o bien establecer redes de datos completas (cuando ya hablamos de LoRaWAN). Las principales características del protocolo LoRa son las siguientes:
Como decía, adquirí los dispositivos, pero luego nunca tuve tiempo para ponerme a dedicarme a ello. Hasta estas semanas, que han coincidido varias circunstancias que me hicieron volver a dedicarle tiempo al proyecto: el confinamiento por coronavirus, unas iniciativas en el trabajo a las que esta tecnología podría aplicar, y que he dedicado algo más de tiempo a investigar con sistemas ESP32 que con los convencionales ESP8266. Así que tocó desempolvar los viejos Heltec LoRa que tenía guardados, y ponerlos a funcionar.
Heltec proporciona una librería bastante interesante para el IDE de Arduino que permite hacer funcionar de una manera bastante sencilla a una pareja de dispositivos. Como decía más arriba, los Heltec pueden funcionar en modo unidireccional (una unidad emisora y otra receptora), bidireccional (intercambio en ambos sentidos para cada dispositivo) o bien en multidifusión (un mensaje es recibido por todos los dispositivos que estén en su rango de alcance). La manera más simple de empezar es con un emisor y un receptor, sin hacer uso de direcciones de dispositivo. Simple y efectivo, la librería viene con ejemplos de funcionamiento de este tipo, y en cuestión de minutos puedes tener un enlace LoRa funcionando. En mi caso, los dispositivos de que dispongo funcionan a 433 MHz, y pude tener comunicación en toda la casa, y en campo abierto pude llegar a establecer sin muchos problemas enlaces de 300 metros con las antenas que traen los dispositivos.
Bien, 300 metros no es gran cosa cuando según el protocolo podemos llegar a decenas de kilómetros. Con estas primeras pruebas pude aprender algunas cosas interesantes:
Tras haber aprendido esto en una serie de pruebas sucesivas, pero en las que no podía verificar el alcance efectivo alcanzado debido al confinamiento, me preparé para hacer una verdadera prueba de campo, en cuanto tuviera la oportunidad. Y la oportunidad llegó hoy. Al haberse permitido salir a realizar actividades deportivas por la mañana, preparé un escenario de prueba que pudiera efectuar mientras -cómo no- saliera a dar una vuelta con la bici por los alrededores de mi domicilio. La prueba consistió en lo siguiente:
Los resultados de la prueba han sido espectaculares. En dirección norte he logrado un enlace de 5.3 km de distancia, sin visibilidad directa con Santiponce, debido a las ondulaciones del terreno. Esto representa casi el doble del alcance que indica el fabricante para este tipo de dispositivos. Si bien esta ha sido la mayor distancia que ha alcanzado un paquete, una señal confiable, sin pérdida apreciable de paquetes, la he conseguido a 4.5 km de distancia, igualmente sin visibilidad directa.
Hacia el sureste, he alcanzado de manera confiable los 4.2 km de distancia en el enlace, en el mismísimo puente de la SE-30 sobre la Guadalquivir, junto al Estadio Olímpico.
Es probable que la señal pudiera llegar más allá, pero por la configuración del terreno, y porque se alcanzaba el fin del horario establecido para hacer deporte por la mañana, me tocaba volver a casa. También es de reseñar que en esta dirección a gran parte de la zona se encontraba en una sombra de cobertura, ya que las edificaciones de Santiponce, además de los taludes de la autovía y la vía férrea a Huelva se interponían entre ambas antenas, bloqueando la línea directa de visión.
Pero visto lo visto, es bastante posible que a una altura elevada se pueda tener un nivel de recepción decente en la Isla de la Cartuja. Cuando tenga oportunidad, haré pruebas desde la azotea del edificio de GMV, ubicado a 5.2 km de mi receptor.
Durante las pruebas he realizado algunas grabaciones en puntos significativos del recorrido. He compilado las más interesantes en el siguiente vídeo
Seguimos con actualizaciones sobre domótica. En esta ocasión se trata de un mando un tanto especial: un Aqara Cube de Xiaomi. Consiste en un cubo con una serie de sensores de movimiento y acelerómetros que permiten (según el fabricante) definir seis gestos con el que controlar distintos elementos del sistema de domotica: agitar, golpear dos veces, girar a la izquierda, girar sobre una cara, voltear 90º y voltear 180º. Y especifico lo de “que dice el fabricante” porque existe la manera de sacar mucho más partido de las especificaciones base: utilizar Zigbee2MQTT.
El cubo se integra en el sistema de domótica (bien el del fabricante, bien de un tercero) mediante protocolo Zigbee. Y es aquí donde viene lo interesante: si se hace uso del sistema de integración de código abierto Zigbee2MQTT, se descubre que el cubo envía mucha más información de la que el fabricante permite hacer uso en su sistema propietario. A las acciones anteriores añade información extra de la cara desde la que se realiza la acción; en el caso de las acciones de giro, si es a derecha o izquierda, y el ángulo del giro aplicado; y en el caso de las acciones de volteo, las caras origen y destino. Todo esto permite dotar de mucha más potencia a la integración con el sistema, definiendo una gran variedad de gestos para controlar distintos sistemas. La única pega es que el cubo sólo identifica visualmente una cara (con el logo del producto), pero no el resto, así que puede resultar un tanto confuso a menos que nosotros marquemos visualmente el cubo de alguna manera.
En cuanto a la integración con el sistema, en la parte Zigbee2MQTT es prácticamente inmediata: el mismo sistema identifica e integra el cubo en sus elementos soportados, sin necesidad de acciones adicionales. Una vez integrado, las acciones realizadas se vuelcan a log y al servidor MQTT con un formato JSON como el siguiente:
info 2020-01-28 15:05:20: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:157,”action”:”shake”}’
info 2020-01-28 15:05:20: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:157,”action”:”"}’
info 2020-01-28 15:05:34: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:141,”action”:”rotate_left”,”angle”:-164.38}’
info 2020-01-28 15:05:34: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:141,”angle”:-164.38,”action”:”"}’
info 2020-01-28 15:05:35: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:134,”angle”:-6.42,”action”:”rotate_left”}’
info 2020-01-28 15:05:35: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:134,”angle”:-6.42,”action”:”"}’
info 2020-01-28 15:05:38: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:144,”angle”:202.68,”action”:”rotate_right”}’
info 2020-01-28 15:05:38: MQTT publish: topic ‘zigbee2mqtt/0x00158d0002e94430′, payload ‘{“battery”:37,”voltage”:2865,”linkquality”:144,”angle”:202.68,”action”:”"}’
En lo referente a la integración con el sistema de domótica Home Assistant, tampoco supone mayor problema. La idea es definir automatizaciones para los distintos elementos a controlar, con una sintaxis similar a la siguiente:
automation:
– alias: Respond to Cube action
trigger:
platform: mqtt
topic: ‘zigbee2mqtt/condition:
condition: template
value_template: '{{ "tap" == trigger.payload_json.action }}'
action:
entity_id: light.bedroom
service: light.toggle
…en las que la idea es recoger el valor JSON del topic MQTT correspondiente, y disparar acciones en el sistema. Esto se puede complicar todo lo que se quiera, para identificar las caras del cubo, ángulos de giro, etc… ¿Y el resultado? Pues algo como lo que sigue:
Control de las luces del salón de la casa.
Control de la pérgola del patio.
La experiencia de uso es muy buena, ya que permite integrar el control de múltiples dispositivos en un mismo mando, y obviar el uso del control del teléfono para acciones avanzadas, como veníamos haciendo hasta ahora. Una gran adquisición.
Etiquetas: aqara cube, domótica, home assistant, zigbee, zigbee2mqtt
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.
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.
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.
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.
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:
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:
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