[Trunk #3003] Visualisierung von DigiTemp

sash99 · 23 Jun 2009

Ich habe in Freetz unter Pakete->RRDstats->Einstellungen: periode der Unterseite

6h 1d 1w 1M 1y

eingegeben, also das 1m auf 1M geändert. Seit dem werden auch die Monatsgrafiken erstellt und angezeigt.

sash

cuma · 23 Jun 2009

Ich hab jetzt mal "6M" ausprobiert, das scheint aber nicht zu funktionieren, es werden wieder Minuten angezeigt :-/ Das passt was noch nicht so ganz

ao · 23 Jul 2009

Hallo,

in meiner Temp.kurve tauchen immer wieder Spitzen auf, die aber keine 85°C-Fehler zu sein scheinen (s. Screenshots). Oder sind das doch welche?
Wie kann ich die dann sicher unterdrücken? (die Option habe ich bereits aktiviert)

Danke für Eure Hilfe!

cuma · 24 Jul 2009

Das sind wohl die Messwerte, die ausgelesen werden. Digitemp kann halt nicht unterscheiden, ob die Sensoren fehlerhafte Werte liefer. Vielleicht liegt es an der Verkabelung/Stromversorgung? Oder manchmal geht eine Heizung oder sowas an?
evtl könnte man sowas mit rrdtool glätten, schau mal in die Doku: http://oss.oetiker.ch/rrdtool/
(Ich hab das Problem mit mehr als 10 Sensoren übrigens nicht)

ao · 25 Jul 2009

Obwohl die Kurven so aussehen, als ob es keine 85°C-Werte sind, sind es tatsächlich solche. Der Fühler ist wie weiter oben und sonstwo "grounded", da er keine externe +5 V-Spannung erhält.

Heizung o.ä. ist nicht in der Nähe. Der letzte 85°C-Wert ist von heute, 13:12 Uhr, und da war der Rollladen des Zimmers komplett geschlossen, so dass ich auch einen Sonnenstrahl direkt auf den Messfühler ausschließen kann.

Danke für den Hinweis bzgl. des Glättens, aber filtert die Option "Unterdrücke 85,0000°C (Fehler und Werte)" nicht solche Werte heraus? Ich habe sie ja aktiviert. Oder liegt es evtl. daran, dass der Wert in der cvs-Datei nicht exakt so lautet, sondern so? D.h., der Messwert hat 6 Nullen nach dem Komma, aber der "Unterdrückte Wert" nur 4 Nullen:

Code:

25.07.2009 13:12:29;85.[B][COLOR=Red]000000[/COLOR][/B];

cuma · 25 Jul 2009

In die cvs werden immer alle Werte (also auch "Fehler") geschrieben, nicht aber in die rrd! Die Werte in der rrd kann man sich mit "rrdtool dump dateiname.rrd" anzeigen lassen oder mit "rrdtool xport" nach xml exportieren.

ao · 27 Jul 2009

Weshalb enthält die rrd-Datei viel weniger Werte als die cvs-Datei?
Außerdem enthält sie als "Ausreißer" keine 85°C, sondern offenbar ca. 58.59°C (2. Zeile):

Code:

<!-- 2009-07-27 07:31:12 CEST / 1248672672 --> <row><v> 2.2250000000e+01 </v></row>
[COLOR=Blue]<!-- 2009-07-27 07:38:24 CEST / 1248673104 --> <row><v> [B]5.85[/B]88160313e+01 </v></row>[/COLOR]
<!-- 2009-07-27 07:45:36 CEST / 1248673536 --> <row><v> 2.2250000000e+01 </v></row>

Der Wert von 58.588160313 hat ja gar nichts mit einem "85°C-Fehler" zu tun.

Wenn ich mir die cvs-Datei vom Zeitraum der drei o.g. Werte anschaue, stelle ich überrascht fest, dass die cvs-Datei viel mehr Werte und einen 85°C-Wert um 07:37:14 Uhr enthält und nicht um 07:38:24 Uhr wie der "Ausreißer" in der rrd-Datei, der aber - s.o. - ja auch keine 85°C, sondern ca. 58.59°C darstellt. Wie passt das zusammen?

cvs-Datei:

Code:

27.07.2009 07:31:05;22.250000;
27.07.2009 07:31:09;22.187500;
27.07.2009 07:31:20;22.187500;
27.07.2009 07:31:31;22.187500;
27.07.2009 07:31:41;22.250000;
27.07.2009 07:31:46;22.250000;
27.07.2009 07:31:50;22.187500;
27.07.2009 07:32:01;22.250000;
27.07.2009 07:32:06;22.250000;
27.07.2009 07:32:11;22.250000;
27.07.2009 07:32:15;22.250000;
27.07.2009 07:32:26;22.250000;
27.07.2009 07:32:37;22.250000;
27.07.2009 07:32:41;22.250000;
27.07.2009 07:32:46;22.250000;
27.07.2009 07:32:51;22.250000;
27.07.2009 07:32:55;22.250000;
27.07.2009 07:33:06;22.250000;
27.07.2009 07:33:11;22.250000;
27.07.2009 07:33:21;22.250000;
27.07.2009 07:33:26;22.187500;
27.07.2009 07:33:37;22.250000;
27.07.2009 07:33:48;22.250000;
27.07.2009 07:33:52;22.250000;
27.07.2009 07:34:03;22.187500;
27.07.2009 07:34:08;22.250000;
27.07.2009 07:34:18;22.250000;
27.07.2009 07:34:29;22.250000;
27.07.2009 07:34:34;22.250000;
27.07.2009 07:34:38;22.250000;
27.07.2009 07:34:49;22.250000;
27.07.2009 07:35:00;22.250000;
27.07.2009 07:35:10;22.250000;
27.07.2009 07:35:15;22.250000;
27.07.2009 07:35:20;22.250000;
27.07.2009 07:35:24;22.187500;
27.07.2009 07:35:35;22.250000;
27.07.2009 07:35:40;22.250000;
27.07.2009 07:35:51;22.187500;
27.07.2009 07:36:01;22.187500;
27.07.2009 07:36:12;22.187500;
27.07.2009 07:36:23;22.187500;
27.07.2009 07:36:28;22.250000;
27.07.2009 07:36:32;22.187500;
27.07.2009 07:36:43;22.250000;
27.07.2009 07:36:48;22.187500;
27.07.2009 07:36:58;22.250000;
27.07.2009 07:37:03;22.187500;[COLOR=Red]
27.07.2009 07:37:14;[B]85.000000[/B];[/COLOR]
27.07.2009 07:37:18;22.250000;
27.07.2009 07:37:29;22.187500;
27.07.2009 07:37:34;22.250000;
27.07.2009 07:37:39;22.250000;
27.07.2009 07:37:49;22.187500;
27.07.2009 07:38:00;22.187500;
27.07.2009 07:38:11;22.187500;
27.07.2009 07:38:21;22.250000;
27.07.2009 07:38:32;22.250000;
27.07.2009 07:38:43;22.187500;
27.07.2009 07:38:47;22.250000;
27.07.2009 07:38:52;22.187500;
27.07.2009 07:39:03;22.250000;
27.07.2009 07:39:13;22.187500;
27.07.2009 07:39:24;22.187500;
27.07.2009 07:39:35;22.187500;
27.07.2009 07:39:46;22.187500;
27.07.2009 07:39:56;22.250000;
27.07.2009 07:40:01;22.187500;
27.07.2009 07:40:12;22.250000;
27.07.2009 07:40:16;22.250000;
27.07.2009 07:40:21;22.187500;
27.07.2009 07:40:32;22.250000;
27.07.2009 07:40:43;22.250000;
27.07.2009 07:40:47;22.250000;
27.07.2009 07:40:52;22.250000;
27.07.2009 07:41:03;22.250000;
27.07.2009 07:41:07;22.187500;
27.07.2009 07:41:18;22.187500;
27.07.2009 07:41:29;22.250000;
27.07.2009 07:41:39;22.187500;
27.07.2009 07:41:50;22.187500;
27.07.2009 07:42:01;22.250000;
27.07.2009 07:42:11;22.187500;
27.07.2009 07:42:16;22.250000;
27.07.2009 07:42:21;22.187500;
27.07.2009 07:42:31;22.187500;
27.07.2009 07:42:42;22.250000;
27.07.2009 07:42:53;22.187500;
27.07.2009 07:42:57;22.250000;
27.07.2009 07:43:08;22.187500;
27.07.2009 07:43:19;22.250000;
27.07.2009 07:43:30;22.250000;
27.07.2009 07:43:34;22.250000;
27.07.2009 07:43:39;22.250000;
27.07.2009 07:43:50;22.250000;
27.07.2009 07:43:54;22.250000;
27.07.2009 07:44:05;22.187500;
27.07.2009 07:44:16;22.250000;
27.07.2009 07:44:20;22.250000;
27.07.2009 07:44:25;22.250000;
27.07.2009 07:44:36;22.187500;
27.07.2009 07:44:47;22.250000;
27.07.2009 07:44:51;22.187500;
27.07.2009 07:45:02;22.250000;
27.07.2009 07:45:07;22.250000;
27.07.2009 07:45:11;22.187500;
27.07.2009 07:45:22;22.250000;
27.07.2009 07:45:27;22.250000;
27.07.2009 07:45:31;22.250000;
27.07.2009 07:45:42;22.250000;
27.07.2009 07:45:47;22.250000;
27.07.2009 07:45:57;22.250000;

PS: Gehen die "Ausreißer" auch in die Werte min/avg/max ein?

cuma · 27 Jul 2009

In die CVS wir jeder gelesen Wert einzeln geloggt, wie gesagt auch die Fehler. Diese Datei ist gedacht, um sie später irgendwie weiterzuvrarbeiten. In die RRD kommen nur die richtigen Werte, diese werden dann noch von rrdtool verdichtet, siehe http://de.wikipedia.org/wiki/RRD
Schau dir auch mal die Dateigrößen an! Zur Anzeige werden nur die RRDs herangezogen

Hier der entsprechenden Codeausschnitt aus /etc/default.rrdstats/rrdstats

Code:

echo "$_CURRENT;$onedata;" >> $RRDSTATS_RRDDATA/one_00-$2_$_SENSOR_UOM[COLOR="Red"].cvs[/COLOR]
[ "$RRDSTATS_DIGITEMP85" = "yes" -a [COLOR="Red"]"$onedate" = "$_SENSOR_ERR"[/COLOR] ] && [COLOR="Red"]return[/COLOR]
<...>
$_NICE [COLOR="Red"]rrdtool update[/COLOR] $RRDSTATS_RRDDATA/$NAMEPREFIX[COLOR="Red"].rrd[/COLOR] "N:$onedata" --template temp

ao · 27 Jul 2009

Danke, cuma, nun habe ich es verstanden. Die Ursache für die Ausreißer muss ich noch ermitteln, aber es muss wohl am Fühler oder der Verdrahtung liegen.

cuma · 27 Jul 2009

Hab gerad noch gesehen, dass die Variable _SENSOR_ERR den Wert "85.0000" hat und nicht wie in deiner CVS mit 6 Nullen. Änder mal in make/rrdstats/files/root/etc/default.rrdstats/rrdstats die Zeile 260 auch auf 6 Nullen. Danach "make rrdstats-dirclean; make". Könnte sein, dass das noch von der geringeren Genauigkeit übriggeblieben ist. Kann das leider nicht selbst testen. Bei mit haben die einzelnen Sensoren je ca 185ooo Werte ohne einen einzigen 85° Fehler :-]

