@mois hat drüben bei Laborprotokoll: 4x5-Temp-Matrix (mit DS18B20) ein schönes Projekt vorgestellt, dabei fiel auch eine Datenschreiberkomponente ab.
Das meiste der Weiterentwicklung spielt sich im Repository ab, aber ab und zu gibt es hier vielleicht etwas dazu zu vermelden oder zu diskutieren.
Kommend von Laborprotokoll: 4x5-Temp-Matrix (mit DS18B20) - #17 by mois und Modularization, documentation, installation, configuration, and naming things · Issue #1 · hiveeyes/ds18b20-datalogger · GitHub, würden wir gerne ein paar Verbesserungen einreichen.
Das Ziel, im Groben und Ganzen: Gute Benamsung, ein paar Software-Tests zum Abfangen von Tippfehlern und Problemen mit Abhängigkeiten (hier: Paho MQTT Client), und vielleicht eine Möglichkeit zur einfachen Installation per pip install?
pip install ds18b20-datalogger
Antwortet gerne dort bei GH-1, dann ufert dieser Faden nicht zu sehr in entsprechende Details aus.
We smithed a few words and came to a conclusion. If you have any other suggestions, please let us know.
| What | Content |
|---|---|
| Package Name | ds18b20-datalogger |
| Package Description | A data logger specializing in reading an array of DS18B20 sensors. |
| Project Description | A temperature sensor matrix with heatmap visualization for bee hive monitoring, using Raspberry Pi, Python, DS18B20, MQTT, Kotori DAQ, and Grafana. |
Das konnte ich nicht beobachten. Auf meiner Arbeitsbank im Emulationsmodus kam das Programm eigentlich recht robust rüber. Die neu eingeführten Softwaretests unterstützen diese These. In jenem Testfall wird simuliert, dass ein Sensor “kaputt” ist.
Mglw. braucht der Code doch noch eine kleine Verbesserung. Die Issue schau ich mir an, klar.
ah, ok, i see, core.py macht das schlauer indem es erstmal alle notwendigen variablen auf none setzt. dann kann nie eine fehlen, auch nicht wenn der zugehörige sensor nicht da ist. das macht temp-matrix*.py ja nicht.
ok das kann ich dort noch ändern.
dann muss ich nochmal gucken warum core.py bei mir noch nix in die datenbank schreibt. muss ich nochmal vorne anfangen und die zugangsdaten zuerst prüfen usw.
Ja genau.
ds18b20-dataloggeris now available on PyPI. – ds18b20-datalogger · PyPICurrently, it does not make much sense, because you still need to configure MQTT settings and sensor mappings within the code.
ds18b20-datalogger 0.0.3 hat nun eine Konfigurationsmöglichkeit per YAML Datei bekommen. So wird endlich ein Schuh draus.
@mois: Als Beispiel, bzw. Schnellstarthilfe, findest Du Dein Setup reflektiert in etc/mois.yaml. Der Code selbst, in core.py, ist nun ganz schmal und kompakt geworden, da er nun nicht mehr die Sensordefinition beherbergen muss.
Jetzt müsste diese Version auf Korrektheit und Vollständigkeit überprüft werden, am besten entlang der aktuellen Dokumentation. Vielleicht kannst Du das übernehmen, da Du die entsprechende Hardware auf dem Tisch oder im Wohnzimmer hast, @mois?
toll!
ja, voraussichtlich morgen abend.
erster testlauf:
installation einfach so per pip install klappt natürlich erstmal nicht.
aber entlang des walkthrough sandbox klappts dann:
erstellung der config-datei 
(anpassung mit eigenen werten (mqtt-connection, sensor-ids) nicht vergessen!!)
testausgabe aufs terminal
testausgabe in die datenbank
erstellung des dashboard.json 
wenn ich das dashboard.json in grafana importiere und speichern will, bekomme ich eine fehlermeldung, weil die UID schon existiert:
es gibt sogar einen überschreiben-button 
die uid sollte also besser dynamisch pseudozufällig generiert werden beim auspielen der dashboard.json per
ds18b20-datalogger make-dashboard > dashboard.json
hab das zur bearbeitung in ein issue gepackt.
edit: lösbar, indem wir einfach die zeile in dashboard.json weglassen, in der die uid übermittelt wird. grafana erstellt dann eine neue und einmalige uid beim ersten speichern des dashboards.
test der anleitung “production setup” folgt.
Vielen Dank für Deine Eingaben und Verbesserungsvorschläge.
Sie wurden hiermit allesamt adressiert.
Die Ergebnisse wurden mit Version 0.0.4 gerade eben veröffentlicht.
sudo su -
python3 -m venv /opt/ds18b20-datalogger
/opt/ds18b20-datalogger/bin/pip install ds18b20-datalogger
~# /opt/ds18b20-datalogger/bin/ds18b20-datalogger make-config > /etc/ds18b20-datalogger/config.yaml 
-bash: /etc/ds18b20-datalogger/config.yaml: No such file or directory
also:
mkdir /etc/ds18b20-datalogger
und nochmal ds18b20-datalogger make-config
config.yaml ist nur eine vorlage: anpassen der MQTT-infos und der sensor ids bzw. device-pfade nicht vergessen.
und weiter:
/opt/ds18b20-datalogger/bin/ds18b20-datalogger read /etc/ds18b20-datalogger/config.yaml
/etc/cron.d/ds18b20-datalogger
und per services:
sieht auch gut aus und die werte sind zu sehen in grafana
Alles klar. Gefixt per Fix documentation about production use: Missing statement about `mkdir` · hiveeyes/ds18b20-datalogger@70742b7 · GitHub. Bitte noch einmal auf »reboot safeness« überprüfen, wegen der Systemd Geschichte.
hmm.
die pixmap scheint broken mit den werten aus dem service. eigentlich sollten alle kacheln so etwa 20° anzeigen.
aber:
Schade. Kriegen wir einen vorher/nachher Vergleich hin? Die ausgelesenen Daten kannst Du per ds18b20-datalogger read prüfen. Das was Du da siehst, müsste das gleiche sein, das auch aufs Telemetriekabel geht.
bringt uns der weiter? die daten kommen doch gut an, wie das panel mit den einzelmesspunkten zeigt.
hier der vorher-screenshot. sobald messreihen von vorher mit in der auswahl sind, stimmts wieder.
was hat sich da geändert, dass es das pixmap-panel zerhagelt?
Wenn dort ebenfalls nur Leerstellen zu sehen sind – führt dies denn dann zur Anzeige von 0°C in der Grafana Pixmap? – vielleicht ist der Abstand zwischen “modprobe” und “Auslesen” zu kurz, oder “modprobe” sollte besser gar nicht vom Programm ausgeführt werden?
Wahrscheinlich ist es aber noch etwas anderes. Wenn Du nichts signifikantes herausfinden kannst, müsste ich wohl mal bei Dir auf die Maschine – oder nochmal scharf auf den Code schauen.
Na dann… Was ist dann krumm? Kam die Messung vielleicht nur ein einziges Mal falsch an, z.B. beim erstmaligen Start? Bitte prüfen! Und:
bindestrich vs. unterstriche in den temperatur-variablen-namen.
früher hatte ich nur bindestriche: temp-ir-4-1
jetzt heißt er temp_ir_4_1.
ist der wechsel auf die untersriche zwingend? wenn ja, dann ändere ich das eben im pixmap-panel und dann ist das nicht rückwärtskompatibel.
wenn nein, dann wären mir bindesriche lieber.
Ah. Habe ich da was umbenannt? Das tut mir leid! Hießen die vorher temp_ir_2_4? Aber im Grafana Dashboard stehen sie ja auch so drin mit Bindestrichen: temp-ir-2-4? Bei Dir noch anders?
