Fehlende Events/Aktualisierung bei Dummy Reading

[arneman]

Ich will mit einem Dummy Folgendes machen:
Wenn der state sich ändert, soll ein reading im selben Dummy mit einem (aus dem state berechneten) Wert gesetzt werden. Ich löse dies mit einem notify, dem ich das Attribut "addStateEvent 1" gegeben habe und das auf "state" horcht (siehe Beispiel unten)

Nun wird im Eventlog zwar ein Event für das durch das Notify gesetzte Reading eingetragen, aber die grafische Oberfläche aktualisiert nur "state", nicht das ebenfalls geänderte Reading. Ich hatte auch Probleme mit FileLogs, die dann nicht ausgelöst haben.

So kann man das Problem nachvollziehen:

Code Auswählen Erweitern

define dummy_reading_event dummy
attr dummy_reading_event event-on-change-reading .*
attr dummy_reading_event room test
define notify_dummy_reading_event notify dummy_reading_event:state.* { fhem ("setreading dummy_reading_event read ".($EVTPART1+1));; }
attr notify_dummy_reading_event addStateEvent 1
attr notify_dummy_reading_event room test

3 Fhem Fenster öffnen. In einem das dummy_reading_event öffnen, im zweiten das Eventlog mit Filter ".*dummy_reading_event.*", im dritten "set dummy_reading_event 1" in die Kommandozeile eingeben

=> Eventlog  (✔)

2018-01-07 13:41:58 dummy dummy_reading_event 1
2018-01-07 13:41:58 dummy dummy_reading_event read: 2

=> Oberfläche (X)

Nur "state" wird geändert, nicht "read" (siehe Anhang)

Das Problem tritt unabhängig von "longpoll websockets" / "longpoll 1" auf.

Ergänzung/Workaround: Sobald ich im notify z.B. ein "sleep 0.01" hinzufüge, geht es (=> fhem ("sleep 0.01;setreading dummy_reading_event read ".($EVTPART1+1))

[justme1968]

readings die aus einem notify angelegt werden erzeugen meine events. sleep ist der 'richtige' workaround der auch so in der commandref dokumentiert ist.

mit einem userReading geht es auch ohne sleep.

[arneman]

Hm, das ist ja nicht so befriedigend. Auf jeden Fall ist das Verhalten nicht ganz konsistent (Eventlog Eintrag, aber kein FileLog/Fhemweb). Ist ein ziemlicher Stolperstein bei der Verwendung von Dummy.
Hinweise in der Commandref habe ich nicht gefunden, sind meines Erachtens nach für den Fall aber auch nicht wirklich der goldene Weg, weil solche "Sonderlocken" immer schwer zu handeln/merken sind. Sind auf jeden Fall ein paar Stunden bei mir ins Land gegangen.

Hoffentlich kann ich mir das dauerhaft merken ODER finde diese Beitrag hier dann wieder

[rudolfkoenig]

Um genauer zu sein:
- Wenn man auf Events fuer ein Geraet reagiert, und hier weitere Events fuer dieses Geraet generiert, dann wird fuer diese neuen Events nicht nochmal die Liste aller Interessenten aufgerufen, um Endlosschleifen zu vermeiden.
- Die neuen Events werden zu der Liste der alten Events hinzugefuegt, und die spaeter in der Schleife aufgerufenen notify/FileLog/WEB* Instanzen kriegen alle mit.
- Die Reihenfolge in der Schleife wird durch NTFY_ORDER bestimmt, erst alle Instanzen mit NOTIFYDEV, dann die ohne.
- Ein FileLog kann solche Events protokollieren, wenn in der beschriebenen Reihenfolge hinter dem notify kommt, z.Bsp. weil man ihn z_dumy_filelog nennt.

Ich gebe zu, das ist nicht anfaengerfreundlich, und ich will auch nicht garantieren, dass diese Reihenfolge fuer immer so bleibt. Ich rate deswegen auch zu userReadings oder zu einem sleep.

[justme1968]

zur commandref: es steht bei setreading und ist eigentlich nicht zu übersehen:

setreading

setreading <devspec> <reading> <value>

Set the reading <reading> for the device <name> to <value> without sending out commands to the device, but triggering events and eventMap/stateFormat transformations as usual. See the set command documentation for replacement description.

Examples:
setreading lamp state on
Note: setreading won't generate an event for device X, if it is called from a notify for device X. Use "sleep 0.1; setreading X Y Z" in this case.

[arneman]

zur commandref: es steht bei setreading und ist eigentlich nicht zu übersehen

Ich habe in der Doku bei notify gesucht. Vielleicht sollte man den Hinweis dort (auch) hinzufügen, zumal es eine Spezialität vom notify ist?!

Gruß

Arne

[arneman]

Um genauer zu sein:
- Wenn man auf Events fuer ein Geraet reagiert, und hier weitere Events fuer dieses Geraet generiert, dann wird fuer diese neuen Events nicht nochmal die Liste aller Interessenten aufgerufen, um Endlosschleifen zu vermeiden.
- Die neuen Events werden zu der Liste der alten Events hinzugefuegt, und die spaeter in der Schleife aufgerufenen notify/FileLog/WEB* Instanzen kriegen alle mit.
- Die Reihenfolge in der Schleife wird durch NTFY_ORDER bestimmt, erst alle Instanzen mit NOTIFYDEV, dann die ohne.
- Ein FileLog kann solche Events protokollieren, wenn in der beschriebenen Reihenfolge hinter dem notify kommt, z.Bsp. weil man ihn z_dumy_filelog nennt.

Ich gebe zu, das ist nicht anfaengerfreundlich, und ich will auch nicht garantieren, dass diese Reihenfolge fuer immer so bleibt. Ich rate deswegen auch zu userReadings oder zu einem sleep.

An Endlosschleifen hatte ich auch gedacht als Erklärung für dieses Verhalten   Zumal ein auf STATE Änderungen reagierendes notify ohne "addStateEvent 1" ja in der Standard-Definiton auf alle Events des Dummys reagiert. Somit auch auf die durch es selber gesetzten readings des dummys. Ich hab dies zunächst mit einer Plausi von $EVENT gelöst (Prüfung ob mehrere Teile oder nicht), bevor ich addStateEvent entdeckt habe.
Einfach plausibilisieren lässt es sich aber ja auch nicht, ob der User die Gefahr von dadurch entstehenden Endlosschleifen im Perl Code bedacht hat. Wobei es ja schon konsquenter wäre, wenn es zu einer Endlosschleife käme.

War echt ein schwieriger Weg, obwohl ich mich nicht als FHEM Anfänger bezeichnen würde.

Danke für die Antworten

Gruß

Arne

[rudolfkoenig]

Vielleicht sollte man den Hinweis dort (auch) hinzufügen, zumal es eine Spezialität vom notify ist?!

..und Spezialitaet von DOIF und watchdog und FileLog und alles, was per NotifyFn reagieren kann, also aktuell 142 FHEM Module.