Guides

ChirpStack : recevoir une alerte quand un appareil cesse d'émettre

ChirpStack ne propose aucune alerte native. Trois façons de savoir qu'un appareil LoRaWAN s'est tu : l'intégration HTTP, l'API gRPC et un watchdog hébergé.

ChirpStack ne vous préviendra pas lorsqu'un appareil cesse d'émettre. Cela surprend, mais la raison est simple : ChirpStack est un serveur de réseau, pas une plateforme de supervision. Il expose des données via des intégrations et une API, et laisse l'alerte à ce qui consomme ces données. Il n'y a ni moteur de règles, ni onglet de notification, ni e-mail « appareil hors ligne » à activer.

Un capteur dont la pile est vide, dont le boîtier a pris l'eau ou dont le rejoin a échoué produit donc exactement la même chose qu'un capteur qui fonctionne parfaitement et n'a simplement pas encore émis : rien. Le trou n'apparaît que lorsque quelqu'un regarde une courbe.

Ce que ChirpStack fournit réellement

Le statut d'appareil. ChirpStack émet périodiquement la commande MAC DevStatusReq et enregistre le niveau de batterie et la marge de liaison renvoyés par l'appareil. L'intervalle se configure dans le profil d'appareil. C'est utile pour repérer une pile qui décline, mais cela ne détecte pas un appareil devenu totalement muet : une requête de statut sans réponse reste simplement sans réponse.

L'horodatage lastSeenAt. C'est le champ qui compte vraiment, et tout ce qui suit n'est qu'une manière de le surveiller.

Solution 1 : l'intégration HTTP (recommandée)

La plus simple et la plus fiable. Dans Applications ▸ votre application ▸ Integrations ▸ HTTP, renseignez une URL de point de terminaison. ChirpStack y enverra un POST JSON à chaque uplink, contenant l'EUI de l'appareil, son nom, le compteur de trames et les passerelles qui l'ont entendu.

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

Attention : ChirpStack envoie aussi les événements de join, d'ack et de statut à cette même URL. Ne considérez que les uplinks comme preuve de vie — un ack n'est pas un capteur qui fonctionne.

Nous publions un script Python d'un seul fichier, sans dépendances, qui fait exactement cela : uplink-watchdog, sous licence MIT.

Solution 2 : interroger l'API

Vous pouvez aussi lire périodiquement lastSeenAt pour chaque appareil et alerter sur toute valeur périmée.

Un piège : ChirpStack v4 n'embarque plus d'API REST. L'interface REST de la v3 était une couche de traduction au-dessus de gRPC ; elle a été retirée en v4. Si vous avez besoin de REST, il faut faire tourner le conteneur séparé chirpstack-rest-api ; sinon, vous parlez gRPC via le paquet chirpstack-api.

Le polling passe également moins bien à l'échelle : avec quelques centaines d'appareils, vous lancez toutes les quelques minutes une grosse requête paginée pour apprendre ce que le serveur de réseau vous aurait dit gratuitement.

Choisir le bon seuil de silence

C'est là que la plupart des supervisions maison échouent. Un délai global unique ne convient pas à un parc réel : un compteur de personnes qui émet toutes les 15 minutes et un capteur de niveau qui émet une fois par jour ont besoin de fenêtres séparées par deux ordres de grandeur. Trop serrée, les capteurs quotidiens crient au loup chaque nuit ; trop large, un compteur mort passe inaperçu toute une journée.

L'approche qui fonctionne est propre à chaque appareil et apprise : suivez l'intervalle moyen de chaque appareil et traitez environ trois intervalles manqués comme une panne. Trois est assez tolérant pour survivre à un uplink perdu — banal sur un réseau radio — et assez serré pour détecter une vraie panne le jour même.

Un détail facile à manquer : excluez les écarts de la durée d'une panne du calcul de cette moyenne. Si une coupure de deux jours entre dans la moyenne, l'intervalle attendu gonfle et la panne suivante met bien plus longtemps à être détectée. Le rythme appris ne doit refléter qu'un comportement sain.

Surveillez aussi les passerelles

Chaque uplink contient un tableau rxInfo nommant les passerelles qui l'ont reçu. Les enregistrer vous donne la supervision des passerelles sans aucune configuration supplémentaire : si une passerelle n'apparaît plus dans aucun rxInfo, elle a cessé de relayer. C'est important, car une passerelle hors service ressemble à tous les appareils situés derrière elle mourant en même temps — et vous voulez connaître la cause, pas le symptôme.

Le problème de la supervision auto-hébergée

Cela vaut pour toutes les solutions ci-dessus et mérite d'être dit clairement : si votre supervision tourne sur votre propre infrastructure, personne ne supervise la supervision. Si le processus meurt, si l'hôte redémarre ou si le disque se remplit, les alertes s'arrêtent — et l'absence d'alertes ressemble exactement à l'absence de problème.

Pour un réseau amateur, le risque est acceptable. Pour un parc dont vous êtes contractuellement responsable, c'est le mode de défaillance qui finit par coûter cher.

Solution 3 : un watchdog hébergé

C'est pour cela que nous avons construit UplinkWatch — lisez donc cette section pour ce qu'elle est. Vous collez notre URL d'ingestion dans ce même champ d'intégration HTTP, et la surveillance s'exécute sur notre infrastructure plutôt que sur la vôtre. Appareils et passerelles s'enregistrent seuls, le rythme est appris par appareil, et les alertes partent par e-mail, notification push ou webhook. Gratuit jusqu'à 5 appareils.

Hébergé dans l'Union européenne : nos serveurs sont à Helsinki (Finlande), chez Hetzner. Vos métadonnées d'uplink ne quittent pas l'UE.

Si vous n'avez qu'une poignée d'appareils et que vous aimez gérer vos propres services, le script de la solution 1 suffit très honnêtement.

Note : l'interface web d'UplinkWatch est en anglais. Support en français par e-mail à info@geosensor.tech.

Also available in: English · Deutsch · Español · Português

Last updated 2026-09-03.