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
03 jul 20 Cómo encontrar la clave de una WiFi guardada en Windows 10
Este pequeño tutorial viene muy bien para encontrar la clave de una WiFi a la que nos hemos conectado en Windows 10, pero de la que no recordamos la clave: Find the WiFi Password in Windows 10 Using CMD. En español, la receta:
- Abrir una ventana de comando con “cmd”
- Obtener la lista de conexiones WiFi almacenadas en el sistema operativo: “netsh wlan show profile”
- Una vez identificada la WiFi en cuestión, obtener la contraseña: “netsh wlan show profile <nombrewifi> key=clear”
Captura de clave de WiFi
…y de esta manera, nos aparecerá la clave de la WiFi seleccionada.
Etiquetas: clave, cmd, wifi, windows 10
03 feb 20 Dash button doméstico con ESP-01
Uno de los proyectos de mejora que tenía para la domótica de la casa era el añadirle un dash button para controlar alguno de los sistemas. ¿Y qué es un dash button? En pocas palabras, es un pequeño pulsador que permite comprar de manera completamente automatizada un producto en concreto a Amazon, con la idea de facilitar la compra sencilla de bienes consumibles.
Ejemplo de dash button
El caso es que aunque el producto fue exitoso, tuvo que enfrentarse a una serie de problemas legales, y Amazon acabó retirándolos de la venta. Pero el concepto detrás de ellos seguía siendo interesante. No tardé en encontrar un proyecto en Thingiverse sobre cómo implementar un dash button software libre, y no tardé demasiado tiempo en preparar mi propia versión, con algunas modificaciones sobre el diseño original.
Dash button doméstico
En mi caso, en vez de hacer uso de un ESP8266, opté por usar un ESP-01, más compacto, y un botón rojo externo en vez de un pulsador interno. Por lo demás, el diseño es el mismo. En lo referente a la lógica del sistema, se basa en el modo deep sleep de los ESP. En este caso, el sistema queda durmiendo de manera permanente hasta que el botón es pulsado, lo que despierta al sistema, ya que el botón puentea el puerto RST del ESP-01 con el GND. Combinado con el uso de la batería CR2 de 3V, en teoría hay alimentación para varios años. ¿Y en cuanto a la acción en sí? Sencillo: el sistema despierta, conecta a mi WiFi doméstica, y actualiza un topic MQTT. Después de eso, vuelve a dormir hasta una nueva pulsación.
Parece poca cosa, pero con esa actualización del topic MQTT se puede programar cualquier acción que deseemos en el sistema de domótica. Eso ya queda para una segunda fase. 
Etiquetas: dash button, domótica, esp-01, impresora 3d, mqtt, wifi
14 oct 19 Repetidor WiFi con router doméstico y OpenWRT
Uno de los inconveniente de tener la casa domotizada, con múltiples sensores y actuadores ubicados a lo largo de las tres plantas de la misma (y todo eso sin contar teléfonos, portátiles y otros cacharros que se conectan a Internet), es que la fiabilidad de la señal WiFi se resiente enormemente. Es normal, a más dispositivos queriendo usar de manera simultánea el canal de comunicación, peor es la calidad de la transmisión. Para los profanos, es como hablar por el patio de luces con tu vecino del quinto, si vives en el segundo: si sólo habláis vosotros os entenderéis bastante bien, pero si también hablan los del primero con el tercero y los del sexto con el bajo, a menos que os pongáis de acuerdo para hablar por turnos (con el consiguiente retardo en la conversación), lo único que se oirá será un guirigay de voces. Existen varias maneras de solucionar este problema, a saber:
- Utilizar red cableada frente a WiFi siembre que sea posible: La mejor solución. Pasas de un canal compartido half-duplex a uno dedicado full-duplex. Pero suele tener como principal inconveniente el divorcio si prentendes llevar cables ethernet por toda la casa para que el sensor de temperatura del salón tenga un canal dedicado para sí. Bromas aparte, para aquellos equipos que estén ocultos, cercanos al router o que consuman un gran ancho de banda es la solución óptima, si bien es la más difícil de implementar a medida que los dispositivos se alejan de los puntos de red, y tiene una movilidad muy escasa.
- Utilizar un dispositivo PLC para llevar otro punto WiFi/Ethernet a otra ubicación de la casa: Los dispositivos Power Line Communication consiguen utilizar la red eléctrica de la casa para propagar una señal de datos. Bastante interesante, ya que los cables eléctricos están por toda la casa, pero tienen como inconveniente que precisa de dos convertidores de medios para poder implementar la solución, con el consiguiente coste económico. Lo bueno es que muchos proporcionan de manera simultánea la conversión de medios PLC y punto de acceso WiFi de manera unificada, además de la toma de red cableada, por lo que en cierto sentido se mitiga el impacto económico, que puede estar en torno a los 50€
- Un repetidor WiFi: La opción más económica, y no tan ineficiente como parece. Se trata de ubicar un repetidor de la señal WiFi en las zonas donde la intensidad de la señal del punto de acceso maestro empiece a flojear, para levantar una nueva WiFi (o extender la existente de manera transparente) que tenga más calidad de señal. Aunque parece contraintuitivo que añadir un nuevo dispositivo WiFi a la red pueda mejorarla, la gracia del asunto es que el repetidor emitirá en un canal WiFi diferente al original, por lo que las señales ya no se pisarán tanto.
En mi caso esta ha sido la opción que he elegido para solucionar el problema. Pero en vez de comprar un repetidor comercial, he optado por una opción más sostenible medioambientalmente: poner en servicio un viejo router Huawei EchoLife HG556a de Vodafone que andaba rondando por casa, reprogramarlo con el software OpenWRT, y utilizar sus capacidades para actuar como repetidor WiFi. En este caso la idea es complementar la instalación base de OpenWRT con la interfaz de administración web LuCi, para una configuración más sencilla.
Configuración del repetidor WiFi
…y la verdad es que funciona como la seda. En mi caso, he preferido levantar una WiFi complementaria a la principal (UPC******), y hasta ahora -lleva ya unos cuantos meses, desde que puse en el salón el Amazon Fire Stick- funciona como la seda. Además de tener la ventaja de darme un mini-switch para enchufar la televisión Philips, que es una smartTV arcaica sin WiFi, pero con toma de red Ethernet. Y tan contento. 
P.S.: Sí, el nombre de mi WiFi original es el nombre de mi configuración doméstica de Dublín, con el operador de cable UPC Ireland. Pequeños detalles que me recuerdan los días pasados allí, y que en cierto sentido me hacen lucir una sonrisa al recordarme los años que allí viví. 
Etiquetas: amazon fire stick, ethernet, huawei, luci, openwrt, wifi
Medidor de entropía
