Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er)

[MKO]

Muß leider über noch einen Bug im Hiveeyes MicroPython Dataloggers 0.3.0 berichen.
Die Datenverbindung zu bee-observer.org bricht bei mir auf allen 3 Nodes alle paar Stunden in unregelmäßigen Abständen ab.
Dabei wird aber fleißig zu swarm.hiveeyes weiter übertragen, ist also auf den Zweig ‘beep-bob’ begrenzt. Habe leider den Ausfall nicht weiter eingrenzen oder provozieren können.
Werde jetzt mal bei einen auf 0.4.0 ungraden und die anderen weiter laufen lassen.

49815.0587 [terkin.telemetry         ] WARNING: Adapter is offline, skipping telemetry to https://bee-observer.org/api/sensors
49843.5640 [terkin.datalogger        ] WARNING: Telemetry status: FAILURE. 1 out of 2 targets failed. Status: {'https://bee-observer.org/api/sensors': False, 'mqtt://swarm.hiveeyes.org/hiveeyes/testdrive/MKO-micropython-firmware/FiPy-mqtt-json': True}

[Andreas]

Vielen Dank für Eure Eingaben und dass Ihr Euch bei manchen Dingen bereits selbst weiterhelfen konntet. Wir werden versuchen, möglichst viele Eurer Meldungen für das kommende Release 0.4.0 zu berücksichtigen.

[clemens]

@MKO

Muß leider über noch einen Bug im Hiveeyes MicroPython Dataloggers 0.3.0 berichen.
Die Datenverbindung zu bee-observer.org bricht bei mir auf allen 3 Nodes alle paar Stunden in unregelmäßigen Abständen ab.

Könnte theoretisch auch am beep / bee-observer.org-Server liegen. Bei mir ist das Frontend / die Website ab und an auch langsam und hängt. Man kann natürlich die Übertagung auch x-mal versuchen, wenn ein Server nicht reagiert. Irgendwann geht das aufs Energiebudget, weshalb ich das sehr moderat machen würde, wenn wir an der Schraube drehen wollen / müssen.

[clemens]

@clemens

@Andreas hat das aber auf dem Schirm und wir haben auch geplant das zu implementieren. d.h. es gibt dann neben der aktuellen Version auch ein release oder Verzeichnis oder was auch immer, das dem Dateisystem auf dem FiPy entspricht. Das könnte man dann auf den FiPy einfach per Atom kopieren.

@Andreas hat das nicht nur auf dem Schrim, sondern, tataa! schon umgesetzt! Lieben Dank! Du findest unter “releases” Releases · hiveeyes/terkin-datalogger · GitHub jetzt eine Datei, z.B.

hiveeyes-micropython-firmware-0.4.0.zip

die du in ein lokales Verzeichnis entpacken kannst und dann per Atom auf den FiPy schiebst! Falls andere Software vorher drauf war, bitte alte Dateien löschen!

[Andreas]

@clemens

Könnte theoretisch auch am beep / bee-observer.org-Server liegen. Bei mir ist das Frontend / die Website ab und an auch langsam und hängt.

… ab sofort jetzt auch bei uns in der Infrastrukturüberwachung.

[Andreas]

@MKO

Muß leider über noch einen Bug im Hiveeyes MicroPython Dataloggers 0.3.0 berichen.
Die Datenverbindung zu bee-observer.org bricht bei mir auf allen 3 Nodes alle paar Stunden in unregelmäßigen Abständen ab.

Egal was hierfür die Ursache sein mag: Im Deep-Sleep Modus sollte es kein Problem darstellen, weil der Datenlogger quasi bei jedem Meßzyklus ohnehin neu anläuft.

Für den nicht- deep sleep Modus müssen wir die Resilienz der Routinen noch ein wenig verbessern, einstweilen ist man diesbzgl. also mit deep sleep besser dran - gerade für Langzeittests.

[Andreas]

