Uno de los puntos fuertes de la Steam Deck es la reparabilidad y posibilidad de sustituir algunas de sus piezas sujetas a desgaste. El almacenamiento interno es una de ellas y en mi caso lo he sustituido por uno de mayor tamaño. Incluyo aquí enlaces a los tutoriales de iFixit donde se detalla el proceso y alguna de las tareas posteriores que he realizado.

Contenido

La Steam Deck puede venir con un almacenamiento interno eMMC de 64 GB, un disco M.2 2230 de 256 Gb o un disco M.2 2230 de 512 GB. En mi caso tengo la versión de 256 Gb, pero alguno de los juegos que utilizo con relativa frecuencia, consume ya casi 150 Gb y otro por encima de los 100, lo que me obligaba a veces a desinstalar e instalar periódicamente.

La solución más directa y recomendada por Valve es incorporar una tarjeta microSD, pero quería comprobar si realmente era sencillo sustituir el almacenamiento interno por uno de mayor tamaño. Además, ¿desde cuándo he buscado la solución sencilla pudiendo complicarlo, aprender por el camino y romper algo?

En este video Valve no recomienda abrir la consola si no es necesario y que en caso de ser necesario lo haga un profesional. Además indica los posibles problemas que puede plantear utilizar otro dispositivo de almacenamiento diferente del incluido de serie:

• Posibles interferencias con la comunicación inalámbrica (WiFi y Bluetooth) ya que los dispositivos de comunicación están cerca de la unidad de almacenamiento.
• Interferencia mecánica con otros componentes de la placa por vibraciones del dispositivo o por presión debido a un diferente tamaño físico que el original.
• Mayor consumo de energía del dispositivo adicional y por lo tanto reducción de la vida de la batería.

A pesar de ello en ese video indica cómo hacer el proceso de desmontaje de un joystick y del almacenamiento interno, si bien de forma muy breve.

En mi caso compré un Corsair MP600 Mini de 1 Tb directamente en la tienda de Corsair.

No voy a detallar los pasos de la sustitución propiamente dichos. En iFixit están descritos paso por paso tanto en video como en tutorial web con fotos y descripción de los pasos en español (formato que me encanta y que está en vías de extinción en pro del vídeo).

El primer paso es habilitar el modo de almacenamiento de la batería para evitar que una pulsación accidental del botón de encendido pueda activar la consola mientras la tenemos abierta y pueda producirse un cortocircuito.

El siguiente paso es el desmontaje propiamente dicho de la máquina y la extracción del almacenamiento M.2.

El método más sencillo para configurar el nuevo almacenamiento es descargar la imagen de recuparación e instalar el sistema desde cero. En mi caso quería conservar si era posible toda la información que tenía y por ello quería hacer una copia exacta de todo el contenido del almacenamiento actual en el nuevo. Opté por utilizar carcasa externa USB para almacenamiento M2/NVMe que ya tenía y en la que inserté el almacenamiento de 256 Gb (Kingston).

La conecté a mi ordenador y verifiqué con lsblk qué dispositivo se le había asignado (/dev/sdb en mi caso).

Visto esto, hice un volcado completo del disco a un archivo con:

sudo dd if=/dev/sdb of=$HOME/iso/steamdeck.iso oflag=sync bs=128M status=progress

Otra opción es hacer este mismo procedimiento desde el modo escritorio de la Steam Deck antes de extraer el almacenamiento incluido de serie, concectando un pendrive o disco duro externo a través de un hub USB o un dock.

Una vez terminado, desconecté la carcasa externa, saqué el disco de de 256 Gb de la carcasa y en su lugar inserté el disco de 1 Tb.

Tras conectar la carcasa al ordenador verifiqué el nombre de dispositivo asignado al almacenamiento USB con el comando lsblk, que fue /dev/sdb.

A continuación restauramos el archivo de imagen en el nuevo disco con:

sudo dd of=/dev/sdb if=$HOME/iso/steamdeck.iso oflag=sync bs=128M status=progress

Una vez terminado el proceso, tendremos el disco de 1 Tb con la misma información que el de 256 Gb, pero con el mismo tamaño de particiones que el antiguo, por lo que no estaremos aprovechando el espacio extra de la unidad..

En mi caso recurrí a gparted para expandir sin pérdida de datos la partición /home hasta el máximo de tamaño ofrecido por el almacenamiento. Con ésto, el disco queda preparado para instalarlo en la Steam Deck.

La instalación se hace siguiendo los mismos pasos del tutorial de desmontaje y extracción del almacenamiento M.2. Si el desmontaje se hizo con cuidado, se puede aprovechar la envoltura que aisla de interferencias para la nueva unidad.

Una vez montado, para arrancar la Steam Deck y salir del modo de almacenamiento de la batería, hay que conectarla a un cargador y pulsar el botón de arranque.

En mi caso la Steam Deck arrancó perfectamente y reconoció la cantidad de almacenamiento disponible, pero al intentar arrancar los juegos, no llegaban a funcionar y volvían a la pantalla de inicio del juego, sin mostrar ningún error aparente.

Aunque no he llegado a consultar los logs para confirmar cual era el problema, sospeché del sistema de verificación que tiene Steam, por lo que el primer paso fue verificar los archivos instalados de un juego de pequeño tamaño.

Para ello, pulsamos en el icono de configuración (rueda dentada):

En el menú que se despliega elegimos Propiedades.

Seleccionamos en el menú de la izquierda la opción Archivos Instalados y en la sección Comprobar si los archivos de este juego están instalados correctamente pulsamos el botón Verificar integridad de los archivos del juego:

Se iniciará el procedimiento de verificación. El motivo de elegir un juego de pequeño tamaño es verificar si éste era el problema en el menor tiempo posible.

Se informa de que no se han podido validar una serie de archivos y que por lo tanto se volverán a descargar

Una vez finalizada la descarga, el juego funciona correctamente.

Esto mismo lo aplico a otros juegos y en todos los casos acaban funcionando correctamente tras este proceso.

La sustitución del almacenamiento interno de la Steam Deck es un proceso sencillo, aunque no exento de riesgos y que puede traer efectos negativos como la reducción de la duración de la batería.

Cualquier daño realizado durante la sustitución puede implicar la pérdida de la garantía, por lo que lo más sencillo es incluir una tarjeta microSD de gran tamaño.

No he hecho pruebas serias, pero en experiencia de uso no he notado de momento pérdida de autonomía ni ningún otro tipo de problema.

• Web oficial de Steam Deck https://www.steamdeck.com
• Vídeo de Steam sobre desmontaje de Steam Deck https://www.youtube.com/watch?v=Dxnr2FAADAs
• Tutorial de iFixit sobre habilitar modo de almacenamiento de batería https://es.ifixit.com/Gu%C3%ADa/C%C3%B3mo+habilitar+el+modo+de+almacenamiento+de+bater%C3%ADa/149962
• Tutorial de iFixit sobre reemplazo del almacenamiento interno de Steam Deck https://es.ifixit.com/Gu%C3%ADa/Reemplazo+del+SSD+del+Steam+Deck/148989
• Instalación desde cero del sistema de Steam Deck https://help.steampowered.com/es/faqs/view/1B71-EDF2-EB6D-2BB3

Al acceder a nuestro Home Assistant tras actualizar a la versión 2023.2, si utilizamos dispositivos ESPHome con contraseña de API, nos podemos encontrar con una alerta en la sección de Ajustes con el mensaje:

API Password deprecated on <nombre dispositivo>

En este artículo vemos cómo resolverlo.

En el menú de Ajustes nos puede aparecer en la parte superior un elemento como el siguiente:

Si pulsamos en el mensaje, nos mostrará el siguiente diálogo:

y en el enlace SABER MÁS nos enviará a https://esphome.io/components/api.html, la documentación de la API. En el apartado Configuration variables nos informará de la variable encryption, que contiene a su vez el parámetro key, una cadena de 32 bytes codificada en base64 como ésta: VEY3yb8yK1x+s03pORI3IBCrGaCHIfBnjaijQaedTRI=. Este valor se genera aleatoriamente cada vez que visitamos la página, por lo que se podría utilizar directamente, pero lo habitual será generar o escribir una nosotros mismos con la misma longitud.

La solución pasa por reemplazar en el archivo YAML de configuración del dispositivo ESPHome, el apartado:

# Enable Home Assistant API
api:
  password: "ABCDEfghi1234"

por

# Enable Home Assistant API
api:
  encryption:
    key: "VEY3yb8yK1x+s03pORI3IBCrGaCHIfBnjaijQaedTRI="

y cargar el nuevo código en nuestro dispositivo ejecutando:

esphome run archivo.yaml

Una vez actualizado el firmware en nuestro dispositivo, aparecerá una notificación en Home Assistant indicando que una integración requiere reconfiguración:

Si pulsamos en el enlace Check it out nos enviará directamente a al apartado Ajustes -> Integraciones, donde aparecerá la integración que requiere aplicar una reconfiguración:

pulsamos en el botón RECONFIGURAR y nos mostrará un diálogo que pedirá la clave de cifrado que hayamos especificado:

Introducimos la clave y pulsamos el enlace ENVIAR. Si la clave es correcta, nos mostrará un diálogo de confirmación:

Sólo queda pulsar en CERRAR. Nuestro dispositivo estará operativo de nuevo y la alerta desaparece.

• https://esphome.io/components/api.html

Fedora libera una nueva versión aproximadamente cada 6 meses y proporciona actualizaciones de paquetes para las dos últimas versiones estables disponibles, dando un mes adicional para la versión que queda fuera de soporte. Esto hace que si queremos el software al día, debemos subir de versión como máximo cada 13 meses.

En este artículo se describen algunos detalles básicos del ciclo de vida de versiones en Fedora y cómo realizar la actualización.

Contenido

Como se ha indicado anteriormente, Fedora libera una nueva versión estable cada 6 meses aproximadamente. Mantiene actualizaciones de paquetes en las dos últimas versiones disponibles. Una vez publicada una nueva versión N, la versión N - 2 mantiene actualizaciones durante un mes más para dar tiempo a actualizarse, pero a partir de ahí deja de recibirlas.

Podemos consultar las fechas de fin de soporte de las diferentes versiones en https://docs.fedoraproject.org/en-US/releases/eol/.

Estos detalles hacen que una versión de Fedora deje de recibir actualizaciones aproximadamente cada 13 meses.

Antes de hace una actualización es recomendable hacer una copia de seguridad de los archivos importantes de datos y configuración, porque siempre existe el riesgo de problemas durante la actualización.

Las actualizaciones a una versión consecutiva superior (por ejemplo de la 42 a la 43) o saltando una versión (de 41 a 43) están soportadas, pero es recomendable hacer la actualización antes de que lleguen a su fin de fida (EOL). Esto ocurre un mes después de que se liberen dos versiones posteriores a la actual, como se ha mencionado anteriormente. Las actualizaciones a más de dos versiones superiores a la vez no están soportadas. De hecho, para la actualización a dos versiones superiores una vez finalizado el mes de margen puede ser necesario importar la clave GPG para la versión a la que se quiere actualizar. Esto se puede hacer con:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-N-primary

Para Fedora 43 utilizaríamos:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-43-primary

En primer lugar debemos actualizar los paquetes:

sudo dnf upgrade --refresh

y reiniciar el equipo. Esto es importante, ya que realiza la actualización de algunos paquetes y claves a la última versión disponibles, que pueden ser necesarias durante la instalación.

Una vez reiniciado el equipo instalamos el paquete dnf-plugin-system-upgrade package si no se encuentra ya instalado:

sudo dnf install dnf-plugin-system-upgrade

Descargamos los paquetes actualizados para la nueva versión a la que queremos actualizar, en este ejemplo, la versión 43:

sudo dnf system-upgrade download --releasever=43

Si alguno de los paquetes tienen dependencias que no se hayan podido conseguir, la actualización rechazará continuar a menos que se ejecute de nuevo con el parámetro --allowerasing. Esto ocurre con paquetes instalados de repositorios de terceros para los que no se han publicado aún repositorios actualizados a la nueva versión. Esta opción lo que haría es eliminar los paquetes que no se pueden actualizar, por lo que hay que estudiar la salida con cuidado y tener presente qué paquetes se eliminarían.

En caso de dependencias no satisfechas, se puede a veces ver más detalles si se añade la opción --best.

Si es necesario añadir o eliminar paquetes antes de ejecutar de nuevo dnf system-upgrade download, es recomendable hacer esas operaciones añadiendo a dnf la opción --setopt=keepcache=1. Si no se utiliza, se eliminará la caché de paquetes completa después de la operación y se tendrá que descargar todos los paquetes de nuevo.

Para lanzar el procedimiento de actualización, habrá que cerrar todos los programas y lanzar el proceso con la instrucción:

sudo dnf5 offline reboot

Esto realizará la actulización durante el siguiente arranque del sistema. Cuando termine la actualización, realizará un nuevo reinicio en la nueva versión.

Fedora en su documentación enumera una serie de tareas que podemos realizar una vez finalizada la actualización para optimizar el sistema y limpiar archivos obsoletos. Podemos consultarlos en https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-optional-post-upgrade-tasks.

En caso de haber cambiado manualmente archivos de configuración situados en /etc, RPM crea archivos con la extensión .rpmnew (para la nueva versión del archivo) y .rpmsave (para la versión previa que hubiéramos modificado). Buscando esos archivos podemos examinarlos manualmente y resolver los conflictos, si los hay. Otra opción es utilizar la herramienta rpmconf diseñada para simplificar este proceso. Se instala con:

sudo dnf install rpmconf

Y se utiliza con:

sudo rpmconf -a

Al utilizar rpmconf para actualizar la configuración del sistema, algunos archivos de configuración pueden cambiar. Después de actualizar hay que verificar especialmente los archivos /etc/ssh/sshd_config, /etc/nsswitch.conf y /etc/ntp.conf. En el caso de OpenSSH, tras la actualización el archivo sshd_configque da con su configuración por defecto en la que por ejemplo no está habilitada la autenticación por clave y permite la autenticación por contraseña.

En sistemas con firmware BIOS, el cargador de arranque no se actualiza de manera automática, por lo que es aconsejable actualizarlo entre versiones de Fedora.

Si no estamos seguros de si nuestro sistema es BIOS o UEFI, un modo de verificarlo es ejecutar:

$ sudo efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0017,0018,0019,001A,001B,001D,001E,001F,0001,001C
Boot0000* Fedora	HD(1,GPT,76400879-6149-42fe-8307-1e0aa5ef1ed8,0x800,0x320b8)/File(\EFI\fedora\shimx64.efi)
Boot0001* Linux-Firmware-Updater	HD(1,GPT,76400898-6149-42fe-8307-1e0aa5ef1ed8,0x800,0x320b8)/File(\EFI\fedora\fwupdx64.efi)
...

La respuesta anterior es para un sistema con UEFI. En caso de ser BIOS, la respuesta será:

EFI variables are not supported on this system

Para actualizar el cargador de arranque, el primer paso es localizar el archivo de dispositivo en el que está ubicado el directorio /boot/:

$ sudo mount | grep "/boot "
/dev/sda4 on /boot type ext4 (rw,relatime,seclabel)

En este caso es /dev/sda4. Hay que reinstalar el cargador de arranque especificando el archivo de dispositivo sin el número:

$ sudo grub2-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Cada versión, Fedora retira algunos paquetes. Puede que el paquete pase a estar obsoleto, que el proyecto original desaparezca o el mantenedor baje la calidad. En esos casos Fedora deja de distribuir esos paquetes, pero continúan en el sistema. Nunca se recibirán actualizaciones, ni siquiera de seguridad, por lo que es recomendable eliminar esos paquetes. Para facilitar esta operación podemos instalar el paquete remove-retired-packages:

sudo dnf install remove-retired-packages

y realizar una limpieza con esta herramienta:

remove-retired-packages

Buscará paquetes retirados y si los encuentra preguntará interactivamente si se desean conservar o eliminar.

Pueden quedar paquetes procedentes de la versión o versiones anteriores. Antes de buscar paquetes anticuados es recomendable ejecutar:

sudo dnf upgrade

ya que la lista que obtengamos sólo es válida si el sistema está totalmente actualizado.

Podemos consultar paquetes duplicados (paquetes que tienen múltiples versiones instaladas) con:

sudo dnf repoquery --duplicates

En caso de que aparezca alguno, lo podemos eliminar.

Puede que haya paquetes que todavía estén en el sistema pero que no aparezcan nunca más en los repositorios. Podemos verlos con:

sudo dnf list extras

Si aparece algún paquete no necesario, se puede eliminar con:

sudo dnf remove $(sudo dnf repoquery --extras --exclude=kernel,kernel-\*)

Se pueden eliminar de forma segura todos los paquetes con:

sudo dnf autoremove

Después de arrancar con el último kernel y comprobar el sistema, se pueden eliminar los kernels previos. Los kernels antiguos no se eliminan con dnf autoremove para evitar eliminaciones accidentales.

Una de las formas más sencillas de eliminar los kernels antiguos es con un script que mantenga el último kernel. El script siguiente es un ejemplo de ello:

#!/usr/bin/env bash

old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#old_kernels[@]}" -eq 0 ]; then
    echo "No old kernels found"
    exit 0
fi

if ! dnf remove "${old_kernels[@]}"; then
    echo "Failed to remove old kernels"
    exit 1
fi

echo "Removed old kernels"
exit 0

Puede haber algunos enlaces simbólicos en el sistema de ficheros que queden colgados tras una actualización.

Para localizarlos, podemos instalar la herramienta symlinks:

sudo dnf install symlinks

Una vez instalada se pueden auditar con un comando como el siguiente (el parámetro -r significa recursivo):

sudo symlinks -r /usr | grep dangling

Después de verificar la lista, se pueden eliminar con el parámetro -d:

sudo symlinks -r -d /usr

A continuación se describen algunas tareas que SÓLO deben ejecutarse si se producen problemas en el sistema actualizado.

Si aparecen advertencias cuando se trabaja con las herramientas rpm o dnf, puede que la base de datos esté corrupta. Es posible reconstruirla y ver si esto resuelve los problemas. Siempre hay que hacer primero un backup del directorio /var/lib/rpm/. Se puede reconstruir con:

sudo rpm --rebuilddb

La herramienta de actualización de sistema utiliza dnf distro-sync por defecto. Si el sistema se actualiza parcialmente o se aprecian algunos problemas de dependencia de paquetes, se puede intentar ejecutar el comando distro-sync manualmente para ver se resuelven. Esto intentará hacer que los paquetes instalados tengan la misma versión que la de los repositorios actualmente habilitados, incluso si para ello debe hacer un downgrade de algunos paquetes:

sudo dnf distro-sync

Se puede además especificar la opción --allowerasing que eliminará paquetes con dependencias que no puedan ser resueltas. Siempre hay que revisar qué paquetes se eliminarán confirmándolo de esta manera:

sudo dnf distro-sync --allowerasing

Si aparece alguna advertencia referentes a políticas SELinux, puede que algunos archivos tengan permisos SELinux incorrectos. Esto puede ocurrir si Ss.fedoraprojELinux fue inhabilitado en el pasado. Para reetiquetar SELinux en el sistema, hay que ejecutar el siguiente comando y después reiniciar:

sudo fixfiles -B onboot

El proceso de arranque puede llevar mucho tiempo, ya que comprueba y corrige las etiquetas de permisos SELinux en todos los archivos del sistema.

• https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
• https://docs.fedoraproject.org/en-US/releases/lifecycle/

El sensor Aqara SJCGQ11LM es un dispositivo con conectividad Zigbee que permite detectar fugas de agua. En este artículo veremos como configurarlo para que publique valores a través de Zigbee2mqtt, lo que permitirá automatizar avisos en caso de detección, ya sea a través de scripts o aplicaciones propias o de Home Assistant.

Debemos disponer de los siguientes componentes ya instalados y configurados:

• Broker MQTT. En este artículo se explica cómo instalar mosquitto en una Raspberry Pi.
• Zigbee2mqtt. La instalación y configuración básica se describen en este artículo

Mantenemos pulsada la parte superior del sensor, donde está el icono de la gota de agua, hasta que el led azul que está justo al lado del icono empiece a parpadear. Esto hará que se inicie el emparejamiento. En el log de zigbee2mqtt aparecerá:

