FW_directNotify?

[Talkabout]

Hallo zusammen,

ich suche gerade nach einer Möglichkeit aus PERL heraus das Aktualisierung eines Devices in FHEMWEB zu triggern. Versuche in PERL den state hin und her zu wechseln scheiterten, weil damit unschöne Seiteneffekte in meiner Konfiguration entstanden sind. Dann bin ich in der 01_FHEMWEB.pm auf die Funktion

FW_directNotify

gestoßen. Liesse sich damit ein Aktualisieren in FHEMWEB umsetzen? Welche Parameter erwartet die Funktion?

Danke!

Gruss

[Talkabout]

Hallo zusammen,

Thema hat sich erledigt. Mit folgendem Code wird das state Icon korrekt aktualisiert:

Code Auswählen Erweitern

my $rf = ($FW_room ? "&room=$FW_room" : "");
my ($allSets, $cmdlist, $txt) = FW_devState($name, $rf, ());
FW_directNotify($name, 'opened', $txt);

Gruss

[rudolfkoenig]

Die Parameter von FW_directNotify werden zu fhemweb.js/FW_doUpdate weitergereicht, falls bei der aktuellen FHEMWEB longpoll Verbindung Arg1 (Geraetename) sichtbar ist, d.h. im Raum ist. FW_doUpdate sucht nach HTML Elementen mit informId=Arg1. Falls das Element ein setValueFn hat, dann wird sie mit Arg2 aufgerufen, sonst wird das HTML-Element durch Arg3 ersetzt.

Was vergleichbares passiert auch bei Events, mit FW_directNotify kann man dem Frontend was mitteilen ohne Events.

[Talkabout]

Die Parameter von FW_directNotify werden zu fhemweb.js/FW_doUpdate weitergereicht, falls bei der aktuellen FHEMWEB longpoll Verbindung Arg1 (Geraetename) sichtbar ist, d.h. im Raum ist. FW_doUpdate sucht nach HTML Elementen mit informId=Arg1. Falls das Element ein setValueFn hat, dann wird sie mit Arg2 aufgerufen, sonst wird das HTML-Element durch Arg3 ersetzt.

Was vergleichbares passiert auch bei Events, mit FW_directNotify kann man dem Frontend was mitteilen ohne Events.

Hallo Rudi,

danke für die Erklärung.

Meine obiges Konstrukt ist mir etwas unsympatisch, da ich mir selber über FW_devStateIcon Daten vom Device holen muss und im schlimmsten Fall sogar noch Sonderbehandlungen einbauen müsste (für nicht-standard-Devices). Wäre es möglich das Update eines Devices im FHEMWEB zu triggern ohne wissen zu müssen was hintenrum passiert? Ich würde mir sowas vorstellen wie:

FW_triggerUpdate($def);

Dieser Befehl würde dann an FHEMWEB gehen wo das Device gesucht wird. Wird es gefunden, triggert es von sich aus ein Update des States und passt die Ansicht an. Einerseits ist das ein bisschen hinten rum ins Auge, aber damit würde man das Aktualisieren sehr vereinfachen, und solche Konstrukte wie oben wären überflüssig.

Danke!

Gruss

[rudolfkoenig]

Mir ist unklar in welchem Fall ein FW_triggerUpdate sinnvoll ist.

Normalerweise erzeugen Geraete bei einer Statusaenderung ein Event, das wird dann an das Frontend weitergeleitet und angezeigt.
Fuer spezielle Geraete wie SVG/readingsGroup/etc gibt es FW_summaryFn oder FW_directNotify.

[Talkabout]

Mir ist unklar in welchem Fall ein FW_triggerUpdate sinnvoll ist.

Normalerweise erzeugen Geraete bei einer Statusaenderung ein Event, das wird dann an das Frontend weitergeleitet und angezeigt.
Fuer spezielle Geraete wie SVG/readingsGroup/etc gibt es FW_summaryFn oder FW_directNotify.

Hallo Rudi,

vielleicht erkläre ich meinen Use-Case damit die Anforderung etwas klarer wird:

Ich habe bei mir Fensterkontakte, die beim öffnen eines Fensters alle 20 Minuten per Sprachausgabe darauf hinweisen, dass man nicht vergessen sollte das Fenster wieder zu schliessen. Nun ist es so, dass man diese Erinnerung natürlich nicht immer haben möchte. Daher habe ich per benutzerdefiniertem Kommando am Fenster und "cmdalias" eine Funktionalität eingebaut, dass beim Klick auf das Status-Icon des Fensters ein Attribut getoggelt wird, welches dann die Sprachausgabe regelt. Dieses Attribut hat dann auch Einfluss auf das State Icon. Ist es auf "1", dann ist das Icon rot, ist es auf "0" ist es grün. Dazu muss ich, wenn ich das Attribut per Klick ändere, natürlich die Ansicht in FHEMWEB aktualisieren (Farbe des Icons ändert sich). Dies habe ich wie oben beschrieben gelöst, indem ich FW_directNotify ausführe. Das funktioniert soweit auch, allerdings finde ich es unschön, dass man dafür als FHEM Benutzer wissen muss, wie man an die Icon-Darstellung für ein Device kommt (FW_devStateIcon). Angenehmer wäre es, wenn ich einfach ein FW_triggerUpdate mit Device-Namen ausführen könnte, und FHEMWEB kümmert sich um den Rest. Damit wäre eine Aktualisierung der Device-States in jedem Kontext unproblematisch, da FHEMWEB ja genau weiss, was es in FHEM abholen muss.

Ich habe im Forum keine Anforderung gefunden, die meiner ähnelt, vielleicht ist es daher ein Sonderfall und eine Änderung von FHEM unnötig. Die Entscheidung dazu möchte ich auch gar nicht forcieren, es war lediglich eine Idee, die aufgrund meiner Anforderung hoch kam. Sollte der Bedarf nicht da sein, ist es auch ok

Gruss

[rudolfkoenig]

Dazu muss ich, wenn ich das Attribut per Klick ändere, natürlich die Ansicht in FHEMWEB aktualisieren

Sowas kriegt man auch mit

{ fhem "trigger Fenster ".Value("Fenster") }

hin.

Ich finde dein Fall sehr speziell (ich haette es mit einem weiteren dummy geloest), und ich befuerchte, dass eine richtige Unterstuetzung attributabhaengiger Statusbilder Aerger/Arbeit bedeutet.
Wenn aber sonst jemand noch meint, dass ein FW_triggerUpdate sinnvoll sei, werde ich es einbauen.

[Talkabout]

Sowas kriegt man auch mit hin.

Ich finde dein Fall sehr speziell (ich haette es mit einem weiteren dummy geloest), und ich befuerchte, dass eine richtige Unterstuetzung attributabhaengiger Statusbilder Aerger/Arbeit bedeutet.
Wenn aber sonst jemand noch meint, dass ein FW_triggerUpdate sinnvoll sei, werde ich es einbauen.

Hallo Rudi,

ja, das trigger hätte funktioniert, allerdings habe ich ein Notify auf den Fensterkontakten, die beim Triggern ebenfalls per Sprachausgabe mitteilen, dass ein Fenster geöffnet wurde. Daher kommt das nicht in Frage, da sonst unnötig eine falsche Benachrichtigung aus dem Lautsprecher kommt

Ich finde Deinen Kompromiss sehr gut. Wenn eine solche Anforderung wieder kommt, wird es eingebaut.

Danke Dir!

Gruss