Events aus X_Notify() heraus erzeugen

[Loredo]

Hi,


gibt es eine Möglichkeit, dass man den Loop-Schutz umgehen/überstimmen kann?
Bei der Entwicklung von 98_powerMap werden in X_Notify() die Events der unterschiedlichen Devices ausgewertet, um dann wiederum 2 weitere Readings im selben Device zu aktualisieren, welches die Eventkette ausgelöst hat. Die beiden Readings sind in X_Notify() entsprechend abgefangen, so dass kein Loop entstehen kann.


Allerdings wird das Event nach Aufruf von readingsEndUpdate() nicht so ganz richtig erzeugt. Die aktualisierten Readings tauchen zwar im Eventmonitor auf, aber die Ansichten werden nicht über Longpoll aktualisiert. Außerdem werden dadurch die Events auch nicht per FileLog geloggt, was ausgerechnet bei diesen zwei Readings eigentlich Sinn und Zweck der Aktion sein soll.


Wäre sehr dankbar, wenn das jemand näher erläutern und helfen könnte, wie man das gelöst bekommt.




Gruß
Julian

[gandy]

Hi, hast du dir mal dewpoint oder statistics angesehen, die machen evtl etwas ähnliches.

Grüße,
Andy.

[Thorsten Pferdekaemper]

Hi,
die übliche InternalTimer-Technik hilft da nicht?
Gruß,
  Thorsten

[Loredo]

Sowas mit InternalTimer zu lösen würde mir irgendwie widerstreben. Möchte ich eigentlich nur im Notfall so tun.


Mir ist aber auch aufgefallen, dass die Demo Umgebung von fhem.cfg.demo auch Probleme mit Updates hat. Wenn ich dort z.B. im Raum "Light" Living Room ein und aus schalten, dann wird der pct Schieberegler nur beim einschalten aktualisiert, jedoch nicht beim ausschalten. Vielleicht besteht also auch ein Zusammenhang mit den jüngsten Änderungen für Websockets.

[Thorsten Pferdekaemper]

Sowas mit InternalTimer zu lösen würde mir irgendwie widerstreben. Möchte ich eigentlich nur im Notfall so tun.

Was ist daran böse? FHEM erledigt das dann einfach sozusagen in der nächsten Runde. Ich denke auch, dass es für das Antwortverhalten des Systems insgesamt sogar besser ist.
Gruß,
   Thorsten

[rudolfkoenig]

Bei der Entwicklung von 98_powerMap werden in X_Notify() die Events der unterschiedlichen Devices ausgewertet, um dann wiederum 2 weitere Readings im selben Device zu aktualisieren, welches die Eventkette ausgelöst hat.

average/dewpoint machen was aehnliches, ohne das Problem zu haben, indem sie nicht die readings*Update Funktionen aufrufen, sondern die Readings direkt anlegen/modifizieren. Hat den Nachteil, dass die so erstellten Readings nicht fuer die event-* Attribute oder fuer stateFormat zur Verfuegung stehen.

Vielleicht besteht also auch ein Zusammenhang mit den jüngsten Änderungen für Websockets.

Auf welche Beweise stuetzt sich diese Hypothese?

[Loredo]

Hat den Nachteil, dass die so erstellten Readings nicht fuer die event-* Attribute oder fuer stateFormat zur Verfuegung stehen.

Eben drum.

Auf welche Beweise stuetzt sich diese Hypothese?

Das Wort "Vielleicht" sollte die Indikation geben, dass ich "Beweise" geliefert hätte, lägen mir solche vor oder hätte ich sonst irgendwelche Anstrengungen in diese Richtung unternommen.
Ich habe die Submissions dazu nicht durchgelesen, aber manchmal brauchen Menschen ja nur ein bestimmtes Stichwort, damit es ihnen "wie Schuppen von den Augen" fällt. Offenbar ist das hier nicht der Fall, was auch ok ist.

[Loredo]

Ich denke auch, dass es für das Antwortverhalten des Systems insgesamt sogar besser ist.

Bei einem 286er ohne Co-Prozessor hast du sicherlich Recht 
Ansonsten glaube ich nicht, dass das merklich ins Gewicht fallen würde (und auch nur unwesentlich messbar).

[Thorsten Pferdekaemper]

Bei einem 286er ohne Co-Prozessor hast du sicherlich Recht 
Ansonsten glaube ich nicht, dass das merklich ins Gewicht fallen würde (und auch nur unwesentlich messbar).

Kommt das nicht darauf an, welche Notifies wiederum an den abgeleiteten Readings hängen? Je nachdem wie viele das sind und was die treiben, kann das schon einen Unterschied machen. ...oder?

[Loredo]

Sicherlich messbar, aber bis das merkbar so wäre (im vierstelligen msec Bereich) müsste IMHO schon einiges passieren und es sich um eine riesige FHEM Installation handeln...


