In diesem Beitrag
LoRaWAN-Wasserzähler im Feldtest: Kommen Zählerstand und Leckalarm an?
Ein Monteur kann am Zähler ablesen, was die Leitstelle beim nächsten vorgesehenen Sendetermin auf dem Bildschirm sehen sollte. Beim Leckalarm fehlt dieser einfache Vergleich. Wann erkennt das Modell eine Auffälligkeit, wann meldet es sie, und sieht die zuständige Person, um welchen Zähler es geht? Vor einer größeren Bestellung würde ich mir beides mit demselben Testgerät vorführen lassen.
Wie lief der Feldtest in Innsbruck ab?
Bei den Innsbrucker Kommunalbetrieben (IKB) stand die Aufgabe schon fest, als wir dazukamen. Die IKB leitete das Projekt. Eine Ablesung konnte vorher eine Fahrt erfordern, selbst wenn der Zählerstand schon beim Vorbeifahren erfasst wurde. Über das städtische LoRaWAN wollte der Versorger solche Fahrten einsparen und aktuellere Werte bekommen. In einem Interview der IKB beschreibt ein Mitarbeiter, wie Alarme seinem Team halfen, auf unbemerkte Leckagen früher zu reagieren.
Wir testeten Wasserzähler an einem typischen Standort und an einer Stelle, an der wir schwächeren Empfang erwarteten. Auch andere Sensoren gehörten zum Projekt, darunter Tracker für Lastenräder. Wir arbeiteten mit der IKB an Dashboards, die Auffälligkeiten sichtbar machen sollten.
Manche Geräte sendeten nach Zeitplan, andere Pakete kamen erst bei einem Ereignis. Oft stimmten die Angaben im Datenblatt. Bei einzelnen Geräten fiel eine Abweichung erst auf, als wir ein echtes Paket mit der Beschreibung vergleichen konnten. Wir zeichneten echte Pakete auf und konnten sie offline erneut auswerten. Die IKB-Fallstudie beschreibt diese Arbeit.
Was sollte das Stadtwerk vor der Bestellung vorführen lassen?
Für eine Abnahme würde ich mit dem Betrieb zwei Standorte festlegen: einen typischen Einbauort und einen repräsentativen Ort mit schwierigem Empfang. Für beide gelten die vorgesehenen Geräteeinstellungen. Der Anbieter nennt das Sendeintervall, die Bedingung für den Leckalarm und den Zeitpunkt, zu dem der Zähler den Alarm verschickt. Der Betrieb legt fest, wie alt ein Zählerstand sein darf und bis wann ein Alarm bei der zuständigen Person ankommen muss.
| Prüfung | Was das Team macht | Was ins Protokoll gehört |
|---|---|---|
| Zählerstand | Anzeige am Gerät zu einem bekannten Messzeitpunkt ablesen und den zugehörigen Wert im Dashboard suchen. An beiden Orten über die vereinbarten Sendeintervalle wiederholen. | Zählerkennung, Wert und Einheit an beiden Enden, Messzeit und Empfangszeit. Ausgebliebene Meldungen gesondert vermerken. |
| Leckalarm | Den dokumentierten Prüfvorgang des Herstellers am Testgerät oder Prüfstand verwenden. Das Betriebsteam am vereinbarten Meldeweg beobachten lassen, wann der Alarm ankommt. | Auslösezeit, Empfangszeit, angezeigter Zähler und Alarmzustand. Festhalten, ob das Team den richtigen Einsatzort zuordnen kann. |
| Rückkehr zum Normalbetrieb | Prüfvorgang beenden und beobachten, wie das Gerät laut Spezifikation die Entwarnung meldet. | Zeitpunkt und Endzustand im Dashboard. Festhalten, wer einen offenen Alarm weiterbearbeitet. |
Ein Testmodus kann die Erkennung im Sensor überspringen. Dann belegt der Versuch den Meldeweg ab dem Gerät. Für die Erkennung selbst bleibt ein eigener Prüfstandversuch offen. Das lässt sich vor dem Termin mit dem Hersteller klären.
Wo sucht man, wenn der Alarm im Dashboard fehlt?
Zuerst lohnt der Blick auf die vereinbarte Alarmbedingung. Manche Zähler melden einen Zustand im nächsten regulären Paket. Bei einem Test muss man also wissen, ab wann die Meldung fällig war. Dann lässt sich prüfen, ob die Anwendung zu diesem Zeitpunkt überhaupt ein Paket vom Testgerät erhalten hat. Die IKB zeigt anhand ihres Funknetzes, wie die Daten vom Sensor über ein Gateway weitergeleitet werden.
Ist ein Paket da, folgt der Abgleich: Welche Bedeutung gibt das Datenblatt dem Feld, was zeigt das Testgerät und welchen Zustand gibt der Decoder aus? Die Dokumentation zu Payload-Formattern erklärt, wie aus den übertragenen Bytes lesbare Felder werden. Mit unserem LoRaWAN-Codec-Tester lässt sich ein aufgezeichnetes Paket wiederholt auswerten. So kann man eine Korrektur prüfen, ohne auf die nächste Meldung zu warten. Die Funkabdeckung prüft man weiterhin vor Ort.
Wann reicht das Ergebnis für den Einkauf?
Für die Bestellung würde ich im Protokoll je Standort festhalten, wie viele planmäßige Meldungen erwartet wurden, wie viele tatsächlich eintrafen und ob der Alarm innerhalb der vereinbarten Zeit zugeordnet werden konnte. Passt der Zählerstand an beiden Orten, während der Alarm nur an einem ankommt, bleibt die Alarmprüfung am zweiten Ort offen. Ein weiterer Gateway-Standort ist erst dann eine belastbare Option, wenn der Betreiber Platzierung, Genehmigung und Wartungszugang geklärt hat.
Wer noch die Funktechnik auswählt, findet im Kostenvergleich für LoRaWAN, NB-IoT und Sigfox die Fragen fürs Pilotbudget. Steht das Funknetz fest, hilft der Leitfaden zur Projektklärung dabei, die benötigten Nachweise vor der Bestellung zu vereinbaren. Wenn du mit unserem Team für kommunale IoT-Projekte einen Feldtest besprechen möchtest, bring ein Mustergerät, das Datenblatt und zwei mögliche Einbauorte mit.