LoRaWAN-Sensorbatterie hält zu kurz: Sendeintervall, Empfangsqualität und Alarmverkehr optimieren

→ Produktkategorie: IIoT Lösungen

 

Ein batteriebetriebener IIoT-Sensor soll laut Planung mehrere Jahre ohne Wartung arbeiten. Nach wenigen Monaten zeigt die Plattform jedoch bereits einen deutlich reduzierten Batteriestand. Der erste Verdacht fällt häufig auf eine zu kleine Batterie. In vielen Fällen liegt die eigentliche Ursache aber in der Konfiguration und der Funkverbindung.

Bei einem LoRaWAN-Sensor ist nicht allein entscheidend, wie oft ein Messwert aufgenommen wird. Wesentlich für die Batterielaufzeit ist, wie häufig das Funkmodul aktiv wird, wie lange eine Übertragung dauert, mit welcher Sendeleistung gearbeitet wird und ob zusätzliche Telegramme durch Alarme, Wiederholungen oder Netzwerkkommunikation entstehen.

Besonders abgelegene Messstellen sind deshalb interessant: Ein Sensor kann nur wenige Messwerte pro Stunde übertragen und trotzdem viel Energie verbrauchen, wenn die Funkverbindung ungünstig ist. Umgekehrt kann ein Sensor häufig messen, die Werte lokal sammeln und nur in größeren Abständen kompakt übertragen.

IIoT-Komponenten für entsprechende Anwendungen finden Sie unter IIoT Lösungen. Lösungen speziell für die drahtlose Fernüberwachung von Füllständen sind unter IIoT Füllstandüberwachung zusammengefasst.

Wo verbraucht ein LoRaWAN-Sensor Energie?

Ein batteriebetriebener IIoT-Sensor verbringt idealerweise den größten Teil seiner Zeit in einem sehr energiesparenden Ruhezustand. Für eine Messung wird die Sensorik aktiviert, der Messwert erfasst und gegebenenfalls verarbeitet. Anschließend kann das Gerät wieder in den Schlafmodus wechseln.

Deutlich mehr Energie wird normalerweise benötigt, sobald das Funkmodul aktiv wird. Dabei spielt nicht nur die eigentliche Sendeleistung eine Rolle. Entscheidend ist auch, wie lange das Telegramm „on air“ ist und welche weiteren Kommunikationsvorgänge anschließend notwendig sind.

Für die Batterielaufzeit müssen daher mehrere Faktoren gemeinsam betrachtet werden: Messhäufigkeit, Übertragungshäufigkeit, Datenrate, Funkqualität, Telegrammgröße und die Zahl zusätzlicher Kommunikationsvorgänge.

Die einfache Rechnung „eine Messung entspricht einer Funkübertragung“ ist deshalb bei vielen IIoT-Anwendungen unnötig ungünstig.

Messintervall und Sendeintervall unterscheiden

Messintervall und Sendeintervall erfüllen unterschiedliche Aufgaben.

Das Messintervall bestimmt, wie fein ein Prozess zeitlich überwacht wird. Ein Füllstand kann beispielsweise alle fünf Minuten erfasst werden, damit schnelle Änderungen lokal erkannt werden.

Das bedeutet jedoch nicht, dass auch alle fünf Minuten ein LoRaWAN-Telegramm erforderlich ist. Wenn für die zentrale Überwachung ein Stundenwert ausreicht, können mehrere Messwerte lokal verarbeitet beziehungsweise gesammelt und wesentlich seltener übertragen werden, sofern das verwendete Gerät diese Betriebsweise unterstützt.

Genau hier liegt häufig ein großes Einsparpotenzial. Für einen langsam veränderlichen Tankfüllstand ist beispielsweise eine Übertragung alle ein bis sechs Stunden oft wesentlich sinnvoller als eine Übertragung im Minutentakt.

