msgbartop
Sé lo que estás pensando, si disparé las seis balas o sólo cinco.
msgbarbottom

19 sep 20 Los nodos LoRaWAN. Hardware y software

Esta entrada es la parte 4 de 6 de la serie Gateway LoRaWAN

Para este proyecto estoy utilizando como nodos LoRaWAN unos dispositivos CubeCell de Heltec. En concreto estoy haciendo uso de las Dev-Board (HTCC-AB01), que integran el patillaje necesario para conectar de manera sencilla los CubeCell a un ordenador para cargarles el código necesario.

IMG_20200919_183904_1.jpg

Estos dispositivos hacen uso de un chiop ASR6501, que integra una MCU PSoC de la serie 4000 (ARM® Cortex® M0+ Core), y el chip LoRA SX1272. La principal ventaja es que son completamente compatibles con Arduino, tienen capacidad para ser alimentados directamente por batería o un pequeño panel solar (desde 5.5 a 7v), y un consumo realmente bajo: 10 mA en modo recepción LoRa, 70 mA emitiendo a 10 dB, y apenas 3.5uA en modo Deep Sleep, lo que los hacen muy adecuados para entornos de muy bajo consumo energético. Además dispone de 8 puertos de E/S, UART, SPI e I2C, además de otras características bastante interesantes.

ab01pinout-1024x531

Sin embargo, y a pesar de que los dispositivos están bastante bien, tienen agún inconveniente con respecto a los Heltec LoRa 32. Los más importantes es que carecen de interfaz WiFi y de Bluetooth. No es demasiado grave, ya que no están pensados para ser dispositivos multiconexión -para eso están los LoRa 32 con su chip ESP32-, sino para priorizar el bajo consumo.

En cuanto a la programación, se puede realizar mediante el IDE de Arduino, como cualquier otro dispositivo. Hay que tener en cuenta, que su programación difiere ligeramente con respecto a los Heltec LoRa 32. Esto tiene un par de implicaciones: la primera es que no se hace uso de la librería Heltec, sino que se utiliza una librería específica (LoRaWan_APP), que la declaración del objeto LoRa es distinta, siendo necesario especificar manualmente determinados parámetros que en el caso de la librería Heltec ya vienen dados muchas veces por defecto, y que sólo es necesario declarar en caso de querer utilizar valores distintos.

#define RF_FREQUENCY 868000000 // Hz
#define TX_OUTPUT_POWER 14 // dBm
#define LORA_BANDWIDTH 0 // [0: 125 kHz,
// 1: 250 kHz,
// 2: 500 kHz,
// 3: Reserved]
#define LORA_SPREADING_FACTOR 8 // [SF7..SF12]
#define LORA_CODINGRATE 4 // [1: 4/5,
// 2: 4/6,
// 3: 4/7,
// 4: 4/8]
#define LORA_PREAMBLE_LENGTH 8 // Same for Tx and Rx
#define LORA_SYMBOL_TIMEOUT 0 // Symbols
#define LORA_FIX_LENGTH_PAYLOAD_ON false
#define LORA_IQ_INVERSION_ON false
#define RX_TIMEOUT_VALUE 1000
#define BUFFER_SIZE 30 // Define the payload size here

La segunda diferencia, como comentaba en el artículo anterior, es que es necesario definir también ciertas configuraciones específicas, precisamente relacionadas con estos parámetros, en la parte del gateway, para garantizar la compatibilidad de las comunicaciones entre ambos dispositivos. No es que haya sido un gran problema, pero me trajo un rato de cabeza hasta que encontré algo de documentación que me hizo la luz a este respecto.

