msgbartop
¡¡Corred insensatos!!
msgbarbottom

05 may 20 Nuevas pruebas de enlaces LoRa

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.

Vista en Google Earth de la prueba del 3 de mayo

Vista en Google Earth de la prueba del 3 de mayo

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.

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

Etiquetas: , , , ,

02 may 20 Comunicación de larga distancia de dispositivos IoT: Heltec LoRa 32

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:

  • Capacidad de trabajo en modo unidireccional, bidireccional o multidifusión
  • Alta tolerancia a las interferencias
  • Alta sensibilidad para recibir datos (-168dB)
  • Basado en modulación “chirp“
  • Bajo Consumo (hasta 10 años con una batería)
  • Largo alcance 10 a 20km
  • Baja transferencia de datos (hasta 255 bytes)
  • Conexión punto a punto
  • Frecuencias de trabajo: 868 Mhz en Europa, 915 Mhz en América, y 433 Mhz en Asia

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.

Pareja de Heltec LoRa 32 con carcasa impresa en 3D

Pareja de Heltec LoRa 32 con carcasa impresa en 3D

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:

  • La ubicación de la antena importa. Mucho. Es extraordinariamente importante que las antenas, tanto de emisor como receptor, estén verticales. Solamente este factor es de una importancia enorme para lograr una buena transmisión de la señal entre dispositivos. Pero no es el único. La frecuencia de 433 MHz no se lleva especialmente bien con paredes de hormigón forjado, ni con mallazo metálico. Si puedes poner la antena en espacio abierto, mejor que mejor.
  • Haz uso de una buena antena. Las que vienen con los dispositivos son extremadamente básicas. Hacen bien su función a distancias relativamente cortas, pero cuando intentas subir de nivel, la cosa cambia. Tanto es así, que el fabricante de los dispositivos da un rango de alcance de sus dispositivos de 2.8 km, frente a las decenas que soporta el protocolo. Sigue estando bastante bien para unos dispositivos que no llegan a los 20€ de precio, pero cuando intentas ir un poco más allá, es preciso invertir un poco más.
  • La cantidad de información que transmites importa. Tanto o más que todo lo anterior. A mayor mensaje que trates de enviar, más problemas tendrás para que llegue, debido a posibles interferencias durante el tiempo que estés transmitiendo. Además de esto, pude observar que el RSSI (indicador de fuerza de la señal recibida) se resentía a mayor longitud del mensaje. Así que nada de enviar elegantes datagramas JSON, o largos paquetes de datos. Empaqueta en hexadecimal, transmite los mínimos bytes posibles, y notarás una gran mejora en el rango de alcance de tus sistemas.
  • Optimiza los parámetros de los enlaces en función de lo que busques. Existe la posibilidad de ajustar diversos parámetros de la transmisión. Simplificando mucho, la velocidad de transmisión y el factor de propagación (spreading factor). A una velocidad de transmisión más baja y mayor factor de propagación, más confiable será la entrega del paquete (realizando un símil algo burdo, es como hablar muy despacio y alargando mucho los sonidos), pero necesitarás más tiempo para enviar la misma cantidad de información, por lo que perjudicarás la vida de la batería, y harás más uso de tiempo de señal (lo que en redes LoRa públicas o privadas puede tener su impacto). En mi caso, como se trata de un enlace punto a punto entre dos dispositivos que controlo yo, no tengo que preocuparme demasiado por estos aspectos. Otro parámetro ajustable es la intensidad de la señal emitida (sólo para el emisor), que se puede ajustar hasta 20 dBm, sobre un valor estándar de 14 dBm. De nuevo, a costa de penalizar la duración de la batería.

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:

  • Preparar un emisor LoRa que pudiera colocar en la bici. Me aburrí bastante pronto de enviar simples secuencias numéricas desde el emisor al receptor. Y dado que los Heltec LoRa son ESP32, con capacidad BLE, desarrollé un aplicativo que permite leer de mi pulsómetro Bluetooth mi ritmo cardíaco, y cada 2 segundos enviarlo empaquetado en hexadecimal, con lo que se puede enviar haciendo uso de tan sólo 2 bytes de información. Para colocarlo cómodamente en la bicicleta, imprimí una carcasa con la impresora 3D que se puede atornillar al manillar. Complementé el emisor con una antena de 7 dBi para 433 MHz, que instalé en el transportín de la bici.
  • Bicicleta con antena y Heltec instalados

    Bicicleta con antena y Heltec instalados

  • Crear un gateway LoRa-MQTT como receptor. La otra mitad del sistema, el receptor, actúa como una pasarela LoRa-MQTT. Se conecta a la red WiFi de mi casa, y vuelca la información recibida por LoRa en mi servidor MQTT, en un topic específico. Además de la información LoRa (decodificada para ofrecer el ritmo cardíaco de nuevo en decimal), añade el RSSI del paquete recibido, para poder verificar de manera sencilla la calidad de la recepción de la señal. De acuerdo a la documentación de LoRa, cualquier cosa peor de -120 dBm implica recibir una señal débil, y por encima de -30 dBm es excelente (el máximo teórico es 0). En mis pruebas, observaba problemas para recibir paquetes cuando el RSSI caía por debajo de -125 dBm.
  • Colocar la antena del receptor en una buena ubicación. Como decíamos antes, la antena y su ubicación importan, también en el receptor. Mi casa se encuentra en el valle del Guadalquivir, en una zona que no es especialmente alta. Lo ideal sería colocarla en lo más alto del tejado, donde hay pocos elementos que bloqueen la vista, y por tanto puedas tener visión directa de los alrededores. Pero no andaba estos días con muchas ganas de andar triscando por los tejados, y de todas maneras tengo un inconveniente en forma de colinas. La colina de Itálica por un lado, que me bloquea gran parte de los campos cercanos por el oeste, y el cerro de Santiponce, al suroeste que hace lo mismo en esa dirección. Así que me he limitado a colocar la antena en la azotea, con vistas razonablemente limpias hacia el norte, este y sureste. No del todo limpias, porque el edificio de pisos que hay junto al teatro de Itálica bloquea gran parte de la visión directa de la ciudad de Sevilla (en otro artículo hablaremos de ello). Pero para pruebas de campo en los alrededores, más que suficiente.
  • Antena del gateway

    Antena del gateway

  • Disponer de un cliente MQTT para verificar la información recibida. Esta parte era sencilla. Un teléfono Android con un cliente MQTT convencional vale perfectamente. Junto con un soporte de móvil para bicicleta, basta para tener toda la información delante de tus ojos.
  • Heltec LoRa 32 con carcasa impresa en 3D

    Heltec LoRa 32 con carcasa impresa en 3D

  • Salir y empezar a rodar. Ironías de la vida, lo más complicado de todo, durante estas jornadas. Ha sido preciso esperar al 2 de mayo para poder hacer la prueba.
