Fragen / Schwierigkeiten Terkin-Release ab v0.7.1

Entwicklung / Development Firmwareschmiede / Firmware development
1

Habe die letzten Tage versucht das Terkin Release 0.7.1 bzw. dann darauffolgend auch 0.7.2 und 0.8.0 von Releases · hiveeyes/terkin-datalogger · GitHub zum Laufen zu bekommen.

Die Waage funktioniert nicht mit dem aktuellem release und meiner Konfiguration.

        {
            'id': 'scale-1',
            'number': 0,
            'name': 'scale',
            'description': 'Waage',
            'type': 'HX711',
            'enabled': True,
            'pin_dout': 'P22',
            'pin_pdsck': 'P21',
            'scale': 23293,
            'offset': 130550,
            'decimals': 3,
        },

Fehlermeldung

 7007.0291 [terkin.datalogger           ] ERROR  : Reading sensor "HX711Sensor" failed
Traceback (most recent call last):
  File "terkin/datalogger.py", line 491, in read_sensors
NotImplementedError:

Mit einer Software-Version von ca. 11. April und Thias’ TTN-branch funktioniert die Waage, es muss also danach was dazugekommen sein.

@Thias vermutet, dass die neue Rundungsfunktion nur floats annimmt und daher in der settings.py offset und scale nicht als int, sondern mit *.0irgendwas stehen müssen.

Die DS18B20 werden nicht zuverlässig ausgelesen, das aber schon mit der Software-Version von Thias und auch mit dem aktuellen release, da habe ich immer wieder Ausfälle:

  216.9727 [terkin.driver.ds18x20_sensor] INFO   : Start conversion for DS18X20 devices on bus "onewire:0"
  217.0718 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd922ab"
  217.1494 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd18ab0"
  217.2284 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd4d5d5"
  217.2819 [terkin.driver.ds18x20_sensor] WARNING: No response from DS18X20 device "28ff641d8fd4d5d5"
  217.3045 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd8778b"
  217.3871 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd833ac"
  217.4689 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "287e4d7997040320"
  217.5208 [terkin.driver.ds18x20_sensor] WARNING: No response from DS18X20 device "287e4d7997040320"

manchmal funktioniert es aber

  400.4396 [terkin.driver.ds18x20_sensor] INFO   : Start conversion for DS18X20 devices on bus "onewire:0"
  400.5394 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd922ab"
  400.6184 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd18ab0"
  400.6975 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd4d5d5"
  400.7722 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd8778b"
  400.8520 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "28ff641d8fd833ac"
  400.9331 [terkin.driver.ds18x20_sensor] INFO   : Reading DS18X20 device "287e4d7997040320"

Ich verschicke gerade die Daten per LoRa und die debug-messages gehen über WLAN an Putty / telnet.

2

Das ist korrekt und die settings.example.py hat einen entsprechenden Hinweis bekommen:

3

Damit geht es jetzt, beide – scale und offset – müssen float sein, eines reicht nicht. Könnte man das nicht auch abfangen, d.h. wenn als int in der settings angegeben, dann automatisch nach float konvertieren?

1 Like
4

Einverstanden, wird jetzt gleich als Gleitkommazahl importiert und der Hinweis in den Settings wurde wieder entfernt.

1 Like
5

Hat noch jemand eine Idee zu den instabilen DS18B20 readings?

6

Spannungsversorgung, hast du mal einen Kondensator zwischen V und GND gelegt?

Timing, zu zügiges Auslesen?

7

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?

8

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
9

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
10

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!

11

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] Pycom LoRaWAN class

1 Like
12

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.

13

Mal kurz rausgekramt:

14

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?

15

Der Code unterscheidet hier nicht nach der Plattform.

16

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)
17

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.

18

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
19

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.

20

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.