Ankündigung: checkReadingEvent soll demnächst nicht erforderlich sein

[Damian]

In der kommenden Version, soll das Verhalten des DOIF-Moduls vereinheitlicht werden. Angabe der Art [<device>:<reading>] soll nur noch auf Änderungen des Readings reagieren und nicht mehr auf beliebige Events des Devices.

Dieses Verhalten ist inzwischen bei indirekten Timern, Widgets und Definitionen im Status-Attribut aktiv.

Status-Angaben der Art [<device>] reagieren dagegen weiterhin auf alle Events des Devices.

Damit wird die Angabe des Attributs checkReadingEvent nicht mehr erforderlich sein.

[Ellert]

Ich hätte dann gern ein Attribut, mit dem ich das alte Verhalten beibehalten kann, ich möchte nicht alle DOIF prüfen müssen, ob das neue Verhalten zu unerwünschten Nebenefekkten führt.

[Damian]

Ich hätte dann gern ein Attribut, mit dem ich das alte Verhalten beibehalten kann, ich möchte nicht alle DOIF prüfen müssen, ob das neue Verhalten zu unerwünschten Nebenefekkten führt.

Das hast du seinerzeit schon geprüft

Für Abwärtskompatibilität wird es eine Option geben.

Es hat sich insb. bei indirekten Timern gezeigt, das checkReadingEvent per default die bessere Alternative ist.

Abgesehen davon, bei Angaben [<device>] ändert sich nichts.

[Brockmann]

In der kommenden Version, soll das Verhalten des DOIF-Moduls vereinheitlicht werden. Angabe der Art [<device>:<reading>] soll nur noch auf Änderungen des Readings reagieren und nicht mehr auf beliebige Events des Devices.
Dieses Verhalten ist inzwischen bei indirekten Timern, Widgets und Definitionen im Status-Attribut aktiv.
Status-Angaben der Art [<device>] reagieren dagegen weiterhin auf alle Events des Devices.
Damit wird die Angabe des Attributs checkReadingEvent nicht mehr erforderlich sein.

Sag mal, hast Du Dir inzwischen einen Pressesprecher zugelegt? Der Post klingt nämlich genauso, wie PR-Fuzzis einem gerne unangenehme Dinge verkaufen, indem sie möglichst positiv beschrieben werden: "vereinheitlicht werden", "reagieren dagegen weiterhin", "nicht mehr erforderlich sein"... 

Tatsächlich geht es doch um eine Änderung an der grundlegenden Funktionsweise von DOIF, die mit Veröffentlichung vermutlich diverse DOIFs kaputt machen dürfte, die sich bislang gewollt oder ungewollt auf diesen "Seiteneffekt" verlassen haben.
Ich hoffe, die Abwärtskompatibilität sieht nicht so aus, dass ich in meinen ca. 100 DOIFs in mehreren FHEM-Instanzen jeweils manuell ein Attribut setzen muss?

[Damian]

Sag mal, hast Du Dir inzwischen einen Pressesprecher zugelegt? Der Post klingt nämlich genauso, wie PR-Fuzzis einem gerne unangenehme Dinge verkaufen, indem sie möglichst positiv beschrieben werden: "vereinheitlicht werden", "reagieren dagegen weiterhin", "nicht mehr erforderlich sein"... 

Tatsächlich geht es doch um eine Änderung an der grundlegenden Funktionsweise von DOIF, die mit Veröffentlichung vermutlich diverse DOIFs kaputt machen dürfte, die sich bislang gewollt oder ungewollt auf diesen "Seiteneffekt" verlassen haben.
Ich hoffe, die Abwärtskompatibilität sieht nicht so aus, dass ich in meinen ca. 100 DOIFs in mehreren FHEM-Instanzen jeweils manuell ein Attribut setzen muss?

Als "Presssprecher" bin ich geübt.

Ich habe ja bereits vor längerer Zeit still und heimlich aufgrund von Problemen indirekte Timer umgestellt, ohne dass sich jemand beschwert hat. OK die kommen vielleicht nicht so oft vor, wie Eventabfragen. Zusätzlich habe ich in Zusammenhang mit den neu eingeführten Widgets intern einen neuen Triggerauswertungsmechanismus eingebaut. Dieser wird ebenfalls bereits still und heimlich im Attribut Status benutzt, hier hat sich auch noch keiner beschwert.

Das Reagieren auf alle Events (per default) macht mehr Probleme als auf bestimmte.

