Construyendo un Dashboard con Grafana

Artículo publicado originalmente en mi antiguo blog de WordPress.
En este artículo daré una explicación extensa de un proyecto que desarrollé para la Infraestructura Avanzada de Redes de Sensores, una de las materias del máster sobre Smart Cities que realicé en Sevilla en 2020. Aquí la versión en vídeo:
0. Planteamiento del Problema
En el proyecto final para la materia se nos planteó el siguiente problema:
Se requiere diseñar una red de contadores de agua. En este caso, la red es muy homogénea. Una vez definido un contador tienes definidos todos los nodos. Así que, en este caso, la problemática que tienes que trabajar es la cantidad de elementos. Cuando simules la red, debes resolver cómo lo vas a hacer el registro para una cantidad elevada de elementos (usando las formas normales explicadas en bases de datos) y cómo harás el mostrado de datos, que permita tener medidas específicas de un contador, así como datos acumulados para una barriada/ciudad entera.
1. Consideraciones Iniciales

En la Figura 1 se observa un ejemplos de cómo se implementa una red inteligente de agua. En dicho ejemplo, se observa que esta red le permite a la empresa de distribución de agua realizar la medición de los medidores de agua ubicados en esa ciudad. Para ello, se utilizan diversas redes de comunicación, como fibra óptica o GPRS.
El objetivo es diseñar un sistema similar al presentado en la Figura 1. Profundizando en el tipo en los sensores, redes y protocolos. Generando a su vez una simulación que permita observar como se comportaría el sistema.
1.1. Instrumentos de Medicion de Agua

Por normal general, los contadores de agua deben estar ubicados a nivel de la calle, de forma que la empresa encargada de la medición del agua pueda tomar sus medidas sin necesidad de acceder a los pisos. En el caso de edificios residenciales, los contadores de agua usualmente están ubicados en un cuarto de servicios, distribuido por medio de baterías que permiten organizar y hacer accesibles todos los contadores de cada unidad residencial desde un mismo lugar, como se muestra en la Figura 2. En dicha Figura también se observa la forma tradicional en la que se realiza la medición: por medio de un operador contratado por la empresa, cuya función era ir mensualmente, residencia por residencia, tomando nota de la medida de cada uno de los contadores.

Los contadores de agua residencial usualmente están hechos en bronce, internamente tiene un mecanismo que rota cuando el agua pasa a través de él. Suelen ser contadores volumétricos, es decir, que una vuelta del embolo interior representa un volumen de líquido específico. La rotación del émbolo activa a su vez un suiche reed, en donde cada pulso del suiche corresponde a una cantidad precisa de litros de agua.
La pieza plástica que está adosada encima del contador en la Figura 3 tiene tantos los mecanismos para la lectura en sitio, es decir, los números rotativos, como el suiche reed con su mecanismo de transmisión. En la Figura también se observa un cable el cual llevaría la información del contador a un bus me medición, como los puede ser M-bus, Modbus, etc (Se hacen a medida).
1.2. Antecendentes
Antes de empezar el desarrollo de este trabajo es importante repasar algunos proyectos sobre redes inteligentes de agua se ha realizado en la última década en España, por ejemplo:
El grupo Agua de Valencia indica que desde 2012 tiene implementado un sistema de Telegestión de Agua. En un vídeo, indican que su topología es la siguiente:
- En el punto más exterior de su red tienen a los contadores inteligentes, los cuales se conectan entre sí por medio de un bus. Este bus lleva sus lecturas a un concentrador. Estas lecturas se envían semanalmente a centro de medición por medio de radio.
- La empresa Acciona, a la cual hice referencia anteriormente habla aquí acerca de su proyecto conjunto con Aguas de Burgos, cuay información extendida puede verse en la Figura 1. Adicional a esto, el Estado Español aprobó una ley en la cual indica que todos los contadores de agua con más de 12 años de antigüedad tienen 5 años para renovarse. Esto indica que la pertinencia en el desarrollo de este proyecto es más que necesaria actualmente. Más información al respecto aquí.
2. Diseño de Sistema
2.1. Instrumentacion
En el mercado europeo existen múltiples fabricantes de contadores de agua, por lo que se disponen de muchas opciones con prestaciones similares. Para este proyecto se ha seleccionado un contador marca Abering, modelo WS de chorro múltiple, pre equipado para tele medición. En la Figura 3 se observa el contador seleccionado.
2.2. Comunicacion

