Hi Matthias,
bei [1] habe ich Deine Änderungen aufgegriffen und ergänzt. Allerdings nur im Trockendock, d.h. untested. Ich hoffe, es klappt trotzdem irgendwie.
Viele Grüße,
Andreas.
1 Like
Danke! Das hätte ich selber wirklich nicht geschafft. Ich komme wohl erst morgen dazu, den Code zu testen. Ich melde mich! Schön’ Nabnd
Es war halt bisher einfach noch “zu lose” an der Stelle. Mich hat es auch einige Hirnverzwirnung gekostet, das jetzt zu lösen. Die Lösung war – wie Du beim Inspizieren des Codes feststellen wirst – den eigentlichen Netzwerk-Socket zur Kommunikation nun erst im LoRa-Adapter hochzufahren und nicht schon im Manager, da es zwischen beiden keine so einfache Verbindung gibt.
Ich sehe sehr wohl, dass die aktuelle Telemetrieschwummserei zwar flexibel ist (N Telemetrieadapter, die man zur Konfigurationszeit mit beliebigen Transporten und Serialisierungen konfigurieren kann), aber leider nur schwer durchschaubar bzw. schlicht “convoluted”.
Im Grunde ist das aber bei den IP-basierten Adaptern genauso: Sie haben auch keine direkte Verbindung zum WiFi-Manager, daher ist die Entkoppelung der Dinge im Rahmen der Architektur schon grundsätzlich in Ordnung. Vielleicht bekommt man die Implementierung aber trotzdem eleganter hin.
Ich werde in der nächsten Zeit zwar nicht zu einem entsprechenden Refactoring kommen, habe mir dazu aber eine Gedankennotiz gemacht.
Das war auch mein Eindruck.
den Code habe ich gezogen und kann leider noch nicht berichten, dass wir am Ziel sind. Mein Branch ist jetzt zwei Commits voraus, womit ich einen Fehler schon mal beheben konnte. Der create_lora_socket Call gehört ja nun nicht mehr in den LoRaManager. Der zweite Commit kann nicht schaden, denn Robustheit der Firmware hast du nun mehrfach als Zielvorgabe geäußert.
Lasse ich die aktuelle Version auf meinen LoPy4 los, erhalte ich folgendes aus dem Telemetrieteil-Log:
12.7384 [terkin.device ] INFO : Starting networking
12.7670 [terkin.network.wifi ] INFO : Starting stopwatch
12.8621 [terkin.network.wifi ] INFO : Started stopwatch successfully
12.8823 [terkin.device ] INFO : [WiFi] interface disabled in settings.
13.4107 [terkin.network.lora ] INFO : [LoRA] LoRaWAN state erased from NVRAM to let the device join the network
16.0593 [terkin.network.lora ] INFO : [LoRA] Not joined yet...
18.6725 [terkin.network.lora ] INFO : [LoRA] Not joined yet...
18.6851 [terkin.network.lora ] INFO : [LoRA] joined...
21.2193 [terkin.device ] INFO : Starting telemetry
21.2451 [terkin.device ] ERROR : Creating telemetry adapter failed for target: {'endpoint': 'lora://', 'topology': 'ttn', 'enabled': True, 'settings': {'size': 12, 'datarate': 0}, 'format': 'lpp'}
Traceback (most recent call last):
File "/flash/lib/terkin/device.py", line 184, in start_telemetry
File "/flash/lib/terkin/device.py", line 197, in create_telemetry_adapter
File "/flash/lib/terkin/telemetry.py", line 65, in __init__
AttributeError: 'dict' object has no attribute 'endpoint'
Und da hörts bei mir auch schon wieder auf mit der Auskennerei :/
so kommt self.target in class TelemetryAdapter:__init__ an:
21.0247 [terkin.telemetry ] INFO : target: {'endpoint': 'lora://', 'topology': 'ttn', 'enabled': True, 'settings': {'size': 12, 'datarate': 0}, 'format': 'lpp'}
Hopefully fixed per Fix refactoring of TelemetryAdapter · hiveeyes/terkin-datalogger@5cea0d5 · GitHub.
Hast Du einen guten Workflow, wie Du Dir die Änderungen bei Dir in den Branch holen kannst? So z.B.?
git remote add upstream https://github.com/hiveeyes/terkin-datalogger.git
git pull upstream ttn_lora
Ja, teilweise. Ein kleiner Fix war noch nötig bevor es funktionierte:
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!
1 Like
DEEP SLEEP funktioniert grundsätzlich ohne Rejoin nach dem Aufwachen über die NVRAM Wiederherstellung. Aber, der Packet Counter bleibt wie vermutet bei 0 stehen.
1 Like
Ich lass den LoPy mal ne Weile mit DEEP_SLEEP Interval = 5min und einer eigenen ttn-logger Instanz auf elbanbo laufen:
https://swarm.hiveeyes.org/grafana/d/9A1oLWBZk/thias-test-terkin-lora
1 Like
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:
from network import LoRa
self.lora_test = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)
... send...
self.lora_test.nvram_save()
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.
1 Like
Exzellent, schön zu hören!
Ich hatte gehofft, vielleicht “unter der Haube”.
Erledigt per Propagate reference to LoRaManager into TelemetryTransportLORA · hiveeyes/terkin-datalogger@5aebfdf · GitHub. Ebenso wie bisher nur im Trockendock/Blindflug, d.h. ohne Gewähr.
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.
1 Like
\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.
1 Like
Jetzt auch mit BME280 Daten im Dashboard.
Über die CayenneLPP-Schiene und die Platzierung der Sensoren auf die Channels muss ich noch mal nachdenken, siehe Integration des Cayenne Low Power Payload Protocol.
1 Like
Exzellent! Die commits aus dem ttn_lora Zweig sind nun auch im master branch gelandet.
Vielen herzlichen Dank dafür, @Thias!
1 Like
Diese Beobachtungen aus dem Pycom Forum wollte ich nur gschwind mit Dir teilen, @Thias.
Für mich ist das erstmal kein Grund zur Sorge. Weiteres werden uns vermutlich Langzeittests bei Dir zeigen.
Absolut nicht. Auf has_joined zu testen unmittelbar nach dem lora.join() grenzt an Glücksspiel. Habe drüben geantwortet.
Und, Terkin hat meine nvram_save/restore Funktionalität gefressen und arbeitet seit der Implementierung ohne jeden Tadel.
Just FYI.
1 Like