Unplausible Werte von Log ausschließen

[Knallfrosch]

Hallo,

ich habe in einem MQTT-Device immer mal wieder unplausible Temp.Werte.

Diese müllen mir die Datenbank voll und als Kurve sieht das natürlich auch nicht schön aus.
Du darfst diesen Dateianhang nicht ansehen.
Plot über einen Monat.

Die Temp. nimmt zeitweise Werte mit -100 o.ä. an

Kann ich diese Werte hier <-15 (könnte ja im Winter tatsächlich mal so kalt werden) irgendwie "unterdrücken"?

Als Attr habe ich folgendes gesetzt:

Code Auswählen Erweitern


DbLogExclude .*
DbLogInclude adc_0, 0_tC
event-min-interval 0_tC:3600,adc_0:3600
event-on-change-reading adc_0:0.2,0_tC:0.5
Natürlich würde ich gerne die Ursache angehen, aber ich kann mir auch nicht erklären, warum diese absurden Werte gesendet werden.

Die Werte kommen von einem Shelly Uni.

Vielen Dank.

Grüße

[rabehd]

Mit der Suchfunktion komme ich zu https://forum.fhem.de/index.php?topic=93690.0.

Die Verwendung von DbLogExclude und DbLogInclude ist für mich sinnfrei.

Die Frage sehe ich auch nicht als Automatisierungsthema.

[Gisbert]

Hallo Knallfrosch,

eine Symptombekämpfung beim SVG-Plot kann wie folgt aussehen. Im Feld function kannst du es damit probieren:

Code Auswählen Erweitern

$fld[3]>-20?$fld[3]:""Voraussetzung ist, dass die Werte an 4. Position in der Datenbank stehen, ansonsten anpassen. Genau genommen kann ich es nur für Filelog sagen. Falls es nicht funktioniert, kannst du den Ausdruck wieder löschen und den Knopf "write .gplot file" betätigen.

Die Daten stehen nach wie vor in der Datenbank und die Ursache bei deinem Shelly ist auch noch da.

Viele Grüße Gisbert

[DS_Starter]

Die Ursache zu beseitigen ist die Beste Variante.
Um zumindest die DB sauber zu halten bietet sich das Attr valueFn im DbLog an, z.B.:

Code Auswählen Erweitern

attr <device> valueFn {if ($DEVICE eq "<Shelly>" && $READING eq "<Reading>") {
                         $IGNORE=1 if($VALUE < -15);
                       }
                      }

Das kann man beliebig erweitern und verfeinern.
Die SVG sieht dann auch wieder i.O. aus.

[frank]

ich würde die plausibilität nicht durch einen vergleich mit einem festen, absoluten wert ermitteln, sondern eine differenz zum letzten "guten" wert als vergleich heranziehen.

[Knallfrosch]

Hallo zusammen,

danke für eure Antworten.

Die Ursache zu beseitigen ist die Beste Variante.

Hättest du einen Tipp für mich, wie ich die Ursachensuche angehen kann?
Mich wundert, dass es offensichtlich nur bei der Temp. zu solchen Sprüngen kommt.
Bei der Spannung, die auch logge, gibt es das nicht.

Die Verwendung von DbLogExclude und DbLogInclude ist für mich sinnfrei.

Nunja, ich habe dbLogExclude global als attr gesetzt und nutze Include dann um nur gezielt das zu loggen, was ich benötige.
Welche sinnhafte Lösung gibt es denn?

Die Frage sehe ich auch nicht als Automatisierungsthema.

Ich verschiebe das Thema gerne in einen passenderen Bereich, sag mir wohin es deiner Meinung nach besser passt.

ich würde die plausibilität nicht durch einen vergleich mit einem festen, absoluten wert ermitteln, sondern eine differenz zum letzten "guten" wert als vergleich heranziehen.

Ja das klingt sogar viel besser.
Und vermeidet die Ausreißer um ein vielfaches und würde die Messung nicht beschneiden, falls es dann doch mal kälter als -15°C werden würde.

Kannst du mir zeigen, wie das dann aussehen müsste?


Vielen Dank.

Grüße

[rabehd]

Die Verwendung von DbLogExclude und DbLogInclude ist für mich sinnfrei.

Nunja, ich habe dbLogExclude global als attr gesetzt und nutze Include dann um nur gezielt das zu loggen, was ich benötige.
Welche sinnhafte Lösung gibt es denn?

Es reicht

Code Auswählen Erweitern

attr logdb DbLogSelectionMode IncludeDas hast Du doch wohl gesetzt?
Damit spartst Du dbLogExclude.

[Knallfrosch]

Es reicht