Man vergisst immer, dass auch die kleinen Prozessoren heutzutage so schnell sind, dass man die Loops nicht im menschen Gehirn gedanklich durchgehen kann. Da trügt das Gefühl oft, dass das so extrem viel wäre, weil man sich in seinen komplexen Quellcode verdenkt.


Aber da darf man gerne unterschiedlicher Auffassung drüber sein.

[Loredo]

Hallo Rudi,


ich bin nicht sicher, ob ich das essentielle aus den beiden genannten Modulen richtig herauslese.


Ich habe jetzt testhalber die Readings selbst direkt geschrieben. Die Notification Loop habe ich einfach entsprechend ergänzt, aber das scheint keinen Effekt zu haben.

Code Auswählen Erweitern



                $dev_hash->{READINGS}{$rname_p}{TIME} = $tn;
                $dev_hash->{READINGS}{$rname_p}{VAL} = $power;
                $dev_hash->{CHANGED}[$max++] = "$rname_p: $power";



Was fehlt denn da noch? Ich kann da im Grundsatz keinen Unterschied zu den Modulen dewpoint oder average erkennen...
Kann es sein, dass die Notification Loop noch mit der alten Anzahl an Änderungen läuft und wenn ja, wie müsste ich die wieder neu anstarten?




Gruß
Julian

[Markus Bloch]

Der Grund, warum das bei average so funktioniert, liegt in der Reihenfolge in der Events verarbeitet werden.

Das Modul average hat in der Initialize()-Funktion ein geändertes NotifyOrderPrefix gesetzt, so dass es bei der Verarbeitung von Events IMMER zuerst aufgerufen wird:

Code Auswählen Erweitern

$hash->{NotifyOrderPrefix} = "10-"

Dadurch kann es für die eventerzeugenden Geräte $hash->{CHANGED} mit zusätzlichen Events zu erweitern. Das Modul dewpoint nutzt das gleiche Schema. Das ganze ist im Wiki zu X_Notify() beschrieben: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify (Abschnitt: Reihenfolge für den Aufruf der Notify-Funktion beeinflussen)

Gruß
Markus

[Thorsten Pferdekaemper]

Sicherlich messbar, aber bis das merkbar so wäre (im vierstelligen msec Bereich) müsste IMHO schon einiges passieren und es sich um eine riesige FHEM Installation handeln...

Naja, ich weiß ja nicht, wie schnell Du was merkst, aber wenn ich auf eine Taste drücke, und das Licht geht erst 100ms später an, dann behaupte ich, da schon was zu merken. Für mich sind eigentlich nur Verzögerungen im zweistellugen ms-Bereich akzeptabel.

Man vergisst immer, dass auch die kleinen Prozessoren heutzutage so schnell sind, dass man die Loops nicht im menschen Gehirn gedanklich durchgehen kann. Da trügt das Gefühl oft, dass das so extrem viel wäre, weil man sich in seinen komplexen Quellcode verdenkt.

So ein bisschen Erfahrung habe ich schon in dem Geschäft. Ich weiß auch, dass es oft der einfach erscheinende Code ist, der Performance-Probleme bereitet.
Aber ich muss zugeben, dass mein Einwand eher prinzipieller Natur war und ich den konkreten Fall nicht weiter untersucht habe.

Gruß,
   Thorsten

[Loredo]

Okay verstehe. Dann bleibt mir für mein Modul aber wohl nur der Weg über den InternalTimer, da die Reihenfolge hier anders herum ist: Das Fremdmodul löst eine Statusänderung aus und diese dient als Trigger dafür den Stromverbrauchswert neu zu berechnen. Da hilft es leider nicht, wenn powerMap dann in der Priorität höher steht, denn es wird das erste Mal dadurch aufgerufen, dass das eben die Eventverarbeitung beim Fremdmodul gestartet ist. Gleichzeitig soll genau dieser Loop erweitert werden. DoTrigger() zählt aber in seiner eigenen Loop nur zu Beginn die Anzahl der Array Elemente und ignoriert daher Änderungen, die während der Loop Verarbeitung gemacht werden. Habe noch nicht ausprobiert, ob man DoTrigger() dahingehend erweitern kann, aber ich vermute das wäre auch nicht gern gesehen...

[Markus Bloch]

DoTrigger() zählt aber in seiner eigenen Loop nur zu Beginn die Anzahl der Array Elemente und ignoriert daher Änderungen, die während der Loop Verarbeitung gemacht werden.

Das ist zwar korrekt, aber kein Problem. DoTrigger() ermittelt zu beginn die Anzahl der Elemente in $hash->{CHANGED} für die Logmeldung, sowie der Prüfung, ob überhaupt Änderungen in CHANGED enthalten sind. Anschließend werden sämtliche NotifyFn's für alle entsprechenden Empfängerdefinitionen ausgeführt. Diese können dann CHANGED manipulieren (wie bspw. average/dewpoint).

Sobald alle NotifyFn's durchgeführt sind, wird in fhem.pl Zeile 3231 die Anzahl neu bestimmt um dafür die Events für den Inform-Mechanismus (Longpoll) zu erstellen.

Gruß
Markus