-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
14_SD_WS07.pm #543
14_SD_WS07.pm #543
Conversation
if humidity or temperature value is out of range, then do not log at verbose 3. Log only at verbose 5
Ich denke über den Loglevel könnte man dort "streiten". 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? |
Was soll der Anwender denn machen wenn er diese Meldung bekommt? Es sind ganz sicher Empfangsfehler. Bitdreher sowas in der Art. |
@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 |
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? |
Ich habe mir nun mal noch 2 Module wie SD_WS und SW_WS09 angesehen.
|
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. |
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 Nach Forschung des Grundes habe ich das Modul (dewpoint) angepasst um genauere Aussagen zu erhalten. Nun erhielt ich den Übeltäter zu gesicht.
Als ich auf das Device schaute, musste ich feststellen das seit TAGEN keine Luftfeuchte erscheint. 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 |
Bezüglich Verbose 4 bin ich mittlerweile überzeugt. 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. |
lowered messages to verbose 4
@HomeAutoUser |
if humidity or temperature value is out of range, then do not log at verbose 3. Log only at verbose 5
Log wrong values only at high verbose level
Hum or temp value out of possible range comes at verbose 3 (default) into log. This causes flooding,
The error is only displayed at verbose 5
no
https://forum.fhem.de/index.php/topic,97910.msg916505.html#msg916505