Triggern auf DOIF-Readings (error, warning)

[PatrickR]

Guten Abend!

Besteht die Möglichkeit, bspw. mit einem notify auf die Readings error, warning eines DOIFs zu triggern? Bei mir scheinen die Readings kein Event auszulösen. Ziel ist ein Alerting über Fehler in DOIFs.

Patrick

[Damian]

Das Thema hatten wir schon bei Timer-Readings, seit dem gibt es ein Konfigurations-Attribut dazu, das will ich nicht für jedes DOIF-Reading definieren.

DOIF ist insb. im Perl-Modus bewusst nicht besonders gesprächig. Es müsste ein Konzept her, ähnlich event-on-....-reading, nur umgekehrt zum Einschalten von DOIF-Reading-Events - wenn ich mal Zeit finde ...

Edit: Solange kann man sich behelfen z. B. mit

Code Auswählen Erweitern

DOIF {[+01:00];set_Reading("error_devices",[?@"":error])}

[PatrickR]

Hi!

Das Thema hatten wir schon bei Timer-Readings, seit dem gibt es ein Konfigurations-Attribut dazu, das will ich nicht für jedes DOIF-Reading definieren.

Bei den error- und warnings-Readings wäre das ausgesprochen wichtig, vor allem wegen der sich leider häufenden Breaking Changes in DOIF-Perl. Man könnte sogar überlegen, ob diese Readings immer ein Event werfen, da sie, insbesondere gepaart mit event-on-change-reading selten auftreten sollten.

Patrick

[Damian]

Hi!

Bei den error- und warnings-Readings wäre das ausgesprochen wichtig, vor allem wegen der sich leider häufenden Breaking Changes in DOIF-Perl. Man könnte sogar überlegen, ob diese Readings immer ein Event werfen, da sie, insbesondere gepaart mit event-on-change-reading selten auftreten sollten.

Patrick

Wahrscheinlich wäre aber genau diese Änderung ein großes "Breaking Change", denn gerade im FHEM-Modus ist nicht klar, was ein Fehler ist und was nicht.

Alles was im FHEM-Modus ungleich Null liefert, wird als error festgehalten z. B. (["trigger"]){return(1)} jetzt ist es nur ein "falsch"gesetztes Reading, aber bisher keine falschen Events.

[Damian]

Wahrscheinlich wäre aber genau diese Änderung ein großes "Breaking Change", denn gerade im FHEM-Modus ist nicht klar, was ein Fehler ist und was nicht.

Alles was im FHEM-Modus ungleich Null liefert, wird als error festgehalten z. B. (["trigger"]){return(1)} jetzt ist es nur ein "falsch"gesetztes Reading, aber bisher keine falschen Events.

Wenn man kompatibel bleiben wollte, müsste man events beliebig einschalten können. Man könnte definieren:

Code Auswählen Erweitern

attr <mydoif> events <Regex für Readings>

z. B.

Code Auswählen Erweitern

attr di_test events error|warning|executed

Mit event-on-change-reading kann man sie dann auf change einschränken

Dazu müsste ich allerdings diverse Stellen im DOIF anpassen.

[PatrickR]

Hi!

Wahrscheinlich wäre aber genau diese Änderung ein großes "Breaking Change", denn gerade im FHEM-Modus ist nicht klar, was ein Fehler ist und was nicht.

Ich verstehe ehrlich gesagt nicht, was der Change kaputt machen würde. Schließlich triggert niemand auf Events, die es noch gar nicht gibt...

Wenn man kompatibel bleiben wollte, müsste man events beliebig einschalten können. Man könnte definieren:
[...]

Schöne Lösung.

Grüße
Patrick

[Damian]

Ich werde dann erst mal für error und warning Event setzen. Wenn jemand keine Events dazu haben haben will, dann muss er für error und warning event-on-change setzen.

Wenn jemand Bedenken hat, dann bitte hier melden.

[Per]

Schließlich triggert niemand auf Events, die es noch gar nicht gibt...

Mit ["myDEVICE"] schon...

[Damian]

Nur mal zur Info:

