openHAB

openHAB Cloud Connector

openHAB Cloud Connector

Cuando deja de funcionar, no siempre es porque se hayan caído los servidores de myopenhab.org… A veces me he encontrado con el servicio desconfigurado. Si ya lo hemos probado todo, el siguiente procedimiento suele funcionar.

  • Desinstalar openhab cloud connector desde la interfaz de usuario de openHAB. Está en la sección User Interfaces.
  • Detener el servicio:
    sudo systemctl stop openhab2
  • Borrar la caché:
    sudo openhab-cli clean-cache
  • Reiniciar el servicio:
    sudo systemctl start openhab2
  • Reinstalar el addon. Normalmente, el UUID y el secret se mantienen los mismos, pero si cambiaran, los nuevos se encuentran en las siguientes ubicaciones:
    cat /var/lib/openhab2/uuid
    cat /var/lib/openhab2/openhabcloud/secret
Publicado por David en Domótica, 0 comentarios
Entrándole a Zigbee por la puerta de atrás (…ejem, MQTT)

Entrándole a Zigbee por la puerta de atrás (…ejem, MQTT)

¿Por qué?

Hasta la fecha de empezar a escribir estas notas, los dispositivos inalámbricos que componían mi sistema doméstico eran de dos tipos: Wifi, con protocolo MQTT y Z-Wave. Como en algún momento dejaré documentado, los dispositivos Wifi tenían la ventaja de ser muy económicos, y el inconveniente de que todos funcionaban con una aplicación propietaria, por lo que si queríamos conectarlos con un protocolo abierto resultaba necesario un pequeño hackeo. Por su parte, los dispositivos Z-Wave tenían la ventaja de funcionar «out of the box» pero el grave problema de ser más caros que el jamón. Respecto a Zigbee, lo cierto es que ha estado siendo durante todos estos años el niño perdido de la domótica. Diseñado como un protocolo con bajos requerimientos de hardware y, por ende, de elección para la fabricación de dispositivos potencialmente baratos, había sido tan pobremente adoptado que los pocos dispositivos que había eran raros y con precios no precisamente competitivos… En fin!

Sin embargo, ahora las cosas están cambiando. Raros engendros como Alexa o Google Assistant están consiguiendo que la domótica, relanzada ahora con el nombre de «hogar digital», este pasando de ser una chaladura de cuatro frikis asociada a pelis japos futuristas a convertirse casi, casi en un deporte nacional. Como consecuencia, estoy empezando a ver aparecer dispositivos Zigbee de diversas marcas más o menos reconocidas y a precios similares a los productos Wifi chinos. Por cierto, que entre ellos está una línea de productos de Ikea. Así que decidí que era momento de dedicarles un poco de atención y empezar a aprovechar el tirón.

¿Por dónde?

Lo primero para empezar a funcionar con Zigbee será adquirir y configurar un coordinador universal. Por supuesto, cada marca ofrece su propio coordinador con su app, pero por mal camino iríamos si para aprovechar un protocolo estándar nos liáramos con hardware particular de cada fabricante. Estos coordinadores universales suelen venir con la forma de un dongle USB, y lo que nos interesa es que pueda ser manejado por nuestro controlador domótico. A día de hoy, Openhab dispone de un Addon para Zigbee, pero desgraciadamente se encuentra todavía un poco en pañales y no son muchos los coordinadores con los que puede funcionar sin problemas. En concreto, le había echado el ojo a un coordinador universal que acaba de sacar Sonoff con bastante buena pinta y a un precio bastante interesante, pero que el Addon de Openhab aún no puede reconocer. Existen coordinadores más caros, más antiguos y menos disponibles que sí son compatibles pero, la verdad, no me parece una buena idea tener que morir a este palo.

Afortunadamente ya hace tiempo que existe una solución, bastante más madura, que tiene pinta de provisional pero que bien pudiera quedarse de manera definitiva en función de como evolucionen las cosas. Y se llama Zigbee2MQTT