Gleichzeitig kann eine ereignisbasierte Logik dafür sorgen, dass kritische Änderungen trotzdem unmittelbar gemeldet werden. Der Sensor arbeitet dann beispielsweise mit einem langen regulären Sendeintervall, sendet aber zusätzlich bei einem definierten Hoch- oder Tiefalarm.

Die optimale Konfiguration lautet daher nicht:

so selten wie möglich messen

sondern:

so häufig messen wie für die Prozessüberwachung erforderlich und nur so häufig senden wie für die Anwendung tatsächlich notwendig.

Warum beeinflusst die Funkqualität die Batterielaufzeit?

LoRaWAN ist für große Reichweiten und einen geringen Energieverbrauch ausgelegt. Große Reichweite bedeutet jedoch nicht, dass jede Messstelle unabhängig von ihrer Einbausituation die gleichen Funkbedingungen besitzt.

Besonders ungünstig sind Sensoren innerhalb oder unmittelbar hinter großen Metallkonstruktionen. Stahlbehälter, Schaltschrankgehäuse, Maschinen, Stahlbeton und unterirdische Schächte können die Funkverbindung deutlich verschlechtern.

Ein Sensor, der auf freiem Gelände zuverlässig mit einem Gateway kommuniziert, kann deshalb wenige Meter weiter hinter einem massiven Tank erheblich ungünstigere Bedingungen besitzen.

Schlechter Funkempfang kann dazu führen, dass robustere LoRa-Übertragungsparameter erforderlich werden. Die Übertragung benötigt dann mehr Airtime. Je nach Netz- und Gerätekonfiguration können außerdem zusätzliche Übertragungen erforderlich sein.

Deshalb ist eine niedrige Empfangsqualität kein reines Reichweitenproblem. Sie kann unmittelbar Einfluss auf die energetische Auslegung des Sensors haben.

ADR, Spreading Factor und Sendeleistung richtig einsetzen

LoRaWAN verwendet unterschiedliche Datenraten. Vereinfacht gilt: Eine robuste Übertragung für schwierige Funkbedingungen benötigt mehr Zeit als eine schnelle Übertragung bei guter Verbindung.

Der sogenannte Spreading Factor ist dabei ein wesentlicher Einflussfaktor. Ein höherer Spreading Factor verbessert die Robustheit beziehungsweise Reichweite der Übertragung, erhöht jedoch die benötigte Airtime.

Für fest installierte Sensoren ist deshalb Adaptive Data Rate – ADR – besonders interessant. Dabei kann das Netzwerk die Funkparameter anhand der tatsächlich beobachteten Verbindung optimieren. Dazu gehören je nach LoRaWAN-Version und Konfiguration unter anderem Datenrate, Sendeleistung und Übertragungsverhalten.

Steht ein Sensor nahe an einem gut erreichbaren Gateway, kann eine hohe Datenrate mit entsprechend kurzer Airtime möglich sein. Ein weit entfernter Sensor hinter mehreren Hindernissen benötigt dagegen möglicherweise robustere Funkparameter.

ADR kann jedoch keine schlechte Anlagenplanung vollständig kompensieren. Wird ein Sensor in einem nahezu abgeschirmten Metallschacht installiert, ist eine Verbesserung der Gateway- oder Antennenposition häufig wesentlich sinnvoller als eine dauerhaft besonders robuste Funkkonfiguration.

Wann entstehen zusätzliche Übertragungen?

Eine wichtige Unterscheidung besteht zwischen bestätigten und unbestätigten Uplinks.

Bei einem unbestätigten Telegramm wird nicht für jeden Messwert zwingend eine Empfangsbestätigung durch das Netzwerk benötigt. Das reduziert den Kommunikationsaufwand und ist für viele regelmäßig wiederkehrende Messwerte sinnvoll.

Ein bestätigter Uplink erwartet dagegen eine Bestätigung. Wird diese nicht empfangen und sind mehrere Übertragungsversuche vorgesehen, kann das Telegramm erneut gesendet werden.

