14_SD_WS07.pm

[sidey79]

if humidity or temperature value is out of range, then do not log at verbose 3. Log only at verbose 5

• Please check if the PR fulfills these requirements

• Tests for the changes have been added / modified (needed for for bug fixes / features)
• commandref has been added / updated (needed for bug fixes / features)
• CHANGED has been updated (needed for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Log wrong values only at high verbose level

• What is the current behavior? (You can also link to an open issue here)

Hum or temp value out of possible range comes at verbose 3 (default) into log. This causes flooding,

• What is the new behavior (if this is a feature change)?

The error is only displayed at verbose 5

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

no

• Other information:
  https://forum.fhem.de/index.php/topic,97910.msg916505.html#msg916505

[HomeAutoUser]

Ich denke über den Loglevel könnte man dort "streiten".
Es gibt leute welche den Fehler mitbekommen wollen und manche sind froh wenn sowas ganz weit weg ist.

Vom Bauchgefühl würde ich sowas auf Verbose 4 setzen. Wie groß ist denn die Warscheinlichkeit, das es sich um "normale" Fehler handelt und nicht um Empfangsfehler?

[sidey79]

@HomeAutoUser

Was soll der Anwender denn machen wenn er diese Meldung bekommt? Es sind ganz sicher Empfangsfehler. Bitdreher sowas in der Art.
Ich habe es auf 5 gesetzt, da es dem Anwender das Logfile zumüllt und ihm die Information doch recht wenig weiterhilft.

[HomeAutoUser]

@sidey79 ich kann dich und den User schon verstehen. Meine Argumente wurden nur angebracht weil ich auch die Gegenseite kenne wo User solche Fehler gern sehen wollen.

Anders gedacht für beide Parteien, wäre es in solchen Fällen vielleicht nicht günstig wenn man solche Prüfungen auf 5 oder 4 setzt, dies zu dokumentieren (Commandref) in Kurzform? -> nur eine Idee

[sidey79]

Ich habe es auf 5 gesetzt, da der Anwender meistens wenig damit machen kann. Kann doch gut sein, dass jede 2. Meldung halt einfach einen Fehler hat.

Bezüglich commandref, was sollen wir da rein schreiben?

[HomeAutoUser]

Ich habe mir nun mal noch 2 Module wie SD_WS und SW_WS09 angesehen.
Da haben wir es auf 4 solche Error Meldungen, eine einheitliche "Schiene" wäre passend denke ich.

Log3 $iohash, 4, "$name: SD_WS_Parse BresserTemeo Humidity Error. Humidity=$hum";
Log3 $iohash, 4, "$name: SD_WS_Parse BresserTemeo Temperature Error. temp=$temp";

if($hum > 100 || $hum < 0) {
            	Log3 $iohash, 4, "$name: SD_WS09_Parse HUM: hum=$hum msg=$rawData " ;

[elektron-bbs]

Wenn den User die Meldngen stören, hätte er ja auch beim Sensor verbose auf 2 setzen können. Besser wäre es gewesen, vom User RAWMSG zu erbitten, um das genauer analysieren zu können. Bitfehler halte ich eigentlich für ziemlich unwahrscheinlich, wenn minutenlang die gleichen Bitmuster empfangen werden.

[HomeAutoUser]

Hallo,

ich habe zu dem Thema aktuell einen Fall wo es gut wäre wenn man die Meldungen nicht einfach unterdrückt.

In meinem Falle habe ich seit Tagen eine Meldung erhalten
2019.03.09 10:21:25 1: dewpoint_notify: humidity invalid: 0

Nach Forschung des Grundes habe ich das Modul (dewpoint) angepasst um genauere Aussagen zu erhalten. Nun erhielt ich den Übeltäter zu gesicht.

2019.03.09 11:29:05 1: dewpoint_notify: humidity Device CUL_WS_2 (humidity) invalid: 0

Als ich auf das Device schaute, musste ich feststellen das seit TAGEN keine Luftfeuchte erscheint.
Was ich damit sagen möchte, wenn wir dem User sowas unterdrücken, dann bekämen wir es nicht mit!

Der genauen Ursache muss ich auf den Grund gehen aber ich denke, das ist bei mir die Batterie weil diese schon seit langem low anzeigt (Nicht der Sensor, sondern die Energieversordung wo dieser dran hängt).

... nur so als Kommentar um die Sache auch live zu bewerten.

Bei sehr häufigen Fehlern sollten wir natürlich genauer schauen woran der Fehler liegt und so kommt nur die Analyse der RAWMSG zum tragen.

MfG

[sidey79]

Bezüglich Verbose 4 bin ich mittlerweile überzeugt.
Allerdings sollte es sich auf den Sensor und nicht auf das IODevice beziehen.

Den Anwender bitten vom Default (3) auf (2) zu gehen fände ich jetzt nicht so gut.

Bezüglich der Recherche, woran es liegt können wir ja immer noch Daten anfordern.

[sidey79]

@HomeAutoUser
Ich habe es auf Verbose 4 angepasst und in der Commandef einen Hinweis eingebaut,