Hay otros dos aspectos finales que quería comentar, también relativos al hardware:

  • El primero es la existencia de un led multicolor que se puede controlar por la librería. Por lo general, se utiliza para distinguir cuándo el dispositivo está enviando o recibiendo paquetes LoRa. Por convenio se utiliza el color rojo para indicar envío, y el verde para recepción, pero esto es completamente configurable. Y muy práctico en el caso de andar enviando datos entre dos CubeCell.
  • El segundo es la antena: el dispositivo viene con una pequeña antena que se conecta mediante un pigtail, pero en mi caso voy a reemplazarla por antenas un poco más elaboradas, para asegurar un mejor enlace.
VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , ,

19 sep 20 El gateway LoRa*. Hardware y software

Esta entrada es la parte 3 de 6 de la serie Gateway LoRaWAN

Seguimos haciendo progresos con mi gateway LoRaWAN. En este caso, en el ámbito del gateway en sí. El lector avispado habrá notado que he encabezado este artículo con Lora* en vez de con LoRaWAN. Y es que en este punto lo que tengo implementado es más bien un gateway LoRa que actúa de pasarela a un servidor MQTT, y no un gateway LoRaWAN propiamente dicho. ¿Cuál es la diferencia? Es sutil, pero importante. A estas alturas lo que he implementado es un gateway, sí, entre dispositivos, y terceros servidores, pero no realizo aún control de acceso, identificadores de equipos en la red, ni nada por el estilo. Así que no puedo -en realidad- considerarlo un gateway LoRaWAN completo. Pero de momento, para el propósito que manejo, basta y sobra.

20200805_094600

Ya he hablado con anterioridad del dispositivo que estoy utilizando para construir el gateway: se trata de una placa Heltec Lora 32, que proporciona capacidad de conexión LoRa, WiFi y Bluetooth, incluyendo la variante Low Energy. Con anterioridad he estado haciendo pruebas con la variante de 433 MHz, pero para este proyecto en cuestión he optado por respetar la normativa radioeléctrica europea, y desplegarlo con la variante de 868 MHz, de la que disponía de un dispositivo que hasta ahora no había hecho un gran uso (en parte porque vino con la pantalla OLED quebrada, y ésta funciona bastante mal). Otro elemento de la configuración es la antena de recepción y el adaptador eléctrico, pero estos elementos quedarán para otro artículo.

En lo referente al software, he desarrollado un software con las siguientes características:

  • La base del sistema son las librerías de Heltec que permiten implementar comunicaciones LoRa. Los aspectos principales de la configuración ha sido establecer los parámetros de conexión adecuados para comunicarse adecuadamente con los dispositivos cliente, en este caso unos Heltec CubeCell. En concreto, los siguientes aspectos son los que hay que configurar:
    LoRa.setSpreadingFactor(8);
    LoRa.setSignalBandwidth(125E3);
    LoRa.setCodingRate4(4);
    LoRa.setPreambleLength(8);
    LoRa.setSyncWord(0×12);
  • El siguiente punto de importancia es la implementación de un sistema de configuración de la conexión del cliente WiFi mediante un AP provisional: IotWebConf. Con esta librería, válida para dispositivos ESP8266 y ESP32, se puede levantar un portal web y un AP para realizar la configuración de la WiFi en el dispositivo. La idea es sencilla: cuando el dispositivo no tiene configurada una conexión WiFi, levanta un punto de acceso con un portal web de configuración, al que se puede conectar para establecer los parámetros de la WiFi (así como otro tipo de parámetros configurables, como el servidor MQTT, por ejemplo). Una vez establecidos, el sistema almacena estos parámetros en la EEPROM de la placa, reinicia, y conecta a la WiFi proporcionada. También permite introducir una nueva configuración WiFi en caso de que se mueva el dispositivo a una ubicación en la que la WiFi configurada no tenga alcance. La principal ventaja es que no hay que preconfigurar en código los parámetros de conexión, pudiendo hacerlo en tiempo de ejecución. A continuación se puede ver una captura de la interfaz web que se levanta:
  • portal-wifi
  • Otro aspecto adicional de esta librería es que permite realizar la actualización de firmware On-The-Air: la interfaz web proporciona una vía para cargar el software precompilado de Arduino en la placa, sin tener que conectar la misma a un PC mediante cable, además de incluir un sistema de seguimiento de versiones de firmware. Sumamente útil, teniendo en cuenta que el gateway va a estar ubicado, en mi caso, en lo alto del tejado.
  • Por último, he realizado algunos ajustes adicionales en optimización de la transmisión de datos entre dispositivo y gateway. La principal (en el caso de transmisión de valores numéricos) es la utilización de codificación hexadecimal, para transmitir menos bytes y optimizar el tiempo de vuelo de los datos.