ao · 27 Jul 2009

Das hatte ich ja oben in Beitrag #145 geschrieben (Anzahl der Nullen).

Wie von Dir vorgeschlagen habe ich Zeile 260 in rrdstats so geändert:

Code:

[ "$RRDSTATS_DIGITEMP_C" = yes ] && _SENSOR_ERR="85.0000[U]00[/U]" || _SENSOR_ERR="185.0000[U]00[/U]"

... nach "make rrdstats-dirclean" das Image neu gebaut, geflasht und die Box neu gestartet. Leider treten die 85er-Aussetzer weiterhin auf. :-(

PS:
Ist es denn korrekt, den 2. SENSOR_ERR auch auf 6 Nullen nach dem Komma aufzufüllen?
Warum gibt es neben dem "85er" noch den "185er"?

cuma · 28 Jul 2009

Rate mal, wieviel Grad Fahrenheit 85°C sind :-]
Der 2. Wert ist in deinem Fall aber egal. Sind die 4 Nullen nun falsch? Kannst du das mal testen, indem du die Zeile

Code:

[ "$RRDSTATS_DIGITEMP85" = "yes" -a "$onedate" = "$_SENSOR_ERR" ] && return

um eine nach oben verschiebst? Dann dürften auch in die CVS keine 85er mehr kommen

