msgbartop
Me encanta el olor del napalm por la mañana
msgbarbottom

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

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

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

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

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

Etiquetas: , , , , , ,

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

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

Datagrama UDP con NFC Tools Professional

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

Etiquetas: , , , , , , , , , , ,

07 may 21 Una webcam con Arduino: el ESP32-Cam

No voy a descubrir nada nuevo si afirmo que los sistemas Arduino son pequeñas maravillas. Se pueden hacer con ellos cosas increíbles en el ámbito de la domótica, e incluso con sistemas IoT y transmisión de radiofrecuencia. El problema habitual que suelen tener es que tienen unos recursos ciertamente limitados, pero para su ámbito de actuación, son más que correctos. Sin embargo, existen placas específicas que tienen algo más de potencia y capacidades, y que permiten dar un paso más allá: es el caso de las placas basadas en el ESP32. Ya he hablado de ellas en otro ámbito, en concreto en lo que se refiere a capacidades LoRa y LoRaWAN, pero hay un desarrollo específico, basado en el ESP32, que da bastante juego: las cámaras web. Y pensando en esto fue para lo que nació la ESP32-Cam.

Placa ESP32-CAM

Placa ESP32-CAM

La placa fue originalmente desarrollada por Espressif, y se compone de un micro ESP32-S, una cámara VO2640, y varios GPIOs que permiten conectar periféricos. Dispone de capacidad Bluetooth, así como conector microSD para utilizar tarjetas de memoria. Y todo ello por un precio ridículo, inferior a los 8€ (menos aún en el caso de las placas clónicas que se pueden encontrar en Aliexpress). De lo que no dispone es de un conector microUSB ni miniUSB, lo que implica que para programarlo es preciso utilizar un programador FTDI, pero no es nada tampoco cosa del otro mundo.

Diagrama de conexionado ESP32-CAM-Programador FTDI

Diagrama de conexionado ESP32-CAM-Programador FTDI

Desde el punto de vista físico, hay que alimentar el dispositivo utilizando los pines de 5v y GND del programador, interconectar los puertos UOR-TX y OUT-RX, y para iniciar el dispositivo en formato de grabación, puentear el GPIO0 y el GND de la propia placa. Una vez conectado de esta manera, se puede conectar el programador al PC, e iniciar la subida del firmware.

Comentaba antes que la placa es un desarrollo de Espressif, y ellos mismos proporcionan el código para subir un servidor de video en streaming a la ESP32-Cam. Este código es interesante, pues -entre otras funcionalidades- incorpora una funcionalidad de detección de rostros y detección de intrusos basado en las caras registradas.

Reconocimiento facial con el ESP32-CAM

Reconocimiento facial con el ESP32-CAM

El código es interesante, pero tiene algunos defectos. Entre ellos, que no permite hacer uso del pequeño LED que trae incorporado para hacer las veces de flash. Tras buscar un poco, encontré otro desarrollo que incorpora una serie de mejoras sobre el código original.. Tras haber utilizado ambos, recomiendo de manera clara este último.

Y para cerrar, comentar que es posible hacer uso de este servidor web dentro de HomeAssistant. Basta con crear una entrada de tipo cámara genérica, apuntando a la URL de captura de imágenes estáticas:

camera
– platform: generic
name: ESP32-Cam
still_image_url: http://192.168.0.XXX/capture?_cb.png
verify_ssl: false

ESP32-CAM integrada con HomeAssistant. Vista de mi patio

ESP32-CAM integrada con HomeAssistant. Vista de mi patio

Las pegas principales de la cámara son dos: la primera es que el módulo de la cámara no es ninguna maravilla. Sin embargo, al ser de un tipo estandarizado, es bastante sencillo encontrar mejores módulos, con cable más largo, y lentes ojo de pez, entre otras flipadas. La segunda es que no dispone de ninguna carcasa. Tampoco es problema, es posible encontrar bastantes diseños en Thingiverse para imprimir una carcasa en 3D.

Referencias:

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

Etiquetas: , , ,