En cuanto a la recepción de datos, ha sido sumamente exitosa. En el código de ejemplo utilizado en el cliente, se envía una trama compuesta de dos valores en hexadecimal, que son inyectados en un topic MQTT, junto con el valor del RSSI de la transmisión, a fin de controlar la calidad de la misma. El servidor MQTT se encuentra completamente ajeno al sistema, siendo un servidor multifunción que utilizo para diversos proyectos.

trafico-mqtt

El resultado es, hasta ahora, bastante bueno. En próximos capítulos hablaré de otros elementos del sistema.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , , , , ,

01 sep 20 Gateway LoRaWAN: Alimentación eléctrica

Esta entrada es la parte 2 de 6 de la serie Gateway LoRaWAN

Una de las primeras cosas que tuve clara cuando me decidí a instalar un gateway LoRaWAN en casa es que el proyecto tendría que estar sostenido por energías renovables. Mi intención es colocar la antena del dispositivo en el punto más alto de la casa, en la chimenea de evacuación de gases de los cuartos de baño, y eso implica que esa ubicación no dispone de toma eléctrica. Sería posible hacer uno de un cable largo para llevar la conexión de la antena a un punto donde disponga de alimentación eléctrica, o bien sacar una derivación de la alimentación del aire acondicionado que tengo en la buhardilla. Pero seamos sinceros: no es tan interesante como plantearse un sistema de alimentación renovable (y en el primer caso, nos enfrentamos a una más que posible caída de la eficiencia de la antena, por el solo hecho de utilizar un cable más largo del estrictamente necesario). Y en este caso, el sistema elegido ha sido la energía solar.

No es este -bien lo sabrá quien me haya seguido a lo largo de los años- un proyecto estrictamente nuevo para mí. Hace ya años que tuve la idea de montar un aerogenerador en el tejado, con el que estuve haciendo una serie de pinitos en casa. Pero la verdad sea dicha, no fueron unas pruebas demasiado exitosas. Tuve durante un tiempo la iluminación de la casa alimentada por energía eólica, apoyada por un panel solar, pero fue un intento demasiado prematuro: la iluminación que teníamos por aquel entonces era principalmente de lámparas electrónicas, y en la práctica la cantidad de aire en Santiponce no bastaba para generar la energía suficiente como para que el aerogenerador produjera la corriente necesaria. Aquel proyecto quedó abandonado cuando nos fuimos a Irlanda, pero me dejó algunos componentes que he podido reaprovechar.

IMG_20200901_095500574.jpg

El principal es un panel solar de 100W que adquirí como sistema de apoyo para el aerogenerador. Éste sí que funcionaba espectacularmente bien. Incluso tuve durante un tiempo conectado un portátil al sistema de baterías que utilizaba, haciendo uso de un inversor. Pero en la práctica, el sistema tenía bastantes ineficiencias, y el portátil apenas aguantaba unas cuantas horas encendido antes de drenar completamente la batería. En su momento, para colocarlo en el tejado, me hice construir un bastidor metálico que anclé al lateral del tejado. En su día desmantelé el panel y lo guardé en Córdoba, pero el bastidor se quedó colocado (estaba fijado con pernos y tacos químicos, como para quitarlo de ahí), y allí estuvo durmiendo el sueño de los justos. Pero lo he traído de vuelta para este proyecto. Ha sido toda una sorpresa ver el bastidor, que seguía en perfectas condiciones en el tejado.

