Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.
Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.
Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.
Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:
Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.
Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.
Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.
¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:
…y en el caso de Forcarey:
No está mal, ¿no?
Etiquetas: aldi, aqara, aqara cube, arduino, asus tinker board, debian, domótica, home assistant, ikea, lidl, mqtt, nodemcu, orange pi zero, proxmox, raspberry pi, zigbee, zigbee2mqtt
Comentaba en un artículo anterior de la serie que había implementado un gateway LoRa*. Y no me faltaba razón. Estaba haciendo uso del protocolo LoRa de enlace basado en 868 MHz para enviar señales de entre un nodo emisor y un receptor, y de este último a un servidor MQTT. ¿Cuál es la diferencia? La más importante es que no estaba realizando ningún tipo de verificación de nodos, sin ni siquiera molestarme en verificar cuál es el emisor y cuál el receptor. Y ni hablemos de cifrado de comunicaciones ni nada que se le parezca. Pero para las pruebas preliminares que venía efectuando, en lo que el aspecto importante era verificar alcance entre nodos, sobraba y bastaba. Por cierto, para ver más detalles de las diferencias entre LoRa y LoRaWAN, tengo otro artículo dedicado a tal efecto.
Pero para este proyecto necesitaba dar un paso más allá, e implementar un verdadero gateway LoRaWAN. Y eso implicaba hacer uso de una red LoRaWAN, que proporcione su servidor de procesado de tráfico de red, y te permita explotar los datos enviados desde los dispositivos. Cuando te enfrentas a esto, tienes dos posibilidades: o te implementas la red, o te conectas a una ya existente. Sobre la primera opción ya hablaremos más adelante, en un artículo al respecto, pero para salir rápidamente del paso hice uso de la segunda. Existe una red pública a la que puedes conectar gateways y dispositivos LoRaWAN, que es la red The Things Network, o TTN. Cuando te registras como usuario, puedes añadir a la red tanto dispositivos como gateways. Si haces lo primero, dependes de que haya algún gateway cercano a ti para que tus dispositivos envíen datos a la red. Pero si no tienes ningún gateway a tu alcance, no te queda otra que implementar un gateway, y conectarlo a la red. Que es precisamente de lo que va esta serie.
Tengo que decir algo desde un principio: estoy haciendo trampas. Una de las especificaciones del protocolo LoRaWAN es que a la hora de establecer un enlace entre dispositivo y gateway se puede utilizar de manera aleatoria cualquier canal de la banda que estés utilizando. En el caso de Europa, la banda es la de 868 MHz, y existen 9 canales dedicados a tal efecto (aunque en realidad son 8+1). La razón para ello es evitar la congestión en cualquiera de los canales, siendo la red la encargada de analizar esta circunstancia, y la responsable de tomar las medidas necesarias (cambio de canal) para solucionarlo. Para ello, la idea es que cuando se configura un nuevo gateway, tu hardware tiene que estar preparado para operar en estos canales. El problema, en mi caso, es que el hardware del que dispongo sólo es capaz de funcionar en un solo canal. ¿Y cuál es este hardware? Nuestro viejo amigo el Heltec LoRa 32.
Tras trastear un poco por Internet, encontré un proyecto bastante interesante de Things4U que consiste exactamente en eso: implementar un gateway de un solo canal. Por supuesto, es un proyecto experimental que no debe usarse en un sistema en producción, pero para mis propósitos de investigación basta y sobra. La instalación es bastante sencilla: tan simple como descargar el código (viene con todas sus librerías), y en el caso de Arduino, hacer lo siguiente:
Captura de pantalla de la web de administración del gateway
Si todo ha ido bien, tu gateway se conectará a la red TTN (donde es preciso configurar tu gateway, aunque por lo que he visto no parece interactuar demasiado bien con la información de estado del mismo), y es cuestión de encender un dispositivo, empezar a emitir, y ver entrar los paquetes en tu aplicación:
…sí claro. Ojalá. Y es que hay un pequeño problema. Con esto hemos configurado nuestro gateway para que trabaje en un solo canal, pero por defecto nuestro dispositivo trabajará en cualquier canal de la banda, de manera aleatoria. Y esto implica que sólo vamos a recibir, estadísticamente hablando, 1 de cada 9 paquetes enviados. Una tasa bastante baja. ¿Cuál es la solución? Obviamente, forzar al dispositivo a emitir en una sola banda. Existe un tutorial de Sparkfun que lo explica bastante bien, pero para el caso de los dispositivos Heltec LoRa es necesario trastear un poco más, y especificar los valores del dispositivo:
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 35, 33},
};
…y con eso, ¡listos! Bueno, casi. Para los Heltec LoRa 32 vale, pero por desgracia no para los Cube Cell que estoy empleando, ya que las implementaciones de la librería LMIC que he encontrado no parecen funcionar bien con estos dispositivos. ¿La solución? Ser un poco más imaginativo. En mi caso, he modificado los parámetros de la librería LoRaWan_APP del fabricante, para hacer que todas las definiciones de la banda de 868 MHz trabajen exactamente en la frecuencia del canal 0, que es que se utiliza por parte del servidor. En concreto, se trata de localizar el fichero RegionEU868.h (en el directorio packages\CubeCell\hardware\CubeCell\1.x.0\cores\asr650x\loramac\mac\region), y modificar lo siguiente:
#define EU868_LC1 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
/*!
* LoRaMac default channel 2
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC2 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
/*!
* LoRaMac default channel 3
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC3 {868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
#define EU868_LC4 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC5 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC6 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC7 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC8 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
Sí, es una ñapa. Pero una ñapa que funciona. Una vez hecho esto y subido el código al Cube Cell, todo va como la seda. Y aprovechando que me encontraba en Córdoba, me decidí a hacer algunas pruebas adicionales de transmisión de datos: un verdadero (bueno, de aquella manera) gateway LoRaWAN conectado a la red TTN, y un dispositivo emitiendo de manera periódica una información sencilla (00 01 02 03). La idea era probar la transmisión en un entorno urbano, con orografía acusada, y sin visibilidad directa, y con el emisor haciendo uso de las antenas por defecto que proporciona el fabricante. Nada de antenas avanzadas. Y el resultado fue bastante mejor del esperado. EL sistema pudo cubrir sin interrupciones todo el parque de la Asomadilla con un único gateway, incluso en zonas donde la curvatura del terreno oculta de manera total el emisor del receptor.
Emisor en el punto más alejado del parque
Como comentaba, el sistema fue capaz de proporcionar cobertura en todo el Parque de la Asomadilla de Córdoba.
Imagen de la zona cubierta
Es de esperar que en una zona con una ubicación óptima (zona alta del parque) la zona de cobertura fuera muy superior. Pero eso ya quedará para otro día.
Etiquetas: 868 MHz, arduino, cubecell, heltec, lora, lorawan, the things network, ttn
Para este proyecto estoy utilizando como nodos LoRaWAN unos dispositivos CubeCell de Heltec. En concreto estoy haciendo uso de las Dev-Board (HTCC-AB01), que integran el patillaje necesario para conectar de manera sencilla los CubeCell a un ordenador para cargarles el código necesario.
Estos dispositivos hacen uso de un chiop ASR6501, que integra una MCU PSoC de la serie 4000 (ARM® Cortex® M0+ Core), y el chip LoRA SX1272. La principal ventaja es que son completamente compatibles con Arduino, tienen capacidad para ser alimentados directamente por batería o un pequeño panel solar (desde 5.5 a 7v), y un consumo realmente bajo: 10 mA en modo recepción LoRa, 70 mA emitiendo a 10 dB, y apenas 3.5uA en modo Deep Sleep, lo que los hacen muy adecuados para entornos de muy bajo consumo energético. Además dispone de 8 puertos de E/S, UART, SPI e I2C, además de otras características bastante interesantes.
Sin embargo, y a pesar de que los dispositivos están bastante bien, tienen agún inconveniente con respecto a los Heltec LoRa 32. Los más importantes es que carecen de interfaz WiFi y de Bluetooth. No es demasiado grave, ya que no están pensados para ser dispositivos multiconexión -para eso están los LoRa 32 con su chip ESP32-, sino para priorizar el bajo consumo.
En cuanto a la programación, se puede realizar mediante el IDE de Arduino, como cualquier otro dispositivo. Hay que tener en cuenta, que su programación difiere ligeramente con respecto a los Heltec LoRa 32. Esto tiene un par de implicaciones: la primera es que no se hace uso de la librería Heltec, sino que se utiliza una librería específica (LoRaWan_APP), que la declaración del objeto LoRa es distinta, siendo necesario especificar manualmente determinados parámetros que en el caso de la librería Heltec ya vienen dados muchas veces por defecto, y que sólo es necesario declarar en caso de querer utilizar valores distintos.
#define RF_FREQUENCY 868000000 // Hz
#define TX_OUTPUT_POWER 14 // dBm
#define LORA_BANDWIDTH 0 // [0: 125 kHz,
// 1: 250 kHz,
// 2: 500 kHz,
// 3: Reserved]
#define LORA_SPREADING_FACTOR 8 // [SF7..SF12]
#define LORA_CODINGRATE 4 // [1: 4/5,
// 2: 4/6,
// 3: 4/7,
// 4: 4/8]
#define LORA_PREAMBLE_LENGTH 8 // Same for Tx and Rx
#define LORA_SYMBOL_TIMEOUT 0 // Symbols
#define LORA_FIX_LENGTH_PAYLOAD_ON false
#define LORA_IQ_INVERSION_ON false
#define RX_TIMEOUT_VALUE 1000
#define BUFFER_SIZE 30 // Define the payload size here
La segunda diferencia, como comentaba en el artículo anterior, es que es necesario definir también ciertas configuraciones específicas, precisamente relacionadas con estos parámetros, en la parte del gateway, para garantizar la compatibilidad de las comunicaciones entre ambos dispositivos. No es que haya sido un gran problema, pero me trajo un rato de cabeza hasta que encontré algo de documentación que me hizo la luz a este respecto.
Hay otros dos aspectos finales que quería comentar, también relativos al hardware:
Etiquetas: antena, arduino, cubecell, esp32, heltec, lora, lorawan
Seguimos haciendo progresos con mi gateway LoRaWAN. En este caso, en el ámbito del gateway en sí. El lector avispado habrá notado que he encabezado este artículo con Lora* en vez de con LoRaWAN. Y es que en este punto lo que tengo implementado es más bien un gateway LoRa que actúa de pasarela a un servidor MQTT, y no un gateway LoRaWAN propiamente dicho. ¿Cuál es la diferencia? Es sutil, pero importante. A estas alturas lo que he implementado es un gateway, sí, entre dispositivos, y terceros servidores, pero no realizo aún control de acceso, identificadores de equipos en la red, ni nada por el estilo. Así que no puedo -en realidad- considerarlo un gateway LoRaWAN completo. Pero de momento, para el propósito que manejo, basta y sobra.
Ya he hablado con anterioridad del dispositivo que estoy utilizando para construir el gateway: se trata de una placa Heltec Lora 32, que proporciona capacidad de conexión LoRa, WiFi y Bluetooth, incluyendo la variante Low Energy. Con anterioridad he estado haciendo pruebas con la variante de 433 MHz, pero para este proyecto en cuestión he optado por respetar la normativa radioeléctrica europea, y desplegarlo con la variante de 868 MHz, de la que disponía de un dispositivo que hasta ahora no había hecho un gran uso (en parte porque vino con la pantalla OLED quebrada, y ésta funciona bastante mal). Otro elemento de la configuración es la antena de recepción y el adaptador eléctrico, pero estos elementos quedarán para otro artículo.
En lo referente al software, he desarrollado un software con las siguientes características:
En cuanto a la recepción de datos, ha sido sumamente exitosa. En el código de ejemplo utilizado en el cliente, se envía una trama compuesta de dos valores en hexadecimal, que son inyectados en un topic MQTT, junto con el valor del RSSI de la transmisión, a fin de controlar la calidad de la misma. El servidor MQTT se encuentra completamente ajeno al sistema, siendo un servidor multifunción que utilizo para diversos proyectos.
El resultado es, hasta ahora, bastante bueno. En próximos capítulos hablaré de otros elementos del sistema.
Etiquetas: arduino, cubecell, firmware, fota, gateway, heltec, lora, lorawan, mqtt, on-the-air
Una de las primeras cosas que tuve clara cuando me decidí a instalar un gateway LoRaWAN en casa es que el proyecto tendría que estar sostenido por energías renovables. Mi intención es colocar la antena del dispositivo en el punto más alto de la casa, en la chimenea de evacuación de gases de los cuartos de baño, y eso implica que esa ubicación no dispone de toma eléctrica. Sería posible hacer uno de un cable largo para llevar la conexión de la antena a un punto donde disponga de alimentación eléctrica, o bien sacar una derivación de la alimentación del aire acondicionado que tengo en la buhardilla. Pero seamos sinceros: no es tan interesante como plantearse un sistema de alimentación renovable (y en el primer caso, nos enfrentamos a una más que posible caída de la eficiencia de la antena, por el solo hecho de utilizar un cable más largo del estrictamente necesario). Y en este caso, el sistema elegido ha sido la energía solar.
No es este -bien lo sabrá quien me haya seguido a lo largo de los años- un proyecto estrictamente nuevo para mí. Hace ya años que tuve la idea de montar un aerogenerador en el tejado, con el que estuve haciendo una serie de pinitos en casa. Pero la verdad sea dicha, no fueron unas pruebas demasiado exitosas. Tuve durante un tiempo la iluminación de la casa alimentada por energía eólica, apoyada por un panel solar, pero fue un intento demasiado prematuro: la iluminación que teníamos por aquel entonces era principalmente de lámparas electrónicas, y en la práctica la cantidad de aire en Santiponce no bastaba para generar la energía suficiente como para que el aerogenerador produjera la corriente necesaria. Aquel proyecto quedó abandonado cuando nos fuimos a Irlanda, pero me dejó algunos componentes que he podido reaprovechar.
El principal es un panel solar de 100W que adquirí como sistema de apoyo para el aerogenerador. Éste sí que funcionaba espectacularmente bien. Incluso tuve durante un tiempo conectado un portátil al sistema de baterías que utilizaba, haciendo uso de un inversor. Pero en la práctica, el sistema tenía bastantes ineficiencias, y el portátil apenas aguantaba unas cuantas horas encendido antes de drenar completamente la batería. En su momento, para colocarlo en el tejado, me hice construir un bastidor metálico que anclé al lateral del tejado. En su día desmantelé el panel y lo guardé en Córdoba, pero el bastidor se quedó colocado (estaba fijado con pernos y tacos químicos, como para quitarlo de ahí), y allí estuvo durmiendo el sueño de los justos. Pero lo he traído de vuelta para este proyecto. Ha sido toda una sorpresa ver el bastidor, que seguía en perfectas condiciones en el tejado.
El segundo elemento, cómo no, ha sido el controlador de carga y la batería. El controlador es el proveniente de mi instalación eólica. En su momento adquirí un controlador dual, capaz de gestionar la carga proveniente de un aerogenerador trifásico en alterna y de un panel solar de 12 voltios en continua. Como es obvio, no estoy haciendo -ni lo voy a hacer- uso del aerogenerador, pero sí de la parte solar. Tras 5 años desconectado, tenía mis dudas de si seguiría funcionando. Pero lo hace, y perfectamente.
Por último, la batería: es una batería convencional de coche, de 12 voltios, proveniente de mi añorado Alfa 33. Estaba nueva cuando el coche se vendió en 2017, y estaba igualmente criando polvo en Córdoba. Ha sido necesario someterla a un ciclo de carga, pero de momento parece que está bien. He colocado tanto el controlador como la batería en una caja -ejem- estanca, con la idea de protegerlos de la lluvia. Me preocupa en cierta medida el posible calentamiento al que puedan estar sometidos, pero se han tirado varios días al sol, probando el nivel de calentamiento, y el resultado ha sido satisfactorio. En cualquier caso, este es un proyecto experimental, con idea de probar precisamente estas cosas.
EL sistema, por tanto, trabaja a 12 voltios en continua. Dado que voy a utilizar como elemento base para el gateway un dispositivo Heltec con Arduino, que trabajan a 5 voltios en continua, tendré que incorporar un elemento para convertir el voltaje. Probablemente haga uso de un buck converter DC-DC de 24v a 5v, regulable, como el que utilicé en el proyecto del difusor de aceites. Pero eso ya quedará para otro capítulo.
Etiquetas: aerogenerador, arduino, batería, buck converter, conversor, heltec, lora, lorawan, panel solar