msgbartop
I always thought something was fundamentally wrong with the universe
msgbarbottom

07 nov 20 Control de apertura de puertas y ventanas con Zigbee y sensores Aqara MCCGQ11LM

Seguimos con proyectos de IoT y domótica. En este caso, y para el piso de Forcarey, estoy preparando un sistema de control de apertura de puertas y ventanas con dispositivos Zigbee. Para ello, he escogido los sensores Aqara MCCGQ11LM. Son unos dispositivos fiables, razonablemente baratos, y -lo más importante- están perfectamente soportados en Zigbee2MQTT.

Sensor de puertas y ventanas Aqara MCCGQ11LM

Sensor de puertas y ventanas Aqara MCCGQ11LM

Y es que la gracia de todo este asunto es que no voy a hacer uso del gateway propietario de Aqara/Xiaomi. Desde hace ya algún tiempo tengo experiencia haciendo uso de Zigbee2MQTT como gateway de código abierto para algunos dispositivos Zigbee que tengo instalados en Santiponce, y la idea -como no podía ser menos- era hacer uso de la misma tecnología en Forcarey. Para ello estoy diseñando un pequeño dispositivo, basado en una placa Orange Pi Zero, que actúe como gateway de los dispositivos que voy a desplegar en el nuevo piso.

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

Sí, el dispositivo con conectividad HSDPA que comentábamos en el artículo anterior.

En lo referente a la instalación de Zigbee2MQTT, en líneas generales basta con seguir las instrucciones de instalación que proporciona la web oficial, con una salvedad: en la versión de Armbian que manejo (Buster 20.08.1 con versión de kernel 5.8.5) a la hora de compilar Zigbee2MQTT daba algunos errores con serialport y node-gyp, que están reportados. En mi caso ninguna de las soluciones propuestas funcionaba. Lo único con lo que conseguí hacerlo funcionar fue ignorando la parte de usar el repositorio de Node.js que se indica en las instrucciones en el apartado 2 de las mismas, e instalar tanto Node.js como específicamente node-gyp desde los repositorios oficiales de Debian. De esta manera todo el proceso de instalación concluyó correctamente.

Una vez concluida la instalación, creé el servicio para iniciar automáticamente Zigbee2MQTT al inicio del sistema, asocié los dispositivos, que fueron reconocidos sin mayor inconveniente, con lo que el proceso de configuración del hardware ha quedado concluido. En cuanto al software, el sistema de notificación de actividad de los sensores, en base a recepción de eventos de los dispositivos y su volcado a un servidor MQTT, está concluido. Los eventos se muestran de la siguiente manera:

Eventos registrados en servidor MQTT

Eventos registrados en servidor MQTT

…lo que nos permite, a partir de aquí, crear el sistema de notificaciones. ¿Cómo lo voy a hacer en mi caso? Con el estupendo software Home Assistant, que constituye la base de mi sistema de domótica. Pero eso ya quedará para otro artículo.

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

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

28 ago 20 Adaptación a IoT de un difusor de aceites esenciales TENSWALL con control remoto IR

Seguimos con las adaptaciones a IoT. Otra de las que he realizado recientemente es la integración en mi sistema de domótica basado en Home Assistant de un difusor de aceites esenciales controlado por infrarrojos. A principio de verano le regalamos uno de estos difusores a mis cuñados para su casa, pero como también nos gustó para la nuestra, nos decidimos a comprar uno. Elegimos un modelo en Amazon con iluminación y control remoto por infrarrojos, un Tenswall de 500 ml.

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Por lo que he podido averiguar, es un modelo bastante estandarizado vendido bajo multitud de marcas y fabricantes: se basa en el uso de frecuencias ultrasónicas para producir una vaporización del agua y los aceites esenciales a ella añadidos, generando una niebla que esparce las esencias, pero sin calentar el agua colocada en el depósito. Existen otros modelos más avanzados que integran capacidad WiFi y controlable desde una aplicación en el teléfono móvil, basado -por lo que recuerdo- en un ESP8266, pero el modelo que nosotros adquirimos tan sólo cuenta con capacidad IR. En realidad, una ventaja para lo que estaba buscando. El modelo que nosotros adquirimos tiene las siguientes funciones:

  • Encendido/apagado
  • Funcionamiento en modo intermitente (varios segundos generando niebla, varios segundos sin generarla)
  • Funcionamiento en modo continuo
  • Temporizador de funcionamiento a 60, 120 o 180 minutos, o bien en continuo
  • Funcionamiento con mucha niebla o poca niebla
  • Encendido de luces led, en modo carrusel, o 16 posiciones posibles
  • Apagado de las luces led

Para realizar la adaptación a IoT, lo primero fue capturar los códigos IR enviados por el mando a distancia. Para ello utilicé un receptor IR y una librería arduino que ya en su momento empleé para leer códigos del aire acondicionado. Capturé cada uno de los códigos asociados a los comportamientos indicados más arriba. Los adjunto por si a alguien más le sirvieran, en formato raw, y su equivalencia en protocolo NEC:

  • uint16_t rawDataOnOff[67] = {9040, 4466, 600, 532, 604, 530, 596, 538, 598, 536, 598, 534, 602, 532, 594, 538, 596, 536, 598, 1642, 598, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1644, 594, 1646, 594, 1646, 594, 538, 596, 536, 598, 560, 576, 558, 566, 568, 568, 564, 572, 562, 574, 560, 576, 1640, 602, 1640, 600, 1640, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600}; // NEC FF00FF
  • uint16_t rawDataIntermittent[67] = {9040, 4462, 592, 540, 594, 540, 596, 536, 598, 534, 602, 532, 592, 542, 594, 538, 598, 536, 600, 1640, 600, 1642, 600, 1642, 600, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1646, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 602, 532, 594, 540, 596, 538, 598, 536, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 598}; // NEC FF807F
  • uint16_t rawDataContinuous[67] = {9032, 4466, 600, 532, 602, 530, 594, 538, 596, 536, 600, 534, 602, 530, 594, 540, 596, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 600, 1642, 598, 534, 600, 1640, 600, 534, 592, 540, 594, 538, 598, 534, 600, 532, 592, 540, 596, 1644, 594, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1644, 598, 1642, 598}; // NEC FF40BF
  • uint16_t rawDataTiming[67] = {9032, 4464, 602, 530, 594, 538, 598, 536, 600, 532, 602, 530, 596, 538, 598, 534, 600, 532, 602, 1638, 604, 1636, 594, 1646, 594, 1646, 594, 1644, 598, 1642, 598, 1642, 598, 1642, 598, 534, 600, 532, 604, 530, 596, 1644, 598, 534, 600, 534, 602, 532, 594, 540, 596, 1644, 596, 1642, 598, 1642, 598, 534, 602, 1638, 602, 1638, 602, 1638, 604, 1636, 604}; // NEC FF10EF
  • uint16_t rawDataBigSmall[67] = {9034, 4466, 600, 532, 602, 530, 594, 538, 596, 538, 598, 534, 602, 532, 594, 566, 570, 564, 570, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 536, 600, 532, 602, 1638, 604, 530, 594, 538, 598, 536, 600, 534, 602, 532, 594, 1646, 594, 1646, 594, 540, 596, 1644, 596, 1644, 596, 1644, 598, 1644, 596}; // NEC FF906F
  • uint16_t rawDataLight[67] = {9040, 4462, 594, 538, 596, 536, 598, 536, 600, 532, 602, 532, 604, 530, 596, 538, 596, 538, 598, 1644, 596, 1644, 598, 1644, 596, 1644, 596, 1646, 594, 1646, 594, 1648, 602, 1640, 602, 530, 594, 1648, 602, 532, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 600, 1640, 600, 532, 592, 1648, 602, 530, 594, 1648, 592, 1648, 592, 1648, 592, 1650, 602}; // NEC FF50AF
  • uint16_t rawDataLightOff[3] = {9042, 2220, 596}; // NEC (Repeat) FFFFFFFFFFFFFFFF

Posteriormente pasé a crear un código arduino que se suscribe a un topic MQTT específico con el que se interactúa con el difusor. La idea es crear en Home Assistant un objeto que implemente las funciones del mando a distancia, y mapear los comandos enviados desde Home Assistant a los códigos IR anteriores. En Home Assistant, basta con crear un objeto de tipo luz, que implemente las funciones anteriormente descritas:


light:
- platform: mqtt
schema: json
name: Oil Diffuser & Light
state_topic: "<topic>"
command_topic: "<topic>/set"
brightness: true
rgb: false
effect: true
effect_list: [intermittent,continuous,timing,big/small,stopLight,lightOff]

…lo que genera una entidad con el siguiente aspecto:

Entidad generada en Home Assistant

Entidad generada en Home Assistant

Posteriormente, es necesario crear en Arduino un código que sea capaz de suscribirse al topic definido en Home Assistant, y reacciones a la información JSON enviada por éste. En realidad, todos los casos posibles son bastante sencillos. El caso que más complejidad tiene es el correspondiente a la luz, ya que el mismo botón/código sirve para encender la luz LED (que siempre empieza en carrusel de colores) y para rotar entre los 16 colores disponibles. En mi caso opté por mapear el deslizador de brillo definido (sin hacer uso de la paleta cromática) para escoger entre las 16 opciones de iluminación, más el modo continuo. En mi caso, opté por lo siguiente:

  • En el caso de recibir “1″ como valor de brillo (valor mínimo): Apagar la luz LED
  • En el caso de recibir “255″ como valor de brillo (valor máximo): Encender en el primer modo, correspondiente a la rotación de colores
  • Para el resto de valores: Calcular en cuál de los 16 tramos de luz se encuentra el deslizador (dividiendo el valor por 16), enviar el código de apagado (que consiste en simular una pulsación continua del botón de control de la luz durante 2 segundos), enviar el código de luz para entrar en el modo de rotación de colores, enviar de nuevo el código para detener la rotación de colores, y posteriormente tantas veces el código de luz como el tramo en el que nos hallemos (ya que este es el funcionamiento del dispositivo).

Por último, es necesario cargar el código en un ESP8266, equipado con un emisor IR. Dado que el difusor de aceites que yo escogí dispone de abundante espacio, es bastante sencillo colocarlo. En mi caso, el difusor se alimenta con un transformador de 24v en continua, que no se puede utilizar directamente para alimentar al ESP8266. En mi caso, opté por utilizar un buck converter DC-DC de 24v a 3.3v, con lo que queda solventado el problema de la diferencia de voltaje. ¡Y listo! Con todo esto es posible controlar un difusor de aceites simple desde la domótica de la casa.

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

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: , , , , , , , , , , , , ,