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
Seguimos con proyectos de IoT y domótica. En este caso, y para el piso de Forcarey, estoy preparando un sistema de control de apertura de puertas y ventanas con dispositivos Zigbee. Para ello, he escogido los sensores Aqara MCCGQ11LM. Son unos dispositivos fiables, razonablemente baratos, y -lo más importante- están perfectamente soportados en Zigbee2MQTT.
Y es que la gracia de todo este asunto es que no voy a hacer uso del gateway propietario de Aqara/Xiaomi. Desde hace ya algún tiempo tengo experiencia haciendo uso de Zigbee2MQTT como gateway de código abierto para algunos dispositivos Zigbee que tengo instalados en Santiponce, y la idea -como no podía ser menos- era hacer uso de la misma tecnología en Forcarey. Para ello estoy diseñando un pequeño dispositivo, basado en una placa Orange Pi Zero, que actúe como gateway de los dispositivos que voy a desplegar en el nuevo piso.
Sí, el dispositivo con conectividad HSDPA que comentábamos en el artículo anterior.
En lo referente a la instalación de Zigbee2MQTT, en líneas generales basta con seguir las instrucciones de instalación que proporciona la web oficial, con una salvedad: en la versión de Armbian que manejo (Buster 20.08.1 con versión de kernel 5.8.5) a la hora de compilar Zigbee2MQTT daba algunos errores con serialport y node-gyp, que están reportados. En mi caso ninguna de las soluciones propuestas funcionaba. Lo único con lo que conseguí hacerlo funcionar fue ignorando la parte de usar el repositorio de Node.js que se indica en las instrucciones en el apartado 2 de las mismas, e instalar tanto Node.js como específicamente node-gyp desde los repositorios oficiales de Debian. De esta manera todo el proceso de instalación concluyó correctamente.
Una vez concluida la instalación, creé el servicio para iniciar automáticamente Zigbee2MQTT al inicio del sistema, asocié los dispositivos, que fueron reconocidos sin mayor inconveniente, con lo que el proceso de configuración del hardware ha quedado concluido. En cuanto al software, el sistema de notificación de actividad de los sensores, en base a recepción de eventos de los dispositivos y su volcado a un servidor MQTT, está concluido. Los eventos se muestran de la siguiente manera:
…lo que nos permite, a partir de aquí, crear el sistema de notificaciones. ¿Cómo lo voy a hacer en mi caso? Con el estupendo software Home Assistant, que constituye la base de mi sistema de domótica. Pero eso ya quedará para otro artículo.
Etiquetas: aqara, armbian, debian, domótica, forcarey, home assistant, iot, MCCGQ11LM, mqtt, node.js, orange pi zero, zigbee, zigbee2mqtt
Seguimos con las adaptaciones a IoT. Otra de las que he realizado recientemente es la integración en mi sistema de domótica basado en Home Assistant de un difusor de aceites esenciales controlado por infrarrojos. A principio de verano le regalamos uno de estos difusores a mis cuñados para su casa, pero como también nos gustó para la nuestra, nos decidimos a comprar uno. Elegimos un modelo en Amazon con iluminación y control remoto por infrarrojos, un Tenswall de 500 ml.
Por lo que he podido averiguar, es un modelo bastante estandarizado vendido bajo multitud de marcas y fabricantes: se basa en el uso de frecuencias ultrasónicas para producir una vaporización del agua y los aceites esenciales a ella añadidos, generando una niebla que esparce las esencias, pero sin calentar el agua colocada en el depósito. Existen otros modelos más avanzados que integran capacidad WiFi y controlable desde una aplicación en el teléfono móvil, basado -por lo que recuerdo- en un ESP8266, pero el modelo que nosotros adquirimos tan sólo cuenta con capacidad IR. En realidad, una ventaja para lo que estaba buscando. El modelo que nosotros adquirimos tiene las siguientes funciones:
Para realizar la adaptación a IoT, lo primero fue capturar los códigos IR enviados por el mando a distancia. Para ello utilicé un receptor IR y una librería arduino que ya en su momento empleé para leer códigos del aire acondicionado. Capturé cada uno de los códigos asociados a los comportamientos indicados más arriba. Los adjunto por si a alguien más le sirvieran, en formato raw, y su equivalencia en protocolo NEC:
Posteriormente pasé a crear un código arduino que se suscribe a un topic MQTT específico con el que se interactúa con el difusor. La idea es crear en Home Assistant un objeto que implemente las funciones del mando a distancia, y mapear los comandos enviados desde Home Assistant a los códigos IR anteriores. En Home Assistant, basta con crear un objeto de tipo luz, que implemente las funciones anteriormente descritas:
light:
- platform: mqtt
schema: json
name: Oil Diffuser & Light
state_topic: "<topic>"
command_topic: "<topic>/set"
brightness: true
rgb: false
effect: true
effect_list: [intermittent,continuous,timing,big/small,stopLight,lightOff]
…lo que genera una entidad con el siguiente aspecto:
Posteriormente, es necesario crear en Arduino un código que sea capaz de suscribirse al topic definido en Home Assistant, y reacciones a la información JSON enviada por éste. En realidad, todos los casos posibles son bastante sencillos. El caso que más complejidad tiene es el correspondiente a la luz, ya que el mismo botón/código sirve para encender la luz LED (que siempre empieza en carrusel de colores) y para rotar entre los 16 colores disponibles. En mi caso opté por mapear el deslizador de brillo definido (sin hacer uso de la paleta cromática) para escoger entre las 16 opciones de iluminación, más el modo continuo. En mi caso, opté por lo siguiente:
Por último, es necesario cargar el código en un ESP8266, equipado con un emisor IR. Dado que el difusor de aceites que yo escogí dispone de abundante espacio, es bastante sencillo colocarlo. En mi caso, el difusor se alimenta con un transformador de 24v en continua, que no se puede utilizar directamente para alimentar al ESP8266. En mi caso, opté por utilizar un buck converter DC-DC de 24v a 3.3v, con lo que queda solventado el problema de la diferencia de voltaje. ¡Y listo! Con todo esto es posible controlar un difusor de aceites simple desde la domótica de la casa.
Etiquetas: difusor de aceites, domótica, esp8266, home assistant, infrarrojos, iot, json, mqtt
Estos días he estado juegueteando un poco con un viejo robot de limpieza doméstico del Lidl, un Dirt Devil. Es un robot de limpieza bastante básico, con algo ya de tiempo a sus espaldas. No dispone de ninguna capacidad de integración con sistemas de domótica, ni nada que se le parezca. Es más, ni siquiera tiene WiFi. Pero tiene algo interesante: su funcionamiento se basa en el uso de un chip etiquetado como RV285R, que controla toda una placa de circuitos integrados para realizar las funciones del robot: movimiento de los cepillos, ventilador de succión, detección de golpes, sensores de vacío para que no se caiga por escaleras… El caso es que buscando un poco por Internet, encontré un par de páginas sumamente interesantes sobre cómo reemplazar este chip por un sistema Arduino. Así que aprovechando que sigo de vacaciones, no podía menos que dedicar algo de tiempo al asunto.
De acuerdo a la información compartida por Paijmans, el chip RV285R trabaja a 5 voltios, por lo que es posible hacerlo funcionar directamente en dispositivos Arduino. Con un trabajo de ingeniería inversa, fue capaz de obtener la información de a qué se dedican los pines del chip:
Yo he podido refinarlo un poco más, distinguiendo las funcionalidades de los pines:
Una vez identificados los elementos del chip, era hora de abrir el robot. Se puede apreciar el chip en la parte central de la placa:
Aunque en Paijmans indican que es posible puentear cada una de las patas del chip y conectarlas directamente al arduino (ya que éste tiene más fuerza en las señales que las que pasa el chip), en mi caso he optado por desoldarlo, y conectarle cables de prototipado. Aunque en un principio parecía una buena idea, al poner de nuevo las carcasas del robot, en mi caso saltaron un par de soldaduras de sus pistas, por lo que tuve que hacer trabajo extra de soldadura. Recomiendo soldar directamente al cable:
Una vez soldados los cables, el siguiente paso es el dispositivo Arduino. He optado por hacer uso de un Wemos D1 Mini Pro, de la familia de los ESP8266, ya que proporciona capacidades WiFi, y viene sin los bornes para los cables de prototipado, por lo que podía soldar directamente los cables para ahorrar espacio. Para la lógica del mismo me he basado en la creada por Conrad Vassallo (Converting a cheap Vacuum Robot into IoT) en su proyecto de domotización, ya que está preparado para integrar directamente en un sistema de domótica Home Assistant.
Algunos comentarios:
Esquema de conexiones del D1 Mini Pro. Atención al uso del pin D4 para el envío de datos como puerto serie desde el Arduino IDE
Por último, queda la parte de Home Assistant. Con añadir el siguiente código a la configuración, el sistema estará preparado para interactuar con el robot:
vacuum:
- platform: mqtt
command_topic: "vacuum/command"
battery_level_topic: "vacuum/state"
battery_level_template: "{{ value_json.battery_level }}"
charging_topic: "vacuum/state"
charging_template: "{{ value_json.charging }}"
cleaning_topic: "vacuum/state"
cleaning_template: "{{ value_json.cleaning }}"
docked_topic: "vacuum/state"
docked_template: "{{ value_json.docked }}"
error_topic: "vacuum/state"
error_template: "{{ value_json.error }}"
El intercambio de información entre el robot y Home Assistant se realiza mediante MQTT. A continuación se puede ver una captura de los datos intercambiados:
¿Y el resultado? Espectacularmente bueno. Dejo un par de vídeos. El primero, con el robot aún abierto, y con una Victorinox haciendo de contrapeso, ya que si no, los sensores de vacío entran en funcionamiento:
…y el segundo, ya con las carcasas colocadas, y probando algunas funcionalidades adicionales, como la limpieza específica en un punto concreto:
Fuentes:
Etiquetas: arduino, dirt devil, domótica, esp8266, home ass, home assistant, iot, mqtt, rv285r, wemos d1 mini pro
Estos días he estado de vacaciones en Galicia, donde he podido seguir con las pruebas de alcance con tecnología LoRa. Estas pruebas consistieron en la repetición de la efectuada en Santiponce el pasado mes de mayo, pero sustituyendo la orografía prácticamente plana de Sevilla por una zona montañosa de las cercanías de Pontevedra.
Vehículo y entorno de pruebas. Nótese la antena LoRa en la parte frontal del techo del vehículo
En realidad, se realizaron dos pruebas distintas: una de corto alcance, y una de largo alcance. En ambos casos se utilizaron los siguientes elementos y escenario:
Éste sería un esquema de los dispositivos implicados y las comunicaciones entre ellos:
Una vez definido el escenario y elementos de prueba, pasé a definir las pruebas propiamente dichas. Estimé conveniente realizar una primera prueba de corto alcance en las cercanías, y en caso de obtener éxito en la misma, pasar a una segunda de largo alcance.
Prueba de corto alcance. 3,08 km
La prueba de corto alcance consistió en un enlace de una distancia estimada de unos 3 kms, desde una casa situada en la aldea de Vilarchán -Puente Caldelas- hasta el monte de La Fracha, donde se encuentran una serie de antenas y repetidores de radio y televisión. La idea era observar cómo de fiable era la transmisión en este entorno de montaña, con visibilidad directa desde el emisor al receptor, pero con obstáculos consistentes en otras viviendas, zonas arboladas y, en determinados tramos, la propia mole rocosa de la montaña.
Lúa saíndo polo monte da Fracha (Pontevedra), cortesía de Pintafontes
EL objetivo de esta prueba era calibrar el impacto esperable de la diferencia de orografía entre Santiponce y Vilarchán, para determinar el impacto de la misma en la transmisión. Hay que tener en cuenta que en el caso de Santiponce se había observado que se podía obtener, con el mismo equipo de pruebas, un enlace confiable de 4,5 km, y hasta 5,3 km de manera esporádica.
Recorrido en Google Earth de la prueba efectuada
Salimos de Vilarchán con el emisor funcionando, y pronto se perdió la señal, apenas al llegar a la carretera de Pontevedra a Puente Caldelas. Durante todo el trayecto, pasando por el polígono de La Reigosa y la subida a la Fracha, hasta las cercanías del polvorín, no se recibió señal alguna. Una primera decepción. Bajamos del coche y empezamos a andar, camino de las antenas, por la parte de la montaña contraria a la casa. Y ahí, sorpresa, empezamos a recibir datos, si bien con un RSSI muy débil, de -131. Una primera medición de distancia nos dio 3,01 km de distancia en línea recta al emisor, pero con toda la ladera del monte obstaculizando la señal. Proseguimos el ascenso hasta las antenas, sin perder recepción de datos en ningún momento, y con la calidad de la señal mejorando a medida que salíamos de la sombra de la montaña, y ganábamos en línea de visión directa hacia el emisor.
Vista desde las antenas de la zona de pruebas, con la zona aproximada del receptor marcada
Realizamos el ascenso a las antenas por la ladera que daba hacia la zona de la casa. Al llegar a las mismas, siempre sin perder la señal, obtuvimos un enlace de 3,08 km, con un mejor RSSI de -111. Como valor comparativo, en la misma casa y a unos 5 metros de distancia, el RSSI rondaba los -85. En cuanto a la visibilidad, se puede considerar casi directa, y el casi es porque hay algunas edificaciones que se interponen entre el punto donde estaba ubicado el receptor, y el punto donde nos encontrábamos.
Captura de pantalla de la distancia observada con Oruxmaps entre nuestra posición a la ubicación del receptor
Tras verificar durante un rato de la estabilidad de la conexión, y disfrutar un poco de las vistas, emprendimos el descenso hasta el vehículo, si bien esta vez por la ladera opuesta, que dispone de un camino que facilitaba la bajada, y que además nos permitía determinar en qué punto la mole del monte obstaculizaba la señal hasta que ésta se perdiera.
Vistas de la Ría de Pontevedra desde La Fracha
Durante un buen rato de descenso se mantuvo la recepción de la señal, si bien con deterioros del RSSI paulatinos. Perdimos la señal a una distancia de 2,81 km del receptor, si bien con toda la ladera interpuesta entre nosotros y el gateway receptor. Sin embargo, al llegar al coche, volvimos a recuperar la señal, que ya no volvimos a perder en todo el trayecto de vuelta hasta la casa, en gran contraste con la observación realizada a la ida, donde pronto se perdió la señal. Posteriormente, y tras analizar los datos reflejados en Grafana, pudimos ver que en realidad el en trayecto de ida nunca se llegó a perder la señal LoRa entre emisor y receptor, sino que habíamos tenido un problema de falta de datos en el teléfono con el cliente MQTT, que había provocado una desconexión con el servidor MQTT -y una aparente pérdida de datos-. Es decir: que salvo en un punto muy localizado de La Fracha, habíamos tenido enlace LoRa casi de manera constante y sin pérdida de datos, pese a las dificultades del terreno, zonas boscosas y construcciones interpuestas. Una primera prueba sumamente satisfactoria.
Prueba de largo alcance. 7,2 km
La segunda prueba era la verdaderamente significativa: intentar un enlace directo con un grupo de antenas de radio, ubicadas a una distancia aproximada de 7 kilómetros, con línea directa de visión, en torno a un 60% más de distancia que las pruebas efectuadas en Santiponce.
Vista desde la antena del receptor, con la zona prevista del emisor marcada
Si bien la distancia en línea recta entre ambas ubicaciones ronda los 7 km, es preciso realizar unos 13 km de recorrido para poder llegar de la una a la otra, debido a orografía del terreno y las vías de comunicación existentes, como se puede apreciar en el recorrido de etapa trazado en Google Earth:
Para esta segunda prueba movimos la ubicación del receptor a una ventana con visibilidad directa de la zona de pruebas, con el objetivo en mente de dirigirnos a una zona de repetidores ubicada en el Monte Catadoiro, cerca de Rebordela. La diferencia es que esta vez podríamos ir directamente con el coche hasta la zona escogida. Dicho y hecho, salimos en dirección Puente Caldelas. Y al igual que en la primera prueba, perdimos la recepción de datos justo al llegar a la carretera. Y al igual que en el caso anterior, estuvo motivada por la pérdida de datos del teléfono Android. Al llegar a las antenas, pudimos ver que el cliente MQTT se había desconectado. Y al volver a conectar… ¡éxito! Los paquetes llegaban sin pérdida, y con un RSSI espectacularmente bueno, de -115 en el mejor de los casos. Tras las pertinentes comprobaciones, verificamos que habíamos logrado un enlace de 7,23 km con línea directa de visión.
Primeros paquetes recibidos en el cliente MQTT una vez restablecida la conexión
Captura de Oruxmaps en la que se aprecia la distancia alcanzada
En las antenas
Estuvimos un rato en las antenas, observando el comportamiento de los datos: sin pérdidas, y con un RSSI que hace pensar que es posible mantener distancias aún mayores de manera confiable. Si no pudimos ir más lejos fue porque la montaña ya no daba para más. Disfrutamos un rato de las vistas, y poco después emprendimos el regreso.
Vista de la zona aproximada del gateway, a través de unos prismáticos
Vista de la ría de Vigo, con el puente de Rande y las Islas Cíes al fondo
Y de nuevo la sorpresa vino en el trayecto de vuelta. Durante todo el recorrido, de casi 14 kilómetros, por zonas boscosas, sin visibilidad directa, con laderas, bosques y pueblos entre medias, no se perdió la señal en ningún momento, como pudimos verificar consultando Grafana. Esto incluye el paso por Puente Caldelas, en la más profundo del valle del Río Verdugo, y en un entorno completamente urbano y sin visibilidad directa, a más de 5,5 km de distancia desde el gateway; y también en la central hidroeléctrica de Hidrofreixa, a 5’3 km, aunque en este caso con visibilidad directa.
Estación de bombeo de Hidrofreixa
Enlace desde Hidrofreixa, de 5,48 km
En lo referente a los datos de Grafana, en esta captura se ven las gráficas de pulsaciones:
Por cierto, que en realidad mis pulsaciones no son tan altas, sino que he observado que mientras no empiezo a sudar en serio el pulsómetro muestra exceso de pulsaciones al alza. En cuanto a los huecos, el correspondiente a las 16:48 a las 16:57 es una de las zonas de sombra de La Fracha, lo mismo que el de pasadas las 17:30. El de las 17:46 a las 18:03 corresponde al tiempo entre prueba y prueba (con cambios de ubicación de antenas y resto de elementos), y los dos huecos posteriores a momentos en que el pulsómetro Bluetooth salió del rango de alcance del emisor LoRa.
Y para cerrar, tenemos ya planificadas nuevas pruebas de alcance: en este caso, a dos campos de aerogeneradores, ubicados a 15 y 25 km de distancia desde Vilarchán. Pero de eso ya hablaremos en otro momento…
Etiquetas: catadoiro, grafana, heltec, iot, json, la fracha, lora, lorawan, mqtt, oruxmaps, puente caldelas, rssi, vilarchán