En la Figura 4 se observa la topología que usualmente se utiliza para realizar la tele-medición de los contadores de una residencia de varios pisos. Puede observarse como los medidores se conectan entre si por medio de un bus (en ese caso M-bus). Luego, esa señal llega a un maestro que se encarga de concentrar las mediciones de todos los sensores. Este módulo maestro puede tener capacidad GSM, y enviar a la empresa de gestión de agua toda la información de los contadores conectados al bus por medio de GPRS o RS232, como se muestra en la Figura.

Una alternativa para el sistema alámbrico de medición es hacerlo por medio de una red inalámbrica, por ejemplo, LoRaWan. En la Figura 5, se observa como la topología que sigue la red es equivalente a la que se tenía en la Figura 4, ya que las mediciones de varios sensores se unen en un concentrador. Luego de que son agrupadas, se transmiten a un centro de datos para su análisis.
Sabiendo entonces que se tienen soluciones equivalentes para el mismo problema, se realizó un análisis para determinar cuál de los dos protocolos se utilizaría para construir la red de tele medición.
3. Selección de Red de Comunicaciones
En la sección anterior se indicó que el costo de los contadores era un costo fijo, ya que casi todos los contadores residenciales disponibles en España tienen un costo aproximado de 35 euros. Los costos variables dentro del proyecto serán aquellos relacionados con los elementos que se necesitan para implementar la red de comunicación
- Opcion 1: Solución M-Bus
Para la solución basada en M-bus se consideró utilizar el concentrador M-Bus Marca Decode, Modelo MM20-GSM. El cual realiza lecturas de hasta 20 esclavos M-bus. En Sevilla la mayoría de las residencias tiene menos de 20 pisos, por lo tanto, este concentrador permitiría agrupar los medidores de agua de un edificio. Lo cual es muy bueno al momento de sectorizar las mediciones.
Dentro de sus prestaciones más interesantes está la posibilidad de realizar la configuración de los mensajes que se enviarán vía GSM por medio de una interfaz de usuario. Esto permite configurar el mensaje SMS únicamente con la información de mayor utilidad para la empresa de distribución.
- Opcion 2: Solución LoRaWan
Para la solución basada en LoRaWan tiene que adosar un módulo de transmisión LoRa al medidor de agua. Esto hace que su precio sea ligeramente superior al medidor que tiene un módulo M-bus. Se profundizará en esto al final de esta sección.
Los concentradores LoRaWan permiten trabajar con muchos más dispositivos que los que los M-bus. Por ejemplo, el concentrador Marca Ursalink, Modelo UG87, puede trabajar hasta con 2000 dispositivos LoRaWan. Esto reduce en gran medida la cantidad de concentradores necesarios para implementar la red. Sin embargo, requiere de una instalación más complicada, ya que los lectores LoRaWan debería tener línea directa con el concentrador.
4. Estimación de Costos
Para poder estimar el costo de la red se decidió limitar geográficamente el área que se quería atender en esta primera etapa. Para ello fue planteada la siguiente pregunta
¿Cuánto me costaría implementar un sistema de tele medición de agua en el Barrio de Triana en Sevilla?
En primer lugar, se quería confirmar si el alcance de los concentradores LoRaWan podría cubrir la zona de Triana. Las especificaciones del concentrador considerado dicen que tiene un alcance de hasta 11km, considerando que los edificios del barrio están contenidos en un área menor a 1.87km² se puede calcular que 1 concentrador es más que suficiente.
Sin embargo, la cantidad de habitantes en Triana es de aproximadamente 49mil personas. Hacer el cálculo de como dividir esas personas en unidades habitacionales, tiendas y bares y demás establecimientos que consumen agua escapa al alcance de este proyecto. Para simplificar decidimos estimar la cantidad de medidores en el área dada a unos 15mil.
- Opcion 1: Solución M-Bus + GSM
Elemento | Unidades | Costo Unitario | Subtotal |
---|---|---|---|
Medidor de agua + Adaptador MeterBus cableado | 15k | 38.00 € | 570000.00 € |
Concentrador M-bus. Marca Decode (Unds = 15k / 20) | 750 | 232.00 € | 174000.00 € |
Interconexión / Instalación / Contrato GSM | 15k | 20.00 € | 300000.00 € |
TOTAL | 1044000.00 € |
- Opcion 2: Solución Lorawan
Elemento | Unidades | Costo Unitario | Subtotal |
---|---|---|---|
Medidor de agua + Adaptador Lorawan | 15k | 42.00 € | 630000.00 € |
Concentrador LoraWan. Marca Ursalink (Unds = 15k / 2000) | 8 | 1100.00 € | 8800.00 € |
Interconexión / Instalación / Servidor Web | 15k | 30.00 € | 450000.00 € |
TOTAL | 1088800.00 € |
Si bien la solución LoRaWan requiere muchos menos concentradores, el costo de instalarlos en los postes, cablear las antenas y contratar el servidor web requerido por LoRaWan es mayor que el requerido para implementar la red M-bus. Adicionalmente, el concentrador M-bus me permite fragmentar y organizar mis mediciones, agrupándolas por edificaciones que se encuentren cercanas geográficamente.
Dado el presupuesto estimado y la facilidad para agrupar las mediciones de los sensores, el desarrollo del proyecto se hará por medio de Meter Bus, es decir, la OPCIÓN 1.
5. Almacenamiento de Datos
Para describir la arquitectura de datos de la red que vamos a construir, es necesario tomar en cuenta los siguientes factores
- Hay varios distritos dentro de una ciudad. En cada distrito se encuentra N concentradores
- Cada concentrador puede agrupar hasta 20 medidores de agua
- Cada medidor de agua realiza al menos una lectura semanal y presenta la cantidad de agua que ha consumido desde la última vez que se realizó la medición.
Por medio de queries se puede construir una tabla donde se almacenen las lecturas históricas de cada distrito y de cada cliente. Semanalmente, la tabla debería replicarse y guardarse para acceder a los históricos de cada cliente y también para calcular los agregados por distrito.
Puesto que en este caso se va a estar trabajando con una simulación del sistema, se va a trabajar con la tabla de históricos o ‘logs’.
log_id | log_date | slave_id | master_id | district_id | water_amount |
---|---|---|---|---|---|
1 | 2020-06-01 10:05:00 | 1 | 1 | 4 | 300 |
2 | 2020-06-01 10:15:00 | 3 | 2 | 2 | 200 |
3 | 2020-06-01 10:25:00 | 2 | 1 | 4 | 400 |
El slave_id indica el medidor de cada cliente. El master_id es el identificador del concentrador y el district_id es el identificador de los barrios dentro de Triana. Por medio de relaciones se podrían extraer los nombres completos de cada uno de los elementos antes indicado
6. Simulación de la Propuesta

