DOIF soll zukünftig nur auf passende Events reagieren

[Damian]

Liebe DOIF-Nutzer,

es gibt immer wieder das Problem, dass Abfragen auf Stati oder Readings getriggert werden, obwohl sich das entsprechende Reading nicht ändert, sondern ein anderes Reading des Devices die Triggerung auslöst. Dass das Modul auf alle Trigger eines Devices reagiert, liegt daran, dass ich seinerzeit state-Events nicht eindeutig erkennen konnte. Dadurch führen insb. indirekte Timer z. B. beim Twilight-Modul z. B. [[mytwilight:ss_weather]] zum ständigen Neusetzen des Timers, obwohl sich das Reading nicht ändert.

Ich stelle gerade die Überlegung an, das Verhalten zu ändern, so dass zukünftig Abfragen mit indirekten Timern, Readings oder Stati der Art:

Code Auswählen Erweitern

[mydevice] eq "on" nur noch ausgewertet werden, wenn tatsächlich sich der Status oder das Reading ändert und nicht irgend ein anderes Event des Devices zum Trigger mit Auswertung führt.

Dazu würde ich das Attribut addStateEvent einführen, welches die Möglichkeit eröffnet state-Events zu erkennen. Das würde ich gerne als default einstellen wollen.  Das würde allerdings gleichzeitig dazu führen, das Event-Abfragen der Art [mydevice:"^on$"] so aussehen müssten: [mydevice:"^state: on$"]. Abfragen [mydevice:"on"] könnten bleiben, weil sie auch auf "state: on" reagieren.

Um die Kompatibilität zum bisherigen Verhalten zu erreichen, müsste man addStateEvent auf Null setzen.

Sieht jemand bei diesen Änderungen ein Problem in seinen Definitionen?

Gruß

Damian

[Per]

Ich würde zwar ein paar DOIFs anfassen müssen, aber da o.a. Verhalten eh das von mir gewünschte wäre, nähme ich das gern in kauf.

[Ellert]

Manche Readings oder Internals werden gesetzt ohne Events zu erzeugen, es werden aber andere Events des Gerätes erzeugt. Könnte man zukünftig eine Bedingung nicht mehr auf solche Readings oder Internals triggern lassen?

Beispiel:
Der SignalDuino hat ein Internal DMSG, dort erscheinen die dekodierten Nachrichten ohne Event. Es werden auch Nachrichten empfangen für die es kein Modul gibt, für diese Nachrichten erzeugt der Signalduino ein unspezifisches Event (Initialized) mit dem man bisher triggern kann durch: [SignalDuino:&DMSG] eq "<Nachricht>".

Müsste man das zukünftig so formulieren [Signalduino:"^state: Initialized$"] and [SignalDuino:&DMSG] eq "<Nachricht>" ?

Code Auswählen Erweitern

Um die Kompatibilität zum bisherigen Verhalten zu erreichen, müsste man addStateEvent auf Null setzen.

Das Attribut "addStateEvent" gibt es schon, als einzuschaltende Option:

addStateEvent
Das mit dem state Reading verknüpfte Event ist speziell, da das dazugehörige Prefix "state: " entfernt wird, d.h. $EVENT ist nicht "state: on", sondern nur "on". In manchen Fällen ist es aber erwünscht ein zusätzliches Event zu bekommen, wo "state: " nicht entfernt ist. Für diese Fälle sollte addStateEvent auf 1 gesetzt werden, die Voreinstellung ist 0 (deaktiviert).
Achtung:

    dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.
    dieses Attribut zeigt nur für solche Geräte-Events eine Wirkung, die readingFnAttributes unterstützen.

Daher sollte es auch bei DOIF als einzuschaltende Option eingeführt werden.

Sieht jemand bei diesen Änderungen ein Problem in seinen Definitionen?

Bei derzeit 18200 DOIF Definitionen plädiere ich für Bestandsschutz, die Änderung sollte keine bestehenden Definitionen beeinflussen.