Como su nombre indica, se trata de un puente entre ambos protocolos. En la práctica consiste en un software independiente que se ejecuta al margen de Openhab, de manera similar al broker MQTT. Zigbe2MQTT puede manejar un buen puñado de coordinadores, entre ellos el que acabo de mencionar de Sonoff, así que decidí probarlo y darle tiempo al equipo que está trabajando en el Addon para ver qué pasa. Y a la vez ir probando el puente y comprobar su versatilidad.

El funcionamiento es bastante sencillo. Por un lado, Zigbe2MQTT se conecta al coordinador para gestionar la red Zigbee, comunicándose directamente con un montón de dispositivos compatibles. Y, por otro, se enlaza al broker MQTT que uno tenga previamente instalado en su controlador domótico permitiendo así la monitorización y control de todos los dispositivos Zigbee mediante mensajes MQTT enviados y recibidos por el broker. Así, para manejar estos dispositivos desde Openhab lo único que tenemos que hacer es añadirlos como cosas genéricas MQTT. Parece sencillo, ¿no?

¿Cómo?

La instalación de Zigbee2MQTT viene bastante bien explicada en su página web. Dejo aquí unas notas de las vueltas que tuve que dar para hacer funcionar el tema.

1.- El software se descarga de Github y se compila en la propia máquina. Una vez hecho, lo instalamos como un servicio. Hasta aquí, ningún misterio.

2.- Si seguimos el proceso de instalación sugerido, el archivo de configuración se guarda en

nano /opt/zigbee2mqtt/data/configuration.yaml

3.- En este fichero conviene hacer algunos cambios. Unos claramente sugeridos en las intrucciones, otros no tanto. Por ejemplo, para manejar el software desde la interfaz web incluida en el paquete es preciso añadir las siguientes líneas al fichero de configuración:

frontend:
   port: 8081

Ojo, que el puerto por defecto es el 8080 que coincide con el de Openhab. De ahí que haya decidido cambiarlo al 8081.

También conviene modificar, por seguridad, el parámetro que permite que cualquier dispositivo Zigbee detectado pueda conectarse sin más (y habilitar esta característica a mano desde la interfaz cada vez que la necesitemos)

permit_join: false

El resto de cambios, como la especificación del puerto serie o la generación de una clave de red personalizada son claramente explicados en las indicaciones. Respecto del puerto serie, dos indicaciones:

  • Si bien podemos especificar directamente el dispositivo creado al enchufar el dongle, no es una buena idea hacerlo así, porque nada garantiza que este puerto no pueda cambiar en un futuro. Es preferible crear un enlace simbólico basado en el ID del dispositivo.
  • También tener en cuenta que el usuario que ejecuta el programa deberá pertenecer al grupo dialout o el programa no podrá acceder al puerto.

Ambas indicaciones vienen explicadas aquí.

¿Con qué?

Ya he mencionado qué coordinador elegí para comenzar mis pruebas. Ahora presentaré el primer dispositivo Zigbee en incorporarse a mis filas: Una bombilla regulable de la marca Osram que encontré en Amazon por menos de 10€

Como hemos indicado, una vez instalado el software la interfaz Web nos permite añadir dispositivos y controlarlos directamente desde la propia interfaz. Ahora bien, si queremos controlar los dispositivos a través del broker MQTT necesitamos conocer la estructura de los mensajes, lo que puede variar un poco de un dispositivo a otro. Para ello, nada como la aplicación MQTT Explorer, directamente disponible desde los repositorios de SNAP,

Operando sobre el dispositivo y fisgando con el explorer podemos ver los mensajes que alcanzan al broker. El «topic» para todos ellos es de la forma zigbee2mqtt/nombre-dispositivo/ y el «payload» del mensaje es una cadena de tipo JSON con los valores de las variables relevantes. Concretamente, para mi bombilla:

{»brightness»:124,»linkquality»:90,»state»:»ON»,»update»:{«state»:»available»}}

El prefijo del «topic» es por defecto zigbee2mqtt, pero puede ser modificado en el archivo de configuración. Y el nombre del dispositivo también puede ser personalizado desde la interfaz web una vez nos conectamos a él.

Sin embargo, si desde el explorer enviamos a dicho «topic» una cadena con la misma estructura y los valores que nosotros queremos, resulta que no pasa nada!!!

Tras mucho darle vueltas y ponerme a trazar diagramas encuentro lo evidente. La pista me la dio la variable «linkquality». Obviamente, esta variable se genera tras la recepción del mensaje, ya que no tiene ningún sentido establecer la calidad del enlace antes de que éste tenga lugar, más que nada porque aún no se conoce. Como estamos operando el dispositivo directamente a través de la red Zigbee, estos mensajes que puedo leer en el explorador son solamente aquellos que van de Zigbee2MQTT hacia el broker MQTT. Es decir, son  mensajes que informan del estado del dispositivo después de que éste haya cambiado su estado. Así que, si queremos modificar el estado del dispositivo enviando mensajes al broker desde otro programa, tal como el MQTT Explorer u Openhab, ¿cómo lo hacemos? Rebuscando un poco por ahí, ya no recuerdo dónde, di con la solución, bastante simple pero un poco puñetera si, como yo, no sabemos bien lo que estamos estamos buscando:

Los mensajes que queremos que alcancen el dispositivo han de ir dirigidos a este topic: zigbee2mqtt/nombre-dispositivo/set, y la carga útil del mensaje es, simplemente, la variable que queremos modificar en formato JSON. Por ejemplo:

zigbee2mqtt/nombre-dispositivo/set {«brightness»:124}

o bien:

zigbee2mqtt/nombre-dispositivo/set {«state»:»ON»}

Y… voilà!

 

Publicado por David en Domótica, 0 comentarios
A vueltas con openHAB

A vueltas con openHAB

Actualizando Openhab

Si hemos instalado Openhab siguiendo las recomendaciones, lo más probable es que hayamos elegido Zulu como la plataforma de Java. Sin embargo, Openhab no es compatible con versiones de Java mayores que 11 y si instalamos Zulu a partir de los repositorios, cada vez que haya una actualización inevitablemente se configurará la más reciente como versión por defecto. Por eso es necesario, antes de reiniciar Openhab, seleccionar la versión correcta de Java:

~$ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                          Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/zulu15/bin/java   2153801   auto mode
* 1            /usr/lib/jvm/zulu11/bin/java   2115401   manual mode
  2            /usr/lib/jvm/zulu15/bin/java   2153801   manual mode

Press <enter> to keep the current choice[*], or type selection number:
1 

Consola Karaf

OpenHab proporciona una consola desde la que poder monitorizar y gestionar algunos aspectos del sistema. Podemos conectarnos de dos maneras:
Si estamos estamos conectados con una sesión remota de shell:

openhab-cli console

Mediante ssh, solamente si estamos conectados localmente

ssh -p 8101 openhab@localhost

Por cierto, que las credenciales por defecto son:
usuario: openhab, contraseña: habopen

Archivos de log

El archivo principal de log se encuentra en la siguiente ubicación

 tail -f /var/log/openhab/openhab.log

Ahora bien, para definir qué es lo que queremos que quede registrado, la manera más sencilla es abrir una consola y ajustar el nivel de registro de depuración deseado:

log:set <nivel> <paquete>

Los niveles de depuración están definidos por constantes de este pelo: OFF, ERROR, WARN, INFO, DEBUG, TRACE, DEFAULT

Respecto a los nombres de los paquetes, podemos obtener un listado de la siguiente manera:

list -s

 

Publicado por David en Domótica, Linux, 0 comentarios