Lemur · 7 Nov 2009

Hallo zusammen,

ich hab mir jetzt auch so eine Selbst-Löt-Lösung gebastelt

Soweit so gut, Sensoren werden über pl2303 erkannt und Temparaturen im ganzen richtig verarbeitet. Ein Sensor ist direkt am Stecker, der 2. eine 15m lange 2 Drahtleitung entfernt, im Außenbereich.

Der Innensensor liefert fehlerfreie Werte, der Außensensor liefert minimal 2-3 mal am Tag, den 85.000000 C Fehlerwert. Damit könnte ich gut leben, sofern dieser nicht im rrd-Chart auftauchen würde, macht er aber leider doch.

Wie kann ich die 85 C Werte aus dem rdd Chart ausschließen?

"Unterdrücke 85,0000°C (Fehler und Werte)" ist an.
Zeile 260 in rrdstats bereits auf 10^-6 Stellen geändert, da im CSV so gelogt, brachte allerdings auch keinen Erfolg.
-READ_TIME auf 3000 erhöht, minimierte zwar die Fehler erheblich, die Charts passen dennoch nicht...

Jemand ne Idee, wie ich das rrd beibiegen kann?

Verwendet wird aktuell folgendes:

Code:

Firmware: 29.04.76freetz-devel-3832M 
DIGITEMP > DS9097
pl2303  usbserial
RRDstats
###
FB 7170 -> 4 Port USB Hub -> USB/Serial -> DS1820 + 15m DS1820