IMG_20200901_112254805_HDR.jpg

El segundo elemento, cómo no, ha sido el controlador de carga y la batería. El controlador es el proveniente de mi instalación eólica. En su momento adquirí un controlador dual, capaz de gestionar la carga proveniente de un aerogenerador trifásico en alterna y de un panel solar de 12 voltios en continua. Como es obvio, no estoy haciendo -ni lo voy a hacer- uso del aerogenerador, pero sí de la parte solar. Tras 5 años desconectado, tenía mis dudas de si seguiría funcionando. Pero lo hace, y perfectamente.

Por último, la batería: es una batería convencional de coche, de 12 voltios, proveniente de mi añorado Alfa 33. Estaba nueva cuando el coche se vendió en 2017, y estaba igualmente criando polvo en Córdoba. Ha sido necesario someterla a un ciclo de carga, pero de momento parece que está bien. He colocado tanto el controlador como la batería en una caja -ejem- estanca, con la idea de protegerlos de la lluvia. Me preocupa en cierta medida el posible calentamiento al que puedan estar sometidos, pero se han tirado varios días al sol, probando el nivel de calentamiento, y el resultado ha sido satisfactorio. En cualquier caso, este es un proyecto experimental, con idea de probar precisamente estas cosas.

EL sistema, por tanto, trabaja a 12 voltios en continua. Dado que voy a utilizar como elemento base para el gateway un dispositivo Heltec con Arduino, que trabajan a 5 voltios en continua, tendré que incorporar un elemento para convertir el voltaje. Probablemente haga uso de un buck converter DC-DC de 24v a 5v, regulable, como el que utilicé en el proyecto del difusor de aceites. Pero eso ya quedará para otro capítulo.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , ,

25 ago 20 Adaptación a IoT de un robot de limpieza Dirt Devil e integración en Home Assistant

Estos días he estado juegueteando un poco con un viejo robot de limpieza doméstico del Lidl, un Dirt Devil. Es un robot de limpieza bastante básico, con algo ya de tiempo a sus espaldas. No dispone de ninguna capacidad de integración con sistemas de domótica, ni nada que se le parezca. Es más, ni siquiera tiene WiFi. Pero tiene algo interesante: su funcionamiento se basa en el uso de un chip etiquetado como RV285R, que controla toda una placa de circuitos integrados para realizar las funciones del robot: movimiento de los cepillos, ventilador de succión, detección de golpes, sensores de vacío para que no se caiga por escaleras… El caso es que buscando un poco por Internet, encontré un par de páginas sumamente interesantes sobre cómo reemplazar este chip por un sistema Arduino. Así que aprovechando que sigo de vacaciones, no podía menos que dedicar algo de tiempo al asunto.

De acuerdo a la información compartida por Paijmans, el chip RV285R trabaja a 5 voltios, por lo que es posible hacerlo funcionar directamente en dispositivos Arduino. Con un trabajo de ingeniería inversa, fue capaz de obtener la información de a qué se dedican los pines del chip:

rv285r-pinout

Yo he podido refinarlo un poco más, distinguiendo las funcionalidades de los pines:

  • P50: Led azul, o de encendido
  • P67: Detector de colisión (bumper)
  • P66: Zumbador interno
  • VDD: 5 voltios
  • P65: Nada
  • P64: Ventilador
  • P63: Nada (Etiquetado como Reset por el fabricante)
  • P51: Led rojo, o de indicación de batería baja
  • P52: Motor de rueda izquierda, funcionamiento hacia delante
  • P63: Motor de rueda izquierda, funcionamiento hacia atrás
  • VSS: Tierra
  • P60: Nada (aunque sospecho que es detector de depósito lleno del robot)
  • P61: Motor de rueda derecha, funcionamiento hacia delante
  • P62: Motor de rueda derecha, funcionamiento hacia atrás

