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.