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.
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.
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:
’0xa4c13855fdxxxxxx’:
friendly_name: interruptor_dormitorio_1
’0xa4c138adxxxxxx’:
friendly_name: interruptor_dormitorio_2
– 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
- 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
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
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:
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:
Etiquetas: android, domótica, homeassistant, mqtt, nfc, node-red, sonoff, tasmota, udp, wifi, zigbee, zigbee2mqtt
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.
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.
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.
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
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:
Etiquetas: arduino, esp32, esp32-cam, homeassistant