msgbartop
El mundo se divide en dos: los que tienen el revólver cargado y los que cavan. Coge la pala
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: , , , , , , , , , , , ,

05 nov 20 Configuración de un módem 3G/4G/HSDPA en Armbian mediante una SIM de Pepephone

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.

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

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: Permite que el sistema operativo reconozca el módem USB como tal, y no como un dispositivo de almacenamiento génerico por USB. El mismo se puede instalar en el caso de Debian en general, y Armbian en particular, desde los repositorios oficiales.
  • Wvdial: Utilidad para realizar la conexión a Internet mediante módem, que levanta una interfaz de red ppp (Diox, ni años que no creaba interfaces de red de este tipo). Tiene la ventaja de que se configura y ejecuta completamente desde línea de comandos, por lo que no es necesario entorno gráfico.

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

  • Asegurarse de tener instalada la tarjeta SIM. Sin ella, el dispositivo nunca se mostrará como un módem.
  • Comprobar que el dispositivo pasa a identificarse como un módem con el comando /usr/sbin/usb_modeswitch -W -v 05c6 -p 1000 -K. Si pasa a identificarse con algo similar a esto, Bus 003 Device 002: ID 05c6:6000 Qualcomm, Inc. Siemens SG75, vas por buen camino.
  • Alcanzado este punto, se puede automatizar este cambio mediante la creación de un fichero con nombre 05c6:1000 en el directorio /etc/usb_modeswitch.d. El fichero debe contener lo siguiente:

    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:

  • Instalar wvdial: wvdial se encuentra en los repositorios oficiales, por lo que se puede instalar con un simple apt install wvdial.
  • Tras instalarla, utilizaremos la aplicación wvdialconf, que tratará de reconocer y configurar de manera automática el módem USB. Si hemos seguido correctamente los pasos anteriores de USB_ModeSwitch, no tendríamos que tener problema alguno. Tras la finalización de la aplicación, ésta nos habrá generado el fichero de configuración /etc/wvdial.conf, con los parámetros genéricos de conexión del módem. La configuración que se genera por defecto para el HSDPA es la siguiente:

    [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

  • Es necesario adaptar estos parámetros a tu operador para poder establecer la conexión. En mi caso, estoy utilizando Pepephone. Tras algunas pruebas, di con una configuración que funciona correctamente:

    [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

  • Por último, una vez guardado el fichero, se puede lanzar la conexión tan sólo ejecutando el comando wvdial

…y con esto quedará levantada la conexión ppp0, como la siguiente:

ppp0: flags=4305 mtu 1500
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

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

Etiquetas: , , , , , , , , ,

31 jul 20 Acceso a través de OpenVPN a equipos de la red local del servidor VPN

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:

  • Configurar el servidor para que advierta al cliente de las rutas a las que puede acceder: Para que el cliente sepa que se puede conectar a más redes además de al propio servidor de VPN es preciso advertirle de ello. Se puede hacer fácilmente añadiendo la directiva “push” en el fichero de configuración del servidor. Para permitir acceso a una red de tipo 192.168.0.0/24, bastaría con lo siguiente: push “route 192.168.0.0 255.255.255.0″, y reiniciar el servicio.
  • Permitir que nuestro servidor haga forwarding de paquetes: Se habrá de modificar el fichero /etc/sysctl.conf, y quitar el comentario de la línea # net.ipv4.ip_forward=1. Posteriormente habrá que reiniciar el servicio con sudo sysctl -p.
  • Activar el enmascaramiento de paquetes en nuestro servidor: Este último paso va en función de nuestra arquitectura. Si nuestro servidor de OpenVPN no es la puerta de enlace por defecto de nuestra red, dado que las peticiones de los clientes OpenVPN llegarán al servidor de destino con una IP del tipo 10.8.0.x (o como sea que lo tengamos configurado en nuestro servidor OpenVPN), a la hora de responder a dichas peticiones, enviarán las respuestas a la puerta de enlace por defecto, con lo que se perderán las respuestas, ya que la puerta de enlace por defecto no tendrá constancia de la emisión de las mismas (enrutado asimétrico), y éstas no llegarán al cliente OpenVPN (este problema no se daría con el servidor OpenVPN actuando como puerta de enlace, ya que tendría constancia de los paquetes, y podría enrutarlos adecuadamente). Para evitar el problema, es posible activar el enmascaramiento de paquetes. Bastaría con añadir la siguiente regla a nuestro iptables: iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE… siempre que la interfaz de la red sea la eth0, y que nuestra red de clientes OpenVPN sea la 10.8.0.0/24 (si no, hay que modificar estos valores según correspondan). Para hacer que la configuración sea persistente, recomiendo usar el servicio iptables-persistent, existente en Debian y otras distribuciones.

Referencias:

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

27 nov 16 Receptor GPS GlobalSat BU-353-S4 en Debian

Hace un rato he recibido en casa un receptor GPS modelo GlobalSat BU-353-S4 que he comprado para un proyecto que tengo en mente.

GlobalSat-BU-353-S4

GlobalSat-BU-353-S4

Este receptor está soportado perfectamente en linux (algo clave para mi proyecto). De momento, he podido comprobar que funciona perfectamente con gpsd y cgps:

Captura de pantalla de cgps

Captura de pantalla de cgps

En apenas unos segundos ha localizado mi ubicación actual.

En cuanto al proyecto en sí, no adelantemos acontecimientos. Pero incluye una Raspberry Pi y un emisor OBD-II por bluetooth (sí, todo es mejor con Bluetooth). :mrgreen:

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

Etiquetas: , , ,