@MKO machte uns darauf aufmerksam, dass es für die MQTT-Telemetrie noch keine Möglichkeit gibt, authentication credentials für die Verbindungsaufnahme zum Broker zu konfigurieren.

Wir sagen danke: Daran ist doch glatt noch etwas zu feilen.

Note to self: Dabei auch prüfen, ob der FiPy vielleicht auch schon gut MQTT über TLS/SSL realisieren kann – bei der HTTPS-Verbindung zu BEEP oder Kotori war dies problemlos möglich.

[MKO]

Please do not forget the light sleep mode.
There is also something to grind in the HTTP transmission. It recognizes that the transmission was unsuccessful. But then apparently does not build a new connection, but still tries to transfer over the lost connection to http.

I think on Prio 3. because we currently have nothing, which forces the awake state or light sleep.
If this option exists, it should also be work robust.
But I already have an idea for a future sensor that might need awake state.

[Andreas]

@MKO

Please do not forget the light sleep mode.

Sure. Thanks for the reminder.

@MKO

There is also something to grind in the HTTP transmission. It recognizes that the transmission was unsuccessful. But then apparently does not build a new connection, but still tries to transfer over the lost connection to http.

While the foundation is reasonable, the behavior implemented on top is totally silly right now. Sorry for that. Will also be improved.

---

The backlog is now a Wiki. Feel free to edit as you like. I’d suggest to append it to Prio 1.

[clemens]

Aktuell werden mit system.time und system.uptime im gleichen Datensatz beinahe identische Werte verschickt, time ohne Nachkommastellen und uptime mit zwei Nachkommastellen.

system.time, system.uptime
51736, 51736.41
52098, 52098.05
52459, 52459.96
52821, 52821.06
53182, 53182.06
53542, 53542.89
53904, 53904.61
54265, 54265.43
54626, 54626.19
54987, 54987.75
55349, 55349.25
55710, 55710.07
56071, 56071.6
56432, 56432.39
56792, 56793.02
57154, 57154.66
57887, 57887.43
58250, 58250.14
58613, 58613.27
58974, 58974.99
59335, 59335.8
59696, 59696.52
60058, 60058.08
60419, 60419.66
60780, 60780.37
61141, 61141.17

Da dies zu Verwirrung führt, und wir uns den doppelten Datentransfer sparen können, würde ich für uptime plädieren, das zukünftig alleine verschickt wird.

[weef]

habe die DS18B20-Kalibrierdiskussion mal verschoben - und zwar in jenes topic, das Ihr vor zwei Monaten dazu schon hattet:

Temperatursensoren justieren / kalibrieren

Meinst du das ist notwendig? Wir wissen ja nicht, ob die Abweichung zum Zeitpunkt der Justierung die normale Schwamkungen der Sensoren sind. Eigentlich sind die DS18B20 per Werk kalibriert und bei mir hat das bisher auch gut gepasst.

---

Edit by @Andreas: Ein ensprechender Eintrag wurde auch oben im Backlog hinzugefügt.

@Andreas

Offset-Einstellung für die DS18B20 von Temperatursensoren justieren / kalibrieren.

[Andreas]

Neben dem Wartungsmodus für den Terkin-Datenlogger gibt es nun auch die

@Andreas

MQTT authentication

im head. Vielen Dank für Eure Rückmeldungen zu den fehlenden Funktionalitäten. Ping @MKO, @clemens und @waggi. Ich hoffe Ihr müsst nun nicht mehr so viel umstecken und habt dadurch weniger Schmerzen bei der sukzessiven halb-hybriden Inbetriebnahme, weil nun hoffentlich möglichst viel über IP geht und man so den Datenlogger verschraubt im Garten-Netzwerk unter der Beute liegenlassen kann – sofern das so gut in Euer Szenario passt.

[MKO]

IP-based sandbox operations

@Andreas

@clemens testet gerade, ob man auch gut mit den anderen Sandbox-Tools ( make install , make recycle , make sketch-and-run , usw.) arbeiten kann, wenn man über IP geht, also vorher export MCU_SERIAL_PORT=192.168.178.20 mit der passenden IP-Adresse durchgeführt hat, die man nun über sudo python3 tools/terkin.py monitor oder weiterhin anderweitig ( nmap , im-router-nachsehen) in Erfahrung bringen kann.