Ausnahme ist der häufig benutzter Zugriff auf den Status, der soll ja weiterhin auf alles triggern.

Bevor ich soweit bin, kann ich ja hier mal die Version zum Testen einstellen. Dann kann jeder vorher überprüfen, ob noch alles gleich funktioniert - davon gehe ich aus.

Wenn es Beschwerden gibt, dann bleibt alles beim alten.

Mir ist allerdings kein Fall bekannt, wo es sinnvoll wäre ein Reading auszuwerten, wenn sich ein anderes Reading ändert.











 

[Per]

Würde addStateEvent da nicht auch irgendwie reinpassen? Wenn ich

Code Auswählen Erweitern

[device:state:"on"] eingebe, sollte ich nicht addStateEvent noch extra benötigen.

[Ellert]

Code Auswählen Erweitern

Mir ist allerdings kein Fall bekannt, wo es sinnvoll wäre ein Reading auszuwerten, wenn sich ein anderes Reading ändert.

Das ist immer dann sinnvoll, wenn es für ein Reading kein Event gibt aber der Status regelmässig aktualisiert wird und der Wert des Readings ausgewertet werden soll, vergleichbar mit der Auswertung von Internals.

Die Änderungen mögen sinnvoll sein, weil das Modul weniger Events verarbeiten muss.

Wenn diese Änderung eingeführt wird, sollten bestehende Definitionen nicht davon betroffen sein.

Ich glaube der Imageschaden für DOIF wäre beträchtlich, wenn nach einem unbedachten Update die Heimautomation oft erst später jahreszeitabhängige Fehlfunktionen zeigt.

[Damian]

Das ist immer dann sinnvoll, wenn es für ein Reading kein Event gibt aber der Status regelmässig aktualisiert wird und der Wert des Readings ausgewertet werden soll, vergleichbar mit der Auswertung von Internals.

Hast du solche Devices, die du abfragst?

[Ellert]

Hast du solche Devices, die du abfragst?

Ich weiß es nicht, aber ich habe nur 2 oder 3 DOIF mit checkReadingEvent, manche DOIF sind rein Event gesteuert, das hatte ich im Zusammenhang mit der ersten Ankündigung angefangen und nach der Einführung von checkReadingEvent habe ich das Thema nicht weiter verfolgt. Insofern müsste ich mir alle ansehen.

checkReadingEvent wird im Grunde heute schon nicht benötigt, wenn Events mit Ausgabeformatierung verwendet werden.´

Ich will dem aber nicht in Wege stehen, notfalls gibts ja auch exclude_from_update, da kann man sich Zeit lassen mit der Überprüfung.

[Damian]

Ich weiß es nicht, aber ich habe nur 2 oder 3 DOIF mit checkReadingEvent, manche DOIF sind rein Event gesteuert, das hatte ich im Zusammenhang mit der ersten Ankündigung angefangen und nach der Einführung von checkReadingEvent habe ich das Thema nicht weiter verfolgt. Insofern müsste ich mir alle ansehen.

checkReadingEvent wird im Grunde heute schon nicht benötigt, wenn Events mit Ausgabeformatierung verwendet werden.´

Ich will dem aber nicht in Wege stehen, notfalls gibts ja auch exclude_from_update, da kann man sich Zeit lassen mit der Überprüfung.

keine Sorge, wenn ich dazukomme eine neue Version zu produzieren, dann würde ich sie hier längere Zeit zum Testen hinterlegen. Ich persönlich gehe nicht davon aus, dass es viele Konflikte gibt. Ich könnte zur Not auch "checkReadingEvent no" als globales User-Attribut vorsehen, um mit einer Änderung für alle DOIFs die bisherige Vorgehensweise zu gewährleisten.

Hier noch mal Argumente, die für die Änderungen sprechen:

-Weniger System-Last, weil weniger oft Bedingungen überprüft werden müssen (bei 100 DOIFs könnte sich da schon etwas aufsummieren )
-Weniger Problem mit unerwartetem Verhalten von DOIFs, weil das bisherige Verhalten (triggern auf alles bei der Angabe von Readings) oft nicht intuitiv erscheint
-Einheitliches Vorgehen bei allen Angaben der Art [<device>:<reading>]
-Weniger Probleme bei Selbsttriggern
-Weniger Sourcecode, wenn die alten Triggermechanismen rausfallen

[Brockmann]

Hier noch mal Argumente, die für die Änderungen sprechen:

Zur Klarstellung: Ich finde es im Prinzip auch vollkommen sinnvoll, das Standardverhalten von DOIF so zu ändern.
Ich fand das immer schon einen etwas sonderbaren Seiteneffekt, der mehr für Verwirrung sorgt als Nutzen bringt.
Aber man hat sich eben im Laufe der Zeit daran gewöhnt und ich bin mir recht sicher, dass ich ihn an der einen oder anderen Stelle bewusst eingesetzt habe. Kann aber sein, dass das dann immer [Device]-Ausdrücke sind, was ja auch in Zukunft weiter funktionieren würde.

Gibt FHEM eigentlich die Möglichkeit her, zwischen einem Define und einem Redefine (also Änderung eines vorhandenen DOIF) zu unterscheiden? Dann könnte man es vereinfacht so machen:
Define -> attr checkReadingEvent 1
Redefine UND checkReadingEvent = 1 -> nix tun
Redefine UND (notexist(checkReadingEvent) ODER checkReadingEvent = 0) -> attr checkReadingEvent 0

Ansonsten: Auch nicht schlimm. Ich würde dann einfach bei meinen bereits vorhandenen DOIF das entsprechende Attribut vorbeugend auf altes Verhalten setzen. Es wird zwar nur in wenigen Fällen oder vielleicht sogar nirgends eine Rolle spielen. Aber der Aufwand, die alle anzuschauen und zu überprüfen, wäre deutlich höher.

Vielleicht könntest Du das entsprechende Attribut ja schon mal zeitnah einführen (noch ohne echte Funktionalität dahinter)?
Dann könnte man es schon passend setzen, bevor es dann "scharf geschaltet" wird.
Oder wird es einfach bei CheckReadingEvent bleiben? Dann könnte man das ja jetzt schon entsprechend setzen?

[Ellert]

Hallo Damian,

gibt es einen konkreten Zeitrahmen bis wann die Umstellung eingeführt wird.

Ich plane für alle DOIF Zug um Zug das Attribut checkReadinEvent 1 zu setzen, um Definitonen bei Fehlverhalten anzupassen.

Wenn alle Definitionen mit gesetztem Attribut checkReadingEvent funktionieren, dann sollte die geplante Änderung zu keiner vorhersehbaren Beeinträchtigung führen.

Ist diese Annahme korrekt?

[Per]

Ich plane für alle DOIF Zug um Zug das Attribut checkReadinEvent 1 zu setzen

Warum setzt du nicht erstmal alle auf 0, dann bist du vor Überraschungen durch ein Update sicher und hast alle Zeit der Welt.

Code Auswählen Erweitern

attr TYPE=DOIF checkReadinEvent 0

Nebenbei: wie reagiert die Event-Erkennung darauf?
Beispiel aus CommandRef:

Code Auswählen Erweitern

["FS"]
Und gibt es hier überhaupt die Möglichkeit, auf ein spezielles Event, ohne Regex, zu reagieren, ohne Nebenwirkungen? Also das GGteil zum Fragezeichen.

[Ellert]

Warum setzt du nicht erstmal alle auf 0, dann bist du vor Überraschungen durch ein Update sicher und hast alle Zeit der Welt.

Code Auswählen Erweitern

attr TYPE=DOIF checkReadinEvent 0

Nebenbei: wie reagiert die Event-Erkennung darauf?
Beispiel aus CommandRef:

Code Auswählen Erweitern

["FS"]
Und gibt es hier überhaupt die Möglichkeit, auf ein spezielles Event, ohne Regex, zu reagieren, ohne Nebenwirkungen? Also das GGteil zum Fragezeichen.

Code Auswählen Erweitern

attr TYPE=DOIF checkReadinEvent 0 setzt voraus, dass es nach dem Update dieses Attibut noch geben wird.
Ich habe es so verstanden, dass nur die Abfrage von

Code Auswählen Erweitern

[Device:Reading] betroffen ist, keine Events.

[Damian]

Code Auswählen Erweitern

attr TYPE=DOIF checkReadinEvent 0 setzt voraus, dass es nach dem Update dieses Attibut noch geben wird.
Ich habe es so verstanden, dass nur die Abfrage von

Code Auswählen Erweitern

[Device:Reading] betroffen ist, keine Events.

checkReadinEvent bezieht sich auch heute immer nur auf Readingangaben der Form [Device:Reading], bei Ereignisangaben hat es keine Bedeutung.