Auch bei unbestätigten Telegrammen kann LoRaWAN abhängig von der Netzkonfiguration mehrere Übertragungen desselben Frames vorsehen. Deshalb sollte bei einer auffällig kurzen Batterielaufzeit nicht pauschal angenommen werden, dass jedes vom Gateway nicht empfangene Paket automatisch wiederholt wird. Entscheidend ist die tatsächliche Konfiguration des Geräts und des Netzwerks.

Für regelmäßig übertragene Temperatur-, Druck- oder Füllstandswerte ist es häufig nicht notwendig, jeden einzelnen Messwert quittieren zu lassen. Geht ein einzelnes zyklisches Telegramm verloren, folgt kurze Zeit später ohnehin der nächste aktuelle Messwert.

Anders kann dies bei einem seltenen kritischen Ereignis sein. Dort kann eine bestätigte Übertragung sinnvoll sein, wenn die Anwendung sicherstellen muss, dass der Alarm tatsächlich vom Netzwerk angenommen wurde.

Gateway-Abdeckung verbessern statt Batterie vergrößern

Wenn mehrere Sensoren in einem Anlagenbereich gleichzeitig eine schwache Funkqualität zeigen, sollte zuerst die Netzabdeckung untersucht werden.

Ein zusätzliches oder besser positioniertes Gateway kann energetisch wesentlich wirksamer sein als größere Batterien in vielen einzelnen Sensoren. Auch eine Positionsänderung um wenige Meter kann helfen, wenn dadurch eine massive Stahlwand oder ein großer Behälter nicht mehr direkt zwischen Sensor und Gateway liegt.

Besonders wichtig ist die Antennenposition. Ein Sensor sollte nicht unnötig tief hinter Rohrleitungen, Metallverkleidungen oder Stahlträgern montiert werden. Bei externen Antennen müssen außerdem die vom Hersteller vorgesehenen Antennen, Kabel und Installationsbedingungen eingehalten werden.

Die Funkplanung sollte möglichst unter realen Anlagenbedingungen erfolgen. Eine Messstelle, die während der Montage bei offenen Schaltschranktüren funktioniert, kann nach dem Schließen des Gehäuses eine völlig andere Funkqualität besitzen.

Alarmverkehr sinnvoll begrenzen

Ereignisbasierte Übertragung ist eine hervorragende Möglichkeit, Batterielaufzeit und Aktualität miteinander zu verbinden. Sie kann jedoch selbst zum Problem werden, wenn Alarmgrenzen ungünstig gewählt sind.

Ein typisches Beispiel ist ein Füllstand, der genau um einen Alarmwert schwankt. Ohne Hysterese kann der Sensor in kurzer Folge „Alarm“, „Normal“, „Alarm“ und wieder „Normal“ übertragen.

Ähnliches gilt für Druck oder Temperatur. Kleine Prozessschwankungen, Messrauschen oder Wellenbewegungen im Tank können eine große Zahl zusätzlicher Funktelegramme erzeugen.

Eine geeignete Hysterese beziehungsweise zeitliche Entprellung verhindert diesen Effekt. Ein Alarm sollte nicht bei jeder minimalen Grenzwertüberschreitung neu übertragen werden.

Auch die Wiederholrate eines aktiven Alarms muss bewusst gewählt werden. Ein seit zwölf Stunden bestehender niedriger Tankfüllstand muss nicht zwangsläufig jede Minute erneut als identischer Alarm übertragen werden. Häufig reichen eine sofortige Erstmeldung und anschließend deutlich größere Erinnerungsintervalle.

Payload und Datenpakete optimieren

Auch die Menge der übertragenen Daten beeinflusst die Airtime. Ein Telegramm sollte deshalb die Informationen enthalten, die für die Anwendung tatsächlich benötigt werden, aber nicht unnötig aufgebläht werden.

