Prüft set, ob der Wert bereits gesetzt ist?

[fritz]

Guten Tag, FHEMler,

gibt es ein set-Kommando, mit dem man FHEM sinngemäß mitteilen kann: "Setze einen Wert, falls der nicht bereits gesetzt ist"?
Ich dachte an Statusanzeigen: es ist ja oft recht einfach, den Status - und die daraus resultierende Anzeigefarbe zu bestimmen, nicht aber unbedingt den gegenwärtigen Status (insb. wenn er von mehreren Faktoren beeinflusst werden kann).

Ich denke aber, ein solches Verhalten des set-Kommandos ist nur in wenigen Fällen sinnvoll - und ich werde das wohl in Perl implementieren...

Viele Grüße
<F>ritz

[Jamo]

Hallo Fritz,
so was gibt es schon, schau mal in der Commandref nach ,,FILTER",
damit kannst du z.b. set schalter:FILTER=STATE!=off off .
schalter wird nur augeschaltet falls er nicht schon aus war.

[fritz]

Hallo inoma,

Dank für Deine schnelle Antwort - ich habe mir das angesehen und festgestellt, dass ich meine Frage nicht präzise gestellt habe:

Ich habe mir eine Homematic-Statusanzeige geleistet, die mit den 2x8 LEDs. Und ich möchte die jetzt so ansteuern:
Links - Heizungsstatus (rot - Fehler (komplexe Bedingung Sensoren/Aktoren etc.), gelb - Heizung heizt - grün - Heizung heizt nicht, ist aber eingeschaltet - aus - Heizung aus) - und auf der rechten Seite den Status der Fenster im entsprechenden Raum (rot - Fenster länger als (konfigurierbar) 10 Min. offen und draußen ists kalt - gelb - Fenster offen (sonst) - grün - Fenster zu --  LED aus - Fehler am Fensterkontakt)
Es wird ohne Perl schon aufwändig, das zu prüfen - und wenn ich das Ergebnis dann habe, weiß ich im Programm natürlich nicht, ob das nicht schon der aktuelle Wert ist.
Ich möchte aber nicht bei jedem Ereignis für jede Anzeige den Wert versenden, insb. wenn der schon  der aktuelle ist, ich brauche ja mein Nachrichtenkontingent für wichtige Aktionen (Statusanzeige ist nicht wichtig    

Da mir dazu erst einmal keine FHEM-Lösung in den Kopf kommt, dachte ich daran, das als Perl-Funktion updateStatusDisplay (<gerätename>, functionarray) zu schreiben, in der das angegebene Display angesteuert wird und für die einzelnen Elemente die entsprechenden Funktionen aufruft, die dann den Zielzustand zu ermitteln haben. Und nun... wird die Perl-Funktion wohl selbst prüfen müssen, ob sich die LED ändern muss - und dann einen set absetzen - oder ob sich der Wert nicht ändert.

Naja, es geht wohl nicht ohne Selbermachen, wie immer

<F>ritz 

[amenomade]

Ich möchte aber nicht bei jedem Ereignis für jede Anzeige den Wert versenden, insb. wenn der schon  der aktuelle ist, ich brauche ja mein Nachrichtenkontingent für wichtige Aktionen (Statusanzeige ist nicht wichtig

Dann setzt die Werte in Readings von einem Dummy, und setzt event-on-change-readings auf dieses Dummy, und ein notify darauf.

Ansonsten ein DOIF. Der wird keinen Befehl senden, solange der Zustand sich nicht ändert.

[fritz]

Gute Idee, zumal ich eh' schon einen Dummy für jede Heizung habe. Schaue ich mir morgen mal an...

<F>

[betateilchen]

gibt es ein set-Kommando, mit dem man FHEM sinngemäß mitteilen kann: "Setze einen Wert, falls der nicht bereits gesetzt ist"?

Das set Kommando prüft auf jeden Fall, ob der zu setzende Wert ein anderer ist als der bisherige. Dementsprechen wird ein event ausgelöst oder nicht. Das kannst Du mit den Attributen event-on-change und event-on-update kontrollieren. Somit kannst Du entscheiden, ob Du auf jede Änderung oder auf jede Aktualisierung eines readings reagieren möchtest.

[fritz]

Das set Kommando prüft auf jeden Fall, ob der zu setzende Wert ein anderer ist als der bisherige. Dementsprechen wird ein event ausgelöst oder nicht. Das kannst Du mit den Attributen event-on-change und event-on-update kontrollieren. Somit kannst Du entscheiden, ob Du auf jede Änderung oder auf jede Aktualisierung eines readings reagieren möchtest.

• Ich gehe mal davon aus, Du meinst event-on-change-reading resp. event-on-update-reading, denn die anderen Attribute finde ich nicht in der CommandRef. Mit diesen habe ich schon für notify's  gearbeitet, deshalb sehe ich nicht, wie ich sie mit set in Verbindung bringen soll.
• Der Vorschlag mit dem Schatten-Display ist ganz gut, aber ich denke, sobald ich dafür sowieso Perl-Code schreiben muss, kann ich auch den Status vor der Aktion schnell testen.
• Aus der CommandRef folgt jedenfalls nicht, dass set einen zu setzenden Wert erst noch testet, was ich mir auch verbitten würde. Schließlich kann es ja sein, dass ein Gerät (ohne Rückkanal) eine Werteänderung nicht mitbekommen hat - und dann muss man in der Lage sein, das set zu wiederholen.

Das Display musste noch warten, zuerst einmal war die Heizungssteuerung familientauglich zu bauen

Aber der Punkt kann in meinen Augen geschlossen werden - kurz: set prüft nicht und es gibt auch keine Variante, die prüfend auf die Werte schaut. (Ich verstehe nur noch nicht, was betateilchen mit dem ersten zitierten Satz wirklich gemeint hat...)

<F>

[amenomade]

Er meint, dass "set" (by design) immer prüft, ob der zu setzende Wert ein anderer ist als der bisherige. Sonst wäre Fhem nicht in der Lage zu entscheiden, ob ein Event abhängig von event-on-change-reading und event-on-update-reading ausgelöst werden muss oder nicht.

set => Wert hat sich geändert?
   ja => event-on-change-reading?  => Event sonst kein Event.
   nein => event-on-update-reading? => Event sonst kein Event.

Deine Problematik ist aber ein bisschen anders. Aber wiederum: mit einem DOIF (bzw. mehere - 1 pro LED) sollte deine Statusanzeige steuerbar sein. Ein DOIF (ohne do always) sendet erst Befehle, wenn der Zustand sich ändert.

[fritz]

Danke. Ja, das ist nicht verkehrt an FHEM, dass die set-Werte (sonst auch Output genannt) wie Readings (sonst auch Input genannt) behandelt werden. Man muss aber etwas aufpassen, denn die Geräte unterscheiden schon streng danach. So habe ich z.B. bei einem Homematic-Thermostat versucht, die Solltemperatur (desired-temp) per set einzustellen. Das geht bis zum FHEM-Modul, aber das Gerät zeigt brav die dort eingestellte Solltemperatur an, eine Änderung (mit dem Stellrad) beginnt dann auch da. Aber das ist nicht weiter tragisch.

Was das DOIF Betrifft, sende ich Dir eine PN...

Viele Grüße - und Dank in die Runde (wobei mir meine noch nicht beantwortete Frage - https://forum.fhem.de/index.php/topic,78700.0.html - eigentlich wichtiger ist)
<F>

[justme1968]

also um der verbreitung von falscher information vorzubeugen:

nein. set prüft nicht ob ein zu setzender wert anders ist als der aktuelle. zumindest nicht generell. und auch die module an die das set weiter geleitet wird machen das meist nicht.

set hat auch erst mal nichts direkt mit den event-.* attributen zu tun.

um ein set bedingt auszuführen gibt es den oben schon angesprochenen devspec FILTER ausdruck.

[amenomade]

readingFnAttribute
Die folgenden Attribute werden bei Modulen verwendet, die standardisierte "readings" Aktualisierung der fhem.pl benutzen. Informieren Sie sich in der Liste der Modulattribute wenn Sie wissen möchten ob dies unterstützt wird

Ich dachte, es gilt für alle Modulen, die die Standard-Funktionen von der API https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Readings_.2F_Events nutzen. Anscheinend ist es aber doch nicht der Fall, da diese Funktionen selbst Parameter dafür haben, um die Events zu steuern. Na dann, danke für die Korrektur. Noch was gelernt

Kann man trotzdem davon ausgehen, dass diejenige, die readingFnAttribute implementieren, es ordentlich machen?

[herrmannj]

Ich dachte, es gilt für alle Modulen, die die Standard-Funktionen von der API https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Readings_.2F_Events nutzen. Anscheinend ist es aber doch nicht der Fall, da diese Funktionen selbst Parameter dafür haben, um die Events zu steuern. Na dann, danke für die Korrektur. Noch was gelernt

Kann man trotzdem davon ausgehen, dass diejenige, die readingFnAttribute implementieren, es ordentlich machen?

Es gibt da kein "ordentlich" oder "un-ordentlich".

Ob durch ein "set", oder das modul-interne setzen eines readings, dass erzeugen von events sinnvoll ist (oder nicht) hängt vom konkreten Zweck ab.

Beispiel:
Lichtschalter (taster) ist auf "on". Der Benutzer drück noch mal drauf. Status war "on" bleibt "on". Je nach (nachgeschalteter) Logik ist hier ein event "on" absolut wünschenswert. Das kann ich als Anwender benutzen um: die Farben durchzuschalten, Betriebsmode zu verändern ... whatever.

Thermometer steht auf "21.5°". Das modul empfängt ein Telegram vom Sender (Außenthermometer) ... "es ist 21,5°". Event ja ? Event nein ? Als Anwender Interessiere ich mich vielleicht nur für die Änderung der Temperatur, dann brauche ich kein event. Vielleicht möchte ich aber diese Bedingung mit der Luftfeuchte verbinden um zu wissen wann ich lüften kann ? Dann benötige ich das event.

Du sieht: es hängt ab von ...

[amenomade]

Mit "ordentlich" meinte ich: wo event-on-change / -update wie erwartet funktionieren.

Ich dachte, dass diese gesamte Logik nich Modul-abhängig sondern irgendwo im Fhem Kernel implementiert ist. Anscheinend ist es aber in einem Modul möglich, z.B. die Funktion readingsBulkUpdate aufzurufen, aber $changed dafür unabhängig von diesen Attribute zu setzen.

[justme1968]

die event-.* logik ist modul unabhängig und zentral implementiert. und sie funktioniert wie erwartet.

und sie hat überhaupt nichts direkt mit dem set kommando zu tun.

[amenomade]

Ja, hatte ich schon verstanden. Aber nehmen wir mal die Funktion readingsBulkUpdate:

$changed | optional
   Flag, ob ein Event für dieses Update erzeugt werden soll (Wert: 1). Oder ob definitiv kein Event erzeugt werden soll (Wert: 0). Wenn nicht gesetzt, wird aufgrund entsprechender Attribute in der Definition von $hash entschieden, ob ein Event zu erzeugen ist, oder nicht (Attribute: event-on-change-reading, event-on-update-reading, event-min-interval, ...)

Das heisst, der Modulentwickler kann die Attribute event-on-change/-update umgehen, indem er z.B. $changed = 0 forciert, oder? Genauso kannn er sich zwischen readingsBulkUpdate und readingsBulkUpdateIfChanged entscheiden?