@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?
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.
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
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.
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.
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?
So sehen die Feldnamen in der allerersten Version aus:
Und so sehen in der jüngsten Version 0.0.4 aus:
Das sieht für mich ziemlich identisch aus.
Vielleicht stimmt doch etwas an den Werten nicht. Produziert ds18b20-datalogger run denn eine annehmbare Ausgabe? So musst Du nicht immer fünf Minuten auf Ergebnisse warten, bzw. weißt andersrum, dass es am Grafana liegen muss, wenn run valide Ergebnisse ausgibt?
Eigentlich “läuft” der Service nicht, denn es ist ja kein Daemon, sondern wird nur ganz normal als Programm alle fünf Minuten vom Timer gestartet. Daher: Normalerweise schon, in unserem Falle nicht. Hier ist das “service unit” File also nur ein Vehikel, um einen Timer drauf legen zu können.
ich selbst hab das zerschrotet. irgendwie in der lokal zugrunde liegenden config.yaml
und erst jetzt gemerkt, wo das eine weile läuft. keine ahnung warum ich da inkonsistent wurde.
