Hi,
das es hier mit sh.py weitergeht, wollte ich mal etwas anregen, was mir schon lange im Kopf rumschwirrt, von dem ich aber nicht weiß, wie man es realisieren könnte.
Im Prinzip ist es ein Kombi aus threshold und eval_trigger.
Mit threshold gibt man ja an, wann ein Item triggern soll. Das ist meiner Meinung nach aber zu kurz gedacht. In den meisten Fällen will ich nicht dem triggernden Item (also der Quelle) sagen, wann es triggern soll, sondern beim getriggerten Item (also am Ziel).
Natürlich kann man dann versuchen, ein komplexes eval am Zielitem zu formulieren oder eben eine Logik schreiben. Würde man aber direkt am eval_trigger die Triggerbedingung formulieren können, dann würde man sich viele komplexe evals bzw. triviale Logiken sparen können.
Ein triviales Beispiel (mit bisherigen Mitteln):
Mit dem obigen Codeschnipsel kann ich beim Einschalten irgendwas machen, beim Ausschalten irgendwas anderes.
Gleiches Beispiel mit Bedingung im eval_trigger :
Über die Notation müsste man sich sicherlich noch Gedanken machen, ich sehe 2 naheliegende Varianten:
Variante 2 ist mächtig, aber man kommt da wieder in die python syntax rein, was es für Gelegenheitsbenutzer schwieriger macht.
Eine "Kür" wäre, wenn man auch noch den value des Triggers überschreiben könnte um einen eval komplett überflüssig zu machen, im obigen Beispiel:
Die angedachte Semantik: Trigger mich mit dem Wert 1 wenn das triggernde Objekt den Wert 0 hat.
Mir ist klar, dass diese Erweiterung den eval und die Logiken nicht ersetzen kann - soll sie aber auch nicht. Ich glaube, dass man aber hiermit weniger triviale Logiken bekommt und die Anzahl an Hilfsitems reduzieren kann.
Mir ist auch klar, dass das obige Beispiel trivial ist, ich habe aber gerade kein komplexeres parat. Wenn ich wieder mal über ein komplexeres Beispiel stolpere, werde ich es hier mal Posten.
Ich wollte das mal loswerden, vielleicht sieht noch jemand den Bedarf...
Gruß, Waldemar
das es hier mit sh.py weitergeht, wollte ich mal etwas anregen, was mir schon lange im Kopf rumschwirrt, von dem ich aber nicht weiß, wie man es realisieren könnte.
Im Prinzip ist es ein Kombi aus threshold und eval_trigger.
Mit threshold gibt man ja an, wann ein Item triggern soll. Das ist meiner Meinung nach aber zu kurz gedacht. In den meisten Fällen will ich nicht dem triggernden Item (also der Quelle) sagen, wann es triggern soll, sondern beim getriggerten Item (also am Ziel).
Natürlich kann man dann versuchen, ein komplexes eval am Zielitem zu formulieren oder eben eine Logik schreiben. Würde man aber direkt am eval_trigger die Triggerbedingung formulieren können, dann würde man sich viele komplexe evals bzw. triviale Logiken sparen können.
Ein triviales Beispiel (mit bisherigen Mitteln):
Code:
[Button]
type = bool
name = Tastendruck
[OnTrue]
type = bool
name = Mach was beim Einschalten
enforce_updates = true
eval = 1 if value == 1 else None
eval_trigger = Button
[OnFalse]
type = bool
name = Mach was beim Ausschalten
enforce_updates = true
eval = 1 if value == 0 else None
eval_trigger = Button
Gleiches Beispiel mit Bedingung im eval_trigger :
Code:
[Button]
type = bool
name = Tastendruck
[OnTrue]
type = bool
name = Mach was beim Einschalten
enforce_updates = true
eval_trigger = Button [COLOR=#0000FF]== 1[/COLOR]
[OnFalse]
type = bool
name = Mach was beim Ausschalten
enforce_updates = true
eval = 1
eval_trigger = Button [COLOR=#0000FF]== 0[/COLOR]
- Wert < Item < Wert bzw. Item == Wert (oder wie bisher nur Item ohne Vergleich)
- Kompletter boolescher Ausdruck in python syntax
Variante 2 ist mächtig, aber man kommt da wieder in die python syntax rein, was es für Gelegenheitsbenutzer schwieriger macht.
Eine "Kür" wäre, wenn man auch noch den value des Triggers überschreiben könnte um einen eval komplett überflüssig zu machen, im obigen Beispiel:
Code:
[OnFalse]
type = bool
name = Mach was beim Ausschalten
enforce_updates = true
eval_trigger = Button[COLOR=#0000FF](1) == 0[/COLOR]
Mir ist klar, dass diese Erweiterung den eval und die Logiken nicht ersetzen kann - soll sie aber auch nicht. Ich glaube, dass man aber hiermit weniger triviale Logiken bekommt und die Anzahl an Hilfsitems reduzieren kann.
Mir ist auch klar, dass das obige Beispiel trivial ist, ich habe aber gerade kein komplexeres parat. Wenn ich wieder mal über ein komplexeres Beispiel stolpere, werde ich es hier mal Posten.
Ich wollte das mal loswerden, vielleicht sieht noch jemand den Bedarf...
Gruß, Waldemar

