ein paar weitere Commits habe ich dem Branch noch spendiert. Mit dem Mergen in master warte bitte noch. Will den Code noch etwas säubern und Deep Sleep testen.
Eine Sorge habe ich noch bezüglich nvram_save() im LoRaManager. Diese Funktion muss eigentlich nach jedem Send aufgerufen werden. Die speichert nicht nur den Join Status und die Keys, sondern auch den Packet Counter, der bei jedem .send eins hochgezählt wird. Das ist so eine Art Sicherheitscheck mittels Abgleich zwischen dem Counter im Payload und dem “Frame Counter Check” im TTN Backend. Im Telemetrie-Module gibt ja es keine Zugriff auf das lora Objekt, was den Call erstmal nicht möglich macht (self.lora.nvram_save()). Für Anregungen wäre ich sehr dankbar!
DEEP SLEEP funktioniert grundsätzlich ohne Rejoin nach dem Aufwachen über die NVRAM Wiederherstellung. Aber, der Packet Counter bleibt wie vermutet bei 0 stehen.
Versuche doch einmal, dort vor Ort einfach ein LoRa-Objekt dummy-mäßig neu zu erstellen und dann darauf nvram_save() aufzurufen – in der Hoffnung, dass es Dir unter der Haube das identische Objekt zur Verfügung stellt, wie bei der ursprünglichen Instantiierung.
Hm, wahrscheinlich wird das aber nicht klappen, weil es dann die falschen UID-Werte abspeichert (None). Auf einen Versuch kommt es aber an.
Ansonsten muss ich mich nochmal ransetzen, dann doch eine Referenz auf den LoRaManager bis hin in den Telemetrie-Handler reinzureichen. Ich hatte gehofft, dass wir das lose entkoppelt beibehalten können, aber die Realität zeigt wohl, dass das ein Holzweg bzw. Hirngespinst gewesen sein könnte und wir davon hinsichtlich der Architektur nun endgültig Abstand nehmen sollten.
Ich glaube, den Versuch können wir eigentlich überspringen. Woher sollte das Objekt, den Join Status, die Keys und den Packet Counter kennen? Neu joinen will ich ja schon gar nicht nach einem DEEP_SLEEP.
Anyway, hab die drei Zeilen doch testweise in def send geschrieben:
Das stört zwar nicht die Übermittlung der LoRa-Pakete aber dem richtigen Verhalten bzgl des Counters hilft es auch nicht.
Der Vorteil des Durchreichens vom lora Objekt wäre auch, dass die ratrack Variante mit den letzen Änderungen auch wieder funktionieren würde (wer auch immer sie nutzt…?). Denn die greift zB auch auf die def create_lora_socket in lora.py zurück, welche wir kürzlich nach telemetry.py verschoben haben.
Ansonsten läuft die Firmware seit letzter Nacht super smooth. Alle 5min aufwachen und senden. Völlig geschmeidig. Meinetwegen kannst du meinen Branch ttn_lora in deinen mergen und anschließend auf master wuppen.
Traumhaft! Teste ich vielleicht noch heute Abend und verschiebe dann auch create_lora_socket wieder zurück nach lora.py und versuche die dortige send Methode zu nutzen.
\o/
Nun auch mit durchgereichtem lora_manager. Deine Vorlage war Gold wert.
Die Data Rate auf dem LoRa-Socket setze ich nun in telemetry:def send, weil dort auch die datarate aus der Config reingereicht wird (statt über otaa_settings in lora.py). Thematisch passt es auch besser in den die Telemetrie-Config, wie ich finde, denn otaa_settings behandelt ja nur den Join-Prozess.
Der Frame Counter zählt nun fleißig hoch, so wie es sein soll:
Wie immer findest du alles in meinem ttn_lora Zweig.