Bei einem einfachen Füllstandssensor können Messwert, Status und Batteriezustand bereits ausreichen. Lange Klartextinformationen oder permanent wiederholte statische Gerätedaten sind dagegen selten sinnvoll.

Mehrere Messgrößen können gegebenenfalls in einem gemeinsamen Telegramm übertragen werden. Dadurch lässt sich vermeiden, dass für jeden einzelnen Wert ein separater Funkvorgang ausgelöst wird.

Eine kompakte Payload reduziert allerdings nur einen Teil des Gesamtverbrauchs. Ein schlecht erreichbarer Sensor mit extrem kurzem Sendeintervall wird nicht allein dadurch zu einer Zehnjahreslösung, dass einige Bytes aus dem Telegramm entfernt werden.

Offline-Puffer und Kommunikationsausfälle

Bei abgelegenen Messstellen sollte außerdem festgelegt werden, was während eines längeren Netzwerkausfalls passieren soll.

Unterstützt das Gerät eine lokale Speicherung, können Messwerte zunächst gepuffert und später übertragen werden. Dabei ist jedoch zu vermeiden, dass nach Wiederherstellung der Verbindung plötzlich tausende historische Einzeltelegramme gesendet werden und die Batterie unnötig belasten.

Für viele Monitoring-Anwendungen ist eine intelligente Verdichtung sinnvoller. Beispielsweise können während eines Kommunikationsausfalls Minimal-, Maximal- und Mittelwerte gespeichert werden, sofern das eingesetzte Gerät diese Funktion unterstützt und die Anwendung keine vollständige Zeitreihe benötigt.

Auch wiederholte Join- beziehungsweise Verbindungsversuche können bei länger fehlender Netzabdeckung relevant werden. Ein Gerät sollte deshalb nicht dauerhaft in sehr kurzen Abständen versuchen, eine nicht vorhandene Verbindung wiederherzustellen.

Temperatur und Batterie berücksichtigen

Die erreichte Batterielaufzeit hängt nicht ausschließlich vom Funkprotokoll ab. Auch die Umgebungsbedingungen beeinflussen die verfügbare Energie und das Verhalten der Batterie.

Gerade Außenmessstellen können im Winter deutlich kälter werden als bei der ursprünglichen Planung angenommen. Gleichzeitig kann ein Sensor tagsüber durch Sonneneinstrahlung stark erwärmt werden.

Bei der Auslegung sollte deshalb nicht nur eine theoretische Laufzeit unter Raumtemperatur betrachtet werden. Entscheidend sind der spezifizierte Temperaturbereich von Funkeinheit und Batterie sowie das reale Temperaturprofil der Messstelle.

Bei sehr abgelegenen Messstellen ist außerdem eine Reserve sinnvoll. Eine theoretisch exakt bis zum nächsten Wartungstermin ausgelegte Batterie bietet wenig Sicherheit, wenn sich Funkbedingungen, Alarmhäufigkeit oder Umgebungstemperatur später ändern.

Systematische Optimierung

Beobachtung	Mögliche Ursache	Sinnvolle Maßnahme
Batterie leert sich trotz weniger Messwerte schnell	Zu häufige Funkübertragung	Mess- und Sendeintervall voneinander trennen
Nur einzelne Sensoren haben kurze Laufzeit	Lokale Funkabschattung	Montageposition und Gateway-Empfang prüfen
Sensor arbeitet dauerhaft mit robuster Funkkonfiguration	Ungünstige Verbindung zum Gateway	ADR, Gatewaystandort und Antennenposition untersuchen
Sehr viele Telegramme im Ereignisprotokoll	Alarm flattert um einen Grenzwert	Hysterese und Alarmverzögerung optimieren
Viele bestätigte Nachrichten	Jeder Messwert verlangt eine Quittierung	Bestätigung nur dort einsetzen, wo sie fachlich erforderlich ist
Verbrauch steigt nach Netzausfall	Wiederholte Kommunikation oder Nachübertragung	Reconnect-Strategie und Offline-Puffer prüfen
Batterieproblem hauptsächlich im Winter	Niedrige Umgebungstemperatur	Temperaturbereich und Batteriereserve überprüfen