Code Auswählen Erweitern

attr logdb DbLogSelectionMode IncludeDas hast Du doch wohl gesetzt?
Damit spartst Du dbLogExclude.

Ja,

Code Auswählen Erweitern

attr logdb DbLogSelectionMode Include
habe ich gesetzt.

Danke für den Hinweis und die Lösung dazu.

Grüße

[JudgeDredd]

So einen Sensor habe ich bei mir auch. Da ich aber keinen Bedarf habe diesen zu tauschen, ist das Problem bei mir mit einem Userreading beim MQTT-Device gelöst:

Code Auswählen Erweitern

aussentemperatur_corr:aussentemperatur.* {
  # Abfangen von fehlerhaften Temperaturwerten
  my $maxdiff = 2;
  my $val = ReadingsNum( $name, 'aussentemperatur', undef );
  my $oldval = ReadingsNum( $name, 'aussentemperatur_corr', undef );
  if( abs( $val - $oldval ) > $maxdiff ) {
    $val = $oldval;
  }
  $val;
}Ich logge dann einfach das Reading "aussentemperatur_corr" anstatt "aussentemperatur".
Vielleicht ist das ja eine Alternative für Dich.

[Knallfrosch]

Danke dir für den weiteren Lösungsweg.

Ich habe jetzt erstmal die Variante von DS_Starter eingebaut und werde das mal beobachten.

Sollte das nicht funktionieren, teste ich noch deinen Vorschlag.

Grüße

[betateilchen]

Ich habe jetzt erstmal die Variante von DS_Starter eingebaut und werde das mal beobachten.
Sollte das nicht funktionieren, teste ich noch deinen Vorschlag.

Du kannst auch beide Vorschläge kombinieren und den Vergleich in die valueFn() einbauen.

Die Verwendung von DbLogExclude und DbLogInclude ist für mich sinnfrei.

Nunja, ich habe dbLogExclude global als attr gesetzt und nutze Include dann um nur gezielt das zu loggen, was ich benötige.

Für mich sind all diese include / exclude Attribute sinnfrei.

Welche sinnhafte Lösung gibt es denn?

Im define des DbLog-device eine gut überlegte, sinnvolle regex angeben. Damit muss man auch später nur noch an einer einzigen Stelle Änderungen vornehmen, wenn man zusätzliche (oder weniger) readings loggen möchte.

Funktioniert bei mir seit vielen Jahren in allen meinen FHEM Installationen perfekt.

[rabehd]

Damit muss man auch später nur noch an einer einzigen Stelle Änderungen vornehmen, wenn man zusätzliche (oder weniger) readings loggen möchte.

Das mache ich über das Include-Attribut im jeweiligen Device. Ist für mich die sinnvolle Dokumentation.

[betateilchen]

Das mache ich über das Include-Attribut im jeweiligen Device. Ist für mich die sinnvolle Dokumentation.

Kann man so machen, ist für mich aber komplett sinnfrei, weil man das dann bei jedem device einstellen muss.

Außerdem stamme ich aus einer Zeit, in der FHEM / DbLog diese sinnfreien Attribute noch gar nicht kannte.
Damals lernte man in FHEM noch, "vor dem Machen zu Denken"...

Ich verschiebe das Thema gerne in einen passenderen Bereich, sag mir wohin es deiner Meinung nach besser passt.

Es geht nicht darum, wohin es nach irgendeiner Meinung passt, sondern darum, wohin der Thread aufgrund des darin diskutierten Moduls gehört.

https://forum.fhem.de/index.php?topic=13092.0

[rabehd]

Kann man so machen, ist für mich aber komplett sinnfrei, weil man das dann bei jedem device einstellen muss.

Außerdem stamme ich aus einer Zeit, in der FHEM / DbLog diese sinnfreien Attribute noch gar nicht kannte.
Damals lernte man in FHEM noch, "vor dem Machen zu Denken"...

Das war mir irgendwann zu unübersichtlich. Wahrscheinlich waren Leute wie ich der Auslöser für die Attribute.
Für jede Variante gibt es Für und Wider. Genau das finde ich auch gut an fhem.
Gegen die Attribute spricht die merkwürdige Verwendung beider Attribute, bei Deiner Lösung kann das nicht passieren.
Letztendlich ist es wie immer wildes Kopieren und Probieren ist die schlimmste Variante.

[Knallfrosch]

Es geht nicht darum, wohin es nach irgendeiner Meinung passt, sondern darum, wohin der Thread aufgrund des darin diskutierten Moduls gehört.

https://forum.fhem.de/index.php?topic=13092.0

Da ich über diese Variante hier gelandet bin, sollte es ja also passen.