Edit: Also, wenn kein Attribut addStateEvent vorhanden ist oder addStateEvent = 0, sollte das bisherige Verhalten beibehalten werden. Bei einem Geräte-Event werden alle benutzen, zugehörigen Readings und Internals aktualisiert und "state" kann weggelassen werden.

[Damian]

Manche Readings oder Internals werden gesetzt ohne Events zu erzeugen, es werden aber andere Events des Gerätes erzeugt. Könnte man zukünftig eine Bedingung nicht mehr auf solche Readings oder Internals triggern lassen?

Beispiel:
Der SignalDuino hat ein Internal DMSG, dort erscheinen die dekodierten Nachrichten ohne Event. Es werden auch Nachrichten empfangen für die es kein Modul gibt, für diese Nachrichten erzeugt der Signalduino ein unspezifisches Event (Initialized) mit dem man bisher triggern kann durch: [SignalDuino:&DMSG] eq "<Nachricht>".

Müsste man das zukünftig so formulieren [Signalduino:"^state: Initialized$"] and [SignalDuino:&DMSG] eq "<Nachricht>" ?

Code Auswählen Erweitern

Um die Kompatibilität zum bisherigen Verhalten zu erreichen, müsste man addStateEvent auf Null setzen.

Das Attribut "addStateEvent" gibt es schon, als einzuschaltende Option:
Daher sollte es auch bei DOIF als einzuschaltende Option eingeführt werden.

Bei derzeit 18200 DOIF Definitionen plädiere ich für Bestandsschutz, die Änderung sollte keine bestehenden Definitionen beeinflussen.

Edit: Also, wenn kein Attribut addStateEvent vorhanden ist oder addStateEvent = 0, sollte das bisherige Verhalten beibehalten werden. Bei einem Geräte-Event werden alle benutzen, zugehörigen Readings und Internals aktualisiert und "state" kann weggelassen werden.

Ja. Ich möchte zukünftig dieses Feature gerne als Standard haben, weil es jetzt schon viele so verstehen und das bisherige Verhalten eigentlich eine Notlösung war, weil ich state-Events nicht erkennen konnte. Bei komplexeren Modulen, die viele Readings unterschiedlich setzen, ist das bisherige Vorgehen nicht günstig (siehe twilight-Modul). Bei Modulen die Internals ohne Events verändern ist es dann eine Glückssache, wann ein Event tatsächlich kommt und wann nicht, hier sollte man schon wissen wie das Modul funktioniert, ansonsten ist es dem Zufall überlassen, ob eine Definition gewünscht funktioniert oder nicht.

Ich denke zu 99 % wird das neue Feature keinen Unterschied ausmachen. Allerdings wäre 1 % bei 18.200 Definition schon zu viel.

Ich könnte bei allen neuen Definitionen automatisch addStateEvent 1 als Attribut setzen. Das automatische Setzen eines Attributes bei Neudefinitionen mache ich bereits beim THRESHOLD-Modul - das sollte auch beim DOIF-Modul funktionieren. Bei allen bisherigen Definitionen würde sich also nichts ändern. Für alles Andere hätte man die Option das Attribut zu löschen oder sich seine Event-Abfragen, wie oben vorgeschlagen, selbst zu definieren, denn in solchen Fällen sollte man sich schon Gedanken machen wann tatsächlich ein Trigger kommt und damit die Abfrage tatsächlich ausgewertet wird.

Gruß

Damian

[FunkOdyssey]

Ich finde dein Vorhaben super, da man die DOIFs dann etwas gezielter steuern kann. Ich gehöre selbst auch zu denjenigen, die sich über die stetigen DOIF-Updates gewundert hatten.

[Ralf.E]

Moin,

es gibt immer wieder das Problem, dass Abfragen auf Stati oder Readings getriggert werden, obwohl sich das entsprechende Reading nicht ändert, sondern ein anderes Reading des Devices die Triggerung auslöst. Dass das Modul auf alle Trigger eines Devices reagiert, liegt daran, dass ich seinerzeit state-Events nicht eindeutig erkennen konnte. Dadurch führen insb. indirekte Timer z. B. beim Twilight-Modul z. B. [[mytwilight:ss_weather]] zum ständigen Neusetzen des Timers, obwohl sich das Reading nicht ändert.