Die wichtigste Information liefert dabei häufig nicht der aktuelle Batteriestand, sondern das Kommunikationsprotokoll. Anzahl der Uplinks, verwendete Datenrate, Funkqualität, Alarmhäufigkeit und eventuelle Wiederholungen zeigen wesentlich genauer, wo die Energie tatsächlich verbraucht wird.

Praxisbeispiel einer abgelegenen Tankmessstelle

Auf einem Betriebsgelände wird der Füllstand eines Tanks mit einem batteriebetriebenen LoRaWAN-Sensor überwacht. Der Füllstand verändert sich normalerweise nur langsam. Trotzdem wurde bei der Inbetriebnahme ein Mess- und Sendeintervall von jeweils fünf Minuten eingestellt.

Damit entstehen 288 reguläre Übertragungsereignisse pro Tag. Zusätzlich befindet sich der Tank zwischen zwei großen Stahlbehältern. Die Funkverbindung zum Gateway im Verwaltungsgebäude ist ungünstig.

Nach einigen Monaten fällt auf, dass die prognostizierte Batterielaufzeit deutlich unterschritten wird.

Die Prozessanforderung wird daraufhin neu bewertet. Für die Disposition reicht ein aktueller Füllstand alle zwei Stunden. Ein schneller Wert ist nur erforderlich, wenn der Tank einen kritischen Mindeststand erreicht.

Die Messung bleibt deshalb intern beispielsweise in einem kürzeren Raster bestehen, das reguläre Sendeintervall wird jedoch deutlich verlängert. Gleichzeitig wird ein Ereignisalarm mit geeigneter Hysterese eingerichtet.

Zusätzlich wird das Gateway an eine günstigere Position gebracht, sodass der direkte Funkweg nicht mehr vollständig durch die Stahlbehälter abgeschattet wird.

Parameter	Vor Optimierung	Nach Optimierung
Reguläres Sendeintervall	5 Minuten	2 Stunden
Reguläre Übertragungen pro Tag	288	12
Kritischer Alarm	Im normalen Zyklus	Ereignisbasiert
Gateway-Situation	Stark durch Metall abgeschattet	Funkweg verbessert
Prozessinformation	Deutlich häufiger als benötigt	An tatsächlichen Bedarf angepasst

Damit werden zwei Ursachen gleichzeitig beseitigt: unnötig viele reguläre Sendungen und eine ungünstige Funkverbindung.

Das Beispiel zeigt auch, warum eine größere Batterie nicht die erste Maßnahme sein sollte. Sie hätte die Symptome lediglich verlängert, ohne die ineffiziente Konfiguration zu beseitigen.

Batteriewechsel planbar machen

Eine lange Batterielaufzeit bedeutet nicht, dass die Batterie bis zum völligen Ausfall betrieben werden sollte.

Bei größeren IIoT-Installationen sollte der Batteriezustand gemeinsam mit den normalen Messwerten überwacht werden. Dadurch kann der Austausch mit ohnehin geplanten Wartungsarbeiten kombiniert werden.

Besonders hilfreich ist ein Trend. Sinkt der Batteriestatus eines einzelnen Sensors deutlich schneller als bei vergleichbaren Messstellen, sollte nicht sofort nur die Batterie ersetzt werden. Zunächst sollte geprüft werden, ob dieser Sensor häufiger sendet, mehr Alarme erzeugt oder schlechtere Funkbedingungen besitzt.

So wird die Batterie selbst zu einem Diagnoseindikator für die Qualität der gesamten IIoT-Installation.

Welche IIoT-Produkte eignen sich?

WIKA NETRIS 1

