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
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
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
…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
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
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. 
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 = 9600Dial 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
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
15 oct 19 Solución hardware para los problemas de conectividad WiFi de la Orange Pi Zero+
Soy usuario habitual -quien lea esto habitualmente lo sabrá a estas alturas- de dispositivos de cómputo en formato single-board computer: para entendernos, Raspberry Pi, Orange Pi y dispositivos similares. Y es que, echando la cuenta, rondan por casa cinco cacharros de este tipo: dos RPi Modelo B (una haciendo de sistema de telemetría en el Mercedes irlandés), una Asus Tinker Board con el Home Assistant, una RPI 3 Modelo B+, y una Orange Pi Zero+, conectada a la impresora 3D. En concreto, tengo una cierta experiencia con las Orange Pi Zero, ya que han pasado por mis manos cuatro de ellas, tres modelos Zero (una en el centro de enseñanza de Ana, otra en casa de mis padres en Córdoba, y otra en casa de mi cuñado Fernando, todas ellas con Home Assistant como plataforma de domótica). El caso es que hace algún tiempo me hice con la evolución de este modelo, una Orange Pi Zero+, pero no había llegado a darle un uso intensivo hasta que la utilicé para controlar la impresora con Octoprint. Y como no le había dado un uso intensivo, no había notado un irritante problema que parece sufrir esta versión del dispositivo: un comportamiento algo errático de la tarjeta WiFi.
En mi caso, este comportamiento se manifiesta cuando se inicia el dispositivo sin estar conectado a ninguna red cableada, y el problema es que la mayoría de las veces la WiFi ni siquiera llegaba a iniciarse. Curiosamente sí funcionaba sin problemas cuando la red cableada también se encontraba conectada, o bien cuando iniciaba la misma con el puerto serie conectado para ver los mensajes de carga del sistema. En estos casos, casi sin excepción la WiFi arrancaba igualmente. Tras leer diversos foros de Armbian, y probar las más variapintas soluciones (versiones de kernel, versiones de sistema operativo, ramas de desarrollo, etc…) y no conseguir nada en claro, finalmente opté ayer por tirar por la calle de en medio: hacer uso de un terminador ethernet de tipo loopback, un viejo truco que usaba en tiempos pretéritos para engañar al sistema operativo de servidores y permitir configurar las interfaces de red sin tenerlas conectadas a redes reales.
Conector loopback RJ45
Tenía mis dudas al respecto, pero ha funcionado perfectamente. A raíz de usar este conector, e incluso sin ninguna configuración específica de la tarjeta de red cableada (simplemente aparece como activa, pero sin dirección IP), la WiFi ya se levanta perfectamente, tras múltiples encendidos, reinicios, apagados, tanto ordenado como desordenado. En fin: puede que no sea una solución muy elegante, pero lo que se puede asegurar es que funciona.
Por cierto, que mi conector loopback no es tan elegante como el de la imagen de arriba: es un simple conector cortado de un cable de red viejo, cortado y con los pines 1-3 y 2-6 empalmados. 
Etiquetas: armbian, loopback, orange pi zero
06 oct 19 Impresora 3D controlada de manera remota
Y seguimos a vueltas con la impresora 3D. En este caso, en el ámbito de la usabilidad. Mi impresora es una Creality Ender 3 Pro, que en su configuración de fábrica se utiliza mediante una tarjeta micro SD y un control en base a una botonera. Sin embargo, la impresora viene con una interfaz mini USB que permite el control remoto de la impresora. Tras un rato de investigar, he encontrado una aplicación llamada OctoPrint que facilita enormemente el control remoto de la impresora. En líneas generales, habilita una interfaz web que permite subir los ficheros .gcode y cargarlos en línea, sin tener que grabarlos previamente en la micro SD de la impresora.
Interfaz gráfica de OctoPrint
No sólo eso, sino que permite controlar todos los aspectos de la impresora, desde la ubicación del cabezal de impresión hasta la temperatura de la cama caliente y extrusor, además del progreso de la impresión. Incluso permite configurar una webcam (bien conectada localmente al servidor donde se encuentre OctoPrint o una cámara IP) para visualizar de manera remota cómo progresa la impresión.
Interfaz gráfica de OctoPrint
En mi caso, he utilizado para albergar OctoPrint un miniservidor Orange Pi Zero+ que había comprado hace algún tiempo (y cuya carcasa había creado con la impresora) con una Armbian recién descargada. Si bien por el momento la alimentación de ambos dispositivos es independiente (existe una manera de obtener la alimentación para la Orange Pi desde la impresora), en mi caso he optado -para optimizar el consumo energético del sistema- por utilizar por delante de la impresora un interruptor general Sonoff Basic con el firmware Tasmota instalado, a fin de poder controlar el sistema desde mi plataforma de domótica de casa, pudiendo encender todo el conjunto cuando vaya a imprimir, y tenerlo apagado cuando no se encuentre en uso. Y así cerramos el círculo: impresora 3D controlada por mi sistema de domótica.
Etiquetas: armbian, creality, ender 3 pro, impresora 3d, octoprint, orange pi zero plus, sonoff, tasmota
15 jun 17 Mitigación de los problemas de sobrecalentamiento de la Orange Pi Zero
En fechas recientes he adquirido un par de Orange Pi Zeros para algunos proyectos personales. Para quien no las conozca, las Orange Pi Zero son una interesante copia china de las Raspberry Pi, con un precio casi imbatible de 15$ contando el modelo de 512 MB de RAM y cuatro cores, junto con un módulo de expansión de puertos y una carcasa bastante maja.
Placa Orange Pi Zero
El problema es que montan un procesador ARM que funciona a 1200 MHz, que tiene una irritante tendencia a sobrecalentarse más que una plancha de acero a pleno sol en Córdoba un 15 de agosto. En Irlanda, con una temperatura ambiente que rara vez sube de los 22 grados ya es problemático, así que cuanto más en Córdoba, donde tengo una de las Zero:
83ºC… ¡y sin hacer nada, por la mañana, y a la sombra en interior!
Así que para no acabar con una bonita fogata quad-core, toca tomar medidas. La solución más básica es empezar por procedimientos mecánicos. Un disipador, vaya. El problema es que la Zero es pequeña, muy pequeña. El procesador central tiene este tamano:
OPi Zero y su tamaño relativo
En efecto, el procesador es del tamaño de una moneda de 1 céntimo de Euro. Genial para construir sistemas pequeños, no tanto si tienes que encontrar un disipador de su tamaño. Puedes encontrarlos en Amazon o en Aliexpress, pero tardan un tiempo en llegar. En mi caso, al final, acabé canibalizando un viejo router, de donde pude sacar un disipador adecuado. Eso sí, de añadir un ventilador, más vale irse olvidando. Ya sólo el disipador me dio guerra para encajarlo en la caja:
OPi Zero con disipador
De todas maneras, es una solución bastante razonable. En mi Orange Pi de Irlanda conseguí bajar la temperatura de unos 72ºC a unos 62ºC. El problema vino con la de Córdoba. A las 11 de la noche alcanzaba una temperatura de unos 85ºC. Vale que había unos 32ºC de temperatura ambiente (¡sí, a las 11 de la noche!), pero aun así, con disipador y todo, seguía resultando demasiado. Así que tocaba tomar medidas adicionales. En este caso, medidas software. Por suerte, el procesador que monta (SunXi H2+, una versión capada del H3) dispone de una utilidad para controlar diversos aspectos del procesador, como velocidad de proceso, número de cores activos, posibilidad de desactivar la tarjeta gráfica o la WiFi. En mi caso, y siguiendo las recomendaciones del enlace anterior, he optado por desactivar un par de cores, dejando sólo 2 activos, así como la GPU y la WiFi. La mejora ha sido considerable. En el caso del equipo de Córdoba, he conseguido moderar la temperatura (en plena mañana en Córdoba) desde más de 85ºC a menos de 75ºC. No es que sea la panacea, pero es una mejora notable.
Etiquetas: armbian, orange pi zero
Medidor de entropía
