---
title: "Contador LoRaWAN: prueba de lectura y alarma de fuga"
canonical: https://wavect.io/es/blog/lorawan-water-meter-field-acceptance-test/
language: es
description: "Prueba un contador de agua LoRaWAN antes de comprarlo. Contrasta la lectura local con el panel en dos ubicaciones y pide una demostración de la alarma de fuga."
image: "https://wavect.io/img/blog/headers/header_lorawan-water-meter-field-acceptance-test.png"
author: ["Kevin Riedl"]
published: "2026-11-12"
updated: "2026-11-12"
reviewed: "2026-11-12"
---

# ¿Cómo comprobar en campo la lectura y la alarma de fuga de un contador LoRaWAN?

[**Volver**](/es/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/)

[Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt

5 min de lectura · 12 de noviembre de 2026 Última revisión 12 de noviembre de 2026

[**Siguiente**](/es/blog/lorawan-nbiot-sigfox-pilot-cost/)

Resumen

Antes de ampliar el pedido, compara la lectura del contador con la que ve el operador en el panel. Haz la prueba en un emplazamiento habitual y en otro con peor recepción. Comprueba por separado la alarma de fuga con el procedimiento previsto para ese modelo y deja constancia de lo que queda pendiente de verificar en campo.

Un técnico puede leer el contador y dictar la cifra que, en el siguiente envío programado, debería aparecer en el centro de control. Una alarma de fuga exige otra comprobación. ¿Qué tiene que detectar este modelo, cuándo lo comunica y cómo sabe el personal de guardia a qué instalación acudir? Antes de comprar un lote, pediría al proveedor que demostrase la lectura y la alarma con el mismo contador de prueba.

## ¿Cómo se hicieron las pruebas en Innsbruck?

La empresa municipal de Innsbruck, IKB, ya dirigía el proyecto cuando nos incorporamos. Recoger una lectura podía exigir un desplazamiento incluso cuando bastaba pasar junto al contador en un vehículo. IKB quería ahorrarse esos recorridos mediante la red LoRaWAN de la ciudad y disponer de lecturas más recientes. En una [entrevista publicada por IKB](https://www.ikb.at/karriere/einblicke/coole-smarties), un técnico de telecomunicaciones explica cómo las alarmas les permitieron actuar antes ante fugas que los usuarios aún no habían advertido.

Probamos contadores de agua en un punto de instalación habitual y en otro donde esperábamos una recepción más débil. También trabajamos con otros dispositivos, entre ellos localizadores para bicicletas de carga. Desarrollamos paneles con el equipo de IKB para detectar posibles problemas. Algunos mensajes llegaban a intervalos fijos y otros solo cuando se producía un evento. En muchos dispositivos, los datos recibidos coincidían con la ficha técnica. En algunos solo descubrimos diferencias al comparar un paquete real con la descripción. Guardábamos los paquetes reales para volver a procesarlos sin conexión. El [caso de IKB](/es/case-studies/ikb/) recoge ese trabajo.

## ¿Qué conviene pedir al proveedor antes de comprar el lote?

Para la prueba de aceptación, elegiría con el equipo de operaciones dos emplazamientos representativos: uno habitual y otro con recepción difícil. En ambos usaría la configuración prevista para el servicio. El proveedor debe indicar cada cuánto transmite el contador, en qué condiciones reconoce una posible fuga y cuándo comunica la alarma. Por su parte, la empresa de aguas fija la antigüedad admisible de las lecturas y el plazo en que el aviso debe llegar a la guardia.

| Prueba | Qué hacer | Qué anotar |
| --- | --- | --- |
| Lectura | Leer el registro del contador a una hora conocida y buscar en el panel la lectura correspondiente a ese instante. Repetir durante los intervalos acordados en ambos puntos. | Identificador, valor y unidad en ambos extremos, hora de medición y hora de recepción. Anotar por separado los mensajes que faltan. |
| Alarma de fuga | Aplicar el procedimiento documentado por el fabricante al contador de prueba o en un banco de ensayos. Pedir a la guardia que observe el canal de avisos acordado. | Hora de activación y de recepción, contador y estado indicado. Comprobar si la guardia identifica la instalación a la que tendría que acudir. |
| Vuelta al servicio | Terminar el ensayo y observar cómo se desactiva la alarma según la documentación del contador. | Hora y estado final en el panel. Si el aviso sigue abierto, anotar quién se encarga de revisarlo. |

Algunos modos de prueba permiten enviar el aviso sin que intervenga el mecanismo de detección. En ese caso se comprueba el recorrido del aviso desde el contador. Para verificar también la detección, conviene acordar con el fabricante el ensayo correspondiente en banco.

## ¿Por dónde empezar si no aparece el aviso?

Primero hay que determinar cuándo debería haber llegado. Un modelo puede indicar una fuga mediante un campo del siguiente mensaje periódico. Una vez establecido el plazo, se comprueba si la aplicación recibió algún paquete de ese contador en ese momento. [IKB explica cómo intervienen los sensores y las pasarelas](https://www.ikb.at/themenwelten/lorawan) en su red LoRaWAN.

Si llegó un paquete, conviene contrastar el significado del campo en la ficha técnica, el estado observado en el contador y el valor que devuelve el decodificador. La [documentación de The Things Stack](https://www.thethingsindustries.com/docs/integrations/payload-formatters/) explica cómo se convierten los bytes recibidos en campos legibles. Con nuestro [probador de códecs LoRaWAN](/es/tools/lorawan-payload-codec-tester/) se puede procesar varias veces el paquete registrado. Así se comprueba una corrección sin esperar a otra alarma. Para verificar la recepción hay que volver al punto de instalación.

## ¿Con qué resultados se puede aprobar la compra?

Por cada emplazamiento, el acta debería recoger cuántas lecturas se esperaban, cuántas llegaron y si la guardia pudo identificar la alarma dentro del plazo acordado. Si llegan lecturas de ambos puntos y solo uno entrega la alarma, queda pendiente repetir esa prueba en el segundo. Si la solución propuesta requiere otra pasarela, conviene confirmar el permiso de instalación y el acceso para su mantenimiento antes de aceptar el presupuesto.

Nuestra [comparativa de costes para pilotos](/es/blog/lorawan-nbiot-sigfox-pilot-cost/) sirve para elegir entre LoRaWAN, NB-IoT y Sigfox. Una vez elegida la red, la [guía para definir el alcance del piloto](/es/software-development-guide/what-is-a-discovery-phase/) ayuda a acordar qué debe quedar probado antes del pedido. Para [plantear una prueba de campo](/es/contact/?intent=smart-city-iot) a nuestro [equipo de IoT para servicios municipales](/es/services/smart-city-iot/), basta con un contador de muestra, su documentación y dos posibles emplazamientos.

## Preguntas de compras y operaciones

### ¿Basta una lectura reciente para validar la alarma?

La lectura confirma que ese dato ha llegado y se ha procesado. Para validar la alarma, hay que registrar el instante de activación y observar el estado correspondiente en el puesto de la guardia.

### ¿Cuánto tiempo debe durar la prueba de campo?

Hay que partir del intervalo real de transmisión, del tiempo que necesita el contador para detectar una fuga y del plazo que tiene la guardia para recibir el aviso. Acordad cuántos envíos periódicos observaréis en cada punto.

### ¿Para qué sirve guardar el paquete de un evento poco frecuente?

Se puede pasar el mismo aviso por el decodificador varias veces y cotejar el resultado con el estado esperado. Una prueba de campo posterior verifica la recepción en el emplazamiento.

### ¿Quién debería participar en la aceptación por parte de la empresa de aguas?

El personal de medición comprueba el identificador, el valor y la unidad. La persona responsable de incidencias muestra cómo encuentra el aviso, localiza la instalación y tramita la actuación.

### ¿Basta una demostración en banco para aceptar el contador?

Documenta lo que demuestra el ensayo y deja constancia de que queda por verificar la recepción en campo. Repite las pruebas de lectura y alarma con el mismo contador en los emplazamientos previstos antes de dar por válida la cobertura.

QA y preparación para producción

## Qué leer después

Pruebas, auditorías, mantenimiento y hardening para software fiable.

[Empieza aquí**QA para Código Generado por IA**](/es/blog/qa-for-ai-generated-code/)

- [Dos proveedores dan por terminada la entrega. ¿Qué pruebas pides antes de aceptarla?](/es/blog/multi-vendor-software-acceptance-testing/)
- [Malware en ZIP enlazado desde README: revisa qué instalas](/es/blog/readme-zip-malware-install-review/)
- [Módulos Odoo generados por IA: audita las reglas de negocio](/es/blog/ai-generated-odoo-module-audit/)
- [Aceptar una migración a Odoo: concilia registros y saldos](/es/blog/odoo-migration-acceptance-reconciliation/)
- [Pruebas de agentes IA en Odoo: valida las actividades guardadas](/es/blog/odoo-ai-agent-business-state-tests/)

[Artículo siguiente**Dos proveedores dan por terminada la entrega. ¿Qué pruebas pides antes de aceptarla?**](/es/blog/multi-vendor-software-acceptance-testing/)

[**Volver**](/es/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/)

[Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt

5 min de lectura · 12 de noviembre de 2026 Última revisión 12 de noviembre de 2026

[**Siguiente**](/es/blog/lorawan-nbiot-sigfox-pilot-cost/)