Para simular el funcionamiento del sistema se decidió utilizar la distribución que se muestra en la Figura 6. La generación de datos dentro del sistema se hará por medio de Node-RED. El flow construido se muestra a continuación y está disponible en el siguiente repositorio.

Entonces, sabiendo la distribución de los medidores y cómo se generarán los datos, la tabla de logs quedará de la siguiente manera:
log_id | log_date | slave_name | master_name | district_name | water_amount |
---|---|---|---|---|---|
1 | 2020-06-01 10:05:00 | slave1 | master1 | distric1 | 300 |
2 | 2020-06-01 10:15:00 | slave3 | master2 | distric2 | 200 |
3 | 2020-06-01 10:25:00 | slave2 | master1 | distric1 | 400 |
4 | 2020-06-01 10:35:00 | slave1 | master1 | distric1 | 230 |
5 | 2020-06-01 10:45:00 | slave3 | master2 | distric2 | 110 |
Con las condiciones antes mencionadas se estableció en entorno de simulación, el cual puede verse mucho mejor en el vídeo que presento al principio de este articulo.
7. Conclusiones
Desarrollar este proyecto fue una tarea muy interesante que permite tener una idea de todas las posibilidades que nos brinda una herramienta como Grafana. Sin embargo, quedan algunas cosas pendientes o posibles mejoras
-
Almacenamiento (PostgreSQL)
- Trabajar con entidades separadas en vez de escribir en una nica tabla.
- Escribir directamente en la tablas de cada una de las entidades
- Crear el querie que me produzcan la tabla logs.
-
Generación de Datos (Node-RED)
- Simplificar la forma en que se escriben los datos en la bases de datos.
- Utilizar nodos JOIN para unir las lecturas generadas por cada uno de los medidores y escribir en la base de datos una nica vez
- Generación de datos más realistas. Que sigan un patrón o una función.
-
Visualización (Grafana)
- Generar alarmas dentro de Grafana, para que aparezcan en el tablero
- Descargar los datos de un usuario por medio de grafana.
- Utilizar fuentes de datos adicionales
Espero que este archivo haya sido de su interés y quedo atento a sus comentarios. Saludos