info  2022-09-12 07:28:39: Device '0x00158d0008059a5b' joined
info  2022-09-12 07:28:39: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d0008059a5b","ieee_address":"0x00158d0008059a5b"},"type":"device_joined"}'
info  2022-09-12 07:28:39: Starting interview of '0x00158d0008059a5b'
info  2022-09-12 07:28:39: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d0008059a5b","ieee_address":"0x00158d0008059a5b","status":"started"},"type":"device_interview"}'
info  2022-09-12 07:28:40: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d0008059a5b","ieee_address":"0x00158d0008059a5b"},"type":"device_announce"}'
info  2022-09-12 07:28:43: MQTT publish: topic 'zigbee2mqtt/enchufe', payload '{"current":0,"energy":0.12,"linkquality":72,"power":0,"power_outage_memory":"restore","state":"OFF","voltage":360}'
info  2022-09-12 07:28:58: MQTT publish: topic 'zigbee2mqtt/enchufe', payload '{"current":0,"energy":0.12,"linkquality":69,"power":0,"power_outage_memory":"restore","state":"OFF","voltage":358}'
info  2022-09-12 07:29:10: Successfully interviewed '0x00158d0008059a5b', device has successfully been paired
info  2022-09-12 07:29:10: Device '0x00158d0008059a5b' is supported, identified as: Xiaomi Aqara water leak sensor (SJCGQ11LM)
info  2022-09-12 07:29:10: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Aqara water leak sensor","exposes":[{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Indicates whether the device detected a water leak","name":"water_leak","property":"water_leak","type":"binary","value_off":false,"value_on":true},{"access":1,"description":"Indicates if the battery of this device is almost empty","name":"battery_low","property":"battery_low","type":"binary","value_off":false,"value_on":true},{"access":1,"description":"Voltage of the battery in millivolts","name":"voltage","property":"voltage","type":"numeric","unit":"mV"},{"access":1,"description":"Measured temperature value","name":"temperature","property":"temperature","type":"numeric","unit":"°C"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"SJCGQ11LM","options":[],"supports_ota":false,"vendor":"Xiaomi"},"friendly_name":"0x00158d0008059a5b","ieee_address":"0x00158d0008059a5b","status":"successful","supported":true},"type":"device_interview"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/sensor/0x00158d0008059a5b/battery/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"device_class":"battery","enabled_by_default":true,"entity_category":"diagnostic","name":"0x00158d0008059a5b battery","state_class":"measurement","state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_battery_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.battery }}"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/binary_sensor/0x00158d0008059a5b/water_leak/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"device_class":"moisture","name":"0x00158d0008059a5b water leak","payload_off":false,"payload_on":true,"state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_water_leak_zigbee2mqtt","value_template":"{{ value_json.water_leak }}"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/binary_sensor/0x00158d0008059a5b/battery_low/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"device_class":"battery","entity_category":"diagnostic","name":"0x00158d0008059a5b battery low","payload_off":false,"payload_on":true,"state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_battery_low_zigbee2mqtt","value_template":"{{ value_json.battery_low }}"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/sensor/0x00158d0008059a5b/voltage/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"device_class":"voltage","enabled_by_default":false,"entity_category":"diagnostic","name":"0x00158d0008059a5b voltage","state_class":"measurement","state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_voltage_zigbee2mqtt","unit_of_measurement":"mV","value_template":"{{ value_json.voltage }}"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/sensor/0x00158d0008059a5b/temperature/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"device_class":"temperature","enabled_by_default":true,"name":"0x00158d0008059a5b temperature","state_class":"measurement","state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_temperature_zigbee2mqtt","unit_of_measurement":"°C","value_template":"{{ value_json.temperature }}"}'
info  2022-09-12 07:29:10: MQTT publish: topic 'homeassistant/sensor/0x00158d0008059a5b/linkquality/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0008059a5b"],"manufacturer":"Xiaomi","model":"Aqara water leak sensor (SJCGQ11LM)","name":"0x00158d0008059a5b","sw_version":"3000-0001"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:signal","name":"0x00158d0008059a5b linkquality","state_class":"measurement","state_topic":"zigbee2mqtt/0x00158d0008059a5b","unique_id":"0x00158d0008059a5b_linkquality_zigbee2mqtt","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}"}'

Si en el log aparece el mensaje device_joined será indicativo de que se ha emparejado correctamente.

Para dar un nombre más amigable al dispositivo, paramos el servicio zigbee2mqtt:

sudo systemctl stop zigbee2mqtt

Editamos el archivo de configuración de zigbee2mqtt, que en este caso está en /opt/zigbee2mqtt/data/configuration.yaml.

Al final del archivo, en la sección devices nos aparecerá una entrada del tipo:

  '0x00158d0008059a5b':
    friendly_name: '0x00158d0008059a5b'

Cambiamos el valor del atributo friendly_name por otro que nos resulte más fácil de reconocer:

  '0x00158d0008059a5b':
    friendly_name: 'sfa_banyo'

y arrancamos el servicio de nuevo para que se aplique el nuevo nombre:

sudo systemctl start zigbee2mqtt

Ahora debe publicar los eventos en el topic zigbee2mqtt/sfa_banyo.

El funcionamiento del dispositivo es muy sencillo. En la parte inferior tiene dos tornillos. Si ambos tornillos entran en contacto con agua, se transmite electricidad entre ambos y se considera que hay fuga de agua. Se trata de un dispositivo de bajo consumo, por lo que el sensor no está accesible la mayoría del tiempo, sólo cuando se activa porque detecta una fuga de agua. Podemos forzarla introduciendo el sensor en un vaso con el nivel de agua para que los dos tornillos de la parte inferior entren en contacto con ella.

Las peticiones de lectura de valores o escritura para configurar parámetros no se procesan inmediatamente sino que son encoladas y se envían en la siguiente ocasión en la que está disponible.

Para leer valores, nos suscribimos con mosquitto_sub al topic zigbee2mqtt/sfa_banyo en nuestro broker MQTT. Si lo hacemos desde dentro de la propia Raspberry pi (o el servidor donde se esté ejecutando mosquitto) utilizaremos el parámetro -h localhost. Si lo hacemos desde otro equipo, especificaremos la dirección IP del la máquina donde se ejecute mosquitto:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sfa_banyo"

Cuando se detecta una fuga de agua, el mensaje enviado es el siguiente:

{"battery":100,"battery_low":false,"linkquality":36,"tamper":false,
"temperature":25,"voltage":3015,"water_leak":true}

Cuando deja de producirse la fuga, el mensaje enviado es el siguiente:

{"battery":100,"battery_low":false,"linkquality":96,"tamper":false,
"temperature":25,"voltage":3015,"water_leak":false}

Los parámetros que publica son los siguientes:

• battery. Número que indica el tanto por ciento (%) de batería restante. En las pruebas realizadas, hasta que transcurrió una hora del emparejamiento del dispositivo, no empezaron a transmitirse valores en este parámetro y aparecía el valor null.
• battery_low. Envía true si la pila está baja y es necesario cambiarla o false si tiene un nivel correcto.
• linkquality. Número que indica la fuerza de la señal de enlace con el hub. El valor puede oscilar entre 0 (mínimo valor, cuando no hay señal) y 255, que sería el máximo valor. La unidad de este valor es lqi (Link Quality Indicator).
• tamper. Indica si el dispositivo es manipulado. Algunos detectores incluyen un par de terminales llamados tamper, como sistema anti-sabotaje. Cuando alguien trata de abrir el dispositivo, la apertura se detecta y se envía una señal para avisar de ello. En este caso, se envía el valor true en este parámetro si el dispositivo es manipulado o false en caso contrario.
• temperature. Temperatura del dispositivo en ºC. En las pruebas realizadas, hasta que transcurrió una hora del emparejamiento del dispositivo, no empezaron a transmitirse valores en este parámetro y aparecía el valor null.
• voltage. Voltaje de la pila en milivoltios. Al igual que ocurre con battery y temperature, en las pruebas realizadas, hasta que transcurrió una hora del emparejamiento del dispositivo, no empezaron a transmitirse valores en este parámetro y aparecía el valor null.
• water_leak. Si se detecta una fuga de agua, contendrá el valor true. Cuando no haya ninguna fuga detectada, se enviará valor false.

Admite la calibración de la temperatura del dispositivo, que podemos realizar añadiendo en la correspondiente entrada del archivo configuration.yaml de zigbee2mqtt lo siguiente:

  '0x00158d0008059a5b':
    friendly_name: 'sfa_banyo'
    device_temperature_calibration: 3

o bien publicar en el servidor mqtt un payload con ese valor en el topic asociado al dispositivo:

mosquitto_pub -d -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sfa_banyo" \
-m '{"device_temperature_calibration": "3"}'

Podemos tener un sistema de detección de fugas de agua para aquellos lugares donde exista riesgo de ello de una forma muy sencilla con este dispositivo. Para ello debemos disponer de un gateway Zigbee y un broker MQTT al que emparejaremos el sensor de fugas de agua con conectividad Zigbee Aqara SJCGQ11LM. Se ha visto como configurarlo y consultar su estado sin necesidad de hacer uso de aplicaciones del fabricante, a través de la publicación y suscripción a topics MQTT, lo que permitiría detectar mediante scripts en bash o cualquier lenguaje de programación como python las fugas y disparar una alarma o enviar un aviso. En combinación con Home Assistant permitiría crear automatizaciones de forma sencilla para estos casos.

• https://www.zigbee2mqtt.io/devices/SJCGQ11LM.html

El Sonoff SNZB-03 es un sensor de movimiento que se conecta a través de protocolo Zigbee. Se alimenta con una pila de botón de 3V CR2450. Presenta unas dimensiones muy reducidas (40x35x30mm)

Está diseñado para funcionar con la aplicación eWeLink, pero veremos cómo configurarlo para su uso con zigbee2mqtt, lo que abre el paso para su control mediante scripts o programas propios y a la integración plataformas como Home Assistant, pero sin requerir de servicios externos.

Debemos disponer de los siguientes componentes ya instalados y configurados:

• Broker MQTT. En este artículo se explica cómo instalar mosquitto en una Raspberry Pi.
• Zigbee2mqtt. La instalación y configuración básica se describen en este artículo

Pulsamos durante cinco segundos el botón de reset, hasta que comience a parpadear un led rojo. El botón de reset está dentro de un pequeño orificio para evitar que se active por accidente. Hay que pulsarlo con un pin similar a los que se utilizan para abrir la bandeja de la tarjeta SIM de los teléfonos, incluído en la caja del dispositivo. Una vez activada la sincronización en el log de zigbee2mqtt aparecerá:

info  2022-02-04 22:46:12: Device '0x00124b00250beb63' joined
info  2022-02-04 22:46:12: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00250beb63","ieee_address":"0x00124b00250beb63"},"type":"device_joined"}'
info  2022-02-04 22:46:12: Starting interview of '0x00124b00250beb63'
info  2022-02-04 22:46:12: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00250beb63","ieee_address":"0x00124b00250beb63","status":"started"},"type":"device_interview"}'
info  2022-02-04 22:46:13: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00250beb63","ieee_address":"0x00124b00250beb63"},"type":"device_announce"}'

Si en el log aparece el mensaje device_joined será indicativo de que se ha emparejado correctamente.

Para dar un nombre más amigable al dispositivo, paramos el servicio zigbee2mqtt:

sudo systemctl stop zigbee2mqtt

Editamos el archivo de configuración de zigbee2mqtt, que en este caso está en /opt/zigbee2mqtt/data/configuration.yaml.

Al final del archivo, en la sección devices nos aparecerá una entrada del tipo:

  '0x00124b00250beb63':
    friendly_name: '0x00124b00250beb63'

Cambiamos el valor del atributo friendly_name por otro que nos resulte más fácil de reconocer:

  '0x00124b00250beb63':
    firendly_name: 'sensor_movimiento'

y arrancamos el servicio de nuevo para que se aplique el nuevo nombre:

sudo systemctl start zigbee2mqtt

Ahora debe publicar los eventos en el topic zigbee2mqtt/sensor_movimiento.

Se trata de un dispositivo de bajo consumo, por lo que el sensor no está accesible la mayoría del tiempo, sólo cuando se activa porque se detecta un movimiento.

Las peticiones de lectura de valores no se procesan inmediatamente sino que son encoladas y se envían en la siguiente ocasión en la que está disponible.

Para leer valores, nos suscribimos con mosquitto_sub al topic zigbee2mqtt/sensor_movimiento en nuestro broker MQTT. Si lo hacemos desde dentro de la propia Raspberry pi (o el servidor donde se esté ejecutando mosquitto) utilizaremos el parámetro -h localhost. Si lo hacemos desde otro equipo, especificaremos la dirección IP del la máquina donde se ejecute mosquitto:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sensor_movimiento"

Cuando detecta un movimiento, recibimos el valor true en el parámetro occupancy.

{"battery":57.5,"battery_low":false,"linkquality":111,"occupancy":true,"tamper":false,"voltage":2900}

Cuando se deja de detectar, se envía el valor false en ese mismo parámetro:

{"battery":57.5,"battery_low":false,"linkquality":114,"occupancy":false,"tamper":false,"voltage":2900}

Además del parámetro occupancy que es el que nos indica si realmente se detecta movimiento, el mensaje JSON muestra otros parámetros:

• battery_low. Indica si la batería está a punto de acabarse, en cuyo caso contiene el valor true. Si la batería tiene un nivel aceptable contiene el valor false.
• battery. Número que indica la batería restante en porcentaje.
• tamper. Indica si el dispositivo es manipulado. Algunos detectores incluyen un par de terminales llamados tamper, como sistema anti-sabotaje. Cuando alguien trata de abrir el dispositivo, la apertura se detecta y se envía una señal para avisar de ello. En este caso, se envía el valor true en este parámetro si el dispositivo es manipulado o false en caso contrario.
• linkquality. Fuerza de la señal. El valor mínimo es 0 y el máximo 255. La unidad de este valor es lqi (Link Quality Indicator).
• voltage. Voltaje de la pila en milivoltios.

Este dispositivo no tiene parámetros de configuración conocidos a la hora de utilizarlo con Zigbee2mqtt como sí tienen otros dispositivos similares como el Tuya ZM-35ZH-Q.

Disponiendo de un gateway Zigbee y un broker MQTT se puede emparejar con el gateway un sensor de movimiento con conectividad Zigbee, en este caso el Sonoff SNZB-03. Se ha visto como consultar su estado a través de suscripción a topics MQTT. Esto permite detectar la entrada de una persona en un área y realizar acciones en consecuencia, como disparar una alarma, un aviso o encender una luz. En combinación con Home Assistant permitiría definir automatizaciones de forma sencilla.

Aún no he hecho un uso suficiente para sacar conclusiones definitivas. La parte negativa en comparación con el Tuya ZM-35ZH-Q es que no admite ningún parámetro de configuración como la sensibilidad o el tiempo en el que permanece activa la detención. Como ventaja sobre ese otro dispositivo, el Sonoff nos informa del estado exacto de la batería.

• https://www.zigbee2mqtt.io/devices/SNZB-03.html
• https://sonoff.tech/product-document/smart-home-security-doc/snzb-03-doc/
• https://sonoff.tech/wp-content/uploads/2021/03/%E5%BF%AB%E9%80%9F%E6%8C%87%E5%8D%97-SNZB-03-V1.0-20200506.pdf
• https://sonoff.tech/wp-content/uploads/2021/03/%E8%AF%B4%E6%98%8E%E4%B9%A6-SNZB-03-V1.0-20210305.pdf

El Sonof SNZB-04 es un sensor de contacto que se conecta a través de protocolo Zigbee y que se alimenta con una pila de botón de 3V CR2032. Nos permite detectar la apertura de una puerta o ventana.

Está compuesto por dos pequeños módulos, uno que contiene la electrónica y otro que contiene un imán. Estos módulos los podemos pegar en el borde de una puerta, poniendo uno de ellos en el marco o parte fija y el otro en la parte móvil, de forma que cuando esté cerrada, los dos módulos estén cerca el uno del otro y alineados según una marca de referencia.

Está diseñado para funcionar con la aplicación eWeLink, pero veremos cómo configurarlo para su uso con zigbee2mqtt, lo que abre el paso para su control mediante scripts o programas propios y a la integración plataformas como Home Assistant, pero sin requerir de servicios externos.

Debemos disponer de los siguientes componentes ya instalados y configurados:

• Broker MQTT. En este artículo se explica cómo instalar mosquitto en una Raspberry Pi.
• Zigbee2mqtt. La instalación y configuración básica se describen en este artículo

Para activar el sensor por primera vez es necesario retirar una protección que impide que la pila toque los contactos de alimentación del dispositivo. En primer lugar hay que abrir la tapa trasera del módulo principal, el de mayor tamaño. Para ello introducimos un destornillador en la muesca que tiene justo debajo de la tapa:

Giramos el destornillador para forzar la apertura y una vez retirada la tapa, veremos debajo de la pila una pieza de plástico con la misma forma que la pila y una pequeña lengüeta de la que deberemos tirar para quitarla.

Una vez quitada la pieza de plástico, la pila estará tocando los contactos de ambos polos. Volvemos a poner la tapa y el dispositivo estará ya operativo para hacer el emparejamiento.

Pulsamos durante cinco segundos el botón de reset, hasta que veamos parpadear tres veces un led rojo en la tapa superior del módulo principal. El botón de reset está en el módulo principal, dentro de un pequeño orificio para evitar que se active por accidente. Hay que pulsarlo con un pin similar a los que se utilizan para abrir la bandeja de la tarjeta SIM de los teléfonos, incluído en la caja del dispositivo. Una vez activada la sincronización en el log de zigbee2mqtt aparecerá:

Device '0x00124b0025003318' joined
MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b0025003318","ieee_address":"0x00124b0025003318"},"type":"device_joined"}'
Starting interview of '0x00124b0025003318'
MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b0025003318","ieee_address":"0x00124b0025003318","status":"started"},"type":"device_interview"}'
MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b0025003318","ieee_address":"0x00124b0025003318"},"type":"device_announce"}'
Successfully interviewed '0x00124b0025003318', device has successfully been paired
Device '0x00124b0025003318' is supported, identified as: SONOFF Contact sensor (SNZB-04)
MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Contact sensor","exposes":[{"access":1,"description":"Indicates if the contact is closed (= true) or open (= false)","name":"contact","property":"contact","type":"binary","value_off":true,"value_on":false},{"access":1,"description":"Indicates if the battery of this device is almost empty","name":"battery_low","property":"battery_low","type":"binary","value_off":false,"value_on":true},{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Voltage of the battery in millivolts","name":"voltage","property":"voltage","type":"numeric","unit":"mV"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"SNZB-04","options":[],"supports_ota":false,"vendor":"SONOFF"},"friendly_name":"0x00124b0025003318","ieee_address":"0x00124b0025003318","status":"successful","supported":true},"type":"device_interview"}'

Si en el log aparece el mensaje device_joined será indicativo de que se ha emparejado correctamente.

Para dar un nombre más amigable al dispositivo, paramos el servicio zigbee2mqtt:

sudo systemctl stop zigbee2mqtt

Editamos el archivo de configuración de zigbee2mqtt, que en este caso está en /opt/zigbee2mqtt/data/configuration.yaml.

Al final del archivo, en la sección devices nos aparecerá una entrada del tipo:

  '0x00124b0025003318':
    friendly_name: '0x00124b0025003318'

Cambiamos el valor del atributo friendly_name por otro que nos resulte más fácil de reconocer:

  '0x00124b0025003318':
    friendly_name: 'sensor_apertura'

y arrancamos el servicio de nuevo para que se aplique el nuevo nombre:

sudo systemctl start zigbee2mqtt

Ahora debe publicar los eventos en el topic zigbee2mqtt/sensor_apertura.

Se trata de un dispositivo de bajo consumo, por lo que el sensor no está accesible la mayoría del tiempo, sólo cuando se activa porque detecta un cambio de estado de la apertura. Esto hace que las peticiones de lectura de valores no se procesen inmediatamente sino que sean encoladas y que el valor se reciba en la siguiente ocasión en la que el dispositivo está disponible, es decir, cuando hay un cambio de estado.

Para leer valores, nos suscribimos con mosquitto_sub al topic zigbee2mqtt/sensor_apertura en nuestro broker MQTT. Si lo hacemos desde dentro de la propia Raspberry pi (o el servidor donde se esté ejecutando mosquitto) utilizaremos el parámetro -h localhost. Si lo hacemos desde otro equipo, especificaremos la dirección IP del la máquina donde se ejecute mosquitto:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sensor_apertura"

Cuando la puerta o ventana está cerrada los dos módulos están alineados y recibimos el valor true en el parámetro contact.

{"battery":50,"battery_low":false,"contact":true,"linkquality":84,"tamper":false,"voltage":2800}

Cuando se abre los dos módulos dejan de estar alineados y se envía el valor false en ese mismo parámetro:

{"battery":50,"battery_low":false,"contact":false,"linkquality":96,"tamper":false,"voltage":2800}

Además del parámetro contact que es el que nos indica si la puerta o ventana está abierta o cerrada, el mensaje JSON muestra otros parámetros:

• battery. Número que indica la batería restante en porcentaje.
• battery_low. Indica si la batería está a punto de acabarse, en cuyo caso contiene el valor true. Si la batería tiene un nivel aceptable contiene el valor false.
• linkquality. Fuerza de la señal. El valor mínimo es 0 y el máximo 255. La unidad de este valor es lqi (Link Quality Indicator).
• tamper. Indica si el dispositivo es manipulado. Algunos detectores incluyen un par de terminales llamados tamper, como sistema anti-sabotaje. Cuando alguien trata de abrir el dispositivo, la apertura se detecta y se envía una señal para avisar de ello. En este caso, se envía el valor true en este parámetro si el dispositivo es manipulado o false en caso contrario.
• voltage. Voltaje de la pila en milivoltios.