Bicicleta utilizada durante las pruebas

Bicicleta utilizada durante las pruebas

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.

Enlace logrado hacia el norte

Enlace logrado hacia el norte

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.

Enlace logrado hacia el sureste

Enlace logrado hacia el sureste

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.

Mapa general de las pruebas

Mapa general de las pruebas

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

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

Etiquetas: , , , ,

03 feb 20 Dash button doméstico con ESP-01

Uno de los proyectos de mejora que tenía para la domótica de la casa era el añadirle un dash button para controlar alguno de los sistemas. ¿Y qué es un dash button? En pocas palabras, es un pequeño pulsador que permite comprar de manera completamente automatizada un producto en concreto a Amazon, con la idea de facilitar la compra sencilla de bienes consumibles.

Ejemplo de dash button

Ejemplo de dash button

El caso es que aunque el producto fue exitoso, tuvo que enfrentarse a una serie de problemas legales, y Amazon acabó retirándolos de la venta. Pero el concepto detrás de ellos seguía siendo interesante. No tardé en encontrar un proyecto en Thingiverse sobre cómo implementar un dash button software libre, y no tardé demasiado tiempo en preparar mi propia versión, con algunas modificaciones sobre el diseño original.

Dash button doméstico

Dash button doméstico

En mi caso, en vez de hacer uso de un ESP8266, opté por usar un ESP-01, más compacto, y un botón rojo externo en vez de un pulsador interno. Por lo demás, el diseño es el mismo. En lo referente a la lógica del sistema, se basa en el modo deep sleep de los ESP. En este caso, el sistema queda durmiendo de manera permanente hasta que el botón es pulsado, lo que despierta al sistema, ya que el botón puentea el puerto RST del ESP-01 con el GND. Combinado con el uso de la batería CR2 de 3V, en teoría hay alimentación para varios años. ¿Y en cuanto a la acción en sí? Sencillo: el sistema despierta, conecta a mi WiFi doméstica, y actualiza un topic MQTT. Después de eso, vuelve a dormir hasta una nueva pulsación.

Parece poca cosa, pero con esa actualización del topic MQTT se puede programar cualquier acción que deseemos en el sistema de domótica. Eso ya queda para una segunda fase. :mrgreen:

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

Etiquetas: , , , , ,

02 feb 20 Integración de Aqara Cube en el sistema de domótica

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.

Aqara Cube

Aqara Cube

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.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes 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: , , , , , , , , , , , , ,