--- title: "LoRaWAN-Wasserzähler im Feldtest: Zählerstand und Leckalarm" canonical: https://wavect.io/de/blog/lorawan-water-meter-field-acceptance-test/ language: de description: "Prüfe vor der Bestellung, ob Zählerstand und Leckalarm deines LoRaWAN-Wasserzählers im Dashboard ankommen. Mit Feldtest an zwei Standorten und Abnahmeprotokoll." 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" --- # LoRaWAN-Wasserzähler im Feldtest: Kommen Zählerstand und Leckalarm an? [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 Min Lesezeit · 12. November 2026 Zuletzt geprüft 12. November 2026 [**Weiter**](/de/blog/lorawan-nbiot-sigfox-pilot-cost/) TL;DR Vergleiche den Zählerstand vor Ort mit dem Wert im Dashboard. Wiederhole die Ablesung an einem Einbauort mit schwierigem Empfang. Lass dir den Leckalarm mit dem für das Modell vorgesehenen Testverfahren separat zeigen. Halte vor der Bestellung fest, welche Meldung der Betrieb an welchem Standort gesehen hat und welche Prüfung noch aussteht. 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](https://www.ikb.at/karriere/einblicke/coole-smarties) 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](/de/case-studies/ikb/) 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](https://www.ikb.at/themenwelten/lorawan). 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](https://www.thethingsindustries.com/docs/integrations/payload-formatters/) erklärt, wie aus den übertragenen Bytes lesbare Felder werden. Mit unserem [LoRaWAN-Codec-Tester](/de/tools/lorawan-payload-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](/de/blog/lorawan-nbiot-sigfox-pilot-cost/) die Fragen fürs Pilotbudget. Steht das Funknetz fest, hilft der [Leitfaden zur Projektklärung](/de/software-development-guide/what-is-a-discovery-phase/) dabei, die benötigten Nachweise vor der Bestellung zu vereinbaren. Wenn du mit unserem [Team für kommunale IoT-Projekte](/de/services/smart-city-iot/) einen [Feldtest besprechen](/de/contact/?intent=smart-city-iot) möchtest, bring ein Mustergerät, das Datenblatt und zwei mögliche Einbauorte mit. ## Fragen aus Einkauf und Betrieb ### Beweist ein aktueller Zählerstand, dass der Leckalarm funktioniert? Der Zählerstand bestätigt den Empfang und die Verarbeitung dieser Ablesung. Für den Alarm braucht der Betrieb einen ausgelösten Test mit bekanntem Zeitpunkt und sichtbarem Alarmzustand. ### Wie lange sollte der Feldtest dauern? Plane anhand des tatsächlichen Sendeintervalls, der Erkennungsdauer des Zählers und der im Betrieb erforderlichen Meldezeit. Vereinbare vorab, wie viele reguläre Übertragungen das Team pro Standort beobachten soll. ### Was bringt ein gespeichertes Paket bei einem seltenen Ereignis? Das Team kann denselben aufgezeichneten Alarm erneut durch den Decoder schicken und Soll und Ist vergleichen. Ein Feldversuch liefert anschließend den Nachweis für den Empfang am Einbauort. ### Wer kann die Abnahme aufseiten des Versorgers beurteilen? Der Messbetrieb vergleicht Kennung, Wert und Einheit. Die für Störungen zuständige Person zeigt, wie sie die Meldung findet, den Zähler zuordnet und den nächsten Schritt veranlasst. ### Reicht eine Vorführung beim Anbieter für die Abnahme? Dokumentiere, was der Prüfstand gezeigt hat, und markiere den Empfang am Einbauort als ungeprüft. Mit demselben Testgerät lassen sich Ablesung und Alarm an den geplanten Standorten wiederholen, bevor der Betrieb die Funkabdeckung freigibt. QA und Produktionsreife ## Weiterlesen Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware. [Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [Software von zwei Anbietern abnehmen: Welcher Nachweis reicht?](/de/blog/multi-vendor-software-acceptance-testing/) - [README ZIP Schadsoftware: Was deckt deine Freigabe ab?](/de/blog/readme-zip-malware-install-review/) - [KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen](/de/blog/ai-generated-odoo-module-audit/) - [Odoo-Migration abnehmen: Datensätze und Salden abgleichen](/de/blog/odoo-migration-acceptance-reconciliation/) - [Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen](/de/blog/odoo-ai-agent-business-state-tests/) [Nächster Artikel**Software von zwei Anbietern abnehmen: Welcher Nachweis reicht?**](/de/blog/multi-vendor-software-acceptance-testing/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 Min Lesezeit · 12. November 2026 Zuletzt geprüft 12. November 2026 [**Weiter**](/de/blog/lorawan-nbiot-sigfox-pilot-cost/)