Der WIKA NETRIS 1 ist eine universelle Funkeinheit für Standardsensoren und eignet sich besonders gut für Retrofit- und Fernüberwachungsaufgaben. Er kann unter anderem Messgeräte mit 4 … 20 mA, 0 … 10 V sowie Pt100- beziehungsweise Pt1000-Sensoren anbinden.

Für die Funkübertragung stehen je nach Ausführung LPWAN-Technologien wie LoRaWAN und mioty sowie Bluetooth für die lokale Kommunikation zur Verfügung. Die Funkeinheit kann batteriebetrieben oder extern versorgt werden. Durch die konfigurierbare Mess- und Übertragungssteuerung lässt sich das Kommunikationsverhalten an die jeweilige Anwendung anpassen.

WIKA NETRIS 2

Der NETRIS 2 ist für Anwendungen in explosionsgefährdeten Bereichen ausgelegt und besitzt zwei eigensichere analoge 4 … 20-mA-Eingänge. Dadurch können vorhandene Prozessmessgeräte in eine batteriebetriebene LoRaWAN-Infrastruktur eingebunden werden.

Das ist beispielsweise für Druck-, Füllstand- oder andere Prozessmessstellen interessant, bei denen eine nachträgliche feste Verkabelung sehr aufwendig wäre.

WIKA NETRIS 3

Der NETRIS 3 ist eine LoRaWAN-Funkeinheit für kompatible WIKA-Messgeräte und ebenfalls für explosionsgefährdete Bereiche vorgesehen. Die Messdaten werden digital vom angeschlossenen WIKA-Gerät übernommen und anschließend drahtlos übertragen.

Ein konkretes Beispiel aus der Füllstandmesstechnik ist der WIKA FLRU Reed-Füllstandstransmitter in Verbindung mit dem NETRIS 3. Damit lässt sich die Füllstandserfassung von Flüssigkeiten in eine webbasierte Fernüberwachung integrieren.

WIKA nennt für die NETRIS-Funkeinheiten abhängig von Geräteversion, Konfiguration und Einsatzbedingungen Batterielaufzeiten von bis zu zehn Jahren. Eine solche Angabe sollte jedoch immer als Ergebnis eines definierten Betriebsprofils verstanden werden und nicht als unabhängig vom Sendeintervall garantierte Laufzeit.

Unter IIoT Lösungen finden Sie entsprechende Funkmodule und Messsysteme. Für Tank- und Behälteranwendungen stehen unter IIoT Füllstandüberwachung geeignete Lösungen zur Verfügung.

ICS Schneider Messtechnik unterstützt bei der Auswahl von Sensor, Funkeinheit und Messprinzip sowie bei der Auslegung von Messintervall, Datenübertragung und geeigneter IIoT-Infrastruktur.

Fazit

Eine kurze Batterielaufzeit bei LoRaWAN-Sensoren ist nicht automatisch ein Batterieproblem. Häufig ist sie das Ergebnis aus zu kurzen Sendeintervallen, ungünstiger Funkabdeckung und unnötigem Kommunikationsverkehr.

Der wichtigste Ansatz besteht darin, Messintervall und Sendeintervall voneinander zu trennen. Ein Prozess kann häufig überwacht werden, ohne jeden einzelnen Messwert sofort zu übertragen.

Für langsam veränderliche Größen wie Tankfüllstand, Druckniveau oder Umgebungstemperatur sind längere reguläre Sendeintervalle kombiniert mit ereignisbasierten Alarmen häufig wesentlich effizienter.

Ebenso wichtig ist eine gute Gateway-Abdeckung. Eine ungünstige Montage hinter Metallkonstruktionen kann zu robusteren und damit längeren Funkübertragungen führen. ADR hilft, die Funkparameter an die reale Verbindung anzupassen, ersetzt aber keine technisch saubere Funkplanung.

