Guides

ChirpStack: Benachrichtigung, wenn ein Gerät keine Daten mehr sendet

ChirpStack hat keine eingebaute Alarmierung. Drei Wege, um zu erfahren, wann ein LoRaWAN-Gerät verstummt: HTTP-Integration, gRPC-API und ein gehosteter Watchdog.

ChirpStack meldet nicht, wenn ein Gerät aufhört zu senden. Das überrascht viele, hat aber einen klaren Grund: ChirpStack ist ein Netzwerkserver, keine Monitoring-Plattform. Es stellt Daten über Integrationen und eine API bereit und überlässt die Alarmierung dem, was diese Daten verarbeitet. Es gibt keine Regel-Engine, keinen Benachrichtigungs-Tab und keine „Gerät offline"-E-Mail, die man einschalten könnte.

Ein Sensor mit leerer Batterie, mit Feuchtigkeit im Gehäuse oder mit fehlgeschlagenem Rejoin erzeugt deshalb genau dasselbe wie ein Sensor, der einwandfrei läuft und nur gerade nichts gesendet hat: nichts. Die Lücke fällt erst auf, wenn jemand ein Diagramm ansieht.

Was ChirpStack tatsächlich liefert

Device Status. ChirpStack sendet in einstellbaren Abständen den MAC-Befehl DevStatusReq und speichert Batteriestand und Link-Margin, die das Gerät zurückmeldet. Das Intervall wird im Geräteprofil konfiguriert. Für eine Batterie, die langsam zur Neige geht, ist das nützlich — für ein Gerät, das komplett verstummt ist, hilft es nicht: Eine unbeantwortete Statusanfrage bleibt schlicht unbeantwortet.

Der Zeitstempel lastSeenAt. Das ist das Feld, auf das es ankommt. Alles Folgende ist eine Methode, es zu überwachen.

Weg 1: die HTTP-Integration (empfohlen)

Der geringste Aufwand und der zuverlässigste Weg. Unter Applications ▸ Ihre Anwendung ▸ Integrations ▸ HTTP tragen Sie eine Event-Endpoint-URL ein. ChirpStack sendet dorthin bei jedem Uplink einen JSON-Body mit Geräte-EUI, Name, Frame Counter und den Gateways, die das Paket empfangen haben.

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

Wichtig: ChirpStack sendet Join-, Ack- und Status-Events an dieselbe URL. Werten Sie ausschließlich Uplinks als Lebenszeichen — ein Ack ist kein funktionierender Sensor.

Wir veröffentlichen ein einzelnes Python-Skript ohne externe Abhängigkeiten, das genau das erledigt: uplink-watchdog, MIT-lizenziert.

Weg 2: die API abfragen

Alternativ lesen Sie lastSeenAt für alle Geräte periodisch aus und alarmieren bei veralteten Werten.

Eine Falle dabei: ChirpStack v4 enthält keine REST-API mehr. Die REST-Schnittstelle von v3 war eine Übersetzungsschicht über gRPC und wurde in v4 entfernt. Wer REST braucht, muss den separaten Container chirpstack-rest-api zusätzlich betreiben; andernfalls spricht man gRPC über das Paket chirpstack-api.

Polling skaliert zudem schlechter: Bei einigen hundert Geräten stellen Sie alle paar Minuten eine große paginierte Anfrage, um etwas zu erfahren, das der Netzwerkserver Ihnen kostenlos mitgeteilt hätte.

Den richtigen Schwellwert wählen

Hier scheitern die meisten Eigenbaulösungen. Ein globales Timeout passt nicht zu einem realen Bestand: Ein Personenzähler, der alle 15 Minuten meldet, und ein Füllstandsensor, der einmal täglich meldet, brauchen Fenster, die sich um zwei Größenordnungen unterscheiden. Zu eng gesetzt, schlagen die Tagesmelder jede Nacht falschen Alarm; zu weit gesetzt, bleibt ein toter Personenzähler einen Tag lang unbemerkt.

Was funktioniert, ist geräteindividuell und gelernt: Erfassen Sie das durchschnittliche Sendeintervall jedes Geräts und werten Sie etwa drei ausgefallene Intervalle als Störung. Drei ist tolerant genug, um einen einzelnen verlorenen Uplink zu überstehen — auf einem Funknetz völlig normal — und eng genug, um einen echten Ausfall am selben Tag zu erkennen.

Ein Detail, das leicht übersehen wird: Schließen Sie ausfallbedingte Lücken aus der Mittelwertbildung aus. Fließt eine zweitägige Störung in den Durchschnitt ein, wächst das erwartete Intervall — und der nächste Ausfall wird deutlich später erkannt. Der gelernte Rhythmus soll nur gesundes Verhalten abbilden.

Gateways gleich mit überwachen

Jeder Uplink enthält ein rxInfo-Array mit den Gateways, die ihn empfangen haben. Wer diese mitschreibt, erhält Gateway-Überwachung ohne Zusatzkonfiguration: Taucht ein Gateway in keinem rxInfo mehr auf, hat es aufgehört weiterzuleiten. Das ist wichtig, weil ein ausgefallenes Gateway aussieht, als würden alle dahinterliegenden Geräte gleichzeitig sterben — und Sie wollen über die Ursache informiert werden, nicht über das Symptom.

Das Problem mit selbst gehostetem Monitoring

Das gilt für alle bisherigen Wege und sollte deutlich gesagt werden: Läuft Ihre Überwachung auf Ihrer eigenen Infrastruktur, überwacht niemand die Überwachung. Stirbt der Prozess, startet der Host neu oder läuft die Platte voll, hören die Alarme auf — und keine Alarme sehen genauso aus wie „alles in Ordnung".

Für ein Hobbynetz ist das ein vertretbares Risiko. Für einen Bestand, für den Sie vertraglich haften, ist es der Fehlerfall, der irgendwann zuschlägt.

Weg 3: ein gehosteter Watchdog

Dafür haben wir UplinkWatch gebaut — betrachten Sie diesen Abschnitt entsprechend. Sie tragen unsere Ingest-URL in dasselbe HTTP-Integrationsfeld ein, und die Überwachung läuft auf unserer Infrastruktur statt auf Ihrer. Geräte und Gateways registrieren sich selbst, der Rhythmus wird pro Gerät gelernt, Alarme gehen per E-Mail, Push oder Webhook heraus. Kostenlos für 5 Geräte.

Gehostet in der EU: Unsere Server stehen in Helsinki (Finnland), betrieben von Hetzner. Ihre Uplink-Metadaten verlassen die EU nicht.

Wenn Sie nur eine Handvoll Geräte betreiben und eigene Dienste gern selbst verwalten, ist das Skript aus Weg 1 ehrlich gesagt völlig ausreichend.

Hinweis: Die Weboberfläche von UplinkWatch ist auf Englisch. Support auf Deutsch per E-Mail an info@geosensor.tech.

Also available in: English · Français · Español · Português

Last updated 2026-09-03.