Disponiendo de un gateway Zigbee y un broker MQTT se ha visto como emparejar un sensor de apertura de puertas y ventanas con conectividad Zigbee, en este caso el Sonoff SNZB-04, y la forma de consultar su estado a través de la publicación y suscripción a topics MQTT. Esto permite detectar la apertura de puertas y ventanas y realizar acciones en consecuencia, como disparar una alarma, un aviso, encender o apagar una luz. En combinación con Home Assistant permitiría definir automatizaciones de forma sencilla.

• https://www.zigbee2mqtt.io/devices/SNZB-04.html
• https://sonoff.tech/product-document/smart-home-security-doc/snzb-04-doc/

La variedad de servicios a los que debemos acceder hoy en día con una contraseña obliga a utilizar contraseñas complejas y distintas para los diferentes servicios. Para gestionarlas de la mejor manera posible existen gran variedad de gestores de contraseñas, desde aquellos que funcionan como aplicaciones de escritorio como Keepass y sus variantes, soluciones completas propietarias ofrecidas por empresas especializadas que nos proporcionan el almacenamiento remoto y acceso desde nuestro equipo a través de un complemento para el navegador o una aplicación móvil como ocurre con Lastpass y soluciones completas de código abierto que podemos utilizar de forma autohospedada o gestionada por sus creadores, como ocurre con Bitwarden.

Todas estas soluciones son muy completas y válidas para la mayor parte de los casos de uso. Pero también tienen su sitio herramientas con una base mucho más sencilla, accesibles desde todo tipo de clientes, incluso desde la terminal. Es el caso de pass, una herramienta desarrollada con la sencillez como principio y cuyo uso a través de la terminal nos permite utilizarla por ejemplo en scripts en los que sea necesaria autenticación con contraseña pero no queramos exponerlas por descuido si nuestros scripts deben estar en un repositorio público de código, entre otros muchos usos.

Pass es una aplicación desarrollada por Jason A. Donenfeld de zx2c4.com con licencia GPLv2+. También es el creador de wireguard, entre otras herramientas.

Contenido

Se encuentra en los repositorios de las principales distribuciones de GNU/Linux, con lo que se puede instalar desde ellos o descargar el comprimido desde su repositorio de git. Se puede instalar en MacOS a través de brew.

Para Debian/Ubuntu:

sudo apt-get install -y pass

Para Fedora:

sudo dnf install -y pass

El esquema de almacenamiento es sumamente simple:

• Todas las contraseñas se almacenan dentro del directorio ${HOME}/.password-store.
• Cada contraseña se almacena dentro de un archivo encriptado con gpg cuyo nombre es el nombre del sitio web o recurso cuya contraseña se almacena.
• Estos archivos encriptados se organizan en una jerarquía de directorios para clasificarlos.

Este esquema permite que la exportación de los datos sea tan sencilla como la copia del contenido de este directorio. Simplemente tendremos que contar con la clave gpg en el lugar donde lo queramos utilizar.

Toda la gestión se realiza con el comando pass, un script de shell con funciones de autocompletado para bash, zsh y fish. Escribiendo el comando y pulsando el tabulador dos veces nos irá sugiriendo los subcomandos y parámetros que admite.

Podemos comprobar la versión actualmente instalada con el subcomando version

pass version

============================================
= pass: the standard unix password manager =
=                                          =
=                  v1.7.4                  =
=                                          =
=             Jason A. Donenfeld           =
=               Jason@zx2c4.com            =
=                                          =
=      http://www.passwordstore.org/       =
============================================

También podemos obtener ayuda con pass help.

Antes de poder utilizar pass debemos iniciar el almacén de las contraseñas. Para ello existe el subcomando init al que debemos indicar el identificador de una clave GPG. Se pueden identificar múltiples claves GPG si hay un equipo de personas que debe tener acceso al almacén.

Si no disponemos de una clave gpg en nuestro equipo debemos generarla con el comando gpg --gen-key, para crear una clave con las opciones por defecto ya que sólo nos preguntará un nombre y una dirección de correo electrónico y elegirá el algoritmo y caducidad de un año, o con el comando gpg --full-generate-key, que nos permitirá especificar todas las características (algoritmo de clave, longitud de clave, caducidad, identificador, etc).

gpg --full-generate-key

gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Por favor seleccione tipo de clave deseado:
   (1) RSA y RSA (por defecto)
   (2) DSA y ElGamal
   (3) DSA (sólo firmar)
   (4) RSA (sólo firmar)
  (14) Existing key from card
Su elección: 1
las claves RSA pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (3072) 4096
El tamaño requerido es de 4096 bits
Por favor, especifique el período de validez de la clave.
         0 = la clave nunca caduca
      <n>  = la clave caduca en n días
      <n>w = la clave caduca en n semanas
      <n>m = la clave caduca en n meses
      <n>y = la clave caduca en n años
¿Validez de la clave (0)? 1y
La clave caduca dom 05 mar 2023 07:56:37 CET
¿Es correcto? (s/n) s

GnuPG debe construir un ID de usuario para identificar su clave.

Nombre y apellidos: Tutorial Pass
Dirección de correo electrónico: tutorial.pass@dvdcr.com
Comentario: Usuario principal de Pass
Ha seleccionado este ID de usuario:
    "Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>"

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V

En este punto un diálogo emergente nos pedirá una contraseña que tendremos que especificar dos veces.

Y luego se recomienda trabajar con el ratón o en otras ventanas para generar mayor entropía y que haya suficientes valores aleatorios para la generación de la clave.

Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
gpg: clave 7BA4043CB83457F9026E38CA9348B9233410DF876 marcada como de confianza absoluta
gpg: certificado de revocación guardado como '/home/usuario/.gnupg/openpgp-revocs.d/8DC10C2043C49D2A184B6083B441F579E8FD4B35.rev'
claves pública y secreta creadas y firmadas.

pub   rsa4096 2022-03-05 [SC] [caduca: 2023-03-05]
      7BA4043CB83457F9026E38CA9348B9233410DF876
uid                      Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>
sub   rsa4096 2022-03-05 [E] [caduca: 2023-03-05]

Podemos obtener la lista de claves gpg disponibles en el equipo con gpg --list-secret-keys.

Una vez que tenemos al menos una clave gpg podemos inicializar el almacén con el comando pass init indicando el correo electrónico asociado a la clave gpg que queremos utilizar, el comentario o el identificador hexadecimal de la clave.

pass init "Usuario principal de Pass"

mkdir: se ha creado el directorio '/home/usuario/.password-store/'
Password store initialized for Usuario principal de Pass

Ahora dispondremos del almacén de contraseñas en el directorio ~/.password-store, con lo que se puede empezar a trabajar con pass.

Opcionalmente podemos inicializar el almacén de contraseñas como un repositorio de git:

pass git init

ayuda: Usando 'master' como el nombre de la rama inicial. Este nombre de rama predeterminado
ayuda: está sujeto a cambios. Para configurar el nombre de la rama inicial para usar en todos
ayuda: de sus nuevos repositorios, que suprimirán esta advertencia, llame a:
ayuda: 
ayuda: 	git config --global init.defaultBranch <nombre>
ayuda: 
ayuda: Los nombres comúnmente elegidos en lugar de 'maestro' son 'principal', 'troncal' y
ayuda: 'desarrollo'. Se puede cambiar el nombre de la rama recién creada mediante este comando:
ayuda: 
ayuda: 	git branch -m <nombre>
Inicializado repositorio Git vacío en /home/usuario/.password-store/.git/
[master (commit-raíz) 5537e70] Add current contents of password store.
 1 file changed, 1 insertion(+)
 create mode 100644 .gpg-id
[master 4c94ae7] Configure git repository for gpg file diff.
 1 file changed, 1 insertion(+)
 create mode 100644 .gitattributes

Esto hará que cada vez que una contraseña sea manipulada se haga un git commit, lo que permitiría tener trazabilidad de los cambios y deshacerlos si es necesario.

Además, opcionalmente, podemos agregar un repositorio remoto para subir los cambios en él:

pass git remote add origin https://migit.es:pass-store

Aunque haremos referencia a “contraseñas”, realmente en una entrada de pass podemos almacenar cualquier tipo de información como identificadores de usuario, direcciones IP o direcciones de correo electrónico. Incluso es posible guardar en una misma entrada múltiples líneas y utilizar alguna sintaxis clave-valor con algún separador como el signo igual o dos puntos.

Para insertar una contraseña especificaremos la jerarquía donde queremos que se guarde y pass nos preguntará el valor dos veces sin mostrar lo que tecleamos por pantalla:

pass insert bbdd/mysql/wordpress/admin

mkdir: se ha creado el directorio '/home/user/.password-store/bbdd'
mkdir: se ha creado el directorio '/home/user/.password-store/bbdd/mysql'
mkdir: se ha creado el directorio '/home/user/.password-store/bbdd/mysql/wordpress'
Enter password for bbdd/mysql/wordpress/admin: 
Retype password for bbdd/mysql/wordpress/admin: 

Para insertar una entrada que contenga múltiples líneas tendremos que utilizar el parámetro -m, teclear toda la información y pulsar CTRL+D cuando hayamos terminado:

pass insert -m wordpress/blog/config

mkdir: se ha creado el directorio '/home/user/.password-store/wordpress'
mkdir: se ha creado el directorio '/home/user/.password-store/wordpress/blog'
Enter contents of wordpress/blog/config and press Ctrl+D when finished:

define('DB_NAME', 'nombredetubasededatos');
define('DB_USER', 'nombredeusuario');
define('DB_PASSWORD', 'contraseña');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Para mostrar el contenido podemos utilizar indistintamente el comando pass sin ningún subcomando o con los subcomandos ls o show. Si no especificamos ninguna ruta, se mostrará el árbol completo de contraseñas del almacén:

pass

Password Store
├── bbdd
│   └── mysql
│       └── wordpress
│           └── admin
└── wordpress
    └── blog
        └── config

Habríamos obtenido el mismo resultado exactamente con:

pass ls

o

pass show

Si especificamos una ruta parcial que no incluya el elemento final de la ruta, pass mostrará sólo la porción del árbol que haya bajo la ruta que hemos escrito. No nos pedirá la contraseña de cifrado de la clave gpg:

pass bbdd

bbdd
└── mysql
    └── wordpress
        └── admin

pass bbdd/mysql

bbdd/mysql
└── wordpress
    └── admin

Si especificamos la ruta completa hasta una contraseña, nos mostrará la contraseña en claro:

pass bbdd/mysql/wordpress/admin

Si es la primera vez en la sesión que solicitamos una contraseña o bien la caché de contraseñas de gpg ha caducado, nos aparecerá un diálogo solicitando la contraseña de la clave gpg:

Tras introducir la contraseña de la clave gpg, nos mostrará el valor de la contraseña cuya ruta hemos especificado. Durante el tiempo de caché que tenga definido gpg no nos volverá a solicitar la contraseña si realizamos más operaciones a continuación.

Debemos recordar también que disponemos de función de autocompletado, que nos ayuda a obtener la ruta sin teclearla completamente, ayudándonos de la tecla Tab. Si escribimos pass bbdd y pulsamos el tabulador nos autocompletará la ruta hasta el máximo posible en el que no haya ambigüedad. En este caso concreto escribirá toda la ruta bbdd/mysql/wordpress/admin hasta la clave final, puesto que sólo hay una contraseña y no hay ambigüedad.

Para copiar el contenido de una contraseña al portapapeles, evitando que aparezca en la terminal, utilizaremos el parámetro -c o --clip.

pass -c bbdd/mysql/wordpress/admin

Copied bbdd/mysql/wordpress/admin to clipboard. Will clear in 45 seconds.

Por defecto permanecerá en el portapapeles durante 45 segundos, durante los cuales podremos pegarla en cualquier aplicación como un navegador web o una aplicación de terminal que nos esté solicitando una contraseña. El tiempo en el que permanecerá en el portapapeles se puede modificar si definimos un valor en la variable de entorno PASSWORD_STORE_CLIP_TIME. Vamos a ver cómo subirlo a 90 segundos temporalmente:

export PASSWORD_STORE_CLIP_TIME=90
pass -c wordpress/blog/config

Copied wordpress/blog/config to clipboard. Will clear in 90 seconds.

En el caso de contraseñas en las que hayamos almacenado varias filas, sólo se copiará una de ellas, por defecto la primera.

Vamos a ver un ejemplo de ello. Mostramos el contenido de una de las claves que hemos introducido previamente:

pass wordpress/blog/config 

define('DB_NAME', 'nombredetubasededatos');
define('DB_USER', 'nombredeusuario');
define('DB_PASSWORD', 'contraseña');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Copiamos el contenido:

pass -c wordpress/blog/config

Copied wordpress/blog/config to clipboard. Will clear in 45 seconds.

Pegamos el contenido:

define('DB_NAME', 'nombredetubasededatos');

Siempre se copia una línea pero podemos precisar el número de línea en concreto especificándolo a continuación del parámetro -c o --clip:

pass -c2 wordpress/blog/config
Copied wordpress/blog/config to clipboard. Will clear in 45 seconds.

Pegamos el contenido y veremos que se ha seleccionado la línea 2:

define('DB_USER', 'nombredeusuario');

De forma muy similar a la copia al portapapeles, pero utilizando el parámetro -q o --qrcode, pass nos generará un código QR con el contenido de una contraseña:

pass -q bbdd/mysql/wordpress/admin

nos mostrará una ventana flotante con el código QR:

pass hace uso de la herramienta qrencode para ello.

Tal y como ocurría con el copiado al portapapeles, pass sólo copia una línea en el caso de entradas multilínea, por lo que si queremos una linea en concreto deberemos indicarlo poniendo el número de línea a continuación del parámetro -q o --qrcode. Si queremos que se genere el código QR con el contenido de la tercera fila:

pass -q3 wordpress/blog/config

pass puede generar nuevas contraseñas de forma aleatoria, para lo que utiliza internamente /dev/urandom.

La forma más sencilla de aprovechar esta funcionalidad es utilizar el subcomando generate sin parámetros, lo que generará un clave que incluirá todo tipo de símbolos y con una longitud de 25 caracteres:

pass generate api/geo/admin

