Guides

ChirpStack: cómo recibir una alerta cuando un dispositivo deja de enviar

ChirpStack no incluye alertas. Tres formas de enterarte de que un dispositivo LoRaWAN se ha quedado mudo: la integración HTTP, la API gRPC y un watchdog alojado.

ChirpStack no te avisa cuando un dispositivo deja de enviar. Sorprende, pero la razón es clara: ChirpStack es un servidor de red, no una plataforma de monitorización. Expone datos mediante integraciones y una API, y deja las alertas a lo que consuma esos datos. No hay motor de reglas, ni pestaña de notificaciones, ni correo de «dispositivo desconectado» esperando a que lo actives.

Un sensor con la pila agotada, con humedad dentro de la caja o con un rejoin fallido produce exactamente lo mismo que un sensor que funciona perfectamente y simplemente todavía no ha transmitido: nada. El hueco solo se ve cuando alguien mira una gráfica.

Lo que ChirpStack sí ofrece

Estado del dispositivo. ChirpStack emite periódicamente el comando MAC DevStatusReq y guarda el nivel de batería y el margen de enlace que el dispositivo devuelve. El intervalo se configura en el perfil de dispositivo. Es útil para detectar una pila que va cayendo, pero no sirve para un dispositivo que ha dejado de hablar del todo: una petición de estado sin respuesta simplemente se queda sin respuesta.

La marca de tiempo lastSeenAt. Este es el campo que de verdad importa, y todo lo que sigue es una manera de vigilarlo.

Opción 1: la integración HTTP (recomendada)

La de menos esfuerzo y la más fiable. En Applications ▸ tu aplicación ▸ Integrations ▸ HTTP, indica una URL de endpoint. ChirpStack enviará un POST JSON en cada uplink, con el EUI del dispositivo, su nombre, el contador de tramas y las pasarelas que lo han oído.

{
  "deviceInfo": { "devEui": "24e124707c481234", "deviceName": "IO103M" },
  "fCnt": 412,
  "rxInfo": [ { "gatewayId": "2cf7f11e15ec0000", "rssi": -97, "snr": 8.2 } ],
  "object": { "battery": 88 }
}

Ojo: ChirpStack envía eventos de join, ack y estado a esa misma URL. Considera solo los uplinks como prueba de vida — un ack no es un sensor que funcione.

Publicamos un script de Python de un solo fichero, sin dependencias, que hace exactamente esto: uplink-watchdog, con licencia MIT.

Opción 2: consultar la API

También puedes leer lastSeenAt de cada dispositivo cada cierto tiempo y alertar sobre cualquier valor caducado.

Una trampa: ChirpStack v4 ya no incluye API REST. La interfaz REST de la v3 era una capa de traducción sobre gRPC y se eliminó en la v4. Si necesitas REST, tienes que ejecutar el contenedor aparte chirpstack-rest-api; si no, hablas gRPC mediante el paquete chirpstack-api.

Además, el sondeo escala peor: con unos cientos de dispositivos estarás lanzando una petición paginada grande cada pocos minutos para averiguar algo que el servidor de red te habría contado gratis.

Elegir el umbral de silencio

Aquí es donde falla casi toda la monitorización casera. Un tiempo de espera global no encaja con un parque real: un contador de personas que transmite cada 15 minutos y un sensor de nivel que transmite una vez al día necesitan ventanas separadas por dos órdenes de magnitud. Si la ajustas corta, los sensores diarios dan falsas alarmas cada noche; si la dejas larga, un contador muerto pasa desapercibido todo un día.

El enfoque que funciona es por dispositivo y aprendido: registra el intervalo medio de cada dispositivo y trata unos tres intervalos perdidos como avería. Tres es lo bastante tolerante para sobrevivir a un uplink perdido — algo normal en cualquier red de radio — y lo bastante estricto para detectar una avería real el mismo día.

Un detalle fácil de pasar por alto: excluye del cálculo de esa media los huecos del tamaño de una caída. Si una avería de dos días entra en la media, el intervalo esperado se dispara y la siguiente caída tarda mucho más en detectarse. El ritmo aprendido debe reflejar solo el comportamiento sano.

Vigila también las pasarelas

Cada uplink lleva un array rxInfo con las pasarelas que lo recibieron. Registrarlas te da monitorización de pasarelas sin configuración adicional: si una pasarela deja de aparecer en cualquier rxInfo, ha dejado de retransmitir. Esto importa porque una pasarela caída parece que todos los dispositivos que hay detrás mueren a la vez — y quieres que te avisen de la causa, no del síntoma.

El problema de alojar tú mismo la vigilancia

Vale para todas las opciones anteriores y conviene decirlo claro: si tu monitorización corre en tu propia infraestructura, nadie vigila a la vigilancia. Si el proceso muere, el servidor se reinicia o el disco se llena, las alertas se detienen — y la ausencia de alertas se parece exactamente a que no pasa nada.

Para una red doméstica es un riesgo asumible. Para un parque del que respondes por contrato, es el fallo que acaba pasando factura.

Opción 3: un watchdog alojado

Para eso construimos UplinkWatch, así que lee esta sección sabiendo lo que es. Pegas nuestra URL de ingesta en ese mismo campo de integración HTTP y la vigilancia ocurre en nuestra infraestructura, no en la tuya. Dispositivos y pasarelas se registran solos, el ritmo se aprende por dispositivo y las alertas salen por correo, notificación al móvil o webhook. Gratis hasta 5 dispositivos.

Alojado en la Unión Europea: nuestros servidores están en Helsinki (Finlandia), en Hetzner. Tus metadatos de uplink no salen de la UE.

Si solo tienes un puñado de dispositivos y te gusta gestionar tus propios servicios, el script de la opción 1 es sinceramente suficiente.

Nota: la interfaz web de UplinkWatch está en inglés. Soporte en español por correo a info@geosensor.tech.

Also available in: English · Deutsch · Français · Português

Last updated 2026-09-03.