Es gibt schon einiges an Vorarbeit, wir haben gerade ein paar Dinge identifiziert, die noch auf dem Weg liegen:
für den Betrieb des LoRa-Sockets musste noch ein fehlender import hinzugefügt werden [1]
wenn wir den LoPy sparsam wie andere LoRa-Nodes betreiben wollen, muss das WiFi-Modem, genauso wie momentan das LTE-Modem komplett abgeschaltet werden können.
CayenneLPP erweitern mit Load Cell Frame für Abbildung im Namesraum von Kotori
Keine Fehlermeldung bei fehlender settings-user.json
Zusammen mit @Thias (vielen vielen Dank!) haben wir letzte Woche an der ordentlichen Integration der LoRaWAN-Telemetrieeinheit gearbeitet, die wir zusammen mit @tonke und @einsiedlerkrebs im Frühjahr begonnen hatten.
ich habe mich nun auch in den Telemetrieteil der Firmware gewagt und habe das Gefühl, nicht mehr weit davon entfernt zu sein, Daten über LoRA an TTN zu senden. Der verlinkte Commit setzt auf den aktuellen Hiveeyes/master auf.
Leider bekomme ich noch diese Logs. Ich bin nicht so der Objektorientierte und komm nicht drauf, wie ich die lora_send Funktion im lora_manager Objekt in Zeile 439 richtig anspreche
30.3450 [terkin.telemetry ] INFO : Sending payload via LoRa...
30.3586 [terkin.telemetry ] INFO : Payload: bytearray(b'\x00g\x00~')
30.3774 [terkin.telemetry ] ERROR : [LoRa] Transmission failed
Traceback (most recent call last):
File "/flash/lib/terkin/telemetry.py", line 439, in send
AttributeError: 'TelemetryTransportLORA' object has no attribute 'lora_manager'
Kannst du mal drauf schauen?
Ich habe auch einige Umbenennungen vorgenommen und hoffe im Ansatz verstanden zu haben, wie die Firmware tickt.
Aber die Codeteile aus dem Branch sind schon am 15. März in den master Zweig geflossen und ein erfolgreicher Merge ist sehr unwahrscheinlich, weil sich seit dem doch einiges in dem Telemetriemodul getan hat.
Wenn ich mir allerdings den Code von einsiedlerkrebs ansehe, verstehe ich nicht, an welcher Stelle die Daten tatsächlich über das LoRa Module gesendet werden sollten.
Ahja? Ok, danke für die Analyse. Gut, dann hatten wir das schon längst gemerged und ich sollte beizeiten mal die verwaisten Branches wegräumen, damit sie keine Verwirrung mehr stiften.
Habe gestern Abend wieder 2 Stunden am Code gesessen - leider erfolglos.
Bin mir auch gar nicht mehr sicher, ob der derzeitige Ansatz über den Aufruf von lora_send in TelemetryTransportLORA funktionieren kann. Keine Ahnung wie man die vorher erstellte Instanz von LoRaManger samt des Sockets ansprechen kann.
Sorry dass Du darum gekämpft hast. Ich versuche, später alles zusammenzuzurren. Da ich ja an der Architektur mit schuld bin, kenne ich einigermaßen die Zapfen, wie sie am besten zusammenpassen sollten.
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.
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 :/