mkdir: se ha creado el directorio '/home/user/.password-store/api/geo'
[master 8c03f82] Add generated password for api/geo/admin.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/geo/admin.gpg
The generated password for api/geo/admin is:
\8Pq*F9,+.Z8VZF0MLe9%`IKt

Podemos indicar que la clave generada sólo contenga caracteres alfanuméricos si incluimos el parámetro -n o --no-symbols y limitar la longitud de la contraseña si especificamos al final del comando un número. En el siguiente ejemplo generaremos una contraseña con caracteres únicamente alfanuméricos que tendrá 12 caracteres:

pass generate -n api/geo/developer 12

[master aa44eb2] Add generated password for api/geo/developer.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/geo/developer.gpg
The generated password for api/geo/developer is:
FViQ3KvuIpY2

Si no queremos que la contraseña generada aparezca en pantalla al generarse, sino que además de almacenarse en su archivo correspondiente se copie en el portapapeles, podemos añadir el parámetro --clip o -c:

pass generate -n -c api/geo/developer2 15

[master 3cec11d] Add generated password for api/geo/developer2.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/geo/developer2.gpg
Copied api/geo/developer2 to clipboard. Will clear in 45 seconds.

Como variante de lo anterior, podemos indicar el parámetro -q o -qrcode para que además de almacenarse la clave en su archivo correspondiente se genere un código QR y la contraseña no salga por consola.

Si especificamos la ruta a una contraseña ya existente, nos preguntará si queremos sobreescribirla:

$ pass generate -n -c api/geo/developer2 15

An entry already exists for api/geo/developer2. Overwrite it? [y/N] y
[master f6f9663] Add generated password for api/geo/developer2.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/geo/developer2.gpg (100%)
Copied api/geo/developer2 to clipboard. Will clear in 45 seconds.

Si a la hora de actualizar una contraseña no deseamos que nos pida confirmación, podemos utilizar el parámetro -f o --force:

pass generate -n -c -f api/geo/developer2 15

[master cfb4798] Add generated password for api/geo/developer2.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/geo/developer2.gpg (89%)
Copied api/geo/developer2 to clipboard. Will clear in 45 seconds.

El parámetro -i o --in-place permite especificar que en caso de archivos multilínea sólo se reemplace el contenido de la primera línea con la contraseña generada aleatoriamente.

Vamos a generar una clave multilínea:

pass insert -m api/node/users

mkdir: se ha creado el directorio '/home/user/.password-store/api/node'
Enter contents of api/node/users and press Ctrl+D when finished:

user1:blablabla
user2:blebleble
user3:bliblibli                            
[master 392d80e] Add given password for api/node/users to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/node/users.gpg

Generamos una contraseña con el parámetro -i:

pass generate -n -i api/node/users

[master 2837f6a] Replace generated password for api/node/users.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/node/users.gpg (100%)
The generated password for api/node/users is:
NijYp8yE19IT06A0uaG1FuG22

Comprobamos el resultado. Veremos que la primera línea ha sido reemplazada por una nueva contraseña generada al azar:

pass api/node/users

NijYp8yE19IT06A0uaG1FuG22
user2:blebleble
user3:bliblibli

Si utilizamos el subcomando generate sin -i sobre una clave multilínea existente sustituye completamente el contenido, quedando una sola línea:

pass generate -n api/node/users

An entry already exists for api/node/users. Overwrite it? [y/N] y
[master 262061f] Add generated password for api/node/users.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/node/users.gpg (100%)
The generated password for api/node/users is:
ibIF3YBTAHrcjOlr61bO2TaV3

pass api/node/users

ibIF3YBTAHrcjOlr61bO2TaV3

Podemos cambiar la longitud predeterminada de las contraseñas generadas aleatoriamente creando la variable de entorno PASSWORD_STORE_GENERATED_LENGTH con el valor de la nueva longitud que queramos establecer:

export PASSWORD_STORE_GENERATED_LENGTH=8
pass generate api/meteo/token

mkdir: se ha creado el directorio '/home/user/.password-store/api/meteo'
[master e460e6e] Add generated password for api/meteo/token.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/meteo/token.gpg
The generated password for api/meteo/token is:
zU-D+WAI

Podemos personalizar el conjunto de caracteres que utilizado para generar contraseñas aleatorias. Si lo que queremos personalizar es el conjunto utilizado cuando se especifica la opción -n o --no-symbols tendremos que crear la variable de entorno PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS con una cadena que contenga los caracteres permitidos:

export PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS="ZzYyXxWxTtSsRr012"
pass generate -f -n api/meteo/token
[master 208ecd5] Add generated password for api/meteo/token.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/meteo/token.gpg (100%)
The generated password for api/meteo/token is:
txT0Yt0x

Si lo que queremos personalizar es el conjunto utilizado cuando NO se especifica la opción -n o la opción --no-symbols tendremos que crear la variable de entorno PASSWORD_STORE_CHARACTER_SET con una cadena que contenga los caracteres permitidos:

export PASSWORD_STORE_CHARACTER_SET="abcdefgABCDEFG56789_$=&$"
pass generate -f api/meteo/token
[master bf92ac1] Add generated password for api/meteo/token.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite api/meteo/token.gpg (100%)
The generated password for api/meteo/token is:
G$e&cdf9

La modificación de una contraseña se puede realizar con los subcomandos insert o generate simplemente con el hecho de indicar la ruta de una contraseña existente. Si no queremos que se pida confirmación utilizaremos el parámetro -f o --force.

Para modificar una contraseña de forma interactiva a través de un editor existe el subcomando edit. Cuando llamamos a pass edit /ruta/a/clave se nos abre un editor de texto. Esto es especialmente util para modificar claves multilínea. El editor que se abre es el especificado en la variable de entorno EDITOR, que la mayoría de distribuciones tienen inicializada. Si no tiene valor, se utilizará vi por defecto. La edición se realiza sobre un archivo creado en un directorio temporal, habitualmente /dev/shm. Este directorio en realidad no se encuentra en disco sino que es un montaje realizado en memoria virtual y que por lo tanto reduce el riesgo de recuperación de contraseñas almacenadas en disco físico. Si este sistema de archivos no estuviera disponible, se utilizaría el directorio temporal estándar y se emitiría un aviso.

La eliminación de una contraseña puede hacerse con los subcomandos rm, remove o delete. Se puede especificar el parámetro -r o --recursive para eliminar toda una rama del árbol de contraseñas. Si queremos evitar que nos pida confirmación podemos utilizar los parámetros -f o --force:

 pass api/meteo

api/meteo
└── token

pass rm -r -f api/meteo

'/home/user/.password-store/api/meteo/token.gpg' borrado
removed directory '/home/user/.password-store/api/meteo/'
[master 4b0b3fa] Remove api/meteo from store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 api/meteo/token.gpg

Podemos copiar una contraseña o directorio completo a una nueva ruta con los subcomandos copy o cp. Pedirá confirmación para sobreescribir el destino si ya existe. Se puede omitir la confirmación si se especifica el parámetro -f o --force.

Si la ruta destino termina en / se considerará un directorio.

Si la ruta destino está cifrada con una clave pgp diferente de la del origen, las contraseñas serán reencriptadas con la clave que le corresponde según su nueva ruta.

pass wordpress

wordpress
└── blog
    └── config

pass cp wordpress/blog wordpress/ecommerce

/home/user/.password-store/wordpress/blog
'/home/user/.password-store/wordpress/blog' -> '/home/user/.password-store/wordpress/ecommerce'
'/home/user/.password-store/wordpress/blog/config.gpg' -> '/home/user/.password-store/wordpress/ecommerce/config.gpg'
[master 4999bd9] Copy wordpress/blog to wordpress/ecommerce.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 wordpress/ecommerce/config.gpg

pass wordpress

wordpress
├── blog
│   └── config
└── ecommerce
    └── config

Con los subcomandos mv o rename podemos cambiar el nombre o directorio donde se encuentra una contraseña. Podemos especificar los parámetros -f o --force para evitar que nos pida confirmación antes de realizar la operación. Si la nueva ruta termina en / se considerará un directorio. Si se mueve una contraseña a un directorio que está encriptado con una clave diferente de la del directorio origen, las contraseñas serán reencriptadas para que se correspondan con la clave de su nuevo destino.

pass wordpress

wordpress
├── blog
│   └── config
└── ecommerce
    └── config

pass mv -f wordpress/ecommerce wordpress/tienda

/home/user/.password-store/wordpress/ecommerce
renamed '/home/user/.password-store/wordpress/ecommerce' -> '/home/user/.password-store/wordpress/tienda'
[master aebbaca] Rename wordpress/ecommerce to wordpress/tienda.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename wordpress/{ecommerce => tienda}/config.gpg (100%)

pass wordpress

wordpress
├── blog
│   └── config
└── tienda
    └── config

Los subcomandos find y search buscan coincidencias parciales en el nombre de una contraseña o en su ruta. Mostrará el árbol completo en el que se encuentren elementos que coincidan con la cadena de búsqueda.

pass find wordpress

Search Terms: wordpress
├── bbdd
│   └── mysql
│       └── wordpress
│           └── admin
└── wordpress
    ├── blog
    │   └── config
    └── tienda
        └── config

El subcomando grep realiza la búsqueda por coincidencia parcial en el contenido de una contraseña. Mostrará la ruta hasta la contraseña o contraseñas encontradas y su contenido completo. La sintaxis es:

pass grep <opciones> <cadena-de-búsqueda>

<opciones> serán parámetros admitidos por el comando grep y se pasarán tal cual a dicho comando para hacer la búsqueda. El siguiente comando realiza una búsqueda en el contenido ignorando mayúsculas y minúsculas:

pass grep -i db_password

wordpress/blog/config:
define('DB_PASSWORD', 'contraseña');
wordpress/tienda/config:
define('DB_PASSWORD', 'contraseña');

En el siguiente comando no incluimos el parámetro -i:

pass grep db_password

No devuelve nada porque no encuentra ningún resultado ya que el contenido está en mayúsculas y no hemos incluído el parámetro -i.

Si buscamos sin -ipero especificando la cadena de búsqueda en mayúsculas sí que encuentra resultados:

pass grep DB_PASSWORD

wordpress/blog/config:
define('DB_PASSWORD', 'contraseña');
wordpress/tienda/config:
define('DB_PASSWORD', 'contraseña');

Es posible la utilización de un almacén por múltiples usuarios, cada uno con su propia clave gpg. Podemos tener directorios de claves sobre los que tengan permisos varios usuarios o solamente alguno de ellos.

Vamos a partir de un equipo en el que tenemos tres claves:

gpg --list-keys
gpg: comprobando base de datos de confianza
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: nivel: 0  validez:   3  firmada:   0  confianza: 0-, 0q, 0n, 0m, 0f, 3u
gpg: siguiente comprobación de base de datos de confianza el: 2023-03-05
/home/user/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096 2022-03-05 [SC] [caduca: 2023-03-05]
      8DC10C2043C49D2A184B6083B441F579E8FD4B35
uid        [  absoluta ] Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>
sub   rsa4096 2022-03-05 [E] [caduca: 2023-03-05]

pub   rsa3072 2022-03-12 [SC]
      481F470ACD42A060A43823EADF8598AD17670555
uid        [  absoluta ] Departamento contabilidad (contabilidad) <contabilidad@dvdcr.com>
sub   rsa3072 2022-03-12 [E]

pub   rsa3072 2022-03-12 [SC]
      8B84A215584C363F0DF905622E3766B165193EFD
uid        [  absoluta ] Departamento Auditoría (auditoria) <auditoria@dvdcr.com>
sub   rsa3072 2022-03-12 [E]

Vamos a inicializar un directorio dentro de nuestro almacén al que sólo tendrá acceso el departamento de contabilidad con su clave:

pass init -p contabilidad/privado contabilidad

mkdir: se ha creado el directorio '/home/user/.password-store/contabilidad'
mkdir: se ha creado el directorio '/home/user/.password-store/contabilidad/privado'
Password store initialized for contabilidad (contabilidad/privado)
[master 49e7c31] Set GPG id to contabilidad (contabilidad/privado).
 1 file changed, 1 insertion(+)
 create mode 100644 contabilidad/privado/.gpg-id

Generamos una clave para el correo electrónico de contabilidad:

pass generate -n contabilidad/privado/email

pass init -p contabilidad/privado contabilidad
mkdir: se ha creado el directorio '/home/user/.password-store/contabilidad'
mkdir: se ha creado el directorio '/home/user/.password-store/contabilidad/privado'
Password store initialized for contabilidad (contabilidad/privado)
[master 49e7c31] Set GPG id to contabilidad (contabilidad/privado).
 1 file changed, 1 insertion(+)
 create mode 100644 contabilidad/privado/.gpg-id
[dvdc@baracus ~]$ pass generate -n contabilidad/privado/email
[master 9162f15] Add generated password for contabilidad/privado/email.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 contabilidad/privado/email.gpg
The generated password for contabilidad/privado/email is:
JJGtJAWZ2yeD5cbSS30WO2l9s

Intentamos copiar al portapapeles esa nueva clave:

pass -c contabilidad/privado/email

Nos pedirá la contraseña de la clave con la que hemos cifrado la rama a la que pertenece esa entrada:

Copied contabilidad/privado/email to clipboard. Will clear in 45 seconds.

Vamos a inicializar un directorio dentro de nuestro almacén al que tendrán acceso tanto el departamento de contabilidad como el de auditoría con sus respectivas claves:

pass init -p contabilidad/publico contabilidad auditoria

mkdir: se ha creado el directorio '/home/user/.password-store/contabilidad/publico'
Password store initialized for contabilidad, auditoria (contabilidad/publico)
[master 48f6c9e] Set GPG id to contabilidad, auditoria (contabilidad/publico).
 1 file changed, 2 insertions(+)
 create mode 100644 contabilidad/publico/.gpg-id

Generamos una nueva clave para la aplicación de facturación dentro de ese directorio:

pass generate -n contabilidad/publico/facturacion

[master 518614c] Add generated password for contabilidad/publico/facturacion.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 contabilidad/publico/facturacion.gpg
The generated password for contabilidad/publico/facturacion is:
jvAY6kjsvpSuzfgJiXHQvj12F

pass contabilidad

contabilidad
├── privado
│   └── email
└── publico
    └── facturacion

Intentamos copiarla al portapapeles.

pass -c contabilidad/publico/facturacion

En nuestro caso, como en el mismo equipo constan tanto las claves de contabilidad como las de auditoría, nos pedirá en primer lugar la contraseña de una de ellas:

y si cancelamos nos preguntará la clave del departamento de auditoría:

Copied contabilidad/publico/facturacion to clipboard. Will clear in 45 seconds.

Cualquiera de las dos claves privadas habría servido para consultar la contraseña de facturación.

Ahora veamos qué ocurre cuando copiamos una clave de un directorio asociado a una clave privada, como ocurre con wordpress/tienda/config, que estaba asociada al usuario principal y por lo tanto no era accesible por las claves de auditoría y contabilidad, a otro con una clave distinta, como es contabilidad/publico:

pass find contabilidad wordpress/tienda

Search Terms: contabilidad,wordpress/tienda
├── contabilidad
│   ├── privado
│   │   └── email
|   └── publico
│       └── facturacion
└── wordpress
    └── tienda
        └── config

pass mv wordpress/tienda contabilidad/publico

pass mv -f wordpress/tienda contabilidad/publico/
/home/user/.password-store/wordpress/tienda
renamed '/home/user/.password-store/wordpress/tienda' -> '/home/user/.password-store/contabilidad/publico/tienda'
contabilidad/publico/tienda/config: reencrypting to 71AC1CC8EF0578B4 B9E9C8615602D819
[master 206ff99] Rename wordpress/tienda to contabilidad/publico/.
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 contabilidad/publico/tienda/config.gpg
 delete mode 100644 wordpress/tienda/config.gpg

Vemos en el mensaje que la clave ha sido reencriptada (reencrypting to 71AC1CC8EF0578B4 B9E9C8615602D819).

La estructura de claves ha quedado así:

pass find contabilidad wordpress/

Search Terms: contabilidad,wordpress/
├── contabilidad
│   ├── privado
│   │   └── email
│   └── publico
│       ├── facturacion
│       └── tienda
│           └── config
└── wordpress
    └── blog
        └── config

Tratamos de acceder a la clave de la tienda:

pass -c contabilidad/publico/tienda/config

Copied contabilidad/publico/tienda/config to clipboard. Will clear in 45 seconds.

Vemos que hay acceso a ella simplemente porque tenemos cacheada una de las dos claves. Si hubiera pasado un tiempo y ya no estuviera en caché, nos habría pedido la clave de auditoría o contabilidad.

Puede que queramos que ciertas contraseñas no queden en el historial de comandos ejecutados. También puede que esos comandos formen parte de un script que va a estar en un repositorio Git público y no queremos que esté expuesto el usuario ni la contraseña.

Un ejemplo de ello puede ser una llamada a una API que requiere usuario y contraseña:

curl -u admin:clave-secret -X GET http://localhost:9200/_cluster/health

Una posible solución a este caso es utilizar variables de entorno o bien utilizar directamente una llamada al comando pass.

Primero almacenamos el usuario y la clave:

pass insert api/elastic/user

mkdir: se ha creado el directorio '/home/user/.password-store/api'
mkdir: se ha creado el directorio '/home/user/.password-store/api/elastic'
Enter password for api/elastic/user: 
Retype password for api/elastic/user: 
[master 413ac44] Add given password for api/elastic/user to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/elastic/user.gpg

pass insert api/elastic/password

Enter password for api/elastic/password: 
Retype password for api/elastic/password: 
[master becd064] Add given password for api/elastic/password to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/elastic/password.gpg

Ahora podemos utilizar el comando pass correspondiente encerrado entre $() para sustituir el usuario y contraseña:

curl -u $(pass api/elastic/user):$(pass api/elastic/password) -X GET http://localhost:9200/_cluster/health

Como se ha especificado en el apartado de inicialización de una almacén de claves, es posible inicializar un almacén de claves como repositorio git:

pass git init

Esto hace que cualquier operación sobre el almacén quede registrada en un commit:

pass generate -f -n api/geo/developer2

pass git log

commit 56a1ff865436d81bfb5e9b9cb8c280c8339b0132 (HEAD -> master)
Author: dvdcr <dvdcr@dvdcr.com>
Date:   Sat Mar 12 06:41:19 2022 +0100

    Add generated password for api/geo/developer2.

commit 682642ef6a5e932e1018a1290df4dbdd31b2115b
Author: dvdcr <dvdcr@dvdcr.com>
Date:   Sat Mar 12 06:40:10 2022 +0100

    Add current contents of password store.

Podemos vincular un repositorio remoto:

pass git remote add origin https://gitlab.com/dvdcr/pass-store

Realizamos una operación adicional:

pass generate -n -f api/geo/developer3

1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 api/geo/developer3.gpg
The generated password for api/geo/developer3 is:
5jzrsabiM7YanVZp4iIu9pLJO

Vemos que aparece la última operación en el historial local:

pass git log

commit 3b2c2dbc090787b4b01379ad3fec680617cb59b7 (HEAD -> master)
Author: dvdcr <dvdcr@dvdcr.com>
Date:   Sat Mar 12 06:45:58 2022 +0100

    Add generated password for api/geo/developer3.

commit 56a1ff865436d81bfb5e9b9cb8c280c8339b0132
Author: dvdcr <dvdcr@dvdcr.com>
Date:   Sat Mar 12 06:41:19 2022 +0100

    Add generated password for api/geo/developer2.

commit 682642ef6a5e932e1018a1290df4dbdd31b2115b
Author: dvdcr <dvdcr@dvdcr.com>
Date:   Sat Mar 12 06:40:10 2022 +0100

    Add current contents of password store.

Pero además podemos subir los cambios al repositorio remoto y tener un backup de una forma rápida y sencilla (siempre que confiemos en el repositorio remoto). Podremos utilizar cualquier comando de git, en este caso un push. Como acabamos de vincular el repositorio y no existe la rama en el repositorio remoto, tendremos que utilizar el parámetro -u, pero las siguientes veces no será necesario:

pass git push -u --all

Enumerando objetos: 40, listo.
Contando objetos: 100% (40/40), listo.
Compresión delta usando hasta 4 hilos
Comprimiendo objetos: 100% (29/29), listo.
Escribiendo objetos: 100% (40/40), 10.54 KiB | 1.32 MiB/s, listo.
Total 40 (delta 4), reusados 0 (delta 0), pack-reusados 0
To https://gitlab.com/dvdcr/pass-store
 * [new branch]      master -> master
Rama 'master' configurada para hacer seguimiento a la rama remota 'master' de 'origin'.

Podemos comprobar a través de la web del repositorio que se ha subido el contenido del directorio que contiene las claves:

El proceso de exportación del almacén de claves para su utilización en otro equipo es sencillo.

Por un lado está el contenido del almacén. Basta con copiarnos todo el contenido de ~/.password-store (o la ruta personalizada si no utilizamos la ruta por defecto) al otro equipo en esa misma ruta. La forma de copiarla es indiferente. Podemos copiar directamente con scp si tenemos acceso por ssh a la máquina destino o bien utilizar un pendrive o recurso compartido intermedio.

Ejemplo de copia del almacén con scp:

scp -r ~/.password-store/ usuario@192.168.1.10:/home/user/

Si en ordenador destino intentamos obtener una de las contraseñas nos informará de que no tenemos una clave de descifrado apta para este almacén:

pass -c api/elastic/password

gpg: descifrado fallido: No tenemos la clave secreta 

Para poder acceder al almacén debemos disponer de la clave o claves gpg en el equipo destino. Para ello comprobamos en el equipo origen la lista de claves:

gpg --list-keys

home/dvdc/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096 2022-03-05 [SC] [caduca: 2023-03-05]
      8DC10C2043C49D2A184B6083B441F579E8FD4B35
uid        [  absoluta ] Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>
sub   rsa4096 2022-03-05 [E] [caduca: 2023-03-05]

pub   rsa3072 2022-03-12 [SC]
      481F470ACD42A060A43823EADF8598AD17670555
uid        [  absoluta ] Departamento contabilidad (contabilidad) <contabilidad@dvdcr.com>
sub   rsa3072 2022-03-12 [E]

pub   rsa3072 2022-03-12 [SC]
      8B84A215584C363F0DF905622E3766B165193EFD
uid        [  absoluta ] Departamento Auditoría (auditoria) <auditoria@dvdcr.com>
sub   rsa3072 2022-03-12 [E]

Hacemos la exportación de la clave privada y pública de cada usuario, utilizando como identificador el correo o hash. Nos pedirá la contraseña de cada una de las claves privadas:

ID_KEY=tutorial.pass@dvdcr.com
gpg --output tutorial_public.gpg --armor --export $ID_KEY
gpg --output tutorial_private.gpg --armor --export-secret-key $ID_KEY
ID_KEY=contabilidad@dvdcr.com
gpg --output contabilidad_public.gpg --armor --export $ID_KEY
gpg --output contabilidad_private.gpg --armor --export-secret-key $ID_KEY
ID_KEY=auditoria@dvdcr.com
gpg --output auditoria_public.gpg --armor --export $ID_KEY
gpg --output auditoria_private.gpg --armor --export-secret-key $ID_KEY

El resultado es el siguiente:

ls -l
total 36
-rw-------. 1 dvdc 5229 mar 12 07:08 auditoria_private.gpg
-rw-rw-r--. 1 dvdc 2472 mar 12 07:08 auditoria_public.gpg
-rw-------. 1 dvdc 5237 mar 12 07:08 contabilidad_private.gpg
-rw-rw-r--. 1 dvdc 2480 mar 12 07:08 contabilidad_public.gpg
-rw-------. 1 dvdc 6817 mar 12 07:08 tutorial_private.gpg
-rw-rw-r--. 1 dvdc 3195 mar 12 07:08 tutorial_public.gpg

Copiamos al ordenador destino las claves por cualquiera de los métodos conocidos. Ejemplo de copia con scp:

ssh usuario@192.168.1.10 mkdir /home/user/gpg-keys
scp *.gpg usuario@192.168.1.10:/home/user/gpg-keys/

y las importamos en el ordenador destino con el comando gpg --import:

gpg --import *_public.gpg

gpg: /home/alumno/.gnupg/trustdb.gpg: se ha creado base de datos de confianza
gpg: clave 2E3766B165193EFD: clave pública "Departamento Auditoría (auditoria) <auditoria@dvdcr.com>" importada
gpg: clave DF8598AD17670555: clave pública "Departamento contabilidad (contabilidad) <contabilidad@dvdcr.com>" importada
gpg: clave B441F579E8FD4B35: clave pública "Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>" importada
gpg: Cantidad total procesada: 3
gpg:               importadas: 3

gpg --allow-secret-key-import --import *_private.gpg

Nos pedirá la contraseña para cada una de las claves privadas en un diálogo que será en modo gráfico o texto dependiendo del equipo destino. Aquí un ejemplo de un diálogo en modo texto:

gpg --allow-secret-key-import --import *_private.gpg

gpg: clave 2E3766B165193EFD: "Departamento Auditoría (auditoria) <auditoria@dvdcr.com>" sin cambios
gpg: clave 2E3766B165193EFD: clave secreta importada
gpg: clave DF8598AD17670555: "Departamento contabilidad (contabilidad) <contabilidad@dvdcr.com>" sin cambios
gpg: clave DF8598AD17670555: clave secreta importada
gpg: clave B441F579E8FD4B35: "Tutorial Pass (Usuario principal de Pass) <tutorial.pass@dvdcr.com>" sin cambios
gpg: clave B441F579E8FD4B35: clave secreta importada
gpg: Cantidad total procesada: 3
gpg:              sin cambios: 3
gpg:       claves secretas leídas: 3
gpg:   claves secretas importadas: 3
gpg:  claves secretas sin cambios: 1

Después de la importación de las claves será posible acceder a las contraseñas.

pass admite extensiones para soportar una mayor variedad de casos de uso. Las extensiones que se instalan en la ruta /usr/lib/password-store/extensions están siempre habilitadas. Las extensiones instaladas en ~/.password-store/.extensions/ estáh habilitadas si la variable de entorno PASSWORD_STORE_ENABLE_EXTENSIONS tiene valor true.

Las extensiones son realizadas por la comunidad. Puede consultarse una lista de ellas en https://www.passwordstore.org/#extensions.

Vamos a probar una extensión para importar claves desde múltiples gestores de contraseñas, concretamente la extensión pass-import, que podemos encontrar en https://github.com/roddhjav/pass-import/.

git clone https://github.com/roddhjav/pass-import/
cd pass-import
sudo python3 setup.py install
sudo pip3 install pykeepass

Una vez instalada la exensión podemos instalar por ejemplo las contraseñas almacenadas en un almacén de Keepass. Dependiendo del tipo de almacén origen puede que requiera instalar algún componente más, pero si es necesario nos informará de ello al intentar utilizarla.

El uso general de la herramienta utiliza la sintaxis:

pass import ruta/al/almacen

Si utilizamos esa sintaxis, la extensión intentará detectar el formato del almacén del que queremos importar las contraseñas. Si no lo detecta o hay ambigüedad y queremos especificarlo, podemos utilizar la sintaxis:

pass import gestor_contraseñas ruta/al/almacen

Ejemplo de importación de un almacén de Keepassxc:

pass import keepassxc almacen.kdbx

Password for almacen.kdbx: 
 (*) Importing passwords from keepassxc to pass
  .  Passwords imported from: almacen.kdbx
  .  Passwords exported to: /home/user/.password-store
  .  Number of password imported: 4
  .  Passwords imported:
	compras/aliexpress
	compras/amazon
	correo/gmail
	correo/outlook

Al instalar la expensión se incluye también el comando pimport que permite exportar un almacén de un tipo determinado a otro que no sea necesariamente pass. La sintaxis en este caso es:

pimport gestor_contraseñas_destino gestor_contraseñas_origen ruta/a/contraseñas/origen \
--out ruta/a/contraseñas/destino

Además del comando pass existen varias aplicaciones cliente compatibles con los almacenes de claves de pass que han sido creadas por otros programadores para diferentes sistemas y/o herramientas. Existen plugins de navegador para Chrome y Firefox, aplicaciones móviles para Android e iOS, paquetes para emacs, aplicaciones de escritorio para Windows, Linux y Mac, etc.

Podemos encontrar una lista de aplicaciones en https://www.passwordstore.org/#other

Existen herramientas creadas por usuarios de pass que permiten importar datos desde otros gestores de contraseñas como One Password, Keepass, Lastpass, Kwallet o Firefox, entre otros.

La lista completa de herramientas y el enlace a su descarga está en está en https://www.passwordstore.org#migration.

Como ejemplo de importación de datos procedentes de Keepass a partir de un archivo de exportación CSV podemos descargar el script de importación correspondiente:

curl https://git.zx2c4.com/password-store/plain/contrib/importers/keepass2csv2pass.py \
-o ~/bin/keepass2csv2pass.py

chmod +x ~/bin/keepass2csv2pass.py

Exportamos un almacén de Keepass a formato CSV con el menú Base de datos > Exportar > Archivo CSV...

y lo importamos con el script:

./keepass2csv2pass.py archivo.csv

Mediante la definición de variables de entorno, se pueden configurar ciertos aspectos del comportamiento de pass.

• https://www.passwordstore.org/
• https://git.zx2c4.com/password-store/about/
• https://github.com/roddhjav/pass-import#readme

Los tipos de letra que vienen de serie en un entorno de escritorio GNU/Linux son bastante limitados, pero podemos agregar nuevos tipos de letra a nuestro sistema para que sean utilizadas por las aplicaciones ofimáticas o de diseño.

Pueden agregarse para un único usuario en concreto o para que estén disponibles para todos los usuarios del sistema.

Un primer método es instalar paquetes de fuentes disponibles en los repositorios de nuestra distribución. Debemos conocer de antemano el nombre del paquete que proporciona las fuentes o hacer alguna búsqueda en nuestros repositorios y luego simplemente instalarlo con el gestor de paquetes de nuestra distribución:

sudo dnf install -y libreoffice-opensymbol-fonts

o

sudo apt install -y libreoffice-opensymbol-fonts

Un segundo método es agregar archivos TTF u OTF que hayamos descargado de Dafont o cualquier sitio web similar.

Para ello debemos crear un nuevo directorio dentro de /usr/share/fonts/ con el nombre de la familia de la fuente, por ejemplo:

sudo mkdir /usr/share/fonts/bauhaus

Después hay que copiar los archivos de las fuentes (TTF u OTF) al nuevo directorio:

sudo cp Bauhaus*.ttf /usr/share/fonts/bauhaus/

Por último hay que actualizar la caché de fuentes para que estén disponibles sin necesidad de reiniciar el equipo:

sudo fc-cache -v

• ttf-aenigma
• ttf-anonymous-pro
• ttf-bitstream-vera
• ttf-sjfonts

No siempre es buena idea agregar fuentes para todo el sistema, sobre todo si hay muchos usuarios y cada uno agrega un importante número de fuentes que realmente el resto de usuarios no utiliza. También puede ocurrir que no se tengan los priviliegios de administración sobre el sistema. Sea cual sea el motivo es posible agregar las fuentes sólo para un usuario. Para ello, el primer paso es crear un nuevo directorio dentro de ~/.local/share/fonts/ o ~/.fonts (puede que el propio directorio fonts no exista y haya que crearlo también) con el nombre de la familia, por ejemplo:

mkdir -p ~/.local/share/fonts/"retro computer"

A continuación copiamos los archivos de las fuentes (TTF u OTF) al nuevo directorio:

cp Retro*.otf ~/.local/share/fonts/"retro computer"/

y por último hay que actualizar la caché de fuentes para que estén disponibles para las aplicaciones sin necesidad de reiniciar el equipo:

fc-cache -v

https://docs.fedoraproject.org/en-US/quick-docs/fonts/#unpackaged

El Tuya ZM-35ZH-Q es un sensor de movimiento que se conecta a través de protocolo Zigbee. Se alimenta con una pila de botón de 3V CR2450 que promete una duración de más de un año. Por sus reducidas dimensiones (33mm de diámetro por 30mm de altura) se puede colocar en cualquier sitio sin que resulte muy llamativo.

Está diseñado para funcionar con la aplicación Tuya Smart Life, pero veremos cómo configurarlo para su uso con zigbee2mqtt, lo que abre el paso para su control mediante scripts o programas propios y a la integración plataformas como Home Assistant, pero sin requerir de servicios externos.

Debemos disponer de los siguientes componentes ya instalados y configurados:

• Broker MQTT. En este artículo se explica cómo instalar mosquitto en una Raspberry Pi.
• Zigbee2mqtt. La instalación y configuración básica se describen en este artículo

Pulsamos durante cinco segundos el botón de reset, hasta que comience a parpadear un led rojo. El botón de reset está dentro de un pequeño orificio para evitar que se active por accidente. Hay que pulsarlo con un pin similar a los que se utilizan para abrir la bandeja de la tarjeta SIM de los teléfonos, incluído en la caja del dispositivo. Una vez activada la sincronización en el log de zigbee2mqtt aparecerá:

info  2022-02-20 21:57:56: Device '0xa4c138b9576d55bf' joined
info  2022-02-20 21:57:56: MQTT publish: topic 'zigbee2mqtt/bridge/event', 
      payload '{"data":{"friendly_name":"0xa4c138b9576d55bf","ieee_address":"0xa4c138b9576d55bf"},
      "type":"device_joined"}'
info  2022-02-20 21:57:56: Starting interview of '0xa4c138b9576d55bf'
info  2022-02-20 21:57:56: MQTT publish: topic 'zigbee2mqtt/bridge/event', 
      payload '{"data":{"friendly_name":"0xa4c138b9576d55bf","ieee_address":"0xa4c138b9576d55bf",
      "status":"started"},"type":"device_interview"}'
info  2022-02-20 21:57:56: MQTT publish: topic 'zigbee2mqtt/bridge/event', 
      payload '{"data":{"friendly_name":"0xa4c138b9576d55bf","ieee_address":"0xa4c138b9576d55bf"},
      "type":"device_announce"}'

Si en el log aparece el mensaje device_joined será indicativo de que se ha emparejado correctamente.

Para dar un nombre más amigable al dispositivo, paramos el servicio zigbee2mqtt:

sudo systemctl stop zigbee2mqtt

Editamos el archivo de configuración de zigbee2mqtt, que en este caso está en /opt/zigbee2mqtt/data/configuration.yaml.

Al final del archivo, en la sección devices nos aparecerá una entrada del tipo:

  '0xa4c138b9576d55bf':
    friendly_name: '0xa4c138b9576d55bf'

Cambiamos el valor del atributo friendly_name por otro que nos resulte más fácil de reconocer:

  '0xa4c138b9576d55bf':
   friendly_name: 'movimiento'

y arrancamos el servicio de nuevo para que se aplique el nuevo nombre:

sudo systemctl start zigbee2mqtt

Ahora debe publicar los eventos en el topic zigbee2mqtt/movimiento.

Se trata de un dispositivo de bajo consumo, por lo que el sensor no está accesible la mayoría del tiempo, sólo cuando se activa porque se detecta un movimiento.

Las peticiones de lectura de valores o escritura para configurar parámetros no se procesan inmediatamente sino que son encoladas y se envían en la siguiente ocasión en la que está disponible.

Para leer valores, nos suscribimos con mosquitto_sub al topic zigbee2mqtt/movimiento en nuestro broker MQTT. Si lo hacemos desde dentro de la propia Raspberry pi (o el servidor donde se esté ejecutando mosquitto) utilizaremos el parámetro -h localhost. Si lo hacemos desde otro equipo, especificaremos la dirección IP del la máquina donde se ejecute mosquitto:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/movimiento"

Cuando detecta un movimiento, recibimos el valor true en el parámetro occupancy.

{"battery":null,"battery_low":false,"linkquality":87,"occupancy":true,"tamper":false}

Cuando se deja de detectar, se envía el valor false en ese mismo parámetro:

{"battery":null,"battery_low":false,"linkquality":84,"occupancy":false,"tamper":false}

Además del parámetro occupancy que es el que nos indica si realmente se detecta movimiento, el mensaje JSON muestra otros parámetros:

• battery_low. Indica si la batería está a punto de acabarse, en cuyo caso contiene el valor true. Si la batería tiene un nivel aceptable contiene el valor false.
• battery. Número que indica la batería restante en porcentaje. Según la documentación, debe mostrar un valor numérico entre 0 y 100, pero en las pruebas que se han realizado, siempre ha mostrado el valor null.
• tamper. Indica si el dispositivo es manipulado. Algunos detectores incluyen un par de terminales llamados tamper, como sistema anti-sabotaje. Cuando alguien trata de abrir el dispositivo, la apertura se detecta y se envía una señal para avisar de ello. En este caso, se envía el valor true en este parámetro si el dispositivo es manipulado o false en caso contrario.
• linkquality. Fuerza de la señal. El valor mínimo es 0 y el máximo 255. La unidad de este valor es lqi (Link Quality Indicator).

Para configurar su comportamiento, este dispositivo admite algunos parámetros que se describen a continuación. Como se ha indicado anteriormente, al tratarse de un dispositivo de bajo consumo, no está permanentemente disponible. Sólo lo está cuando se detecta movimiento ({"occupancy": true}).

Ajuste de sensibilidad al movimiento. Admite tres valores: low, medium y high. Para modificar la configuración hay que publicar un mensaje en el topic zigbee2mqtt/FRIENDLY_NAME/setcon el payload {"sensitivity": <valor>} con uno de esos tres valores. Para que se aplique la configuración lo antes posible, lo mejor es generar movimiento delante del sensor para que se active. Ejemplo para poner la sensibilidad al mínimo:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/movimiento/set" \
-m '{"sensitivity": "low"}'

Tiempo de espera tras una activación para volver al modo occupancy=false. Representa una cifra en segundos y admite sólo los valores 30, 60 y 120. En las pruebas realizadas se ha visto que es un valor aproximado, no exacto.

Para modificar este valor hay que publicar un mensaje en el topic zigbee2mqtt/FRIENDLY_NAME/set con el payload {"keep_time": <valor>}. Si se indica un valor numérico que no sea uno de los 3 especificados, no realiza ningún cambio.

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/movimiento/set" \
-m '{"keep_time": "60"}'

Disponiendo de un gateway Zigbee y un broker MQTT se puede emparejar con el gateway un sensor de movimiento con conectividad Zigbee, en este caso el Tuya ZM-35ZH-Q. Se ha visto como configurarlo y consultar su estado a través de la publicación y suscripción a topics MQTT. Esto permite detectar la entrada de una persona en un área y realizar acciones en consecuencia, como disparar una alarma, un aviso o encender una luz. En combinación con Home Assistant permitiría definir automatizaciones de forma sencilla.

• https://www.zigbee2mqtt.io/devices/ZM-35H-Q.html

La gestión de recursos en kubernetes se realiza principalmente a través de definiciones en lenguaje YAML. Para mejorar la gestión y reutilizar definiciones, algunas de las implementaciones específicas de kubernetes como OpenShift permiten el uso de plantillas o templates, mientras que en otros casos se utilizan herramientas de terceros que permiten definir plantillas, procesarlas y generar recursos en base a parámetros.

kustomize es una herramienta para conseguir el mismo objetivo con un enfoque ligeramente diferente. Permite personalizar una definición inicial que sirve como base, especificando parches concretos por entorno, proyecto o grupo de recursos. Las personalizaciones o parches incluyen sólo aquellas partes que difieren de la definición base. A diferencia de una plantilla, el documento de partida es una definición real y perfectamente utilizable de manera individual, no un documento con una sintaxis de marcado que requiere un procesado previo que reemplace las variables por valores reales para su utilización.

Contenido

Kustomize viene incluido en el cliente de kubernetes kubectl desde la versión 1.14. Utilizamos kustomize con este cliente con el comando kubectl apply -k <archivo.yaml> en lugar de utilizar el habitual parámetro -f que se utiliza al aplicar las definiciones de un archivo. También existe la posibilidad de utilizarlo como una herramienta standalone. Es una herramienta creada en Go por lo que consta de un sólo ejecutable que depende del sistema operativo. Basta con descargar el archivo comprimido de la página de versiones, descomprimirlo y copiarlo a algún directorio que se encuentre dentro del path en nuestro sistema operativo.

También se puede instalar con la instrucción:

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" \
 | bash

que detectará el sistema operativo y se descargará el binario que corresponda. Este sistema no funciona para arquitectura ARM.

Para entender el funcionamiento de kustomize vamos a crear una aplicación de ejemplo. Nos basaremos en el cluster de microk8s, llamado ocm-hub que configuramos en el artículo Instalar Open Cluster Management en un equipo personal

Arrancamos la máquina virtual y el cluster:

multipass start ocm-hub
multipass exec ocm-hub microk8s start

Partimos de un namespace llamado portales donde vamos a crear nuestro proyecto:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config create namespace portales

La definición inicial de la aplicación será para un entorno de desarrollo y tendrá los siguientes elementos:

• Un config map llamado contenido con el código de la página index.html.
• Un deployment llamado portal que crea un pod de nginx y monta el config map como archivo index.html en el directorio de publicación de ngnix.
• Un service portal para exponer los pods de forma que sean accesibles desde fuera del cluster.

Vamos a crear un directorio llamado base donde van a existir un archivo por cada uno de estos elementos:

webapp
└── base
    ├── configmap.yaml
    ├── deployment.yaml
    └── service.yaml

Podemos crear todos los objetos necesarios para esta aplicación situándonos en el directorio donde están los archivos YAML de definición y ejecutando:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config apply -f .

configmap/contenido created
deployment.apps/portal created
service/portal created

Comprobamos que se han creado el pod y el servicio:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config get pods -n portales

NAME                     READY   STATUS    RESTARTS   AGE
portal-87bdbf6c8-8m7cf   1/1     Running   0          5m5s

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config get service -n portales

NAME     TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
portal   NodePort   10.152.183.147   <none>        8080:30001/TCP   5m17s

Podemos comprobar que funciona haciendo una petición al puerto 30001 de nuestro cluster. Para ello obtenemos la dirección IP de nuestra máquina virtual:

multipass info ocm-hub | grep IPv4

IPv4:           10.89.130.31

e introducimos la dirección en el navegador o probamos con curl:

curl 10.89.130.31:30001

<html>
  <style>
    body {
      background-color: #fff;
    }
  </style>
  <body>
     <h1>Portal corporativo</h1>
     <h2>Entorno: Desarrollo</h2>
  </body>
</html>

Ahora supongamos que esta aplicación corresponde a un entorno de desarrollo, pero queremos ahora desplegarla además en un entorno de preproducción. La configuración en lo esencial será la misma, pero habrá algunos parámetros diferentes, como las etiquetas, el número de pods y los límites de recursos por pod. Podríamos simplemente repetir todos los archivos YAML y modificarlos en aquellos puntos que difieren, pero aquí es donde interviene kustomize para hacer esto un poco más sencillo.

Kustomize permite partir de una configuración válida, como en este caso la de desarrollo, y definir varias configuraciones alternativas con cambios a partir de configuración base. Esto permitiría por ejemplo partir de un repositorio de git sobre el que no tengamos control, personalizando las partes que difieren y adaptar más fácilmente los cambios que surjan en el repositorio original.

Vamos a seguir una de las estrategias posibles que es especificar sólo los atributos del archivo YAML que difieren y aquellos que conforman la jerarquía completa de la que dependen hasta la raíz para que el resultado sea un archivo correcto.

Primero vamos a eliminar todos los objetos que hemos creado:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config delete -f .

Vamos a revisar la configuración base, que estará compuesta por los archivos que ya teníamos con alguna leve modificación.

base/configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: contenido
  namespace: portales
data:
  entorno: Base
  index: >
    <html>
      <style>
        body {
          background-color: #fff;
        }
      </style>
      <body>
         <h1>Portal corporativo</h1>
         <h2>Entorno base</h2>
      </body>
    </html>    

base/deployment.yaml

----
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: portales
  name: portal
  labels:
    app: portal
spec:
  replicas: 0
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.5
        ports:
        - containerPort: 8080
          protocol: TCP
        volumeMounts:
          - name: paginas
            mountPath: /usr/share/nginx/html
        resources:
          requests:
            cpu: 100m
            memory: "128M"
          limits:
            cpu: 100m
            memory: "256M"
        env:
        - name: LOG_LEVEL
          value: "DEBUG"
        - name: ENTORNO
          valueFrom:
            configMapKeyRef:
              name: contenido
              key: entorno
      volumes:
      - name: paginas
        configMap:
          name: contenido
          items:
          - key: index
            path: index.html

base/service.yaml

---
apiVersion: v1
kind: Service
metadata:
  namespace: portales
  name: portal
  labels:
    app: portal
spec:
  type: NodePort
  ports:
  - name: acceso-externo
    nodePort: 30000
    port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    app: portal

Aparte de los archivos de definición propiamente dichos tendremos que añadir un archivo de configuración para kustomize. Tiene que estar en el directorio donde tenemos nuestros archivos YAML y su nombre debe ser kustomization.yaml:

base/kustomization.yaml

---
resources:
- configmap.yaml
- deployment.yaml
- service.yaml

Este archivo contiene la lista de los archivos que conforman la configuración base, lo que se indica bajo la etiqueta resources.

Ahora crearemos el directorio overlays donde añadiremos las personalizaciones sobre la base para cada uno de los entornos. Comenzamos creando una personalización para el entorno de desarrollo, en un directorio que llamaremos dev:

mkdir -p overlays/dev

Respecto al configmap, tendremos un archivo completo. Difiere en la variable entorno y que en el código html mostrará en un encabezado el texto Entorno desarrollo. Con respecto a este elemento no hay ningún ahorro en código y reutilización que nos aporte kustomization. El contenido principal es el código HTML, que es contenido estático. Si se tratara de otro tipo de archivo que no fuera estático podríamos incluir contenido en base a variables de entorno y no sería necesario repetirlo al completo:

overlays/dev/configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: contenido
  namespace: portales
data:
  entorno: Desarrollo
  index: >
    <html>
      <style>
        body {
          background-color: #fff;
        }
      </style>
      <body>
         <h1>Portal corporativo</h1>
         <h2>Entorno desarrollo</h2>
      </body>
    </html>    

Respecto al deployment, vamos a especificar el número de pods, que será 1 (en la configuración base era 0), para lo que crearemos el archivo overlays/dev/deployment-replicas.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: portales
  name: portal
spec:
  replicas: 1

En este caso sólo incluimos los datos necesarios para la identificación del objeto (metadata.namespace y metadata.name) y el dato concreto que queremos modificar (spec.replicas:1)

También sobre el deployment vamos a modificar las etiquetas asignadas al deployment y a los pods que contiene, para que sean diferentes de las de otros entornos, en este caso las etiquetas van a ser app: portal-dev. El archivo lo llamaremos overlays/dev/deployment-labels.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: portales
  name: portal
  labels:
    app: portal-dev
spec:
  selector:
    matchLabels:
      app: portal-dev
  template:
    metadata:
      labels:
        app: portal-dev

En el service, será necesario modificar las etiquetas de selección de pods para que se adecúen al entorno de desarrollo, etiquetado con app: portal-dev. También habrá que variar el puerto. Estos cambios estarán en el archivo overlays/dev/service.yaml:

---
apiVersion: v1
kind: Service
metadata:
  namespace: portales
  name: portal
spec:
  ports:
  - name: acceso-externo
    nodePort: 30001
    port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    app: portal-dev

A todo lo enterior añadiremos un archivo de configuración para kustomize. Tiene que estar en el directorio donde tenemos nuestros archivos YAML y se llamará kustomization.yaml:

---
nameSuffix:
  -dev
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
- service.yaml
- deployment-labels.yaml
- deployment-replicas.yaml

Este archivo refleja cuáles son los archivos de definición a procesar, indicando cuál es el directorio o directorios que contienen la configuración base (parámetro bases), cuales son los archivos que modificarán esa configuración base (parámetro patchesStrategicMerge) y además que sobre los nombres de los objetos que se creen se aplicará el sufijo -dev (parámetro nameSuffix).

Kustomize soporta diferentes mecanismos de parcheo o personalización de la configuración base, como patchesStrategicMerge y patchesJson6902. El primero de ellos, que es el que estamos utilizando en este ejemplo, es una lista de archivos, cada uno de los cuales debe incluir el nombre de un recurso (Deployment, Pod, Service, etc.) procedente de la base. Lo más recomendable es hacer pequeños parches que hacen un cambio en concreto.

La estructura de archivos y directorios que queda tras la configuración es la siguiente:

webapp
├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    └── dev
        ├── configmap.yaml
        ├── deployment-labels.yaml
        ├── deployment-replicas.yaml
        ├── kustomization.yaml
        └── service.yaml

Volvemos a desplegar nuestra aplicación, pero en este caso especificando el parámetro -k para indicar que se debe utilizar kustomize para procesar los archivos de definición y el directorio donde se encuentran las definiciones. Al utilizar este parámetro kustomize buscará un archivo kustomization.yaml y aplicará las instrucciones ahí definidas. Si nos situamos en el directorio webapp la forma de aplicar la configuración para el entorno de desarrollo sería:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config apply -k overlays/dev

configmap/contenido-dev created
service/portal-dev created
deployment.apps/portal-dev created

Podemos ver que los elementos se han creado con el nombre previsto y el sufijo -dev.

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config get pods,deployments,services -n portales

NAME                             READY   STATUS    RESTARTS   AGE
pod/portal-dev-d6f58dc49-zb47c   1/1     Running   0          27s

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/portal-dev   1/1     1            1           27s

NAME                 TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/portal-dev   NodePort   10.152.183.50   <none>        8080:30001/TCP   27s

y que la web muestra su contenido a través del puerto 30001:

curl 10.89.130.31:30001

<html>
  <style>
    body {
      background-color: #fff;
    }
  </style>
  <body>
     <h1>Portal corporativo</h1>
     <h2>Entorno desarrollo</h2>
  </body>
</html>

Ahora crearemos dentro del directorio overlays un directorio que llamaremos pre para almacenar la personalización para el entorno de preproducción:

mkdir -p overlays/pre

El config map será idéntico salvo por la variable entorno y la descripción del encabezado h2 del código html:

overlays/dev/configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: contenido
  namespace: portales
data:
  entorno: Preproducción
  index: >
    <html>
      <style>
        body {
          background-color: #fff;
        }
      </style>
      <body>
         <h1>Portal corporativo</h1>
         <h2>Entorno preproducción</h2>
      </body>
    </html>    

Respecto al deployment, vamos a especificar el número de pods para el, que será 2, para lo que crearemos el archivo overlays/dev/deployment-replicas.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: portales
  name: portal
spec:
  replicas: 2

Sobre el deployment vamos a modificar las etiquetas asignadas al deployment y a los pods que contiene, en este caso app: portal-pre. El archivo lo llamaremos overlays/dev/deployment-labels.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: portales
  name: portal
  labels:
    app: portal-pre
spec:
  selector:
    matchLabels:
      app: portal-pre
  template:
    metadata:
      labels:
        app: portal-pre

En el service, cambiarán las etiquetas de selección de pods, etiquetados con app: portal-pre. También habrá que variar el puerto. Estos cambios estarán en el archivo overlays/dev/service.yaml:

---
apiVersion: v1
kind: Service
metadata:
  namespace: portales
  name: portal
spec:
  ports:
  - name: acceso-externo
    nodePort: 30002
    port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    app: portal-pre

Por último añadimos el archivo kustomization.yaml:

---
nameSuffix:
  -pre
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
- service.yaml
- deployment-labels.yaml
- deployment-replicas.yaml

La estructura de archivos y directorios que tenemos es la siguiente:

webapp
├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    ├── dev
    │   ├── configmap.yaml
    │   ├── deployment-labels.yaml
    │   ├── deployment-replicas.yaml
    │   ├── kustomization.yaml
    │   └── service.yaml
    └── pre
        ├── configmap.yaml
        ├── deployment-labels.yaml
        ├── deployment-replicas.yaml
        ├── kustomization.yaml
        └── service.yaml

Volvemos a desplegar nuestra aplicación, pero en este lugar indicando tras el parámetro -k la ruta de los archivos del entorno de preproducción:

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config apply -k overlays/pre

configmap/contenido-pre created
service/portal-pre created
deployment.apps/portal-pre created

Podemos ver que los elementos se han creado con el nombre previsto y el sufijo -pre.

kubectl --kubeconfig=$HOME/.kube/ocm-hub.config get pods,deployments,services -n portales

NAME                             READY   STATUS    RESTARTS   AGE
pod/portal-dev-d6f58dc49-zb47c   1/1     Running   0          21m
pod/portal-pre-5756bdc5f-j8xsx   1/1     Running   0          26s
pod/portal-pre-5756bdc5f-d8cjv   1/1     Running   0          26s

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/portal-dev   1/1     1            1           21m
deployment.apps/portal-pre   2/2     2            2           26s

NAME                 TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/portal-dev   NodePort   10.152.183.50   <none>        8080:30001/TCP   21m
service/portal-pre   NodePort   10.152.183.47   <none>        8080:30002/TCP   26s

En este caso vemos que se han desplegado dos pods para el entorno de preproducción. También podemos ver que la web muestra su contenido, en este caso a través del puerto 30002:

curl 10.89.130.31:30002

<html>
  <style>
    body {
      background-color: #fff;
    }
  </style>
  <body>
     <h1>Portal corporativo</h1>
     <h2>Entorno preproducción</h2>
  </body>
</html>

Hemos visto la definición de recursos para desplegar en kubernetes una aplicación básica de la forma habitual.

A continuación hemos adaptado la estructura de este despliegue para crear una configuración base apta para kustomize.

Se ha definido un parche con kustomize sobre la configuración base para el despliegue de la aplicación en un supuesto entorno de desarrollo.

Se ha definido un segundo parche con kustomize para el despliegue en un supuesto entorno de producción.

Este esquema sería replicable para otros entornos y variantes de configuración, que podríamos desplegar de forma individual o en conjunto de forma simultánea.

Los archivos de recursos utilizados en este artículo se encuentran en https://gitlab.com/dvdcr/kustomize-basic-sample

• https://kustomize.io/
• https://github.com/kubernetes-sigs/kustomize/
• https://learnk8s.io/templating-yaml-with-code
• https://kubectl.docs.kubernetes.io/guides/introduction/kustomize/
• https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md
• https://gitlab.com/dvdcr/kustomize-basic-sample

Debemos disponer de los siguientes componentes ya instalados y configurados:

• Broker MQTT. En este artículo se explica cómo instalar mosquitto en una Raspberry pi.
• Zigbee2mqtt. La instalación y configuración básica se describen en este artículo

Para emparejar el dispositivo con nuestra pasarela, debemos pulsar el botón de encendido durante 5 segundos. El led del botón se pondrá a parpadear para indicar que está en el modo de emparejamiento. Cuando deja de parpadear puede indicarnos que ha finalizado el emparejamiento o que no ha sido capaz de realizarlo. Según la documentación, se indica que si al dejar de parpadear el led queda en color rojo, significa que el emparejamiento se ha realizado correctamente, y si queda en color azul, significa que el emparejamiento no se ha realizado correctamente. En mi caso el led no se encendía tras el emparejamiento correcto. La forma más clara de verificar el emparejamiento es revisando los logs de zigbee2mqtt. Con la configuración del artículo al que hemos hecho referencia, el log principal es el archivo /opt/zigbee2mqtt/data/logs/zigbee2mqtt.log. Si entramos a nuestra Raspberry pi o servidor que haga de pasarela y consultamos los logs:

tail -f /opt/zigbee2mqtt/data/logs/zigbee2mqtt.log

Veremos en este caso que el emparejamiento ha tenido éxito por el mensaje device has successfully been paired, además de otra información del dispositivo:

Zigbee2MQTT:info  2022-01-20 22:21:39: Device '0xa4c138c495df5e80' joined
Zigbee2MQTT:info  2022-01-20 22:21:39: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0xa4c138c495df5e80","ieee_address":"0xa4c138c495df5e80"},"type":"device_joined"}'
Zigbee2MQTT:info  2022-01-20 22:21:39: Starting interview of '0xa4c138c495df5e80'
Zigbee2MQTT:info  2022-01-20 22:21:39: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0xa4c138c495df5e80","ieee_address":"0xa4c138c495df5e80","status":"started"},"type":"device_interview"}'
Zigbee2MQTT:info  2022-01-20 22:21:39: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0xa4c138c495df5e80","ieee_address":"0xa4c138c495df5e80"},"type":"device_announce"}'
Zigbee2MQTT:info  2022-01-20 22:21:40: Successfully interviewed '0xa4c138c495df5e80', device has successfully been paired
Zigbee2MQTT:info  2022-01-20 22:21:40: Device '0xa4c138c495df5e80' is supported, identified as: TuYa Smart plug (with power monitoring by polling) (TS011F_plug_3)
Zigbee2MQTT:info  2022-01-20 22:21:40: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Smart plug (with power monitoring by polling)","exposes":[{"features":[{"access":7,"description":"On/off state of the switch","name":"state","property":"state","type":"binary","value_off":"OFF","value_on":"ON","value_toggle":"TOGGLE"}],"type":"switch"},{"access":1,"description":"Instantaneous measured power","name":"power","property":"power","type":"numeric","unit":"W"},{"access":1,"description":"Instantaneous measured electrical current","name":"current","property":"current","type":"numeric","unit":"A"},{"access":1,"description":"Measured electrical potential value","name":"voltage","property":"voltage","type":"numeric","unit":"V"},{"access":1,"description":"Sum of consumed energy","name":"energy","property":"energy","type":"numeric","unit":"kWh"},{"access":3,"description":"Recover state after power outage","name":"power_outage_memory","property":"power_outage_memory","type":"enum","values":["on","off","restore"]},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"TS011F_plug_3","options":[{"access":2,"description":"This device does not support reporting electric measurements so it is polled instead. The default poll interval is 60 seconds, set to -1 to disable.","name":"measurement_poll_interval","property":"measurement_poll_interval","type":"numeric","value_min":-1}],"supports_ota":false,"vendor":"TuYa"},"friendly_name":"0xa4c138c495df5e80","ieee_address":"0xa4c138c495df5e80","status":"successful","supported":true},"type":"device_interview"}'
Zigbee2MQTT:info  2022-01-20 22:21:40: Configuring '0xa4c138c495df5e80'
Zigbee2MQTT:info  2022-01-20 22:21:40: Successfully configured '0xa4c138c495df5e80'
Zigbee2MQTT:info  2022-01-20 22:21:44: MQTT publish: topic 'zigbee2mqtt/0xa4c138c495df5e80', payload '{"energy":0,"linkquality":92}'
Zigbee2MQTT:info  2022-01-20 22:21:45: MQTT publish: topic 'zigbee2mqtt/0xa4c138c495df5e80', payload '{"energy":0,"linkquality":89,"state":"OFF"}'

Todos los dispositivos Zigbee tienen un identificador único hexadecimal, que es el nombre que se les asigna por defecto en zigbee2mqtt, pero podemos asignar un friendly_name fácil de recordar, por ejemplo enchufe. Para ello debemos en primer lugar parar el servicio zigbee2mqtt:

sudo systemctl stop zigbee2mqtt

Luego modificamos el archivo configuration.yaml de zigbee2mqtt para especificar el nuevo nombre:

devices:
  '0xa4c138c495df5e80':
    friendly_name: 'enchufe'

y arrancamos el servicio zigbee2mqtt para que haga efecto el cambio:

sudo systemctl start zigbee2mqtt

Ahora podremos hacer pruebas directamente con mensajes MQTT utilizando el topic zigbee2mqtt/enchufe.

La manipulación del enchufe la podemos hacer publicando mensajes en el servidor MQTT en el topic zigbee2mqtt/enchufe/set, incluyendo en el mensaje o payload un texto en formato JSON que tendrá el contenido {"state": "<estado>"}, donde <estado> tendrá diferentes valores según la operación que queramos realizar.

Las llamadas que vemos a continuación se van a realizar desde la propia Raspberry pi donde se está ejecutando zigbee2mqtt y el broker MQTT, de ahí que se utilice localhost en el parámetro -h que indica el nombre o dirección del host MQTT. Si accedemos desde otro equipo tendremos que poner la dirección IP de la máquina donde se esté ejecutando el broker MQTT.

Para encender, el payload deberá ser {"state": "ON"}:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe/set" \
-m '{"state": "ON"}'

Para apagar, el payload deberá ser {"state": "OFF"}:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe/set" \
-m '{"state": "OFF"}'

Para cambiar al estado contrario, el payload deberá ser {"state": "TOGGLE"}:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe/set" \
-m '{"state": "TOGGLE"}'

Este dispositivo admite algunas opciones de configuración que permiten por ejemplo, calibrar las mediciones o indicar cada cuánto tiempo queremos que informe del estado actual. La configuración se realiza a través de las siguientes variables de configuración:

• measurement_poll_interval. Desde el último trimestre de 2021, Tuya ha desactivado el envío automático de la información de potencia, voltaje y corriente. Los dispositivos afectados por esta limitación se detectan como TS011F_plug_3 en lugar de TS011F_plug_1 como ocurría con las versiones previas. Para solucionar esto hay que preguntar (poll) al dispositivo de forma activa para obtener la información. El intervalo entre consultas se puede controlar a través de la variable measurement_poll_intervall. Si no se especifica un valor, no se realiza la consulta de estos valores. Si queremos desactivarla hay que especificar el valor -1.
• power_calibration. Calibra el valor de la potencia, mediante un valor numérico que supone un porcentaje de corrección y que se aplica en la siguiente lectura.
• current_calibration. Calibra el valor de la corriente, mediante un valor numérico que supone un porcentaje de corrección y que se aplica en la siguiente lectura.
• voltage_calibration. Calibra el valor del voltaje, mediante un valor numérico que supone un porcentaje de corrección y que se aplica en la siguiente lectura.

Las opciones se pueden indicar añadiéndolas en el archivo configuration.yaml dentro de la sección devices, en el dispositivo correspondiente, realizando el reinicio del servicio zigbee2mqtt tras el cambio:

devices:
  '0xa4c138c495df5e80':
    friendly_name: enchufe
    measurement_poll_interval: '60'
    power_calibration: 5
    current_calibration: 1
    voltage_calibration: 2

Otra forma de ajustar la configuración del dispositivo es enviar payloads al topic zigbee2mqtt/bridge/request/device/options con el contenido {"id": "<friendly_name>", "options":{"<nombre_opcion>":"<valor>"}}.

Actualización del intervalo de tiempo transcurrido entre medidas a 30 segundos:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/request/device/options" \
-m '{"id": "enchufe", "options":{"measurement_poll_interval":"30"}}' 

Calibración del voltaje para incrementarlo en un 2%:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/request/device/options" \
-m '{"id": "enchufe", "options":{"voltage_calibration":"2"}}' 

Calibración de la corriente para incrementarla en un 1%:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/request/device/options" \
-m '{"id": "enchufe", "options":{"current_calibration":"1"}}' 

Calibración de la potencia para reducirla en un 1%:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/request/device/options" \
-m '{"id": "enchufe", "options":{"power_calibration":"-1"}}' 

Para leer los parámetros actuales de estado y consumo del dispositivo podemos utilizar mosquitto_sub, aunque primero tendremos que publicar inicialmente en el topic zigbee2mqtt/<friendly_name>/state el mensaje {"state":""} (a través de mosquitto_pub):

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe/state" \
-m '{"state": ""}' 

Una vez hecho eso, veremos en los logs mensajes con los valores que devuelve el dispositivo:

tail -f /opt/zigbee2mqtt/data/log/zigbee2mqtt.log 

info  2022-02-14 22:30:30: MQTT publish: topic 'zigbee2mqtt/enchufe', payload '{"current":0.14,"energy":0,"linkquality":72,"power":13,"power_outage_memory":null,"state":"ON","voltage":225}'
ltage":225}'

La información recibida es un mensaje JSON con los siguientes parámetros:

• power. Medida instantánea de la potencia. Es un valor numérico cuya unidad es el Watio (W).
• current. Medida instantánea de la corriente. Es un valor numérico cuya unidad es el Amperio (A).
• voltage. Medida instantánea de potencial electríco. Es un valor numérico cuya unidad es el Voltio (V).
• energy. Suma de energía consumida. La unidad de este valor es el Kilowatio-hora (KWh).
• power_outage_memory. Indica el estado de activación en que quedará el echufe tras un corte de luz. Para escribir un valor nuevo, hay que escribir en el topic zigbee2mqtt/<friendly_name>/set un mensaje con el valor {"power_outage_memory": <VALOR>}. Los posibles valores son: on (encendido), off (apagado) y restore (estado anterior).
• linkquality. Fuerza de la señal. El valor mínimo es 0 y el máximo 255. La unidad de este valor es lqi (Link Quality Indicator).

Actualización del estado de activación (power_outage_memory):

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe/set" \
-m '{"power_outage_memory": "restore"}' 

En los logs podremos ver cómo aparece el valor de éste parámetro:

tail -f /opt/zigbee2mqtt/data/log/zigbee2mqtt.log 

info  2022-02-14 22:48:21: MQTT publish: topic 'zigbee2mqtt/enchufe', payload '{"current":0,"energy":0.01,"linkquality":129,"power":0,"power_outage_memory":"restore","state":"OFF","voltage":230}'

Al margen de los logs, podemos leer los valores de la información que muestra el enchufe utilizando mosquitto_sub con el siguiente comando:

mosquitto_sub -C 1 \
-h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/enchufe"

{"current":0.09,"energy":0.01,"linkquality":120,"power":13,"power_outage_memory":"restore","state":"ON","voltage":222}

Disponiendo de un gateway Zigbee y un broker MQTT podemos emparejar un enchufe inteligente, configurarlo y manipularlo a través de la publicación y suscripción a topics MQTT. Esto nos permite gestionar el enchufe desde scripts y consultar detalles de consumo, voltaje y corriente.

• https://www.zigbee2mqtt.io/devices/TS011F_plug_3.html
• https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html

El uso de dispositivos de domótica que funcionan bajo protocolo Zigbee requiere para su conexión de un gateway Zigbee, un dispositivo hardware que sirve para interconectarlos. Podemos recurrir a dispositivos comerciales, que suelen estar basados en soluciones propietarias cerradas a un conjunto de dispositivos concretos de una marca, o montar nuestro propio gateway Zigbee utilizando el software zigbee2mqtt, un adaptador USB Zigbee y una Raspberry Pi, PC o dispositivo similar que ejecute GNU/LINUX para realizar esta función.

En este caso veremos como montar esta solución utilizando una Raspberry Pi 3.

Para obtener un buen rendimiento, la recomendación de zigbee2mqtt es que se utilice cualquier adaptador USB Zigbee basado en los chips CC2652 y CC1352 de Texas Instruments. Hay otros dispositivos soportados que pueden tener alguna limitación o que necesitan que el firmware sea actualizado. La lista completa está descrita en https://www.zigbee2mqtt.io/guide/adapters/ y se incluyen enlaces con las instrucciones de actualización del firmware para algunos de ellos. En este caso vamos a utilizar un Sonoff Zigbee 3.0 USB Dongle Plus, un dispositivo basado en el chip CC2652P, que se encuentra dentro de los recomendados, y cuyo firmware de serie es compatible con zigbee2mqtt.

Conectamos el adaptador a uno de los puertos de la Raspberry pi y desde un terminal comprobamos si se ha detectado el dispositivo, lanzando el siguiente comando:

lsusb | grep CP210

Bus 001 Device 005: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

El dispositivo debe aparecer en el directorio /dev. Dependiendo del modelo, puede aparecer como ttyACM0 o bien, como es nuestro caso como ttyUSB0:

ls -l /dev/ttyUSB0

crw-rw----. 1 root dialout 188, 0 feb  7 22:21 /dev/ttyUSB0

Si no lo localizamos, podemos lanzar la siguiente instrucción:

ls -l /dev/serial/by-id

total 0
lrwxrwxrwx. 1 root root 13 feb  7 22:21 usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_c6edf6bd90c8eb119099c1c3de5b81b4-if00-port0 -> ../../ttyUSB0

Nos devolverá una descripción más larga que se corresponde a un enlace simbólico que apuntará al dispositivo anterior.

Tenemos que disponer de permisos de escritura en el puerto que corresponde al dispositivo. Lo podemos comprobar con el siguiente comando que devolverá success si todo está correcto:

test -w  /dev/ttyUSB0 && echo success || echo failure

success

Si el resultado es failure hay que dar permisos al usuario con el que estamos trabajando, asignándolo al grupo dialout o al grupo al que pertenezca el archivo del dispositivo (/dev/ttyUSB0 en nuestro caso):

usermod -a -G dialout $USER
newgrp dialout

Debemos disponer de un broker MQTT, ya sea en la misma Raspberry pi o en otro dispositivo al que tengamos acceso por la red. El proceso de instalación del broker mosquitto en la Raspberry pi está descrito en este artículo

Para la configuración tenemos que instalar primero los paquetes nodejs, npm, git, make, g++ y gcc.

sudo apt-get install -y nodejs npm git make g++ gcc

Verificamos la versión de nodejs. Debe ser v10.X, v12.X, v14.X, v15.X or V16.X

node --version

v12.22.5

Verificamos la versión de npm. Debe ser 6.X o 7.X

npm --version

7.5.2

Una vez que tenemos instalados todos los paquetes en las versiones requeridas, procedemos a clonar el repositorio de zigbee2mqtt de Github:

cd /tmp
git clone https://github.com/Koenkk/zigbee2mqtt.git
sudo mv zigbee2mqtt /opt/zigbee2mqtt

Instalamos las dependencias del proyecto:

cd /opt/zigbee2mqtt
npm ci

Antes de arrancar Zigbee2MQTT necesitamos editar el archivo de configuración configuration.yaml:

vi /opt/zigbee2mqtt/data/configuration.yaml

Debemos configurar la url y datos de autenticación del servidor MQTT. También debemos especificar la ruta donde se encuentra el adaptador USB Zigbee. El archivo quedaría de la siguiente forma:

# MQTT settings
homeassistant: false

permit_join: true

advanced:
    network_key: GENERATE
mqtt:
  # MQTT base topic for Zigbee2MQTT MQTT messages
  base_topic: zigbee2mqtt
  # MQTT server URL
  server: 'mqtt://localhost:1883'
  # MQTT server authentication, uncomment if required:
  user: zigbee
  password: contraseña

# Serial settings
serial:
  # Location of the adapter (see first step of this guide)
  port: /dev/ttyUSB0

Es recomendable utilizar una clave de red personalizada. Podemos hacer esto añadiendo lo siguiente al archivo configuraiton.yaml, que generá una clave de red en el siguiente arranque.

advanced:
    network_key: GENERATE

Guardamos el archivo y salimos del editor.

Ya podemos arrancar zigbee2mqtt manualmente:

cd /opt/zigbee2mqtt
npm start

Building Zigbee2MQTT... (initial build), finished
Zigbee2MQTT:info  2022-01-20 19:10:30: Logging to console and directory: '/opt/zigbee2mqtt/data/log/2022-01-20.19-10-26' filename: log.txt
Zigbee2MQTT:info  2022-01-20 19:10:30: Starting Zigbee2MQTT version 1.22.2 (commit #1a0a9a6e)
Zigbee2MQTT:info  2022-01-20 19:10:30: Starting zigbee-herdsman (0.13.188)
Zigbee2MQTT:info  2022-01-20 19:10:38: zigbee-herdsman started (reset)
Zigbee2MQTT:info  2022-01-20 19:10:38: Coordinator firmware version: '{"meta":{"maintrel":3,"majorrel":2,"minorrel":6,"product":0,"revision":20190608,"transportrev":2},"type":"zStack12"}'
Zigbee2MQTT:info  2022-01-20 19:10:38: Currently 0 devices are joined:
Zigbee2MQTT:warn  2022-01-20 19:10:38: `permit_join` set to  `true` in configuration.yaml.
Zigbee2MQTT:warn  2022-01-20 19:10:38: Allowing new devices to join.
Zigbee2MQTT:warn  2022-01-20 19:10:38: Set `permit_join` to `false` once you joined all devices.
Zigbee2MQTT:info  2022-01-20 19:10:38: Zigbee: allowing new devices to join.
Zigbee2MQTT:info  2022-01-20 19:10:39: Connecting to MQTT server at mqtt://192.168.168.1:1883
Zigbee2MQTT:info  2022-01-20 19:10:39: Connected to MQTT server
Zigbee2MQTT:info  2022-01-20 19:10:39: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'

Una vez que comprobamos que arranca bien, podemos crear archivo de configuración de systemctl para que Zigbee2MQTT pueda arrancar como un daemon:

sudo vi /etc/systemd/system/zigbee2mqtt.service

El contenido de ese archivo debe ser el siguiente:

[Unit]
Description=zigbee2mqtt
After=network.target

[Service]
ExecStart=/usr/bin/npm start
WorkingDirectory=/opt/zigbee2mqtt
# Descomentar siguiente línea para mostrar logs de los mensajes 
#StandardOutput=inherit
# La siguiente línea evita que se generen demasiados logs
StandardOutput=null
# Or use StandardOutput=null if you don't want Zigbee2MQTT messages filling syslog, for more options see systemd.exec(5)
StandardError=inherit
Restart=always
User=pi

[Install]
WantedBy=multi-user.target

En caso de estar utilizando una Raspberry Pi 1 o Zero, hay que reemplazar ExecStart=/usr/bin/npm start por ExecStart=/usr/local/bin/npm start.

Si el sistema se está ejecutando desde una tarjeta SD, es recomendable minimizar el número de archivos de log, para prolongar la vida de la tarjeta. El servicio systemd con la opción StandardOutput=inherit dará como resultado el registro de todo dos veces, una en journalctl a través de la unidad systemd y otra a través del sistema de log predeterminado de Zigbee2MQTT. Podemos mantener sólo una copia de ellos utilizando StandardOutput=null en la unidad systemd y mantener sólo los logs que están dentro de data/log, o estaleciendo ‘advanced.log_output = [‘console’]en la configuración de **Zigbee2MQTT** para mantener sólo los logs de *journalctl*. Complementando esto, podemos añadir algunos atributos en el archivoconfiguration.yamlpara personalizar la ubicación, nivel de detalle y nombre de los archivos de log. En este caso optamos por un nivel de loginfo, guardar en el directorio en /opt/zigbee2mqtt/data/logen un archivo llamadozigbee2mqtt.log`. El fragmento de parámetros de configuración sería:

...
advanced:
  log_level: info
  log_directory: data/log/
  log_file: zigbee2mqtt.log
  log_rotation: true
  log_output:
    - console
    - file
  log_symlink_current: false

Revisado todo esto, guardamos el archivo y salimos del editor.

Podemos comprobar que funciona la configuración arrancando el servicio:

sudo systemctl start zigbee2mqtt

Comprobamos el estado:

systemctl status zigbee2mqtt.service

La salida debe mostrar que el servicio está activo:

 zigbee2mqtt.service - zigbee2mqtt
     Loaded: loaded (/etc/systemd/system/zigbee2mqtt.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-01-20 22:31:23 CET; 10s ago

Lo habilitamos para que inicie en el arranque del sistema de manera automática:

systemctl enable zigbee2qtt.service

La actualización de versión de zigbee2mqtt consiste en los siguientes pasos

Parar zigbee2mqtt y entrar en el directorio donde se encuentra el código de github:

sudo systemctl stop zigbee2mqtt
cd /opt/zigbee2mqtt

Hacer backup de la configuración:

cp -R data data-backup

Descargar el código más reciente de github y actualizar las dependencias:

git checkout HEAD -- npm-shrinkwrap.json
git pull
npm ci

Restaurar la configuración:

cp -R data-backup/* data
rm -rf data-backup

Arrancar el servicio:

sudo systemctl start zigbee2mqtt

Para comprobar el funcionamiento, vamos a emparejar un sensor de temperatura y humedad WD500A de Tuya, cuya documentación para Zigbee2mqtt se encuentra en https://www.zigbee2mqtt.io/devices/WSD500A.html.

Para ver todo el proceso, podemos consultar el archivo de log, que se encontrará en /opt/zigbee2mqtt/data/log, con el nombre que indicamos en nuestra configuración específica. Ejemplo:

tail -f /opt/zigbee2mqtt/data/log/zigbee2mqtt.log

Para realizar el emparejamiento del dispositivo con pinchamos el botón reset durante 5 segundos, hasta que el led del sensor se pone a parpadear. Zigbee2mqtt lo detecta y muestra lo siguiente:

Zigbee2MQTT:info  2022-01-20 19:16:41: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0xa4c13831700f4951","ieee_address":"0xa4c13831700f4951"},"type":"device_announce"}'
Zigbee2MQTT:info  2022-01-20 19:16:45: Successfully interviewed '0xa4c13831700f4951', device has successfully been paired
Zigbee2MQTT:info  2022-01-20 19:16:45: Device '0xa4c13831700f4951' is supported, identified as: TuYa Temperature & humidity sensor (WSD500A)
Zigbee2MQTT:info  2022-01-20 19:16:45: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Temperature & humidity sensor","exposes":[{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Measured temperature value","name":"temperature","property":"temperature","type":"numeric","unit":"°C"},{"access":1,"description":"Measured relative humidity","name":"humidity","property":"humidity","type":"numeric","unit":"%"},{"access":1,"description":"Voltage of the battery in millivolts","name":"voltage","property":"voltage","type":"numeric","unit":"mV"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"WSD500A","options":[{"access":2,"description":"Number of digits after decimal point for temperature, takes into effect on next report of device.","name":"temperature_precision","property":"temperature_precision","type":"numeric","value_max":3,"value_min":0},{"access":2,"description":"Calibrates the temperature value (absolute offset), takes into effect on next report of device.","name":"temperature_calibration","property":"temperature_calibration","type":"numeric"},{"access":2,"description":"Number of digits after decimal point for humidity, takes into effect on next report of device.","name":"humidity_precision","property":"humidity_precision","type":"numeric","value_max":3,"value_min":0},{"access":2,"description":"Calibrates the humidity value (absolute offset), takes into effect on next report of device.","name":"humidity_calibration","property":"humidity_calibration","type":"numeric"}],"supports_ota":false,"vendor":"TuYa"},"friendly_name":"0xa4c13831700f4951","ieee_address":"0xa4c13831700f4951","status":"successful","supported":true},"type":"device_interview"}'
Zigbee2MQTT:info  2022-01-20 19:16:48: MQTT publish: topic 'zigbee2mqtt/0xa4c13831700f4951', payload '{"linkquality":123,"temperature":23.21}'
Zigbee2MQTT:info  2022-01-20 19:16:48: MQTT publish: topic 'zigbee2mqtt/0xa4c13831700f4951', payload '{"humidity":42.01,"linkquality":120,"temperature":23.21}'

Si volvemos a editar el archivo configuration.yaml de zigbee2mqtt, aparecerá lo siguiente:

devices:
  '0xa4c13831700f4951':
    friendly_name: '0xa4c13831700f4951'

Podemos cambiar el atributo friendly_name por un nombre más descriptivo, como sensor_habitación. También podemos añadir otras propiedades que se encuentren dentro de la documentación del sensor, aunque de momento cambiaremos sólo el nombre:

devices:
  '0xa4c13831700f4951':
    friendly_name: sensor_habitacion

y reiniciamos el servicio para que se aplique el cambio:

sudo systemctl restart zigbee2mqtt

Una vez reiniciado el servicio y asignado un nombre fácil de reconocer, zigbee2mqtt se encarga de recibir la información del sensor y publicarla en el broker MQTT en un topic llamado zigbee2mqtt/friendly_name en nuestro caso zigbee2mqtt/sensor_habitacion. Los datos que se publican son un objeto JSON que variará según el dispositivo. Para comprobar los datos que se están publicando en nuestro broker MQTT nos vamos a suscribir a ese topic. Si lo hacemos desde la propia RPi, pondremos en el parámetro -h el valor localhost. Si lo hacemos desde otro equipo pondremos la dirección IP de la RPi. Tendremos que especificar el usuario y contraseña que especificáramos durante la instalación de mosquitto. En este caso se utilizan un par de variables de entorno:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sensor_habitacion"

zigbee2mqtt/sensor_habitacion {"battery":null,"humidity":61.29,"linkquality":69,"temperature":20.39,"voltage":null}
zigbee2mqtt/sensor_habitacion {"battery":null,"humidity":61.01,"linkquality":72,"temperature":20.39,"voltage":null}

El tiempo que tardemos en recibir el valor depende de varios factores, como las características del sensor en concreto y si el ambiente está cambiando, ya que si la temperatura y/o humedad están estables, enviará datos con menos frecuencia.

Vemos que recibimos como respuesta datos en formato JSON, parejas clave-valor separadas por comas, y en las que se separa el nombre de parámetro de su valor por dos puntos. En este caso no se reciben valores en los parámetros battery y voltage (null). En cambio sí que se están enviando valores para los parámetros:

• linkquality. Fuerza de la señal. Es un valor comprendido entre 0 y 255.
• humidity. Humedad relativa, expresada en tanto por ciento (%).
• temperature. Temperatura, expresada en grados centígrados.

Es posible hacer algunos ajustes del sensor para personalizar la precisión de las mediciones o calibrar la temperatura y la humedad. Los parámetros que admite este sensor son:

• temperature_precision. Número de dígitos decimales para la temperatura. El valor admitido va de 0 (ningún decimal) a 3 (3 decimales).
• temperature_calibration. Permite calibrar la temperatura, sumando o restando un valor numérico para ajustarlo al valor real que queramos obtener. Si nuestro sensor marca 1 grado menos, pondríamos un valor 1. Si marca 2,5 grados de más, pondríamos -2.5.
• humidity_precision. Número de dígitos decimales para la humedad. El valor admitido va de 0 (ningún decimal) a 3 (3 decimales).
• humidity_calibration. Permite calibrar la humedad, sumando o restando un valor numérico para ajustarlo al valor real que queramos obtener.

Para ajustar estos parámetros podemos añadir uno o varios de ellos en el archivo de configuración /opt/zigbee2mqtt/data/configuration.yaml, en la sección correspondiente al dispositivo. Un ejemplo de ello sería lo siguiente, para el sensor que hemos llamado sensor_habitacion:

devices:
  '0xa4c13831700f4951':
    friendly_name: sensor_habitacion
    temperature_precision: 1
    humidity_precision: 0
    temperature_calibration: 2.5
    humidity_calibration: 3

Le estamos indicando que queremos la temperatura con un decimal, la humedad sin decimales, que sume 2 grados y medio a la temperatura que recoja el sensor y que sume 3 tantos porcentuales a la humedad. Para que se apliquen estos cambios tenemos que reiniciar el servicio zigbee2mqtt:

sudo systemctl restart zigbee2mqtt

Al cabo de unos minutos, veremos que los datos recibidos cambian de formato y de valor:

mosquitto_sub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/sensor_habitacion"

zigbee2mqtt/sensor_habitacion {"battery":null,"humidity":64,"linkquality":93,"temperature":22.8,"voltage":null}

Enviar al topic zigbee2mqtt/bridge/request/device/remove el payload {"id": "deviceID"}. Ejemplo:

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/request/device/remove" \
-m '{"id": "0xa4c13831700f4950"}'

mosquitto_pub -h localhost -p 1883 \
-u $MQTTUSER -P $MQTTPASS \
-t "zigbee2mqtt/bridge/config/force_remove" \
-m '{"id": "0xa4c13831700f4950"}'

== Resumen

Como hemos visto, podemos recibir información de un sensor a través del comando mosquitto_sub, con lo que podríamos aprovechar esta información desde scripts. Además de esta posibilidad, una forma muy flexible de utilizar esta información es instalar Home Assistant e integrar nuestro gateway con esta aplicación. Nos permitirá mostrar de forma visual la información y aprovecharla junto con otros dispositivos para hacer automatizaciones, como por ejemplo, avisar a través de Telegram cuando la temperatura pase de un determinado valor, o encender el aire acondicionado.

• https://www.zigbee2mqtt.io/guide/adapters/
• https://www.zigbee2mqtt.io/guide/installation/01_linux.html
• https://www.zigbee2mqtt.io/devices/WSD500A.html
• https://zigbee2mqtt.discourse.group/t/how-can-i-unpair-devices/1041/3

Los almacenes de certificados de confianza de Java o truststores son archivos binarios en los que se almacenan claves públicas de Autoridades de Certificación (CA). Las aplicaciones Java, a la hora de hacer peticiones a sitios web que ofrecen su contenido (APIs REST, APIs SOAP, contenido HTML, etc.) a través del protocolo HTTPS, comprueban como parte del proceso de negociación TLS/SSL que el certificado de ese sitio se encuentra emitido por una de las CA que se encuentren en su truststore. Vamos a ver cómo consultar y gestionar el contenido de estos almacenes.

Contenido

En cualquier equipo con un JRE/JDK instalado, el truststore predeterminado se encuentra dentro del directorio donde está ubicado el JRE (frecuentemente referenciado por la variable JAVA_HOME). Está concretamente en el subdirectorio lib/security y el archivo se denomina cacerts. Por defecto está protegido por la contraseña changeit.

Cualquier JRE/JDK incluye en el directorio bin la herramienta keytool que permite realizar varias operaciones sobre almacenes de certificados y archivos de certificados. Vamos a ver unas cuantas operaciones con esta herramienta que pueden resultar útiles.

Si tenemos correctamente definida la variable de entorno JAVA_HOME, podemos utilizarla para referenciar la ruta del truststore predeterminado. Si no está definida o estamos utilizando un JRE/JDK distinto del predeterminado, tendremos que hacer referencia a la ruta que apunte al almacén concreto que queramos gestionar.

Con el parámetro -list mostramos la lista de certificados contenidos en el truststore predeterminado. Si está protegido por contraseña, debemos indicar la contraseña en el parámetro -storepass. La ruta al almacén la indicamos con el parámetro -keystore:

keytool -list -storepass changeit -keystore $JAVA_HOME/lib/security/cacerts

keystore type: jks
Keystore provider: SUN

Your keystore contains 138 entries

actalisauthenticationrootca, Dec 14, 2021, trustedCertEntry, 
Certificate fingerprint (SHA-256): 55:92:60:84:EC:96:3A:64:B9:6E:2A:BE:01:CE:0B:A8:6A:64:FB:FE:BC:C7:AA:B5:AF:C1:55:B3:7F:D7:60:66
affirmtrustcommercial, Dec 14, 2021, trustedCertEntry, 
Certificate fingerprint (SHA-256): 03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7

...

xrampglobalcaroot, Dec 14, 2021, trustedCertEntry, 
Certificate fingerprint (SHA-256): CE:CD:DC:90:50:99:D8:DA:DF:C5:B1:D2:09:B7:37:CB:E2:C1:8C:FB:2C:10:C0:FF:0B:CF:0D:32:86:FC:1A:A2

Si al comando anterior le agregamos el parámetro -v nos mostrará todos los detalles de cada uno de los certificados.

También podemos obtener información detallada de uno de los certificados del almacén en concreto, especificando su alias con el parámetro -alias. El alias lo habremos visto a raíz del resultado de los comandos anteriores. En el siguiente ejemplo consultamos el detalle del certificado con alias thawteserverca:

keytool -list -v -storepass changeit -keystore $JAVA_HOME/lib/security/cacerts -alias thawteserverca

Nombre de Alias: thawteserverca
Fecha de Creación: 12 feb. 1999
Tipo de Entrada: trustedCertEntry

Propietario: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Emisor: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Número de serie: 1
Válido desde: Thu Aug 01 02:00:00 CEST 1996 hasta: Fri Jan 01 00:59:59 CET 2021
Huellas digitales del certificado:
	SHA1: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C
	SHA256: B4:41:0B:73:E2:E6:EA:CA:47:FB:C4:2F:8F:A4:01:8A:F4:38:1D:C5:4C:FA:A8:44:50:46:1E:ED:09:45:4D:E9
Nombre del algoritmo de firma: MD5withRSA
Algoritmo de clave pública de asunto: Clave RSA de 1024 bits (débil)
Versión: 3

Extensiones: 

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

Podemos cambiar la contraseña de un almacén por otra con el parámetro -storepasswd, indicando la contraseña actual con el parámetro -storepass y la nueva con el parámetro -new:

keytool -storepasswd -new nueva_contraseña -keystore $JAVA_HOME/lib/security/cacerts -storepass contraseña_actual

Los certificados digitales se pueden almacenar en diversos formatos. En lo que se refiere a los certificados de clave pública, que son los que se incluyen en un almacén de certificados de confianza para establecer las comunicaciones SSL/TLS, los formatos más habituales son dos:

• PEM. Archivo cifrado en formato Base64. Suele tener extensiones .pem, .cer o .crt, aunque la extensión no es determinante del formato real del archivo. Se distinguen más fácilmente porque su contenido se puede ver claramente con un editor de texto y en él se ven las líneas ----BEGIN CERTIFICATE---- y ----END CERTIFICATE----. En el caso de archivos que contengan una cadena completa de certificación, se puede distinguir el inicio y fin de cada uno de los certificados que contiene gracias a esas etiquetas.
• DER. Archivo binario. Suele tener extensiones .der, .crt o incluso .cer. Su contenido no se puede ver de forma “entendible” a través de un editor de textos.

Con keytool podemos obtener el detalle de un certificado, tanto si está dentro de un almacén como si está en un archivo independiente.

Vamos a ver cómo extraer el detalle de un certificado que viene en un archivo individual. Como ejemplo, vamos a descargarnos el archivo de un certificado raíz de GlobalSign, una de las autoridades de certificación más conocidas. Podemos descargarlo de https://secure.globalsign.net/cacert/root-r6.crt con:

curl https://secure.globalsign.net/cacert/root-r6.crt -o globalsign-root-r6.crt

Podemos mostrar los detalles de este certificado con:

keytool -printcert -file globalsign-root-r6.crt

Los datos de cabecera que nos devuelve el comando son:

Propietario: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
Emisor: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
Número de serie: 45e6bb038333c3856548e6ff4551
Válido desde: Wed Dec 10 01:00:00 CET 2014 hasta: Sun Dec 10 01:00:00 CET 2034
Huellas digitales del certificado:
	SHA1: 80:94:64:0E:B5:A7:A1:CA:11:9C:1F:DD:D5:9F:81:02:63:A7:FB:D1
	SHA256: 2C:AB:EA:FE:37:D0:6C:A2:2A:BA:73:91:C0:03:3D:25:98:29:52:C4:53:64:73:49:76:3A:3A:B5:AD:6C:CF:69
Nombre del algoritmo de firma: SHA384withRSA
Algoritmo de clave pública de asunto: Clave RSA de 4096 bits
Versión: 3

Muestra mucha más información que la del ejemplo anterior, pero nos vamos a centrar en primer bloque de información, concretamente en la línea que nos indica las fechas de validez, que en este caso vemos que van del 10/12/2014 al 10/12/2034. Vamos a procesar el resultado para quedarnos sólo con esta parte de la información, filtrándo por la palabra “Válido”, aunque dependiendo del idioma del sistema puede que tengamos que cambiarla por cualquier otra equivalente:

keytool -printcert -file globalsign-root-r6.crt | grep -E "Válido" 

Válido desde: Wed Dec 10 01:00:00 CET 2014 hasta: Sun Dec 10 01:00:00 CET 2034

Ahora modificamos el comando anterior para filtrar con awk, que por defecto divide en elementos separados por espacio en blanco, especificando las posiciones en las que se encuentran el día, el mes y el año de la fecha de fin de validez:

keytool -printcert -file globalsign-root-r6.crt | grep -E "Válido" | awk  '{print $12" "$11" "$15}'

10 Dec 2034

Una vez que tenemos la fecha de fin de validez podemos hacer un pequeño script en bash para calcular los días de validez. Los pásos básicos son:

1. Convertir la fecha de fin de validez a un valor unix epoch, que representa el número de segundos transcurridos entre el 1 de enero de 1970 y la fecha.
2. Obtener la fecha actual en formato unix epoch
3. Obtener la diferencia entre la fecha de fin de validez y la fecha actual, lo que nos dará el número de segundos que faltan hasta la caducidad. Dividimos ese valor entre el número de segundos por día y así obtendremos los días que faltan (o exceden) hasta la fecha de caducidad.
4. Mostraremos un mensaje diferente según el certificado esté ya caducado, le falten menos de 30 días para su caducidad o le falten más de 30 días.

Para ello, creamos el archivo check-certificate-expiration con el siguiente contenido:

#!/usr/bin/env bash
archivo_cert="$1"
finval=$(keytool -printcert -file $archivo_cert | grep -E "Válido" | awk  '{print $12" "$11" "$15}')
finval=$(date -d "$finval" '+%s')
hoy="$(date '+%s')"
dias_caducidad=$(( ($finval - $hoy) / (60*60*24) ))
if [ $dias_caducidad -lt 1 ]; then
  echo "El certificado ha caducado"
elif [ $dias_caducidad -lt 30 ]; then
  echo "Quedan menos de 30 días para que caduque el certificado"
else
  echo "Quedan $dias_caducidad dias para que caduque el certificado"
fi

Le damos permisos de ejecución:

chmod +x check-certificate-expiration

Y lo ejecutamos para verificar nuestro certificado

./check-certificate-expiration globalsign-root-r6.crt 

Quedan 4689 dias para que caduque el certificado

Con la misma idea, podríamos hacer un script algo más complejo al que le indiquemos como argumento la ruta a un truststore y su contraseña, que compruebe todos los certificados que contiene e informe de aquellos que han caducado o quedan menos de 30 días para que caduquen. Creamos una función validarcertificado que valida la caducidad de un certificado dentro de un almacén que habremos filtrado por su alias. Una vez que tengamos esa función, obtenemos la lista de todos los alias contenidos en un almacén y llamamos a la función validarcertificado para cada uno de ellos.

#!/usr/bin/env bash

validarcertificado(){
  truststore="$1"
  password="$2"
  alias="$3"
  keytool -list -v -storepass "$password" -keystore "$truststore" -alias "$alias" 2>/dev/null | grep -E "Propietario|Válido" \
    | while read propietario ; do
      read fechas
      propietario=${propietario#"Propietario: "}
      finval=$(echo "$fechas" | awk  '{print $12" "$11" "$15}')
      finval=$(date -d "$finval" '+%s')
      hoy="$(date '+%s')"
      dias_caducidad=$(( ($finval - $hoy) / (60*60*24) ))

      if [ $dias_caducidad -lt 1 ]; then
        echo "El certificado $alias ($propietario) ha caducado"
      elif [ $dias_caducidad -lt 30 ]; then
        echo "Quedan $dias_caducidad para que caduque el certificado $alias ($propietario)"
      fi

    done
}

truststore="$1"
password="$2"
keytool -list -storepass $password -keystore $truststore 2>/dev/null | grep "trustedCertEntry" \
| while read linea_alias; do
   alias=$(echo "$linea_alias" | cut -d ',' -f 1)
   validarcertificado "$truststore" "$password" "$alias"
done

Por último podemos verificar la caducidad de todos los certificados que se encuentren en un directorio. Algunos de los archivos de certificados pueden contener más de un certificado, incluyendo toda una cadena, por lo que se incluye la posibilidad de procesar más de un certificado en cada archivo. Esto se consigue filtrando de la información de cada certificado por las expresiones “Propietario” y “Válido”, con lo que obtendremos todas las líneas en las que aparezca el propietario del certificado y la fecha de validez, en la mayor parte de los casos sólo una de cada tipo. Por la posibilidad de que aparecieran varias, se utiliza la expresión while read propietario y a continuación se utiliza la instrucción read fechas que leerá la siguiente línea, que será la que contenga las fechas correspondientes al certificado del propietario obtenido a través del while. En este ejemplo se buscarán archivos con extensiones .cer, .pem y .crt dentro del directorio especificado:

#!/usr/bin/env bash

validarcertificado(){
  archivo_cert="$1"
  keytool -printcert -file $archivo_cert 2>/dev/null 2>/dev/null | grep -E "Propietario|Válido" \
  | while read propietario ; do
      read fechas
      propietario=${propietario#"Propietario: "}
      finval=$(echo "$fechas" | awk  '{print $12" "$11" "$15}')
      finval=$(date -d "$finval" '+%s')
      hoy="$(date '+%s')"
      dias_caducidad=$(( ($finval - $hoy) / (60*60*24) ))
      if [ $dias_caducidad -lt 1 ]; then
        echo "El certificado ($propietario) de $archivo_cert ha caducado"
      elif [ $dias_caducidad -lt 30 ]; then
        echo "Quedan menos de 30 días para que caduque el certificado ($propietario) de $archivo_cert"
      fi
    done
}

directorio=$1
for certificado in $directorio/*.{cer,pem,crt}
do
[ -f "$certificado" ] || continue
    validarcertificado "$certificado"
done

Hay casos en los que tenemos que utilizar un almacén específico. Podemos crear un nuevo almacén utilizando el parámetro -genkey, especificando el algoritmo de clave (parámetro -keyalg) y el tamaño de clave (parámetro -keysize). Nos solicitará los datos necesarios de forma interactiva:

keytool -genkey -keyalg RSA -keystore keystore.jks -keysize 2048

Introduzca la contraseña del almacén de claves:  
Volver a escribir la contraseña nueva: 
¿Cuáles son su nombre y su apellido?
  [Unknown]:  Dvdcr
¿Cuál es el nombre de su unidad de organización?
  [Unknown]:  publicaciones
¿Cuál es el nombre de su organización?
  [Unknown]:  Dvdcr Blog
¿Cuál es el nombre de su ciudad o localidad?
  [Unknown]:  Madrid
¿Cuál es el nombre de su estado o provincia?
  [Unknown]:  Madrid
¿Cuál es el código de país de dos letras de la unidad?
  [Unknown]:  ES
¿Es correcto CN=Dvdcr, OU=publicaciones, O=Dvdcr Blog, L=Madrid, ST=Madrid, C=ES?
  [no]:  si

Para añadir un certificado de confianza a un almacén existente, utilizamos el parámetro -importcert. La sintaxis del siguiente ejemplo, especifica todos los datos necesarios para que se haga en un sólo paso y no sea necesario que la herramienta nos pregunte:

keytool -importcert -keystore cacerts18 -storepass "changeit" -noprompt \
-trustcacerts -alias "globalsign-root-r6-custom"  -file globalsign-root-r6.crt

Se ha agregado el certificado al almacén de claves

A partir de la información del apartado anterior, podríamos hacer un sencillo script (import-certs-to-store) al que se especifique la ruta al almacén, la ruta al directorio que contiene certificados a importar y la contraseña del almacén y que realice la importación en bloque de todos los certificados que se encuentran en un directorio concreto. Este ejemplo en concreto, busca archivos con extensiones .cer, .pem y .crt. Los importa con un alias que es el nombre del archivo sin extensión ni la barra inclinada de la ruta:

#!/usr/bin/env bash

almacen=$1
dir=$2
password=$3

for certificado in $dir/*.{cer,pem,crt}
do
  if [ -f "$certificado" ]; then
    alias=${certificado%".cer"}
    alias=${alias%".pem"}
    alias=${alias%".crt"}
    alias=${alias##*"/"}    
    echo "Importando a [$almacen] certificado de archivo [$certificado] con alias [$alias]..."
    keytool -importcert -noprompt -trustcacerts -keystore "$almacen" -storepass "$password" -alias "$alias" -file "$certificado"
  fi
done

Ejemplo de ejecución:

./import-certs-to-store ./cacerts ./dir-con-certificados changeit

Importando a [./cacerts] certificado de archivo [./dir-con-certificados/globalsign-root-r6.crt] con alias [globalsign-root-r6]...
Se ha agregado el certificado al almacén de claves

Importando a [./cacerts] certificado de archivo [./dir-con-certificados/ejemplo.pem] con alias [ejemplo]...
Se ha agregado el certificado al almacén de claves

Para que una aplicación Java utilice un trustStore específico diferente del que incluye por defecto el JDK/JRE sobre el que se ejecuta, hay que indicar la ubicación de dicho truststore con la variable javax.net.ssl.trustStore y la contraseña de dicho almacén a través de la variable javax.net.ssl.trustStorePassword.

java -Djavax.net.ssl.trustStore=/opt/java-alt/JRE/lib/security/cacerts \
     -Djavax.net.ssl.trustStorePassword="contraseña" \
     -jar aplicacion.jar

• https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

Icono de caja fuerte creado por Diego Marquetti

MQTT (Message Queue Telemetry Transport) es un protocolo estándar de mensajería entre dispositivos del Internet of Things (IoT). El software que sirve como nexo de unión a todos los dispositivos que utilizan este protocolo se denomina broker. Vamos a instalar mosquitto, uno de los brokers más conocidos, y a configurar la autenticación por usuario y contraseña.

MQTT funciona siguiendo un modelo de publicación-subscripción. Los dispositivos se suscriben a uno o varios topics o temas, que consisten en una ruta jerárquica separada por la barra inclinada, y recibirán todos los mensajes publicados sobre ese topic. Podemos tener por ejemplo un tema raíz que se llama hogar y dentro de él podemos tener temas que representen las estancias, como hogar/dormitorio, hogar/cocina u hogar/salon. Podríamos detallar todos los niveles que queramos: hogar/salon/temperatura o hogar/salon/lampara_techo. Cualquier dispositivo puede publicar un mensaje en uno de esos topics y automáticamente todos los que estén suscritos a ese topic lo recibirán.

Para hacer todo esto posible es necesario un software que actúe como servidor, denominado broker. Vamos a proceder a la instalación y configuración de mosquitto, el servidor MQTT más conocido, en una Raspberry Pi. Podemos instalar mosquitto a través del gestor de paquetes de nuestra distribución Linux o utilizar un contenedor. Nos centraremos en el primer sistema.

Mosquitto está disponible en los repositorios oficiales de la Raspberry Pi. Para instalarlo ejecutamos lo siguiente:

sudo apt-get install -y mosquitto

Para configurar el servicio de manera que se exija autenticación para la publicación y la suscripción, tenemos en primer lugar de asegurarnos de que el servicio está parado:

sudo systemctl stop mosquitto

Creamos un archivo de credenciales al que añadimos un usuario. En este caso añadimos el usuario zigbee con el siguiente comando que nos pedirá la contraseña de forma interactiva dos veces:

sudo mosquitto_passwd -c /etc/mosquitto/users zigbee

Podemos añadir más usuarios al archivo, o cambiar la contraseña a un usuario existente, eliminando el parámetro -c:

sudo mosquitto_passwd /etc/mosquitto/users zigbee

Si queremos eliminar un usuario del archivo, utilizaremos el parámetro -D:

sudo mosquitto_passwd -D /etc/mosquitto/users usuario_a_eliminar

Una vez agregados los usuarios que necesitemos, eliminamos permisos de lectura sobre el archivo de credenciales para los usuarios en general:

sudo chgrp mosquitto /etc/mosquitto/users
sudo chmod o-r /etc/mosquitto/users

Para activar la autenticación en el servicio en base a este archivo de credenciales podemos editar el archivo /etc/mosquitto/mosquitto.conf o crear un archivo nuevo en el directorio /etc/mosquitto/conf.d/. En ambos casos debemos incluir la instrucción password_file y la ruta del archivo de credenciales. La siguiente instrucción utiliza la segunda opción:

echo -e "password_file /etc/mosquitto/users\nlistener 1883\nallow_anonymous false" | sudo tee /etc/mosquitto/conf.d/auth.conf

Ahora pasamos a activar el servicio para que arranque al inicio del sistema:

sudo systemctl enable mosquitto.service

Y lo arrancamos con la configuración aplicada:

sudo systemctl start mosquitto.service

Comprobamos que el servicio está activo:

sudo systemctl status mosquitto

mosquitto.service - Mosquitto MQTT Broker
     Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-01-20 13:23:54 CET; 5s ago
       Docs: man:mosquitto.conf(5)
             man:mosquitto(8)

Para comprobar que está funcionando correctamente, desde la propia Raspberry Pi podemos instalarnos la herramienta cliente:

sudo apt-get install -y mosquitto-clients

Utilizamos el comando mosquitto_sub para suscribirnos a un topic, en este caso rpi/test, sin autenticar. Si hemos configurado correctamente el servicio, esta operación debe dar un error de autorización:

mosquitto_sub -d -h localhost -p 1883 -t "rpi/test"

Client (null) sending CONNECT
Client (null) received CONNACK (5)
Connection error: Connection Refused: not authorised.
Client (null) sending DISCONNECT

Ahora probamos de nuevo el comando de suscripción, incluyendo el usuario (parámetro -u) y la contraseña (parámetro -P):

mosquitto_sub -d -h localhost -p 1883 -u zigbee -P contraseña -t "rpi/test"

Publicamos un valor en ese topic utilizando el comando mosquitto_pub:

mosquitto_pub -d -h localhost -p 1883 -t "rpi/test" -u zigbee -P contraseña -m "Buenos días"

y comprobamos que es recibido en el otro lado:

 Client (null) received PUBLISH (d0, q0, r0, m0, 'rpi/test', ... (10 bytes))
Buenos días

Ahora podemos repetir la prueba desde otro equipo distinto de la Rpi. El comando será el mismo, pero en el parámetro -h indicaremos la dirección IP de la RPi en lugar de localhost (en el ejemplo la dirección de la RPi es 192.168.1.10).

mosquitto_sub -d -h 192.168.1.0 -p 1883 -u zigbee -P contraseña -t "rpi/test"

Si en la RPi está activado el firewall, habrá que permitir el puerto 1883/tcp, que es el que utiliza MQTT, por defecto o desactivar el firewall para poder conectar.

A continuación publicaremos un mensaje en el topic rpi/test, también desde otro equipo:

mosquitto_pub -d -h 192.168.1.10 -p 1883 -t "rpi/test" -u zigbee -P contraseña -m "Saludos"

en la sesión de suscripción recibimos:

Client null sending PINGREQ
Client null received PINGRESP
Client null received PUBLISH (d0, q0, r0, m0, 'rpi/test', ... (7 bytes))
Saludos

Ya tenemos disponible nuestro broker, que será la base para interconectar muchos disposititos IoT. Esto puede ser de utilidad para controlar o recibir información de dispositivos IoT Wifi basados en el chip ESP8266 o ESP32 con el firmware Espurna o Tasmota. También para gestionar dispositivos Zigbee a través de zigbee2mqtt. En otros tutoriales veremos cómo trabajar con algunos de ellos.

• https://mosquitto.org/documentation/authentication-methods/
• https://mqtt.org/

Por defecto, en Fedora nano es el editor por defecto. Pero si lo que utilizamos habitualmente es vim, es algo sencillo de cambiar.

Para establecer vim como editor por defecto basta con ejecutar:

 sudo dnf install --allowerasing vim-default-editor

y reiniciar el equipo para que el cambio tenga efecto.

El comando anterior simplemente cambia la variable de entorno $EDITOR.

Open Cluster Management (OCM) es una herramienta modular y extensible para orquestar múltiples clusters de Kubernetes. Este artículo es un tutorial paso a paso de instalación de una versión mínima de Kubernetes y OCM en un equipo personal para poder experimentar con esta herramienta.

Se trata de un proyecto de código abierto, con licencia Apache 2.0 cuyo código fuente podemos encontrar en https://github.com/open-cluster-management-io y que constituye el proyecto upstream de Advanced Cluster Management (RHACM) de Red Hat.

Este tutorial se basa en el artículo de introducción a esta herramienta que figura directamente como guía de inicio rápido en la documentación OCM.

Contenido

En cuanto a hardware, los requisitos mínimos necesarios con los que se ha conseguido probar son los siguientes:

• CPU. Procesador con 4 cores, Intel Core i5 de sexta generación o equivalente.
• RAM. 12 Gb.
• Disco. Al menos 30 Gb de almacenamiento.

En cuanto a software, la prueba se ha realizado con Ubuntu 20.04 y Fedora 34, pero con ligeros cambios se puede ejecutar en cualquier distribución de Linux. Se utiliza la herramienta multipass para gestionar las dos máquinas virtuales necesarias. Es una herramienta que se puede instalar tanto en Windows 10 como en MacOS, y por lo tanto se podría aplicar en estos sistemas operativos de forma similar casi todo lo expuesto aquí, pero no se ha comprobado realmente el funcionamiento y si los requisitos de hardware mínimos indicados son suficientes en esos casos. Además de multipass es necesario instalar:

• MicroK8s
• kubectl
• clusteradm

Un cluster de Kubernetes está constituido por varios nodos (equipos físicos o máquinas virtuales) que incluyen el plano de control (pods necesarios para el funcionamiento de la propia infraestructura de Kubernetes) y la capacidad de carga útil para ejecutar aplicaciones. Dependiendo de los recursos y las necesidades nos podemos encontrar con clusters en los que idealmente hay como mínimo cinco nodos:

• 3 nodos para el plano de control denominados masters y que por lo tanto se utilizan para la gestión de la propia plataforma Kubernetes.
• 2 nodos denominados workers que ejecutan la carga útil, es decir, las aplicaciones.

Utiliza por tanto un patrón que se denomina master-kubelet o master-agent, ya que en cada worker se ejecuta un pod agente, llamado kubelet, encargado de comunicarse con los nodos master para obtener información de cuál es el estado deseado para las aplicaciones y transmitir a los componentes necesarios las tareas para conseguir ese estado (imagen, número de pods de la aplicación, cuenta de servicio, etc.).

El mínimo de dos nodos workers proporciona tolerancia a fallos en uno de los nodos, en cuyo caso la carga pasaría a ejecutarse en el otro. Este número de nodos es un mínimo, pero lo habitual en un cluster productivo es que haya muchos más nodos workers, incluso decenas de ellos.

Podemos encontrarnos también con clusters constituidos por tres nodos que desempeñan simultáneamente las funciones de master y de worker, aunque generalmente se trata de configuraciones para entornos de laboratorio con pocos recursos. No es lo recomendable para un entorno de producción.

El término cluster implica la existencia de varios elementos que se comportan como uno sólo. Es posible tener una instalación de Kubernetes en un sólo nodo, útil para pruebas de concepto o entornos locales, aunque en este caso se pierden muchas de las bondades de Kubernetes como el reparto de la carga de trabajo. Para este tutorial se crearán dos instalaciones de Kubernetes, cada una con un sólo nodo. Nos tomaremos la libertad de utilizar el término cluster para cada una de ellas, aunque estrictamente hablando es incorrecto. Las operaciones a realizar serían casi idénticas en un cluster de varios nodos y por lo tanto se podrían aplicar a un cluster real. De esta forma nos adaptamos a la terminología que utiliza OCM, que se refiere a la orquestación de clusters.

OCM utiliza una arquitectura maestro-agente (master-agent) entre los clusters, que imita la idea del patrón master-kubelet que existe entre los diferentes nodos de un cluster de Kubernetes, como se ha mencionado anteriormente. Existirán por tanto dos tipos de clusters:

• Cluster Hub. Se trata del cluster sobre el que se ejecuta el plano de control de OCM. Se trataría de un cluster muy ligero sobre el que se ejecutan un pequeño conjunto de servicios.
• Cluster Gestionado, Managed cluster o Klusterlet. Serían los clusters que son gestionados por el cluster hub. El servicio klusterlet está continuamente consultando las últimas especificaciones del cluster hub y ajustando de forma consistente el cluster de Kubernetes para que coincida con el estado esperado.