eval_update_item - Update auf fremde Items

[Tom Bombadil]

Im eval darf man übrigens auch den Wert von anderen Items setzen, man könnte also folgendes machen:

[[boost]]
  type = bool
  visu_acl = w
  autotimer = 25 = 0
[COLOR=#FF0000]  eval = sh.kwl.level(204)[/COLOR] if value else sh.kwl.level(sh.kwl.level_alt())
[[level]]
  type = num

Das ist tatsächlich ein brauchbarer Ansatz. Da das eval oft für die eigentliche/tatsächliche Evaluierung gebraucht wird, müsste man das Setzen des fremden Items vermutlich zwar wieder in ein Hilfsitem verschieben (oder eben ggf. in mehrere, siehe Kommentar von dafra). Aber es sollte funktionieren:

[item1]
  type = num
  eval = __import__('math').ceil(sh.ventilation.booster.time_remaining()/60)

  [[item1_hilfsitem]]
    type = foo
    eval = sh.fremdes_item(sh.item1())
    eval_trigger = item1

Das eval hab ich mal aus einem meiner aktuellen Items genommen, funktioniert so. Das Hilfsitem würde also die verbleibenden Minuten der Stoßlüftung in 'fremdes_item' schreiben ...

/tom

[smai]

Nun hab' ich aber auch noch was gelernt: __import__('math'). Ich bin vor einiger Zeit gescheitert und fast verzweifelt beim Versuch, math in eval zu verwenden bzw. importieren.

Dein Hilfsitem liesse sich übrigens noch minim optimieren, indem du anstelle von sh.fremdes_item(sh.item1()) schreibst sh.fremdes_item(value).
So vermeidest du die doppelte Referenz auf item1.

Aber wie bereits erwähnt, müsstest du das doch auch so lösen können:

[item1]
  type = num
  eval = __import__('math').ceil(sh.ventilation.booster.time_remaining()/60)
​​​​​​​[fremdes_item]
  type = num
  eval = value
  eval_trigger = item1

Oder wenn mehrere Items auf fremdes_item übertragen werden sollen:

​​​​​​​[item1]
  type = num
  eval = __import__('math').ceil(sh.ventilation.booster.time_remaining()/60)
​​​​​​​[item2]
  type = num
  eval = foo_bar()
​​​​​​​[fremdes_item]
  type = num
  eval = value
  eval_trigger = item1 | item2

[wvhn]

An der Lösung des jetzt zitierten Threads war ich auch ein bisschen beteiligt. Deshalb klinke ich mich hier mal ein.

Ein KNX-System im Haus muss auch funktionieren, wenn Smarthome nicht läuft. Das Geniale an Smarthome mit KNX-Plugin ist, dass das Haus der Master ist und gerade eben nicht nur die "Bande". Dies mag für andere Schnittstellentypen anders sein. Darum sollten sich meiner Ansicht nach die jeweiligen Plugins kümmern. Denen steht es frei, ähnliche Variablen zur Kommunikation (xxx_listen, xxx_send ...) zur Verfügung zu stellen.

Das Schreiben in fremde Items ist mir nicht sonderlich sympathisch, weil es die Komplexität erhöht. Mir ist wesentlich lieber, wenn die mit dem Bus kommunizierenden Items ihre Bedingungen ziehen und alles zu einem Item an einer Stelle übersichtlich und strukturiert zu finden ist.

Ich glaube, dass wir schon einige Verbesserung erreichen würden, wenn wir die eval-Syntax und auch den Aufbau der Items (s. Hinweis von smai zur Item-Struktur im letzten Post) in der Doku besser erläutern würden. Mit meinem Halbwissen musste ich schon sehr lange suchen und knobeln, um auf eine funktionierende Lösung zu kommen, die bei weitem nicht optimal war, wie smai mal eben locker aufgezeigt hat. Es wäre toll, wenn sich einer der "Cracks" der Doku annehmen könnte. Ich wäre auch bereit, dies als Sammlung von Aufzeichnungen/Hinweisen entgegen zu nehmen und ins Wiki zu gießen.

Gruß Wolfram

[rscde]

ich hätte eine Frage zum eval_trigger (in smarthomeNG):

wenn ich Inhalte eines anderen Items in eval_trigger abfragen möchte, ist dann folgende Syntax richtig?

eval_trigger = kitchen.light.wall | kitchen.light.seiling | dinning.light.seiling

oder muss es heissen

eval_trigger = sh.kitchen.light.wall | sh.kitchen.light.seiling | sh.dinning.light.seiling


bei der Version smarthome.py gings ohne sh vorneweg,
nach dem update auf smarthomeNG funktioniert dies nicht mehr

[smai]

Zusammengefasst könnte man sagen:
Im eval darf man eine beliebige Python Expression verwenden. Diese wird an die Python-Funktion eval übergeben. Falls der Code einen Wert zurück gibt, wird dem Item dieser Wert zugewiesen (andernfalls wird eine Warnung geloggt).

Für die Struktur gibt es leider keine absolute Wahrheit, die hängt sehr von den Gegebenheiten und dem persönlichen Geschmack ab.
Man könnte da höchstens ein paar Beispiele oder best practices aufführen.

wvhn ich wollte deine Lösung übrigens nicht schlecht machen - Code kann man (fast) immer optimieren. Solange es korrekt läuft, ist ja schonmal gut.
Das gilt ja selbst für eigenen Code, wenn man den vielleicht ein paar Tage später mit etwas Distanz nochmal anschaut.

rscde es muss heissen kitchen.light.wall

[rscde]

schade.

[Tom Bombadil]

Für die Struktur gibt es leider keine absolute Wahrheit, die hängt sehr von den Gegebenheiten und dem persönlichen Geschmack ab.
Man könnte da höchstens ein paar Beispiele oder best practices aufführen.

Das würde ich so unterschreiben. Wie z.B. die Posts von Ivan und Daniel gezeigt haben, bin nicht der einzige, der schon mal auf das "Schreib"Problem gestossen ist (Ivan hat sogar ziemlich viel Arbeit investiert und extra eine Logik dafür geschrieben).

Daher halte ich den ursprünglichen Vorschlag nach wie vor für ein vernünftiges Feature. Aber wir haben ja jetzt einen funktionierenden Workaround - dieser wird zumindest mir unter den gegebenen Umständen (bestehende Item-Struktur, vorhandene Technik, kein KNX) einiges an Logiken und komplexen eval's ersparen ...

/tom

[Msinn]

wenn ich Inhalte eines anderen Items in eval_trigger abfragen möchte, ist dann folgende Syntax richtig?

eval_trigger = kitchen.light.wall | kitchen.light.seiling | dinning.light.seiling

Ja, das hat sich beim Übergang vin smarthome.py zu SmartHomeNG nicht geändert.