Una vez identificados los elementos del chip, era hora de abrir el robot. Se puede apreciar el chip en la parte central de la placa:

IMG_20200824_103439438

Aunque en Paijmans indican que es posible puentear cada una de las patas del chip y conectarlas directamente al arduino (ya que éste tiene más fuerza en las señales que las que pasa el chip), en mi caso he optado por desoldarlo, y conectarle cables de prototipado. Aunque en un principio parecía una buena idea, al poner de nuevo las carcasas del robot, en mi caso saltaron un par de soldaduras de sus pistas, por lo que tuve que hacer trabajo extra de soldadura. Recomiendo soldar directamente al cable:

IMG_20200824_185905184

Una vez soldados los cables, el siguiente paso es el dispositivo Arduino. He optado por hacer uso de un Wemos D1 Mini Pro, de la familia de los ESP8266, ya que proporciona capacidades WiFi, y viene sin los bornes para los cables de prototipado, por lo que podía soldar directamente los cables para ahorrar espacio. Para la lógica del mismo me he basado en la creada por Conrad Vassallo (Converting a cheap Vacuum Robot into IoT) en su proyecto de domotización, ya que está preparado para integrar directamente en un sistema de domótica Home Assistant.

IMG_20200824_185913934_HDR

Algunos comentarios:

  • He tenido que hacer algunas modificaciones al trabajo de Conrad, ya que en el código que comparte faltaba la parte de conectar a la red WiFi el ESP8266. También he eliminado algunas librerías de las que no se hacía uso (EEPROM, Wire). Además he tenido que adaptar los valores de detección de batería baja (más en el siguiente punto) para que se amoldara a mi caso.
  • Conrad ha añadido al proyecto base una idea interesante: un detector de voltaje de la batería de 16v del robot. Usa para ello el pin A0 del ESP8266, que tiene capacidad para medir voltajes. Sin embargo, es necesario utilizar un conversor de voltaje para no quemar el disposito. Un simple divisor de voltaje con dos resistencias funcionará bien, y esta información estará disponible para Home Assistant.
  • Carga el código antes de soldar los pines provenientes de la placa. Una vez soldados, ya no es posible cargar código al Wemos a través del puerto microUSB, ya que el pin D4 mete ruido. En mi caso, tuve que desoldar. Para evitar este problema sería interesante añadir actualización OTA, pero me temo que eso quedará para una nueva versión.
pinout-wemos-mini-d1

Esquema de conexiones del D1 Mini Pro. Atención al uso del pin D4 para el envío de datos como puerto serie desde el Arduino IDE

Por último, queda la parte de Home Assistant. Con añadir el siguiente código a la configuración, el sistema estará preparado para interactuar con el robot:

vacuum:
- platform: mqtt
command_topic: "vacuum/command"
battery_level_topic: "vacuum/state"
battery_level_template: "{{ value_json.battery_level }}"
charging_topic: "vacuum/state"
charging_template: "{{ value_json.charging }}"
cleaning_topic: "vacuum/state"
cleaning_template: "{{ value_json.cleaning }}"
docked_topic: "vacuum/state"
docked_template: "{{ value_json.docked }}"
error_topic: "vacuum/state"
error_template: "{{ value_json.error }}"

El intercambio de información entre el robot y Home Assistant se realiza mediante MQTT. A continuación se puede ver una captura de los datos intercambiados:

mqtt-capture

¿Y el resultado? Espectacularmente bueno. Dejo un par de vídeos. El primero, con el robot aún abierto, y con una Victorinox haciendo de contrapeso, ya que si no, los sensores de vacío entran en funcionamiento:

…y el segundo, ya con las carcasas colocadas, y probando algunas funcionalidades adicionales, como la limpieza específica en un punto concreto:

Fuentes:

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , ,

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

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

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

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 Celsius

var 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

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

Información mostrada en Home Assistant de la estación meteorológica

Gráfica de la información histórica recibida

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. :mrgreen:

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

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. :D

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , , , , , ,