Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.
Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.
Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.
Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:
Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.
Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.
Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.
¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:
…y en el caso de Forcarey:
No está mal, ¿no?
Etiquetas: aldi, aqara, aqara cube, arduino, asus tinker board, debian, domótica, home assistant, ikea, lidl, mqtt, nodemcu, orange pi zero, proxmox, raspberry pi, zigbee, zigbee2mqtt
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.
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.
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:
…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.
Etiquetas: aqara, armbian, debian, domótica, forcarey, home assistant, iot, MCCGQ11LM, mqtt, node.js, orange pi zero, zigbee, zigbee2mqtt
Estoy trabajando en un proyecto IoT que implica el que un dispositivo ARM (en mi caso, una Orange Pi Zero) sea capaz de tener conectividad a Internet en un entorno aislado, sin WiFi o conexión cableada. Para ello, la mejor manera que he encontrado es dotar al mismo de una conexión 3G/4G mediante una tarjeta SIM de un operador de telefonía. En mi caso, Pepephone. A diferencia de otros dispositivos que disponen de un lector de tarjetas SIM, la Orange Pi Zero no dispone del mismo, para lo cual es preciso hacer uso de un módem USB. He utilizado un modelo genérico, un HSDPA 3G que se puede encontrar por unos pocos euros en Aliexpress. Estos dispositivos vienen de casa con los drivers necesarios para hacerlos funcionar en diversas versiones de Windows, pero no cuentan con soporte oficial para Linux. Sin embargo, no es complicado hacerlos funcionar. A continuación detallo los pasos para ello.
En primer lugar, estoy haciendo uso de una Orange Pi Zero con sistema operativo Armbian. En el momento en que escribo esto la versión publicada, y que estoy utilizando, es la 20.08.1, versión de kernel 5.8.5. Sobre esta versión del sistema operativo, para hacer funcionar el módem USB, hay que instalar dos aplicaciones:
USB_ModeSwitch
La configuración de USB_ModeSwitch no tiene misterio. Dado que la aplicación está recogida en los repositorios oficiales de Debian, basta con instalar los dos paquetes correspondientes (usb-modeswitch y usb-modeswitch-data) utilizando apt. En función del dispositivo del que hagas uso, con esto debería bastar para que tu módem USB sea reconocido, pero a veces las cosas se complican un poco. Como en mi caso. El dispositivo que yo uso se identifica a sí mismo inicialmente como un dispositivo de almacenamiento masivo. Al hacer un lsusb aparece identificado de la siguiente manera: Bus 003 Device 011: ID 05c6:1000 Qualcomm, Inc. Mass Storage Device. Es necesario trastear un poco para que se muestre en el sistema como un módem USB. Para ello:
TargetVendor=0x05c6
TargetProduct=0x6000
StandardEject=1
Con esta configuración, Armbian pasará a configurar de manera correcta el módem, y estará listo para ser utilizado por la aplicación de marcado.
Wvdial
Ya con el módem USB correctamente reconocido por el sistema, es necesario configurar una aplicación de marcado, que permita levantar una interfaz de red en el sistema. En mi caso, he optado por utilizar wvdial. Los pasos para configurarla son los siguientes:
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
Phone =
ISDN = 0
Password = "password"
New PPPD = yes
Username = "username"
Modem = /dev/ttyUSB0
Baud = 9600
[Dialer Defaults]
Init1 = ATE1
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
Phone = *99#
ISDN = 0
Password = "pepephone"
New PPPD = yes
Username = "pepephone"
Modem = /dev/ttyUSB0
Baud = 9600
Dial Command = ATDT
Stupid Mode = 1
Auto Reconnect = on
Init3 = AT+CFUN=1
Init4 = AT+CGATT=1
Init5 = AT+CGDCONT=1,"IP","internet","",0,0
…y con esto quedará levantada la conexión ppp0, como la siguiente:
ppp0: flags=4305
inet 10.118.75.xx netmask 255.255.255.255 destination 10.64.64.xx
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 125 bytes 9030 (8.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 122 bytes 9001 (8.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Como punto de configuración adicional, es conveniente automatizar la creación de la interfaz. Aunque idealmente podría hacerse con la siguiente configuración en /etc/network/interfaces:
auto ppp0
iface ppp0 inet wvdial
…pero he observado que no funciona demasiado bien tras un reinicio. Sospecho que es porque se intenta configurar la interfaz ppp0 cuando USB_ModeSwitch aún no ha completado la transición de dispositivo de almacenamiento masivo a módem USB. En mi caso, y para no complicarme, he optado por prescindir de la configuración anterior, y en su lugar he añadido el comando wvdial al fichero /etc/rc.local, resolviendo de esta manera el problema. No es tan elegante, pero funciona.
Editado
Un pequeño complemento: dado que por sí sola no se añade la ruta por defecto para que el tráfico de red salga por el módem USB, se puede añadir de manera automática mediante un script. Basta con crear un script ejecutable bajo la ruta /etc/ppp/ip-up.d/ con un contenido como este:
#!/bin/sh
ip route add default dev ppp0
exit 0
Etiquetas: 3g, armbian, debian, hsdpa, linux, módem, orange pi zero, pepephone, usb_modeswitch, wvdial
La configuración por defecto de OpenVPN permite acceder sólo al equipo servidor de VPN cuando estableces la conexión desde el cliente. Sin embargo, es posible extender el acceso al resto de equipos de la red local de dicho servidor, en caso de necesitar acceso a otras máquinas. La receta es la siguiente:
Referencias:
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