Manuell getriggerte Logik nicht über return_next() ermittelbar?

[Robert]

Hallo Robert,

Schaffst Du mit logic.foo=xxx einen persistentes Attribut was die items (soweit ich verstanden habe) nicht zulassen? Ist logic an dieser Stelle durch den Namen der Logik zu ersetzen oder bleibt es bei logic?
Ähnlich dem plugin_info beim WireGate, eben nur nicht Neustart resistent? Müsste doch auch mit item gehen?

Dank und Gruß
Mirko

Ja.
logic - so wie auch logic.name oder logic.trigger
Geht auch mit Items so wie allen anderen Python-Objekten.
<itemname>.conf["<attribut>"] greift auf die in der item.conf definierten Attribute zu (nicht alle, wie type - siehe item.py)
oder selber erstellen mit <itemname>.foo
Aber hier gilt: wenn ihr hier was sh.py-relevantes überschreibt droht der Crash oder zumindest extrem schwer zu findende Fehler. Da gibt es kein Netz und keinen doppelten Boden.

[mode]

Hallo Robert,

du hast mein Beispiel genau richtig verstanden. Eigentlich bräuchte ich die Logik nicht noch einmal Triggern wenn ich mit item.timer() arbeiten würde.

Erweitern wir das Beispiel aber mal so dass nicht einfach die Heizung ausgeschaltet werden soll, sondern eine weitere Logik Logi_Heiz gestartet wird, die dann entscheidet ob die Heizung ausgeschaltet werden soll.

Dann hat man imho 2 Optionen.
1) Man triggert die 2. Logik direkt und muss damit leben dass einmal getriggerte Logiken (dt) nicht überschrieben oder abgebrochen werden. Mit den Konsequenzen die ich oben beschrieben habe.
2) Man definiert ein Dummy Item nur um die item.timer() Methode nutzen zu können. Die 2. Logik hat dann ein watch_item auf das Dummy Item.

Gibt es ggfs. noch eine dritte Möglichkeit bei der auf das Dummy Item verzichtet werden kann und dennoch die terminiert getriggerte Logik unterbunden werden kann?

Mode