Reading setzen mit Event kostet ca. 100 mal mehr Performance als ohne - hab´s gerade grob überprüft.

[Ellert]

Ich werde dann erst mal für error und warning Event setzen. Wenn jemand keine Events dazu haben haben will, dann muss er für error und warning event-on-change setzen.

Wenn jemand Bedenken hat, dann bitte hier melden.

Wenn error und warning ins globale Logfile geschrieben werden, dann müssten keine Events erzeugt werden, da ein notify auch auf Logeinträge triggern kann, über das Attribut readLog.

[PatrickR]

Hi!

Mit ["myDEVICE"] schon...

Korrekt. Aber jemand, der explizit alles möchte, darf sich nicht wundern, wenn er alles bekommt. Ebenso könnte man argumentieren, dass jemand, der auf [""] triggert, ein anderes Ergebnis erhält, wenn ein neues Device ein Event wirft, mit dem der Nutzer nicht gerechnet hat.

Reading setzen mit Event kostet ca. 100 mal mehr Performance als ohne - hab´s gerade grob überprüft.

D. h. es dauert 100 mal so lange? Unabhängig davon: Das halte ich für verschmerzbar:

• Die Events sollten grundsätzlich gar nicht auftreten, falls doch sollte man ohnehin seine Definition reparieren.
• Das Nicht-Erzeugen von Events beraubt den Nutzer der Möglichkeit, elegant (d. h. ohne Polling) auf Fehler zu reagieren und zwar dann, wenn sie auftreten.

Um es einmal plastisch zu machen: Der set_timer-Patch hat bei mir dazu geführt, dass das DOIF, das Fehlerzustände meiner HmIP-Geräte überwacht hat, keine Notifications mehr verschickt hat. Ich verwende DOIFs für weitaus kritischere Steuerungsaufgaben, bspw. für die Tauchpumpen in meinem Keller. Fail-Silent ist da schlichtweg nicht ausreichend, ich möchte im Mindesten eine Möglichkeit haben, über Fehler sofort informiert zu werden.

Wenn error und warning ins globale Logfile geschrieben werden, dann müssten keine Events erzeugt werden, da ein notify auch auf Logeinträge triggern kann, über das Attribut readLog.

Das klingt auch ok.

Damians Idee mit einem Filter-Attribut in readingFnAttributes gefällt mir immer besser.

Patrick

[Damian]

Neue DOIF-Version eingecheckt. Jetzt mit Event für Readings: error und warning und block_... im Fehlerfall.

Im Perlmodus wurde bisher kein error gesetzt. Im Perlmodus wird im jeweiligen Reading block_... der Fehler festgehalten, sonst wird dort "executed" eingetragen.

Nun gibt auf für die Readings block_... jeweils ein Event, falls dort eine Fehlermeldung geschrieben wird.

[PatrickR]

Mahlzeit!

Nun gibt auf für die Readings block_... jeweils ein Event, falls dort eine Fehlermeldung geschrieben wird.

Habe das gerade mal kurz getestet und es sieht gut aus. Danke!

Grüße
Patrick

[Damian]

Mahlzeit!

Habe das gerade mal kurz getestet und es sieht gut aus. Danke!

Grüße
Patrick

Ich befürchte, dass wird dir nicht ausreichen, da im Perl-Modus error gar nicht gesetzt wird (bzw. nie gesetzt wurde). Ich denke, ich werde in der kommenden Version im Fehlerfall nicht nur des entsprechende block-Reading mit der Fehlermeldung belegen, sondern auch das Reading error selbst, wie im FHEM-Modus.

[PatrickR]

Hole mir den Fehler aktuell aus block. Error wäre war eleganter aber - auch wenn Du es nicht glauben wirst - mir gefällt es

Patrick


Von unterwegs gesendet.

[Damian]

Hole mir den Fehler aktuell aus block. Error wäre war eleganter aber - auch wenn Du es nicht glauben wirst - mir gefällt es

Patrick


Von unterwegs gesendet.

Wenn du nur einen Block im DOIF-Device hast, dann ist es egal, bei vielen Blöcken kann die Überwachung aufwändig sein.