Hat noch jemand eine Idee zu den instabilen DS18B20 readings?
Spannungsversorgung, hast du mal einen Kondensator zwischen V und GND gelegt?
Timing, zu zügiges Auslesen?
Laufen die LoRa-joins eigentlich bis ein join erfolgt oder haben wir da eine Zeitspanne nach der aufgegeben, sprich Energie gespart wird? Nach einem deep sleep macht der LoPy doch jedes mal einen neuen join, oder? Wenn der nun aus welchen Gründen auch immer nicht erfolgt wäre irgendwann die Batterie leer?
Nach Aufwachen aus Deep Sleep erfolgt kein Rejoin, denn der Join-Status samt Packet Counter wird im NVRAM nach dem send() gespeichert. Nur ein RESET löscht den Status und erzwingt einen Rejoin. Also einmal gejoint jagt er nach jedem Deep Sleep den Payload in die Luft und hofft, dass ein Gateway ihn empfängt.
1 Like
Andreas hatte noch den Tipp, den nativen DS18B20-Treiber zu verwenden. Dazu in der settings.py das Kommentarzeichen (#) vor "driver": "native", entfernen, sollte dann so ausschauen:
'busses': [
[...]
{
"id": "bus-onewire-0",
"family": "onewire",
"number": 0,
"enabled": True,
"pin_data": "P11",
"driver": "native",
},
Nun schnurrt der LoPy mit nativem-DS18B20-Treiber wie eine Mietzekatze! Alle 6 Sensoren werden ohne Ausfall gelesen!
Daher haben wir nun auch in den beiden settings-example-Dateien den nativen Treiber per default aktiviert, s.
2 Likes
Momentan ist es auf “42 Versuche” hartkodiert. Klar!
Pro “Versuch” wird 2,5 Sekunden gewartet.
Insgesamt ist also für den LoRaWAN-Join-Vorgang ein Timeout von 105 Sekunden einprogrammiert. Mit einem der nächsten Commits von @tonke werden diese Werte über die Settings konfigurierbar sein. Merci schon im Voraus!
Ich glaub, dass stimmt so nicht. Die while Schleife testet nur alle 2.5s, ob der JOIN da ist. Wie lange dabei auf den JOIN innerhalb eines for Loops gewartet wird, wissen wir nicht. Unser Eindruck ist unendlich - und das 42 mal ;)
Wir könnten dem lora.join() ein timeout-Argument != 0 geben statt der Pycom Doku [1] zu folgen.
Und für den Fall, dass kein JOIN zustande kommt, fangen wir die Folgen noch nicht ab.
1 Like
Hatte heute im log auch deutlich mehr als 42 join Versuche und die Zeit war ebenfalls höher, so um die 180 Sekunden waren es bestimmt.
Mal kurz rausgekramt:
In der 0.9.0er Version gibt es in settings.example.py nun den neuen Abschnitt
Ist power_toggle_buses nur für den RasPi? Was macht das bei PyCom-Geräten? Muss es für PyCom False sein?
Der Code unterscheidet hier nicht nach der Plattform.
Mit Terkin 0.9.0 habe ich folgenden Fehler in den Logs, wenn ich die Daten über LoRa schicken will.
11.2031 [terkin.telemetry.core ] INFO : Telemetry transport: CayenneLPP over LoRaWAN/TTN
12.6419 [terkin.telemetry.formatter ] INFO : [CayenneLPP] Sensor type "scale.0.kg" not found in CayenneLPP
12.6761 [terkin.telemetry.formatter ] INFO : [CayenneLPP] Sensor type "scale.0.offset" not found in CayenneLPP
12.7189 [terkin.telemetry.formatter ] INFO : [CayenneLPP] Sensor type "scale.0.scale" not found in CayenneLPP
12.7612 [terkin.telemetry.formatter ] INFO : [CayenneLPP] Sensor type "scale.0.raw" not found in CayenneLPP
Per Wifi hingegen werden die Daten normal übertragen. Liegt das evtl. daran, dass in der Formatierung für lpp-hiveeyes in \lib\terkin\telemetry\formatter.py der Name weight für den HX711-Sensor erwartet wird?
elif "weight" in name:
# treat weight as outside sensor and assign to channel 5-9
# Channel 5 for single reading (weight.0))
# Channel 6-9 for multiple readings (weight.[1-4])
if name == "weight.0":
chan = 5
else:
chan = channel['scal']
channel['scal'] += 1
frame.add_load(chan, value)Hi Clemens,
@tonke hat diese Einstellung eingeführt, um ein Problem mit dem PyTrack board zu umschiffen, das nicht mehr antwortete, sobald der Bus stillgelegt wurde. Es hat also überhaupt nichts mit dem Raspberry Pi zu tun, sondern erweitert die Möglichkeiten für Pycom MicroPython Geräte.
Viele Grüße,
Andreas.
Hi Jan,
Ich glaube das sind keine Fehler, sondern nur Berichte darüber, dass diese Telemetriewerte nicht umgesetzt werden. Der “Hauptwert” heißt “weight.0” …
… und sollte korrekt umgesetzt werden.
Zusätzlich werden noch alle anderen Werte aus der Sensordomäne zur Verfügung gestellt, die aber bei der LoRaWAN-Umsetzung nicht berücksichtigt werden.
Viele Grüße,
Andreas.
3 Likes
Was muss dann da bei PyCom aber nicht PyTrack-Geräten, also FiPy, LoPy solo in der settings.py stehen? Oder ist es da wurscht, ob false oder true? Afaik schalten wir die Sensoren ja mit der ihnen eigenen sleep-Implementiereung z.B. beim BME oder HX711 aus, respektive in den sleep mode des Sensors.
Auf jeden Fall power_toggle_buses: True, das ist aber auch der Default.
Wie man an der Implementierung sieht, gilt das momentan scheinbar für beides: Buses und Sensors. Wir sollten also u.U. das Setting umbenennen in power_toggle_sensors. Möglicherweise sollten wir sogar beide Dinge voneinander entkoppeln.
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.
1 Like
Ja, Cayenne kennt hier nur load und temperature.
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
1 Like
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 .
2 Likes
Zu CayenneLPP:
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:
https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload
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.
4 Likes