Bestätigte Telegramme sollten gezielt eingesetzt werden. Nicht jeder zyklische Messwert benötigt zwingend eine individuelle Empfangsbestätigung. Kritische Ereignisse können dagegen anders behandelt werden als regelmäßig wiederkehrende Zustandswerte.

Auch Alarmhysterese, Payload, Offline-Verhalten und Umgebungstemperatur gehören zur Laufzeitbetrachtung.

Eine lange Batterielaufzeit entsteht deshalb nicht durch einen einzelnen Parameter. Sie ist das Ergebnis eines abgestimmten Systems aus Sensorik, Datenmodell, Funkverbindung, Gateway-Infrastruktur und Wartungsstrategie.

Häufige Fragen zur LoRaWAN-Batterielaufzeit

Warum ist die Batterie meines LoRaWAN-Sensors so schnell leer?

Häufige Ursachen sind ein sehr kurzes Sendeintervall, ungünstige Funkbedingungen, viele Alarmtelegramme, zusätzliche Übertragungsversuche oder eine Kombination dieser Faktoren.

Ist das Messintervall dasselbe wie das Sendeintervall?

Nicht zwingend. Ein Sensor kann beispielsweise alle fünf Minuten messen, aber nur einmal pro Stunde einen Wert beziehungsweise zusammengefasste Daten übertragen, sofern das Gerät diese Konfiguration unterstützt.

Verbraucht LoRaWAN bei schlechtem Empfang mehr Batterie?

Das kann der Fall sein. Bei ungünstigen Funkbedingungen können robustere Funkparameter mit längerer Airtime erforderlich werden. Abhängig von der Konfiguration können außerdem zusätzliche Übertragungen entstehen.

Was macht ADR?

Adaptive Data Rate ermöglicht dem LoRaWAN-Netzwerk, Übertragungsparameter wie Datenrate und Sendeleistung an die Funkbedingungen eines Geräts anzupassen. Dadurch können Airtime und Energieverbrauch insbesondere bei stationären Geräten optimiert werden.

Ist ein hoher Spreading Factor schlecht?

Ein höherer Spreading Factor ist nicht grundsätzlich falsch. Er ermöglicht robustere Kommunikation unter schwierigen Funkbedingungen. Die Übertragung benötigt jedoch mehr Airtime, weshalb eine dauerhaft unnötig hohe Einstellung vermieden werden sollte.

Wird jedes verlorene LoRaWAN-Paket automatisch wiederholt?

Nein. Das Übertragungsverhalten hängt unter anderem vom Nachrichtentyp und von den Netzwerkparametern ab. Deshalb sollte bei einer Batteriediagnose die tatsächliche Gerätekonfiguration geprüft werden.

Sollte ich alle Messwerte als Confirmed Uplink senden?

Für regelmäßig wiederkehrende Messwerte ist das häufig nicht notwendig. Eine Empfangsbestätigung verursacht zusätzliche Kommunikation. Kritische Ereignisse können dagegen eine bestätigte Übertragung rechtfertigen.

Wie kann ich einen Sensor hinter einem Metalltank verbessern?

Zunächst sollten Sensor- beziehungsweise Antennenposition und Gatewaystandort untersucht werden. Häufig ist eine bessere Funkgeometrie effektiver als eine Änderung der Batteriegröße.

Was ist bei Alarmen wichtig?

Hysterese und gegebenenfalls Zeitverzögerung sollten verhindern, dass ein Messwert direkt am Grenzwert ständig zwischen Normal- und Alarmzustand wechselt und dadurch viele zusätzliche Telegramme erzeugt.

Sind zehn Jahre Batterielaufzeit bei LoRaWAN realistisch?

Solche Laufzeiten sind bei entsprechend ausgelegten Geräten und günstigen Betriebsprofilen möglich. Sie hängen jedoch wesentlich von Sendeintervall, Funkbedingungen, Alarmverkehr, Umgebungstemperatur und der konkreten Gerätekonfiguration ab.