Das hatte ich bereits probiert, dort müsste noch eine Art Authentifizierung fehlen. Er bleibt auf alle fälle direkt nach der ersten Kontaktaufnahme noch vor Repl … stehen. ins Blaue getippt müsste sowas wie export MCU_SERIAL_PORT=micro:python@192.168.178.20 sein hab ich aber noch nicht getestet.

[Andreas]

@MKO

Hatte ich bereits probiert, dort müsste noch eine art Authentifizierung fehlen

Vielen Dank für die Analyse. Daher hakte es wohl bei mir :P. Mit den aktuellsten Änderungen sollte es jetzt klappen.

$ export MCU_PORT=192.168.178.168
$ make console

Connecting via telnet to 192.168.178.168. Please enter User: micro, Password: python
expect -c 'spawn telnet 192.168.178.168; expect "*?ogin as:*"; sleep 0.2; send -- "micro\r"; expect "*?assword:*"; sleep 0.2; send -- "python\r"; interact;'
spawn telnet 192.168.178.168
Trying 192.168.178.168...
Connected to 192.168.178.168.
Escape character is '^]'.
MicroPython v1.9.4-0a38f88 on 2019-05-14; FiPy with ESP32
Login as: micro
Password:
Login succeeded!
Type "help()" for more information.

>>> from terkin import __appname__, __version__; print(__appname__, __version__)
terkin-datalogger 0.5.1

Hinweis: Die Umgebungsvariable heißt ab sofort MCU_PORT, die Abwärtskompatibilität zu MCU_SERIAL_PORT sollte jedoch erhalten geblieben sein.

[Andreas]

@Andreas

Offset-Einstellung für die DS18B20

… von Temperatursensoren justieren / kalibrieren.

Konfiguration

'ds18x20': {
    'bus': 'onewire:0',
    'devices': {
        '28ff641d8fdf18c1': {
            'enabled': False,
            'offset': 0.42,
        },
        '28ff641d8fc3944f': {
            'enabled': True,
            'offset': -0.42,
        },
    }
}

Die Konfiguration ist derzeit leider leicht redundant zur sensor_telemetry_map. Wir bitten um Verständnis.

Ausgabe

   32.3776 [terkin.datalogger        ] INFO   : Reading sensor port "DS18X20Sensor"
   32.3964 [hiveeyes.sensor_ds18x20  ] INFO   : Acquire readings from all DS18X20 sensors attached to bus onewire:0
   32.4157 [hiveeyes.sensor_ds18x20  ] INFO   : Skipping DS18X20 device 28ff641d8fdf18c1
   32.4348 [hiveeyes.sensor_ds18x20  ] INFO   : Reading DS18X20 device 28ff641d8fc3944f
   33.2526 [hiveeyes.sensor_ds18x20  ] INFO   : Adding offset -0.42 to value 21.875 from sensor 28ff641d8fc3944f

[Andreas]

@Andreas

Enable/disable individual sensors.

Ist nun auch mit dabei.

[MKO]

@Andreas

Mit den aktuellsten Änderungen sollte es jetzt klappen.

Hammer!
Ein entscheidender Meilenstein in Sachen Updates und Konfiguration im laufenden “Feld”- Einsatz.
Hab gestern Abend noch ein wenig ohne Erfolg Recherchiert wie es funktionieren könnte, und Du kommst schon mit der Lösung raus.
Bin Begeistert und enttäuscht zugleich, da ich die neue Funktionalität nicht gleich testen kann. Bin leider bis zum Wochenende unterwegs.

@Andreas

MQTT authentication

Genial! Danke

@Andreas

Offset-Einstellung für die DS18B20

Super!

Ihr legt Mal wieder ein Wahnsinns Tempo vor, ich glaub ich werd zum Fan