Ok, jetzt bin ich meine “Problem” auf die Spur gekommen… [CayenneLPP] Sensor type "scale.0.kg" not found in CayenneLPP ist wie @Andreas sagte nur eine Statusmeldung bei der Benutzung von LoRa und CayenneLPP. Bei mir wurden der HX711 nur direkt nach dem power on einmal ausgelesen und danach wurde der Sensor bei den nächsten Loops nicht mehr gefunden. Ich habe die Kabel bei meinem Testaufbau dann noch mal gecheckt und nun geht es wieder, scheinbar ein schlecht gestecktes Kabel auf meinem Breadboard.
Vielleicht sollte die Statusmeldung [CayenneLPP] Sensor type "scale.0.kg" not found in CayenneLPP geändert werden, so dass es nicht wie ein Fehler aussieht?
Und: gibt es einen speziellen Grund, dass die Sensorwerte bei der LoRa Übertragung umbenannt werden? Also z.B. “weight.0” zu “load_5” oder “temperature.287350c2371901d0.onewire:0” zu “temperature_10”? Die anderen Namen der Sensorwerte bei WiFi bzw. LoRa hat mich auch erstmal etwas verwirrt.
Ist das nötig für das CayenneLPP Format?
Ich habe den LoPy4 übrigens auf einem pyTrack, bei mir macht es so erstmal keinen Unterschied ob power_toggle_busses auf True oder False steht.
Weiter ist z.B. temperature.287350c2371901d0.onewire:0” deutlich länger als mit der Cayenne payload. Ist halt LoRa und einen Tod muss man sterben! :-) Wenn wir alle – bei BOB z.B. 6 Temperatursensoren – jeweils vollqualifiziert mit der Sensor-ID und dem onewire-bus übergeben würden wäre die maxiale payload size z.B. von 51 byte bei SF10 längst überschritten, s. TTN maximal payload size
Ich versuche mal ein wenig Licht ins Dunkel zu bringen. Zunächst zum LoRaWAN OTAA Join Prozedere:
Die Logs und die neue Settings-Option join_attempt_interval sind trügerisch. Ich wiederhole mich vielleicht, aber die “Not joined yet” Meldung suggeriert nur einen JOIN Versuch. In Wirklichkeit ist es nur ein pausierter while Loop der auf has_joined testet und die Meldung im (default) 2,5 Sekunden Takt ausspuckt. Die Join Versuche werden nur intern vom LoRa Modul nach dem lora.join() kontrolliert.
Internally the stack will automatically retry every 15 seconds until a Join Accept message is received.
mit 15 Sekunden Intervall geht es los und erhöht sich dann nach einigen Fehlversuchen bis hin zu mehreren Minuten, wenn kein JOIN ACK von einem Gateway sauber empfangen wurde. Terkin hat keine Kontrolle über Taktung und das Ergebnis. Die einhüllende for Schleife ist deshalb total überflüssig samt des attempts Konfig-Parameters. Sie bleibt einfach immer im ersten Loop bis zum JOIN und das kann schon mal ewig dauern. Die Schleife kann deshalb meines Erachtens > /dev/null.
Eine Alternative, die ohne die JOIN-Prozedur auskommt, wäre Aktivierung per APB. Hier findet keine Aushandlung der Verbindungssicherheit statt. Das Device sendet von Angang an seine Pakete los, ohne zu wissen, ob ein Gateway in der Nähe ist. Mit APB muss man allerdings auf den Frame Counter aufpassen .
Ist kein Fehler, sondern teilt nur mit, dass es kein Mapping in der to_cayenne_lpp Methode für die Kalibrierungsparameter des HX711 gibt. Die sind erstens konstant und zweitens ohne Informtionsgehalt für die Datenvisualisierung.
Dazu sei ein Blick in die CayenneLPP Dokumentation angeregt:
Ein CayenneLPP Data Frame wie es auf die Funkstrecke geschickt wird, besteht immer aus einem Byte für den Channel, ein Byte für den Datentyp (Variable) und ein bis 9 Bytes für den Datenwert bzw Datetuple. Weder findet eine Umbenennung statt noch werden ASCII Strings ohne Informationsgehalt übertragen, wie sie zB eine JSON Struktur aufbauen: {},:". … JSON über LoRa zu verschicken funktioniert grundsätzlich, allerdings kommen wir sehr schnell an die Limitierungen hinsichtlich Payload-Größe und Airtime. src/lib/terkin/telemetry/formatter.py mappt unsere Variablen auf die vordefinierten Datentypen und da zB der Datentyp Temperatur mehrfach verwendet wird, müssen wir sie auf verschiedene Channels legen. Den vollen Telemetrienamen samt Adresse und Bus des Sensors werden wir nie über Cayenne+LoRa übermitteln können.