Grüße Lemur

cuma · 8 Nov 2009

Das Unterdrücken der 85°C Fehlerwerte wirkt sich nur auf die .rrd Dateien aus, nicht auf die .cvs!
Ich habe 11 Sensoren in einem ~35 Meter Netzwerk und keine Fehler. Ich vermute Verkablungsprobleme! Meine "1-wire" Sensoren hab ich mit 3 Adern angeschlossen: Daten, Masse und Stromversorgung!

Lemur · 8 Nov 2009

Hallo cuma,

danke für die schnelle Antwort,
es sind ja auch die rrd Charts gemeint. Mein Problem dabei ist, dass mir die 85 ° Fehler, die Charts 3-4 mal täglich "versauen", die csv Dateien verarbeite ich soweit eh nicht.

Bzgl. der Verkabelung muss ich mal gucken, was hast Du auf das 3. Bein gelegt, +5V DC?

Mich wundert nur, dass trotz des Filters die 85C Fehler an die RRD Datenbank übergeben werden, bzw. sich in den Charts zeigen.

cuma · 8 Nov 2009

Ist bei mir schon 1 Jahr her dass ich das gelötet hab, müsste aber 5V sein. Hab das direkt am DS9490R abgegriffen.

"Eigentlich" können die nicht in die rrd kommen. Lies dich einfach mal die 10 letzten Posts in diesm Thread, da hatte jemand das gleiche Problem. Achte insbesondere auf die Nachkommastellen

Lemur · 8 Nov 2009

Hallo cuma,

auf die Nachkommastellen hatte ich auch erst getippt, ich hab die Threads alle gelesen und daraufhin auch die Datei gefixt, auf 6 Nachkommastellen...

Dennoch waren die 85C Werte in der RDD Grafik, ich hab jetzt diese Schaltung:

Durch diese ersetzt:

Danach (i.d. letzten 2 Std.) trat der Fehler nicht mehr auf.
Da nun auch keine 85C Werte mehr gelesen werden.

Wäre dennoch interessant, warum die Fehlerwerte in die RRD-Datenbank wandern.

Grüße Lemur

cuma · 8 Nov 2009

Schau mal wie in Post #146 nach ob dir wirklich drinnen sind. Ich kann das ohne 85er hier nicht testen. Ich hab halt den fertigen USB-Adapter im Einsatz

Lemur · 8 Nov 2009

Die Zeilen aus der /etc/default.rrdstats/rrdstats (direkt aus der Box)

Zeile 218-223

Code:

    if [ -n "$onedata" -a "$oneretv" -eq 0 ]; then
        echo "$_CURRENT;$onedata;" >> $RRDSTATS_RRDDATA/one_00-$2_$_SENSOR_UOM.cvs
        [ "$RRDSTATS_DIGITEMP85" = "yes" -a "$onedate" = "$_SENSOR_ERR" ] && return
        [ "$RRDSTATS_DIGITEMP_A" = "yes" ] && one_alert $onedata $2
        $_NICE rrdtool update $RRDSTATS_RRDDATA/$NAMEPREFIX.rrd "N:$onedata" --template temp
    fi

Zeile 260-261

Code:

[ "$RRDSTATS_DIGITEMP_C" = yes ] && _SENSOR_ERR="85.000000" || _SENSOR_ERR="185.000000"
while true; do

Ich kann es nicht mehr testen, da die Sensoren jetzt ordnungsgemäß ausgelesen werden, falls jedoch in den nächsten Tagen doch noch 85C Fehler kommen sollten, kann ich die gerne auch posten, ich bin aber froh - das es nun einwandfrei läuft.

WLAN-VoIP-Fan · 18 Dez 2009

Hi,

so ich habe an meiner FritzBox 7270 einen USB zu 1-Wire-Adapter hängen und im Testbetieb erstmal nur einen Temperatursensor. Es sollen später mal um die 70 bis 100 Stück werden im ganzen Haus verteilt.

Frage:
Wer kann mir dabei helfen eine Statusseite über die ganzen Sensoren zu erstellen ohne Grafen nur mit aktueller Wert Min und Max des Tages und Durchschnitt des Tages.

Ich selber habe mal programmieren gelernt und könnte sicher das eine oder andere selber schreiben nur habe ich im Moment keinen Plan an welche stelle ich das in welcher Datei wie bei Freetz einfügen muß.

Wäre neet wenn da jemdand mir helfen könnte und das als Gemeinschaftsprojekt zu erstellen.

Gruß.

[Trunk #3003] Visualisierung von DigiTemp

Neuer User

Aktives Mitglied

Aktives Mitglied

Anhänge

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Mitglied

Statistik des Forums