NEWS
Test Adapter LoraWan
-
@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:
Falls ich dich richtig verstanden habe,
lorawan.0.ApplicatioID.devices.DevEUIXXXXXX.downlink.raw.jsonNein, dort stehen nur die "Queued" Messages drin, die zum Versenden anstehen. Diese wurden noch nicht unbedingt an das Device gesendet (weil es z.B. noch schläft).
@marc-berg
Nur ist nicht richtig, wenn versendet wurde, findest du dort „downlink_sent“ (sorry fürs Bild, bin nicht am PC)
Stimmt, es wird immer angehängt, weil es in Chirpstack kein Replace gibt und wir es einheitlich haben wollten. -
@marc-berg
Nur ist nicht richtig, wenn versendet wurde, findest du dort „downlink_sent“ (sorry fürs Bild, bin nicht am PC)
Stimmt, es wird immer angehängt, weil es in Chirpstack kein Replace gibt und wir es einheitlich haben wollten.@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:
Stimmt, es wird immer angehängt, weil es in Chirpstack kein Replace gibt und wir es einheitlich haben wollten.
Danke für deine Mühe. Ich muss jetzt erstmal überlegen, ob die Umstellung für mich sinnvoll ist, wenn ich am Ende für Up- und Downlinks doch wieder mit JSON hantieren muss.
Mein Usecase ist u.a. eine Minimierung des Akkuverbrauchs eines Zisternensensors bei gleichzeitig bester Messauflösung durch "intelligente" Steuerung der Mess- und Uploadintervalle. Dafür muss ich sicher wissen, welchen Intervall das Gerät zuletzt empfangen hat und ich muss in der Lage sein, den neuen zu setzenden Intervall innerhalb der "Sleep" Zeit mehrfach zu ändern.
-
@marc-berg
Du hattest zwar keine Frage gestellt, ich möchte aber trotzdem antworten, einfach auch damit für diejenigen, die hier mitlesen kein falscher Eindruck entsteht, dass man auch bei der sinnvollen Nutzung des Adapters "mit JSON hantieren muss", weil das nicht stimmt.Wenn man ein Video macht, wie ein Brief in einen Briefkasten geworfen wird, mag das als Nachweis gelten, dass der Brief verschickt wurde, aber kein Nachweis dafür, dass er empfangen wurde. Das ist nur mit Versand Nachnahme mit Rückschein möglich.
Genauso verhält es sich bei LoRaWAN, mit den im JSON eingebetteten Werten zum Versand, weil damit nur bestätigt wird, dass der Downlink erfolgreich versendet wurde. Das heisst noch lange nicht, dass er beim Gerät auch angekommen ist. Möchte man sicher sein, dass Downlink am Gerät angekommen ist, dann kann man den Downlink "mit Bestätigung" versenden. Das Gerät quittiert dann den Empfang mit einem Uplink.
Eine Minimierung des Akkuverbrauchs?
Als wenn man durch den Empfang von Downlinks und deren Verarbeitung keinen Akkuverbrauch hätte, im Gegenteil, durch das ständige Umkonfigurieren wird man den Akkuverbrauch mehr erhöhen, als durch Intervalländerungen einzusparen wäre.
Beste Messauflösung? Bei einer Zisterne?
Ist deine Zisterne dynamisch wie ein junges Wiesel? Intervalle von 20/15 von mir aus 10 Minuten, sollte für jeden UseCase ausreichend sein.
Du muss wissen welchen Intervall das Gerät als letztes empfangen hat?
Es wird wohl der sein, den du hingeschickt hast. Nicht nur dafür, sondern auch zur Berechnung des Flows (plus/minus Liter/Minute) setzten wir ein Script ein, welches den aktuellen Stand, mit dem vorherigen, im Verhältnis zwischen den beiden Timestamps setzt. Damit hat man den aktuellen Intervall, selbst wenn mal ein Paket verloren geht.
Außerdem:
Die Fair Use Policey von TTN besagt, dass Downlinks auf ein absolutes Minimum zu begrenzen und nur aus gutem Grund eingesetzt werden sollen. Kein guter Grund ist es die Lebensdauer einer 20€ Batterie um ein Tage verlängern zu wollen. Es gibt einen Grund warum die maximale Anzahl der Downlinks eines Geräts auf 10 DL in 24 Stunden begrenzt ist, nämlich damit alle etwas von diesem kostenfreien Netzwerk haben und nicht einzelne es benutzen, als wären sie die alleinigen Eigentümer.
Nachtrag, weil gefragt wurde:
Nein LoRaWAN ist nicht auf 10 Downlinks am Tag beschränkt, dies ist erstmal bei der Community Version von TTN in den Fair Use Policeys festgelegt und bei der "Bezahlversion" anders geregelt.
Wenn man einen eigenen LNS betreibt, wie z.B.- Chirpstack, ist man nur durch die gesetzliche Regelung begrenzt (1% Duty-Cycle und das ist bei 36 Sekunden "Sendezeit" in einer Stunde (3600 Sek.) und 60ms pro Paket im SF7 schon einiges, was da möglich ist. -
@marc-berg
Du hattest zwar keine Frage gestellt, ich möchte aber trotzdem antworten, einfach auch damit für diejenigen, die hier mitlesen kein falscher Eindruck entsteht, dass man auch bei der sinnvollen Nutzung des Adapters "mit JSON hantieren muss", weil das nicht stimmt.Wenn man ein Video macht, wie ein Brief in einen Briefkasten geworfen wird, mag das als Nachweis gelten, dass der Brief verschickt wurde, aber kein Nachweis dafür, dass er empfangen wurde. Das ist nur mit Versand Nachnahme mit Rückschein möglich.
Genauso verhält es sich bei LoRaWAN, mit den im JSON eingebetteten Werten zum Versand, weil damit nur bestätigt wird, dass der Downlink erfolgreich versendet wurde. Das heisst noch lange nicht, dass er beim Gerät auch angekommen ist. Möchte man sicher sein, dass Downlink am Gerät angekommen ist, dann kann man den Downlink "mit Bestätigung" versenden. Das Gerät quittiert dann den Empfang mit einem Uplink.
Eine Minimierung des Akkuverbrauchs?
Als wenn man durch den Empfang von Downlinks und deren Verarbeitung keinen Akkuverbrauch hätte, im Gegenteil, durch das ständige Umkonfigurieren wird man den Akkuverbrauch mehr erhöhen, als durch Intervalländerungen einzusparen wäre.
Beste Messauflösung? Bei einer Zisterne?
Ist deine Zisterne dynamisch wie ein junges Wiesel? Intervalle von 20/15 von mir aus 10 Minuten, sollte für jeden UseCase ausreichend sein.
Du muss wissen welchen Intervall das Gerät als letztes empfangen hat?
Es wird wohl der sein, den du hingeschickt hast. Nicht nur dafür, sondern auch zur Berechnung des Flows (plus/minus Liter/Minute) setzten wir ein Script ein, welches den aktuellen Stand, mit dem vorherigen, im Verhältnis zwischen den beiden Timestamps setzt. Damit hat man den aktuellen Intervall, selbst wenn mal ein Paket verloren geht.
Außerdem:
Die Fair Use Policey von TTN besagt, dass Downlinks auf ein absolutes Minimum zu begrenzen und nur aus gutem Grund eingesetzt werden sollen. Kein guter Grund ist es die Lebensdauer einer 20€ Batterie um ein Tage verlängern zu wollen. Es gibt einen Grund warum die maximale Anzahl der Downlinks eines Geräts auf 10 DL in 24 Stunden begrenzt ist, nämlich damit alle etwas von diesem kostenfreien Netzwerk haben und nicht einzelne es benutzen, als wären sie die alleinigen Eigentümer.
Nachtrag, weil gefragt wurde:
Nein LoRaWAN ist nicht auf 10 Downlinks am Tag beschränkt, dies ist erstmal bei der Community Version von TTN in den Fair Use Policeys festgelegt und bei der "Bezahlversion" anders geregelt.
Wenn man einen eigenen LNS betreibt, wie z.B.- Chirpstack, ist man nur durch die gesetzliche Regelung begrenzt (1% Duty-Cycle und das ist bei 36 Sekunden "Sendezeit" in einer Stunde (3600 Sek.) und 60ms pro Paket im SF7 schon einiges, was da möglich ist.
-
Neu hinzu gekommen ist ein eigenes Github Repository für bereits erstellte Downlink Konfigurationen. Diese lassen sich unabhängig von Updates des LoRaWAN Adapters importieren und exportieren und sind danach sofort nutzbar.
https://github.com/BenAhrdt/LoRaWANDeviceProfilesNeben den bereits vorhandenen Geräte Konfigurationen hat auch erstmals die Konfiguration für die beiden Schaltrelais von MClimate den Weg dort hin gefunden. Ab FW Version 1.1 vom „Dry Switch“ und 1.4 vom 16ASPM (mit Leistungsmessung) vom 20.03.2025 und der hinterlegten DL Konfiguration ist es nun erstmals möglich für eine bestimmte Zeit (50ms-30 Stunden) per Downlink schalten zu lassen.
Weitere Infos hier:
Mclimate Info Text -
Habe seit heute Fehler von allen Applications.
Musste den Chirpstack neu starten und den LoRaWan-Adapter auch.error at generateRekursivObjects: TypeError: Cannot read properties of undefined (reading 'Words') - - - Message: {"deduplicationId":"c123f6e0-6dc7-4a36-9da1-73bce1088ff5","time":"2025-11-22T12:49:05.030148+00:00","deviceInfo":{"tenantId":"52f14cd4-c6f1-4fbd-8f87-4025e1d49242","tenantName":"ChirpStack","applicationId":"4acc7ee2-db6e-4971-8a2a-707c41f4185a","applicationName":"Dragino LT-22222","deviceProfileId":"6344bbb3-a1e6-44eb-b465-13455f111cac","deviceProfileName":"Dragino LT-22222","deviceName":"LT-22222_002","devEui":"a84041f88187130b","deviceClassEnabled":"CLASS_C","tags":{}},"devAddr":"001744e8","adr":true,"dr":1,"fCnt":77,"fPort":2,"confirmed":false,"data":"TwoAAAAAT+48/0E=","object":{"DI1_status":"H","ACI2_mA":20.462,"RO1_status":"OFF","Hardware_mode":"LT22222","Work_mode":"2ACI+2AVI","ACI1_mA":0,"DO2_status":"H","DO1_status":"H","AVI2_V":0,"RO2_status":"OFF","AVI1_V":20.234,"DI2_status":"H"},"rxInfo":[{"gatewayId":"503139534e7d4750","uplinkId":63489,"gwTime":"2025-11-22T12:49:05.030148+00:00","nsTime":"2025-11-22T12:49:06.935021775+00:00","rssi":-110,"snr":-6.75,"channel":5,"location":{"latitude":51.205958,"longitude":6.478704,"altitude":80},"context":"0GOprA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":867500000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":11,"codeRate":"CR_4_5"}}}}
INTEL NUC i7, Sonoff, hmIP, AVM, Jeelink, T-Link, Alexa, Saia-Burgess, uvm.
-
Habe seit heute Fehler von allen Applications.
Musste den Chirpstack neu starten und den LoRaWan-Adapter auch.error at generateRekursivObjects: TypeError: Cannot read properties of undefined (reading 'Words') - - - Message: {"deduplicationId":"c123f6e0-6dc7-4a36-9da1-73bce1088ff5","time":"2025-11-22T12:49:05.030148+00:00","deviceInfo":{"tenantId":"52f14cd4-c6f1-4fbd-8f87-4025e1d49242","tenantName":"ChirpStack","applicationId":"4acc7ee2-db6e-4971-8a2a-707c41f4185a","applicationName":"Dragino LT-22222","deviceProfileId":"6344bbb3-a1e6-44eb-b465-13455f111cac","deviceProfileName":"Dragino LT-22222","deviceName":"LT-22222_002","devEui":"a84041f88187130b","deviceClassEnabled":"CLASS_C","tags":{}},"devAddr":"001744e8","adr":true,"dr":1,"fCnt":77,"fPort":2,"confirmed":false,"data":"TwoAAAAAT+48/0E=","object":{"DI1_status":"H","ACI2_mA":20.462,"RO1_status":"OFF","Hardware_mode":"LT22222","Work_mode":"2ACI+2AVI","ACI1_mA":0,"DO2_status":"H","DO1_status":"H","AVI2_V":0,"RO2_status":"OFF","AVI1_V":20.234,"DI2_status":"H"},"rxInfo":[{"gatewayId":"503139534e7d4750","uplinkId":63489,"gwTime":"2025-11-22T12:49:05.030148+00:00","nsTime":"2025-11-22T12:49:06.935021775+00:00","rssi":-110,"snr":-6.75,"channel":5,"location":{"latitude":51.205958,"longitude":6.478704,"altitude":80},"context":"0GOprA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":867500000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":11,"codeRate":"CR_4_5"}}}}
@GregorS sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:
Habe seit heute Fehler von allen Applications.
Musste den Chirpstack neu starten und den LoRaWan-Adapter auch.error at generateRekursivObjects: TypeError: Cannot read properties of undefined (reading 'Words') - - - Message: {"deduplicationId":"c123f6e0-6dc7-4a36-9da1-73bce1088ff5","time":"2025-11-22T12:49:05.030148+00:00","deviceInfo":{"tenantId":"52f14cd4-c6f1-4fbd-8f87-4025e1d49242","tenantName":"ChirpStack","applicationId":"4acc7ee2-db6e-4971-8a2a-707c41f4185a","applicationName":"Dragino LT-22222","deviceProfileId":"6344bbb3-a1e6-44eb-b465-13455f111cac","deviceProfileName":"Dragino LT-22222","deviceName":"LT-22222_002","devEui":"a84041f88187130b","deviceClassEnabled":"CLASS_C","tags":{}},"devAddr":"001744e8","adr":true,"dr":1,"fCnt":77,"fPort":2,"confirmed":false,"data":"TwoAAAAAT+48/0E=","object":{"DI1_status":"H","ACI2_mA":20.462,"RO1_status":"OFF","Hardware_mode":"LT22222","Work_mode":"2ACI+2AVI","ACI1_mA":0,"DO2_status":"H","DO1_status":"H","AVI2_V":0,"RO2_status":"OFF","AVI1_V":20.234,"DI2_status":"H"},"rxInfo":[{"gatewayId":"503139534e7d4750","uplinkId":63489,"gwTime":"2025-11-22T12:49:05.030148+00:00","nsTime":"2025-11-22T12:49:06.935021775+00:00","rssi":-110,"snr":-6.75,"channel":5,"location":{"latitude":51.205958,"longitude":6.478704,"altitude":80},"context":"0GOprA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":867500000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":11,"codeRate":"CR_4_5"}}}}
Danke für die Info. Das war ein Bug in einer der ersten Versionen mit Bridge Funktion.
Hier wird eine notification zur Bridge gesendet, wenn ein Gerät offline war und wieder online geht.
Der Bug ist in Version 1.18.8 behoben.
Der Fehler tritt als nur auf, wenn ein Gerät, was offline war wieder sendet. Kann es sein, dass Du nach dem Neustart des Adapters einfach noch nichts von dem Gerät empfangen hast?
Auf jeden Fall, sollte es wie gesagt mit V 1.18.8 funktionieren. -
Hallo Ben,
habe die Version auf 1.18.8 angehoben, hatte bis dato nur 1.18.0.Neue Versionen standen als Update nicht zur Verfügung.
Habe aus Github installiertINTEL NUC i7, Sonoff, hmIP, AVM, Jeelink, T-Link, Alexa, Saia-Burgess, uvm.
-
@GregorS
Bitte nicht von Github installieren (NIE), sondern wenn schon, dann von NPM. -
Hallo Ben,
habe die Version auf 1.18.8 angehoben, hatte bis dato nur 1.18.0.Neue Versionen standen als Update nicht zur Verfügung.
Habe aus Github installiert@GregorS sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:
Hallo Ben,
habe die Version auf 1.18.8 angehoben, hatte bis dato nur 1.18.0.Neue Versionen standen als Update nicht zur Verfügung.
Habe aus Github installiertBis heute Mittag warten und die offizielle Beta installieren.
-
Danke für die Korrektur des Titels.
Die Angabe
ist aber auch noch nicht so ganz aktuell :-)
@mcm1957
Zum Zeitpunkt der Erstellung des Threads am 13.02.2024 war die aktuelle Version 0.2.1
Mit einen Hinweis auf den Changelog ist somit alles korrekt und bedarf keiner Änderung. -
Da die Versionsangeban im ersten Topic zwischenzeitlich veraltet sind hier mal ein Update:
Aktuelle Test Version 1.18.13 Veröffentlichungsdatum 23.11.2025 Github Link https://github.com/BenAhrdt/ioBroker.lorawan Hier Adapter Beschreibung, Changelog etc.
Support us
909
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge