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
Una de las gracias de ejecutar servicios en un contenedor docker es que, si cambian las necesidades del contenedor (como por ejemplo publicar en un nuevo puerto), es bastante sencillo aprovisionar uno nuevo sin mayores consecuencias. Pero a veces pasa que no puedes destruir y aprovisionar un nuevo contenedor, bien porque tienes determinada información persistente en el mismo (cosa que no debe hacerse, ya que en teoría los contenedores han de poder ser sin estado, pero esa es otra historia) o por cualquier otro motivo, y precisas de mantener el mismo contenedor, pero modificando (bien añadiendo, quitando o reemplazando puertos) el contenedor existente. Aunque no es una buena práctica, es posible realizarlo, siguiendo los siguientes pasos (por supuesto, recomiendo hacer primero una copia de seguridad de los ficheros modificados):
“PortBindings”:{“18332/tcp”:[{"HostIp":"","HostPort":"18332"}],”18334/tcp”:[{"HostIp":"","HostPort":"18334"}]}
“ExposedPorts”:{“18332/tcp”:{},”18334/tcp”:{}},
Referencias:
Etiquetas: contenedor, docker, microservicios, puertos
Desde hace algunos días vengo experimentando problemas con mi conexión doméstica a Internet. Esto es un problema bastante molesto para mí, porque hago uso de una serie de servicios en un servidor casero que publico hacia el exterior. El principal de ellos es este sitio web, pero hay algunos adicionales, como algunos servicios de domótica y una conexión VPN para acceder de manera segura desde el exterior. Hasta ahora, venía publicándolo todo de manera directa, ya que disponía de una IPv4 con mi conexión, pero desde la semana pasada han pasado a darme acceso a Internet detrás de un CG-NAT. Esto implica que ya no dispongo de una IPv4 propia, sino que salgo a través de una NAT del operador, por lo que no es posible acceder de manera remota a dichos servicios.
Mientras me lo solucionan, he optado por poner en pie un mecanismo para poder seguir publicando servicios, basado en el uso de un pequeño servidor público que se encarga de redireccionar los servicios hacia mi sistema detrás del CG-NAT. Y para ello, hago uso de una plataforma que permite establecer redes securizadas mediante una combinación de SG-NAT y VPN, llamada ZeroTier. La gracia de ZeroTier es que el entorno funciona como un concentrador de VPNs, de tal manera que entre los clientes que necesitemos conectar se establece una red privada, con lo que es posible dotar de conectividad entre ellos a los mismos, tan sólo instalando un agente del propio ZeroTier entre ellos, y establecer la visibilidad oportuna entre nodos. Haciendo que el servidor publicado en Internet sea uno de los nodos, puedo proporcionar servicios utilizándolo de pasarela pública.
La segunda pata del asunto es conseguir este servidor frontal público, y hacer que funcione de pasarela. En mi caso, he optado por hacer uso de Oracle Cloud Infrastructure, donde se puede desplegar de manera gratuita un servidor basado en Linux. Y una vez que me he hecho con este servidor, he montado la pasarela con un servidor NGINX, debido a que me permite redireccionar tanto servicios publicados por TCP (mi servidor web y mi servidor MQTT) como UDP (mi servidor VPN), con lo que me ahorro tener que andar instalando y gestionando servicios duplicados en este frontal. Sencillo y eficiente. El diagrama general de cómo ha quedado el entorno es el siguiente:
La configuración a nivel interno sí que tiene algunos puntos a tener en cuenta:
stream {
upstream web_server {
server IP_PRIVADA_REMOTA_ZEROTIER:443;
}server {
listen 443;
ssl_preread on;
proxy_pass web_server;
}upstream mqtt_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1883;
}
server {
listen 1883;
proxy_pass mqtt_server;
proxy_connect_timeout 1s;
}upstream vpn_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
stream {
upstream vpn_server {
server IP_SERVIDOR_LOCAL_VPN:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
En realidad, me gusta tanto cómo ha quedado configurado, que es posible que lo deje así incluso cuando se solucione el tema del CG-NAT, ya que añade una capa extra de seguridad y disponibilidad a mis sistemas.
Referencias:
How to bypass CGNAT and expose your server to the internet using ZeroTier, a VPS and NGINX
Bypassing a CGNAT with Wireguard (Especialmente útil para la parte de configuración del entorno en Oracle Cloud)
How to set nginx reverse proxy to an SSL site without certificate?
Etiquetas: cg-nat, iot, mqtt, nginx, oracle cloud, vpn, vps, wordpress, zerotier
Con el nivel tan disparatado de precios que están alcanzando los combustibles en estas fechas, es interesante tener una manera rápida de consultar los precios en diferentes estaciones de servicio, a fin de poder reposar en la que más nos convenga. Por razones de trabajo y sus subsecuentes desplazamientos, hay varias gasolineras que nos interesa a Ana y a mí tener monitorizadas. Existe una página del Ministerio para la Transición Ecológica (Geoportal de Gasolineras) que permite acceder a los precios de todas las estaciones de servicio de España, pero que no es especialmente usable para hacer consultas rápidas y recurrentes de las mismas estaciones, ya que lo que hace es desplegar un mapa y un buscador, pero que no proporciona URLs de acceso directo ni nada que se le parezca.
Al menos, no lo hace a la vista del usuario. Pero si trasteas un poco con el funcionamiento de la página, es posible ver que sí se hace uso a nivel interno de URLs únicas que proporcionan en el mapa los valores de cada una de las gasolineras en formato XML, para poder reflejar dichos valores al pulsar sobre las gasolineras, con un aspecto como este:
Y ya teniendo esta información, haciendo uso de Node Red es sencillo procesar los parámetros, jugar un poco con ellos, e insertarlos en topics MQTT. En mi caso, me quedo con el valor de la gasolina sin plomo 95, de tres estaciones de servicio determinadas, realizando consultas una vez a la hora para cada una de ellas.
Por último, al existir esta información en un topic MQTT, es sencillo consumirla desde Home Assistant. En mi caso, he optado por mostrarla en tres diales, para que sea sencillo comparar los precios entre estaciones. Además, como valor añadido, me guarda el histórico de cotizaciones y cuándo se produjeron cambios en las mismas.
Con todo esto, es sencillo comprobar el precio de los combustibles en nuestro Home Assistant, al que accedemos desde nuestro móvil, de un solo vistazo, y escoger el sitio óptimo para repostar. Estoy pensando en darle una vuelta de tuerca, e integrar un sistema de consulta en los sistemas de infoentretenimiento de los coches, pero eso quedará para otra ocasión.
Etiquetas: home assistant, mqtt, node-red
En fechas recientes he realizado un aprovechamiento interesante de las capacidades de comunicación que proporciona el servidor MQTT que tengo instalado para diversos temas: el envío de imágenes a través del mismo. en principio no es algo para lo que esté pensado un servidor MQTT, que actúa como servidor de mensajería, mediante la suscripción a una serie de topics, mediante los cuales clientes del servidor MQTT pueden intercambiar información en formato texto. Pero como al fin y al cabo, las imágenes no dejan de transmitirse como información codificada, es posible ponerse algo creativo para conseguir su procesamiento correcto.
En mi escenario, se trataba de compartir información proveniente de una webcam, para integrarla en mi sistema de domótica. En otras circunstancias, consumiría la información directamente de la webcam, pero el servidor de domótica y la webcam se encuentran en ubicaciones geográficas distintas, y la red de la webcam se encuentra tras un CG-NAT, por lo que no es posible establecer una publicación directa de puertos. Existe la posibilidad de establecer una VPN, pero esta opción me parecía bastante más interesante. La webcam se trata de una ESP32-CAM, con capacidad para publicar imágenes tanto en formato streaming como imágenes individuales, y acceder a ellas a través de una URL concreta. Mi idea era aprovechar la capacidad de Python de convertir imágenes a arrays de bytes, y volcar la información a un topic MQTT específico, para su posterior consumo. Consumo que en una primera instancia sería una publicación directa en Home Assistant, pero que posteriormente se vio complementado con una idea adicional interesante.
Codificación y envío de la imagen por MQTT
La primera parte de este proyecto consiste en el volcado de la información de la imagen en un topic MQTT. En mi caso, aprovechando que dispongo de un servidor Orange Pi Zero instalada en Forcarey para controlar diversos dispositivos Zigbee, creé un pequeño script en Python que toma una captura de imagen de la ESP32-CAM, la vuelca en un fichero temporal, y posteriormente la codifica como un bytearray, para enviarla a un topic MQTT concreto. El código sería el siguiente:
mport paho.mqtt.publish as publish
from PIL import Image
import requests
from io import BytesIOMQTT_SERVER = “xxx.xxx.xxx.xxx” #Write Server IP Address, or your server FQDN
MQTT_PATH = “path” #Write your MQTT topic pathresponse = requests.get(“http://xxx.xxx.xxx.xxx/capture”) #Write your ESP32-CAM IP address
f=open(“/tmp/image_test.jpg”,”wb”)
f.write(response.content)
f.closef=open(“/tmp/image_test.jpg”, “rb”)
fileContent = f.read()
byteArr = bytearray(fileContent)
publish.single(MQTT_PATH, byteArr, hostname=MQTT_SERVER)
f.close
Bastante sencillo. Para no andarme loco con servicios en linux, me limito a invocarlo desde /etc/crontab una vez cada 5 minutos, aunque se puede programar la frecuencia que se desee.
Captura y publicación en Home Assistant
Una vez tenemos nuestra imagen siendo volcada en el topic MQTT correspondiente, se trata de explotarla de manera adecuada. Y en este caso, Home Assistant nos lo pone bastante sencillo, ya que existe una integración de tipo cámara MQTT directamente incorporada a Home Assistant. Su uso es tan sencillo como indicar el topic del que tendremos que recoger la imagen:
camera:
– platform: mqtt
name: MQTT Cam
topic: MQTT_TOPIC_PATH
El resultado es el que sigue:
En mi caso, una topa del recibidor del piso de Forcarey.
Otros usos: sistema de alarma mediante correo electrónico con Node-Red
Pero estando ya este sistema montado, y merced a algunos detectores de apertura de puertas y ventanas Zigbee que ya tenía previamente instalados, es posible dar una vuelta de tuerca, y hacer algo más interesante: un sistema que detecte aperturas no deseadas de la puerta de la entrada, que tome varias imágenes, y las envíe por correo electrónico a un buzón previamente definido. El proceso es el siguiente: tengo instalado en la puerta un sensor de apertura Zigbee. La información de este sensor es procesada por un servidor Zigbee2MQTT, que vuelca en un topic MQTT la información de cuándo se activa este sensor. Este topic es procesado mediante una automatización en Home Assistant que, cuando se encuentra activada, envía una señal de alarma mediante un segundo topic MQTT. A su vez, tengo un script en Python en la Orange Pi Zero de Forcarey que se encuentra suscrito a este topic, y que cuando detecta una activación del mismo, toma tres imágenes a intervalos regulares, y las envía codificadas como bytearray por un tercer topic MQTT. Y por último, tengo creado en Node-Red un flujo que está suscrito a este último topic, descodifica las imágenes, y las envía a una cuenta de correo como un adjunto.
Admito que tiene que haber maneras más sencillas de hacerlo, pero esta resulta bastante instructiva.
Etiquetas: esp32-cam, home assistant, mqtt, node-red, orange pi zero, python, zigbee, zigbee2mqtt