cool, genau über dieses Verhalten bin ich gerade gestolpert und habe mich gewundert warum zyklisch ein und dasselbe command ausgeführt wird (do always = false):

DOIF( [wz_MotionTablet:reportedState] eq "open" )({ Log 3,"motion-on: $DEVICE:$EVENT" })

Letztendlich ist es wohl die wakeup notification (z-wave) welche hier das auslösende Element ist.

Zu Deiner eigentliche Frage:
- eine Art Bestandsschutz verärgert weniger User, welche sich auf das bisherige Verhalten verlassen
- als default für neu definierte DOIF's Ok, wenn die Verhaltensänderung im Modul für möglichst viele User sichtbar wird
- alternativ eine Übergangszeit, in der das neue Verhalten aktiv gesetzt werden muss

Gruß Ralf

[Damian]

Ich habe eine Version nun gebastelt, die eine Kompromiss-Lösung darstellt:

Abfragen der Form [mydevice] eq "on" stellen eine Abfrage auf das Internal STATE dar und entsprechen heute schon intern der Abfrage [mydevice:&STATE]. Diese Abfragen reagieren weiterhin auf alle Trigger des Devices, da Internals ja keine Events produzieren.

Abfragen auf Readings der Form [mydevice:myreading] reagieren dagegen beim gesetzten addStateEvent nur auf Trigger von myreading. Wenn man also zukünftig Änderungen des Status nur beim entsprechenden Trigger auswerten will, dann muss man einfach:

[mydevice:state] in der Abfrage angeben.

Gruß

Damian

[FunkOdyssey]

Habe ich sowieso schon überall, da ich STATE per stateformat verändert habe.

[Damian]

Ich habe jetzt doch eine voll kompatible Version programmiert. Durch gesetzte event-on-change-reading Attribute funktionierten einige DOIFs in der neuen Version bei mir nicht mehr richtig - das würde bei anderen Usern nicht anders sein.

Es gibt jetzt ein neues Attribut checkReadingEvent für den neuen Modus.  Dabei funktionieren alle Eventabfragen der Form [mydevice:"^on$"] ohne state-Angabe wie bisher. Die State-Darstellung wird zur Erkennung des state-Readings nur intern genutzt. Das neue Attribut wird nicht automatisch gesetzt - es bleibt also erst mal alles beim alten, wenn man nicht bewusst das Attribut setzt.

Unabhängig davon kann man jetzt das Attribut addStateEvent setzen, damit kann man auch selbst zukünftig Event-Abfragen der Form [mydevice:"^state:on$"] bei Modulen, die die State-Darstellung unterstützen, nutzen.

Gruß

Damian

[Ellert]

Ich habe jetzt doch eine voll kompatible Version programmiert. Durch gesetzte event-on-change-reading Attribute funktionierten einige DOIFs in der neuen Version bei mir nicht mehr richtig - das würde bei anderen Usern nicht anders sein.

Es gibt jetzt ein neues Attribut checkReadingEvent für den neuen Modus.  Dabei funktionieren alle Eventabfragen der Form [mydevice:"^on$"] ohne state-Angabe wie bisher. Die State-Darstellung wird zur Erkennung des state-Readings nur intern genutzt. Das neue Attribut wird nicht automatisch gesetzt - es bleibt also erst mal alles beim alten, wenn man nicht bewusst das Attribut setzt.

Unabhängig davon kann man jetzt das Attribut addStateEvent setzen, damit kann man auch selbst zukünftig Event-Abfragen der Form [mydevice:"^state:on$"] bei Modulen, die die State-Darstellung unterstützen, nutzen.

Gruß

Damian

Ich denke, das ist eine konsequente Lösung, addStateEvent so zu implementieren, wie es in der Commandref beschrieben ist und die Änderung der Readingstriggerung davon zu entkoppeln.

[Damian]

neue Version siehe hier:

https://forum.fhem.de/index.php/topic,51060.msg429494.html#msg429494

Gruß

Damian