19 ene 25 Nuevo servidor de virtualización – Introducción
En las últimas semanas he estado realizando una serie de cambios bastante importante en mi sistema informático. Desde hace muchos años tengo desplegado en casa un servidor que históricamente ha contenido mi sitio web, pero que con el paso del tiempo ha ido ganando en funcionalidades: domótica, servicio de mensajería, automatización, almacenamiento, VPN, streaming de vídeo… Todo empezó en la Universidad, con unas prácticas de alguna asignatura que ni siquiera recuerdo, pero ha persistido con el paso del tiempo.
En un momento dado tuve una serie de sistemas aislados que complementaban al servidor: un Mini-ITX, un par de Raspberry Pi, una Asus Tinker Board, una NAS… Pero con el paso del tiempo fui simplificando. Un paso trascendental fue la consolidación de las máquinas físicas separadas en un único servidor de virtualización. Para ello escogí realizar un despliegue de ProxMox, virtualización basada en KVM, pero que proporcionaba una interfaz de usuario vía web bastante amigable, lo que hacía la administración del entorno fuera sencilla. Para ello utilicé un viejo PC de oficina con un procesador Intel y 4 GB de RAM. Todo bastante ajustado para contener tres máquinas virtuales: un frontal web NGINX que además desplegaba un servidor MQTT y VPN, un backend con el servidor web WordPress, securizado por el frontal antes comentado, y una máquina separada para el entorno de domótica. Durante años ha funcionado bien, pero hace unos meses el servidor, ya veterano cuando lo desplegué, empezó a presentar fallos hardware. El principal fue que se estropeó uno de los módulos de RAM, quedando reducida la cantidad disponible a 3 MB. Además, presentaba fallos de encendido en caso de que se fuera la luz, lo que hacía que la recuperación del sistema fuera bastante complicado.
Ante ello, decidí renovar el hardware, para lo que me puse a mirar precio de módulos RAM para añadirle el módulo faltante al PC, y también precios de PCs nuevos. Tanto lo uno como lo otro tenían precios elevados (la RAM por tener que adquirirla a través de Ebay y sitios así), y el PC nuevo por el hecho de comprarlo nuevo. Y en ello andaba cuando se me ocurrió una idea disparatada:
Servidor HP Proliant DL360p Gen8
Hacerme con un servidor. Uno de verdad. No un viejo PC reconvertido. Un ser-vi-dor. Y resultó que la idea no era tan disparatada. Encontré un servidor HP DL360p Gen8 con doble fuente de alimentación, dos procesadores de 12 núcleos cada uno, 96 GB de RAM, 4 discos de 2 TB a 7200 RPM y controladora RAID, 4 puertos de red a giga, y un año de garantía por la ridícula cifra de 100€. Resultaba que la idea no era tan disparatada. Así que me hice con él. Pero es un servidor, claro. Está optimizado para el rendimiento. Y eso suele tener algunos problemillas cuando lo metes en una casa. Y no es el menor de ellos el que puede ponerse a sonar como un MIG 21 despegando.
Estas semanas he estado lidiando para poner el servidor de manera funcional, adaptarlo a un uso doméstico, volver a instalar un entorno de virtualización, y migrar las máquinas desde el viejo servidor. Por el camino he aprendido una serie de cosas bastante interesantes, y creo que vale la pena recopilarlas por si a alguien más le resultan interesantes, así que espero escribir unos cuantos artículos al respecto.
Etiquetas: domótica, home assistant, hp dl360p gen8, mqtt, nginx, proxmox, virtualización, vpn
18 ene 25 Uso de pulsadores Zigbee e interruptores WiFi para emular llaves conmutadas con Home Assistant
Como decía en el anterior artículo, estoy haciendo algunas mejoras en la domótica de Forcarey, motivadas por algunos cambios en el dormitorio principal. En concreto, estamos poniendo un cabecero de cama con mesillas flotantes, que hace que el cabecero ocupe todo el frontal de la pared, impidiendo el acceso a las llaves conmutadas del dormitorio.
Ejemplo de cabecero, no el mismo modelo
Esto implica que es necesario trasladar estas llaves al tablero del cabecero, lo que en condiciones normales implicaría abrir agujeros para empotrar las llaves y los enchufes, pero he pensado en hacer algo diferente para evitar hacer estos agujeros, que es usar pulsadores de tipo Zigbee, que al no necesitar cableado, son muy compactos y se pueden instalar simplemente en superficie.
Pulsador Zibgee compatible con Tuya
He escogido un modelo compatible con Tuya con dos pulsadores independientes, que además permite realizar tres acciones por pulsador (pulsación única, doble y larga), lo que permite mapear hasta seis acciones, y que se alimenta con una pila de botón. Este modelo es compatible con Zigbee2MQTT, que es lo que tengo montado para mi domótica, lo que me permite controlar cualquier tipo de dispositivo, y no sólo dispositivos de tipo Zigbee.
En cuanto al interruptor, he escogido los Sonoff Mini R2, con los que ya tengo experiencia sobrada, a los que he instalado el firmware Tasmota, de tal manera que puedo controlar el dispositivo mediante MQTT.
El sistema de domótica es Home Assistant, lo que me permite definir automatizaciones para integrar el funcionamiento de los pulsadores Zigbee y del interruptor Sonoff Mini R2. Y en este caso, esta automatización me permite emular el funcionamiento de las llaves conmutadas. El despliegue ha sido el siguiente:
- He anulado las dos llaves que están en la cabecera de la cama, ya que no van a tener uso.
- He adaptado el cableado que va desde la caja de registro para que la fase esté conectada al conector de salida de fase del Sonoff. Éste, a su vez, se ha conectado a fase y neutro de la caja de registro. Además, he conectado a las entradas de pulsador manual un par de hilos que van a la antigua llave de la entrada del dormitorio, de tal manera que se pueda seguir utilizando. Esta parte es que que permite un uso de esta llave para encender y apagar, pero sin ser ya realmente conmutada.
Esquema de cableado del Sonoff Mini en modo simple
- He registrado las llaves en Zigbee2MQTT. En mi caso, ha sido simplemente ponerlas en modo de emparejado (5 segundos pulsado el primer botón del pulsador) y se registran automáticamente. Es conveniente ponerles un alias descriptivo, para el posterior seguimiento del topic MQTT. Por ejemplo:
’0xa4c13855fdxxxxxx’:
friendly_name: interruptor_dormitorio_1
’0xa4c138adxxxxxx’:
friendly_name: interruptor_dormitorio_2 - En el Sonoff Mini, configurar el dispositivo para que trabaje con MQTT (Configuration->MQTT). De nuevo, es recomendable hacer uso de un topic descriptivo.
- Pasamos a Home Assistant. Aquí tendremos que hacer dos acciones diferentes: registrar el Sonoff Mini como un dispositivo de tipo switch, y crear una automatización basada en MQTT que se dispare con los topic MQTT de los pulsadores Zigbee.
- Registro del Sonoff Mini: En mi caso lo realizo de manera manual, mediante una entrada en el fichero configuration.yaml de mi Home Assistant, con una entrada como esta:
– platform: mqtt
name: “Luz dormitorio Forcarey 1″
state_topic: “topic_interruptor1/stat/dormitorio1/RESULT”
value_template: ‘{{ value_json["POWER"] }}’
command_topic: “topic_interruptor1/cmnd/dormitorio1/POWER”
availability_topic: “topic_interruptor1/tele/dormitorio1/LWT”
qos: 1
payload_on: “ON”
payload_off: “OFF”
payload_available: “Online”
payload_not_available: “Offline”
retain: false - Creación de la automatización: Esta es la clave del asunto para lograr el funcionamiento conmutado. Se trata de crear una automatización que responda a tantos topic como interruptores tengamos, de tal modo que la activación de cualquiera de ellos haga que se dispare la automatización (otra alternativa sería usar automatizaciones independientes por pulsardor, pero el resultado no es tan limpio, y la gestión es más engorrosa). Este es un ejemplo de cómo realizar esta automatización, para el caso de una sola pulsación:
- alias: Activacion simple del primer pulsador de las llaves
trigger:
– platform: mqtt
topic: topic_pulsador/interruptor_dormitorio_1
– platform: mqtt
topic: topic_pulsador/interruptor_dormitorio_2
condition:
condition: template
value_template: ‘{{ “1_single” == trigger.payload_json.action }}’
action:
entity_id: switch.luz_dormitorio_forcarey_1
service: switch.toggle - ¡Y listo! Para definir hasta las seis acciones que permite este pulsador doble, basta con crear más automatizaciones según el esquema anterior, simplemente jugando con la condición de la automatización, configurando de manera adecuada el parámetro “action” que se recibe de cualquiera de los dos topic MQTT. Estos pueden venir con los valores siguientes: “1_single” (que es el que se genera cuando se pulsa una vez el primero de los dos pulsadores del interruptor), “2_single” (lo mismo, para el segundo pulsador), “1_double” (pulsación doble), “2_double”, “1_hold” (pulsación mantenida) y “2_hold”.
Hemos escogido un pulsador doble porque tenemos dos luces independientes en el dormitorio, una sobre la cama, y otra sobre la entrada a la habitación. Con esto, tenemos un bonito sistema para controlar la iluminación de manera independiente (con un segundo Sonoff Mini R2 para la otra luz, conectado de manera equivalente, claro), y tenemos aún cuatro acciones disponibles para controlar otros aspectos, como la calefacción o cualquier otro elemento la casa. Todo un progreso que nace de la necesidad de evitar taladrar el cabecero. 
Etiquetas: home assistant, homeassistant, mqtt, sonoff mini, tuya, zigbee, zigbee2mqtt
11 ene 24 Monitorización de vehículos Toyota conectados en Owntracks
Desde hace algún tiempo tenemos en casa un par de Toyotas, un Auris y un Aygo. El Aygo es de 2021, y tiene algo bastante interesante, y es que dispone de conectividad con la plataforma de servicios conectados de Toyota. Con ello, se puede acceder a información sobre viajes, historial, así como generar avisos automáticos en caso de accidente. Existe una aplicación oficial MyToyota, que permite acceder a dichos servicios desde el móvil, además de poder hacerse a través de la web de Toyota.
Pero lo que es más interesante es que alguien se ha currado un proyecto en GitHub que permite acceder con Python 3 a dicha plataforma: MyToyota. Es una versión puesta al día de otro proyecto, MyT, que hacía básicamente lo mismo, pero con una versión anterior de la API de los servicios conectados de Toyota que ha dejado de estar disponible a finales de 2023.
A partir de aquí, ya es echarle imaginación. En mi caso, he desarrollado un programa que permite recabar la información de posicionamiento del vehículo, e inyectarlo en mi MQTT, para integrar esta información en Owntracks. Así tengo centralizado el seguimiento de mis vehículos en una plataforma abierta.
07 ene 24 Sistema de telemetría 2.0, basado en ESP32
Hace ya algunos años, cuando aún vivíamos en Irlanda, desarrollé un sistema de telemetría casero para el Mercedes C180 Sportcoupe que teníamos allí, basado en una Raspberry Pi y un receptor GPS, junto con un conector OBD-II por Bluetooth para leer datos de la centralita del coche. Fue un sistema que estuvo funcionando estupendamente bien, pero que dejé de utilizar, por razones que no vienen al caso.
En fechas recientes me he decidido a revivirlo (también por razones que no vienen al caso), pero quería darle una vuelta de tuerca al sistema, para cambiar algunas características que -estando bien- no se amoldaban del todo a mis necesidades. La principal de ella es que el sistema original dependía de una conexión Bluetooth con un teléfono móvil que hiciera de módem sobre este medio, a fin de proporcionar conectividad al exterior. Buscaba que la nueva versión del entorno tuviera conectividad independiente, a fin de poder hacer seguimiento del coche de manera más sencilla. Mi primera idea fue conectar un modem USB a la Raspberry Pi, pero se trata de un modelo 2 de la RPi, que sólo dispone de 2 conexiones USB, y ambas estaban en uso: una para el receptor GPS, y otra para el dongle Bluetooth que se necesita para conectar con la centralita del coche. Pensé en portar todo a una RPi más moderna, pero fue aquí cuando entró en danza el siguiente artilugio:
LilyGO TTGO T-A7670G
Se trata de un dispositivo LilyGO TTGO T-A7670G. Se trata de un ESP-32 que proporciona, de manera simultánea, conectividad Bluetooth, zócalo para tarjetas de telefonía 4G, receptor GPS, e incluso un zócalo para conectar una batería 18650, todo ello en una sola placa. Ya tenía experiencia trabajando con ESP-32 en Arduino, lo cual era una gran ventaja para mí, además de trabajar con estos componentes por separado, pero nunca lo había hecho con una placa de fabricante que proporcionara todos estos elementos de manera integrada. Mucho mejor que tener que ir montando componentes por separado.
El fabricante, además, proporciona un repositorio en GitHub donde acceder a librerías, ejemplos de código, documentación, e incluso esquemáticos de carcasas, lo que ha hecho que haya podido imprimir una caja para el dispositivo:
TTGO con carcasa 3D y receptor GPS
Con todo esto, he podido realizar una nueva versión del sistema de telemetría, con las siguientes características:
- Hago uso de una tarjeta de datos 4G española, de tipo MicroSIM, con un funcionamiento excelente. El sistema apenas consume sobre 2-3 MB de datos, haciendo envío de información cada 10 segundos a la plataforma.
- La conectividad, como en el caso original, está basada en el envío de datos en formato JSON a un servidor MQTT. Posteriormente esa información es consumida de diversas maneras, tanto para proporcionar ubicación en tiempo real, como para realizar analítica de datos sobre el viaje. A diferencia del caso original, el envío de información se hace directamente al MQTT remoto, en vez de componer un MQTT local que se sincroniza con el remoto, cosa que se hacía para preservar el envío de información en caso de pérdida de conectividad. En este caso, he podido comprobar que no se producen pérdidas de datos significativas, por lo que he preferido simplificar.
- El sistema hace uso del GPS integrado para recibir información GPS. Este es un punto importante en el caso de esta placa. Existen diversas variantes de la misma, con cobertura GPS regional, global, o sin cobertura GPS. En mi caso, hago uso de la placa “A7670G R2 With GPS”, que es el que proporciona cobertura GPS global, y más compatibilidad con sistemas de telefonía, pero tiene el detalle de que el módulo GPS no está integrado en la placa, sino como módulo anexo, en la trasera de la misma, junto al zócalo de la batería 18650. Esto implica que el modo de uso del GPS es distinto, haciendo uso de la librería GPSShield, en vez del ejemplo convencional que indica el fabricante. Esto me tuvo un tiempo dando vueltas, hasta que me di cuenta de ello.
Además, la placa viene con una antena GPS pasiva. Esto está bien si el dispositivo se encuentra directamente al aire libre, pero era problemático si estaba dentro de una casa o de un coche, ya que apenas tenía cobertura. Para solucionar este inconveniente tuve que hacer uso de una antena GPS activa con conector SMA, y hacer uso de un pigtail UFL/U.FL/IPX a RP-SMA/SMA. Nada grave, pero sí un poco molesto. Ahora bien, en cuanto dispuse de esta antena activa el sistema pasó a ser capaz de detectar señal GPS incluso en interiores. Todo una diferencia, y sin necesidad de reprogramar.
- La telemetría OBD-II es algo que no he conseguido hacer funcionar aún del todo. Si bien la placa es capaz de conectar correctamente con mi conector OBD-II por Bluetooth, no es capaz de extraer correctamente los datos de la centralita. Hago uso para ello de la librería ELMduino, que conocía desde hace algunos años, pero con la que no he tenido resultados muy buenos hasta ahora. Antes hacía uso de un ESP-32 convencional, y esperaba que con esta placa funcionara mejor, pero no ha sido el caso. Puede ser tema del dongle Bluetooth, que es de los baratillos. He encargado otro, para probar, así que espero mejoras al respecto.
En estos días he estado haciendo algunas pruebas, y al margen de la captura de datos de la centralita, el resultado es bastante bueno. Espero poder seguir haciendo mejor al respecto en las próximas semanas.
Etiquetas: a7670, arduino, bluetooth, esp32, gps, impresora 3d, lilygo, mqtt, obd-ii, telemetría
25 oct 23 Control de luces inteligentes con NFC, MQTT y Node Red
En fechas recientes he implementado un elemento adicional de interacción con la domótica. No es algo especialmente nuevo (de hecho, ya en Irlanda empecé a trastear con ellos), pero sí es algo que he recuperado recientemente: el uso de tags NFC para interactuar con la domótica, usando teléfonos inteligentes. La idea es bastante sencilla: desplegar una serie de tags desplegados por la casa, allí donde quiera que se dispare una acción concreta, para escanearlo con el teléfono, y ejecutar la acción. Y el elemento más obvio para ello es el control de luces inteligentes.
En mi caso, tengo desplegadas dos tecnologías diferentes para el control de luces inteligentes: interruptores WiFi (básicamente, diversas variedades de Sonoff) y luces Zigbee, que controlo mediante sendas plataformas zigbee2MQTT que tengo tanto en Santiponce como en Forcarey. Todo ello integrado en mi servidor MQTT, que se utiliza también con la plataforma HomeAssistant. La gracia del asunto es que toda la interacción con ellas se realiza desde el propio HomeAssistant, independientemente de la tecnología subyacente. Y siempre usando MQTT como elemento de mensajería.
Para poner en marcha el sistema de interacción basado con NFC he optado por lo siguiente: codificar en los NFC el envío de un datagrama UDP. La razón de hacerlo así es que es que de esta manera se evita, como es el caso de conexiones HTTP o similar, el tener que hacer uso de un programa específico en el teléfono, ya que mediante el envío del datagrama se evita que el usuario tenga que interactuar con ninguna aplicación, haciéndose el envío siempre en segundo plano. Esto implica que es preciso tener abierto en algún lugar un puerto UDP al que enviar los mensajes. Y la opción obvia en mi caso es hacer uso de Node-Red.
Así pues, he hecho un flujo bastante simple, que lo que hace es exponer un puerto UDP, a donde el teléfono envía la mensaje del datagrama. Este mensaje, en líneas generales, es un alfanumérico que me permite identificar qué luz quiero encender (por ejemplo, santiponceSalon1, para identificar la luz principal del salón de Santiponce). Una vez recibido el mensaje, se procesa en un switch, con tantas entradas como luces a controlar (en mi caso, de momento, 4), y se incluye en el payload el mensaje de encendido/apagado. Aquí hay dos opciones:
- Luces Sonoff: Para las luces WiFi basadas en Sonoff con el firmware Tasmota, basta con enviar un “TOGGLE”, y con eso variaremos el estado de la luz entre encendido y apagado. Ese mensaje se envía mediante MQTT al topic que permite dar órdenes al interruptor (por lo general, algo como xxxxx/xxxx/cmnd/xxxx/POWER).
- Luces Zigbee: En mi caso, como decía, uso Zigbee2MQTT para controlar las luces Zigbee de manera agnóstica al fabricante, interactuando a través de un servidor MQTT. En este caso, la composición del mensaje es algo distinta. Hay que enviar un ‘{“state”: “TOGGLE”}’. Se enviará al topic que, como en el caso anterior, permite enviar comandos. Será algo como zigbee2mqtt/0xxxxxxxxxxxx/set
Flujo Node Red para control de luces inteligentes con NFC y MQTT
Una vez publicado el flujo, el servidor donde tengamos desplegado Node-Red abrirá un puerto UDP para escuchar conexiones (aconsejo hacer uso de un puerto alto, para evitar tener que asignar permisos de root). En mi caso, dado que publico Node-Red mediante un contenedor docker, es por lo que tenía que realizar una publicación de puertos del contenedor, de lo que hablaba en el artículo anterior. Y con esto, estaremos listos para controlar las luces con un móvil NFC.
Un par de comentarios adicionales:
- Desde el punto de vista de la seguridad, no es una buena práctica publicar estos puertos hacia Internet. En mi caso, lo tengo publicado sólo en el contexto de la red local de mi casa, lo que no supone un problema, ya que siempre voy a estar conectado a la WiFi cuando interactúe con los tags NFC. Se puede exponer hacia Internet, pero lo desaconsejo de manera vehemente.
- Para grabar los tags NFC para que envíen datagramas por UDP hago uso de la versión Profesional de la aplicación de Android NFC Tools. Vale apenas unos 3€, y compensa tenerla. La manera de hacerlo es muy sencilla, basta con agregar una Tarea, de tipo Redes, UDP, y grabar el tag. Y lo bueno es que cualquier otro teléfono con NFC, aunque no tenga la aplicación, será capaz de enviar el datagrama.
Datagrama UDP con NFC Tools Professional
Etiquetas: android, domótica, homeassistant, mqtt, nfc, node-red, sonoff, tasmota, udp, wifi, zigbee, zigbee2mqtt
Medidor de entropía
