Problema
En muchos pueblos, los contadores de agua se siguen leyendo a mano. Alguien recorre el pueblo casa por casa y apunta cada cifra. Una vez cada uno o dos meses.
Así, de cada contador se tienen unas pocas cifras al año. Y entre una y otra, nada. Un consumo normal, un pico puntual o una fuga lenta pueden acabar dando la misma lectura. Desde una sola cifra no hay forma de saber qué pasó. Y en un pueblo entero, esa incertidumbre se multiplica.
La telelectura lo cambia: cada contador envía sus lecturas solo, y se consultan desde el navegador. Pero llevarla a la práctica tiene su miga. Cada fabricante habla su propio idioma. Un pueblo, con las casas repartidas, no se conecta igual que un hotel con decenas de contadores en pocos metros. Y una lectura que llega no vale nada si no se puede confiar en ella.
La pregunta es: ¿cómo se junta todo eso en un solo sitio, y se convierte en algo útil para quien gestiona el agua?
Restricciones
- Una sola plataforma centralizada. Radio en los pueblos, cable en los edificios, contadores de distintos fabricantes: todo tenía que acabar en la misma plataforma, con las mismas gráficas y las mismas alarmas.
- Datos fiables. Cada contador manda sus lecturas en su propio formato. Si la plataforma lo entiende mal, enseña consumos que no son: avisa de una fuga que no existe o se le escapa una de verdad. Cada lectura se comprueba antes de mostrarla.
- Fácil de usar. La usa quien gestiona el agua en un ayuntamiento, un hotel o una comunidad de vecinos, no un experto en comunicaciones. Basta con abrir el navegador para ver qué gasta cada contador y dónde hay un problema.
Enfoque
Con telelectura, nadie tiene que ir a leer el contador: cada uno lleva una pequeña radio y envía sus lecturas solo, a lo largo del día. Desde el navegador se ve cada contador, hora a hora.
Cómo llegan las lecturas depende de dónde estén los contadores. En un pueblo, las casas están repartidas: una antena en lo alto las recoge por LoRaWAN, una red de radio pensada para enviar mensajes pequeños a kilómetros de distancia, gastando muy poca pila. De la antena pasan a ChirpStack, el servidor que gestiona esa red, y de ahí a la plataforma. En un hotel o una comunidad de vecinos, los contadores están juntos y comparten un cable: el M-Bus, el estándar europeo para leer contadores.
Por cualquiera de los dos caminos, lo que llega son tramas: mensajes de unos pocos bytes con las lecturas del contador. M-Bus (Meter-Bus) es una especificación muy completa: define tanto esas tramas como el cable por el que viajan. Con el tiempo, OMS (Open Metering System) la ha ampliado con una capa estándar que permite otros transportes, como LoRaWAN o NB-IoT. Sobre ella se han construido los contadores de agua de nueva generación, para viviendas e infraestructuras: sin partes mecánicas, miden por ultrasonidos. Es el idioma común que intenta poner de acuerdo a los fabricantes. En la práctica, cada uno tiene su dialecto.
Mi trabajo fue lo que pasa cuando esas tramas llegan a la nube. En tres pasos:
- Descodificar. Traducir las tramas de cada modelo de contador a un mismo idioma (lecturas, consumos, estado) y comprobar que todo cuadra antes de darlo por bueno.
- Construir el backend. Es la parte de la plataforma que no se ve. Guarda todas las lecturas, calcula el consumo hora a hora y saca las alarmas por dos vías: las que manda el propio contador y las que salen de analizar su histórico. También prepara los informes: por contador, por edificio o por pueblo, en web y en PDF.
- Montar el modelo digital. Cada contador en su sitio, sobre el mapa del pueblo o del edificio. De un vistazo se ve dónde se gasta más y dónde salta una alarma.
Resultado
La plataforma ya funciona con contadores reales de tres fabricantes, cada uno con su propio formato. Desde marzo de 2026 recibe sus lecturas hora a hora, y cada una se comprueba antes de mostrarse.
Ahora está en fase de implantación: los contadores se van incorporando a la plataforma en pueblos de la comarca de Els Ports, en Castellón, y en hoteles de la provincia que quieren seguir sus consumos internos.
Donde antes había una cifra cada uno o dos meses, ahora hay una curva hora a hora de cada contador, la del pueblo o el edificio entero, y un aviso en cuanto algo no cuadra. Todo en un mismo modelo de la red.
De una cifra cada dos meses a cada contador, hora a hora.
Stack y entregables
- Descodificadores Uno por modelo de contador: traducen sus tramas a lecturas, consumos y estado, y comprueban que cuadran.
- Backend Guarda las lecturas, calcula el consumo hora a hora y saca las alarmas.
- Modelo digital Cada contador en su sitio, sobre el mapa del pueblo o del edificio.
- Informes A la medida: por contador, por edificio o por pueblo, en web y en PDF.
Dónde encaja esto
Cada vez hay más equipos que miden solos: contadores, sensores, máquinas. Pero cada fabricante habla su propio idioma, y los datos se quedan en el aparato o en el programa de cada marca. Para juntarlos no basta con saber programar: hay que conocer el hardware, saber qué manda cada equipo, cómo lo manda y cuándo no fiarse de lo que llega.
Ese salto es lo que hago: entender cada equipo y su protocolo, juntar los datos en una sola plataforma y convertirlos en algo útil: gráficas, alarmas, un modelo digital. Y con los datos en orden empieza lo interesante: con meses de histórico, se pueden entrenar modelos de machine learning que predigan el consumo y detecten lo anómalo antes de que se convierta en un problema.