Nutzung/Bedeutung von Value in eval Ausdrücken

[mumpf]

Ich würde es bleiben lassen. Ich kenne den Quellcode, smai nicht.

Hi Martin,

da würde ich gerne kurz rückfragen: Temp wird von Temp_dict getriggert, somit hat value doch den Wert von Temp_dict, oder? Solange Temp nicht direkt beschrieben oder noch von einer weiteren Quelle getriggert wird, sollte das doch wie gewünscht funktionieren, oder?
Natürlich ist Dein Vorschlag stabiler und ich würde auch empfehlen, es so zu machen, aber mich interessiert, ob sich am value-Handling grundsätzlich was geändert hat, da ich in den Weihnachtsferien in shNG (wieder-) einsteigen wollte.

Gruß, Waldemar

[Msinn]

So ist value aber nicht definiert. Wenn das so als Seiteneffekt funktioniert, ok. Es führt aber schon zu Verwirrung, wenn mehrere Items als Trigger angegeben werden. Welchen Wert soll Value dann annehmen?

[smai]

So ist value aber nicht definiert.

Wie ist value bei eval_trigger denn definiert?
Ich bin bisher davon ausgegangen, dass dies genau so gewollt ist. Woher ich das hatte, weiss ich ehrlich gesagt nicht mehr.
Jedenfalls verwende ich das erfolgreich in diversen Items (in meinen Fällen als simple Werte und nicht als dict, aber das spielt ja keine Rolle).

Ich habe mich nun auch mit dem Quellcode bekannt gemacht, und es passt IMHO schon:
In item.py wird in __update smarthome.trigger unter anderem mit dem Wert des Trigger-Items als Argument aufgerufen.
Dies bewirkt dann in scheduler.py einen Aufruf von __run_eval des Ziel-Items mit dem Wert als Argument (also das Gleiche, wie wenn das Item selbst ohne eval_trigger einen neuen Wert gesendet erhalten würde).
Und in item.py wird dann das eval ausgeführt und dabei 'value' durch den erwarteten Wert ersetzt.

Value nimmt übrigens jeweils den Wert des triggernden Items an, auch wenn mehrere Items als Trigger angegeben wurden. Funktioniert also auch dann nachvollziehbar und kann durchaus nützlich sein.

Auch wenn das bisher anscheinend nur ein ungeplanter und undokumentierter Seiteneffekt war, würde ich dies an deiner Stelle als Feature betrachten und dokumentieren.

[mumpf]

Hi,

ich war seit den Anfängen von sh.py (noch ohne NG) dabei, und damals stand in einer Kurzdoku von Marcus exakt dieses Verhalten: value hat den Wert (und den Typ) des triggernden Objektes (wobei hier die triggernden Items nur ein Fall sind, es gibt ja noch die trigger-Values bei autotimer, crontab, etc. und die Wertänderung des Items selbst). Im Prinzip enthält value also den neuen Wert, der durch eval noch geändert werden kann.

Ich weiß, dass es inzwischen eine Option gibt, dass value vom Typ des Zielitems ist (was ich als Einschränkung der Möglichkeiten empfinde, aber es geht ja noch das alte).

Ich hatte nur nachgefragt, weil ich wissen wollte, ob sich noch was anderes geändert hat oder geplant ist.

Gruß, Waldemar

[Msinn]

Das hatte ich in der Doku von mknx so nicht gefunden. Dann würde ein Counter der Form eval: value+1 nicht funktionieren, zumal wenn das oder die Trigger Items von beliebigen Datentypen sind.

Ich halte das Verhalten (zumal bei mehreren Triggern) eher für verwirrend.

[Msinn]

Wenn ein solches Verhalten gewünscht ist, sollte es auch zur Erzeugung von Klarheit über eine weitere Variable implementiert werden. Ich könnte mir vorstellen, dass ausse **value** noch ein **trigger** eingeführt wird. Dann gibt es kein vertun und jeder kann es nach seiner Facon nutzen.

[smai]

Ich verstehe nicht ganz, weshalb du eine neue Variable einführen willst, wenn die bestehende ja genau das gewünschte Verhalten zeigt.

value ist ja immer der neu erhaltene Wert, nicht der bestehende Wert des Items mit dem eval. Ein Counter funktioniert also eh nicht so.

value+1 funktioniert, aber natürlich nur, wenn das triggernde Item auch nummerisch ist.
Ob dieser Wert nun von einem eval_trigger oder aus einer Logik oder z.B. dem KNX-Plugin stammt, spielt ja keine Rolle. In all diesen Fällen muss man ja sicherstellen, dass der Datentyp zum eval-Ausdruck passt.

[Msinn]

Weil value in allen anderen Zuständen sind auf das Item selbst bezieht und nicht auf ein anderes Item.

[smai]

Wenn ich beim eval "or" oder "min" usw. angebe, bezieht sich das ja ebenfalls auf die Werte der Items aus dem eval_trigger.

value bezieht sich immer auf den neu erhaltenen Wert des Items.
Bei Aufruf von sh.mein.item(xy) in einer Logik stammt dieser z.B. von dieser Logik, beim KNX-Plugin vom Plugin bzw. dem Bus und bei Verwendung eines eval_triggers halt aus einem anderen Item.
Das Item selbst erhält ja dann erst das Resultat des evals als Wert zugewiesen.

[mumpf]

Hi Martin,

Du hast Dich bereit erklärt, das Projekt weiter zu treiben, insofern ist es Deine Entscheidung, wie es hier weiter geht.

Um es aber besser zu verstehen: Was ist denn "value" für Dich? Wie hast Du es verstanden (ich habe nochmal geschaut, aber die oben erwähnte Kurzdoku finde ich nicht mehr, kann meine Behauptung also nicht belegen).

Ich fand es nicht verwirrend: Ein Item soll geändert werden, das kann von mehreren Quellen aus passieren (direkter Setter, eval_trigger, autotimer, crontab, etc.). Bevor der Wert übernommen wird, kann man noch eingreifen (eval). Der neue Wert steht in value. Das einzige, worauf man achten muss, ist der Datentyp, man muss also einen cast selber machen. Wenn man kein eval macht, wird value zum Zieldatentyp "gecastet" und das Item entsprechend verändert. Trigger (hier meine ich explizit eval_trigger) wurden genau so verarbeitet, waren aber nicht Item-Verändernd ohne einem expliziten eval, denn das war eher Erwartungskonform.

Das obige Bild fand ich einleuchtend. Mich würde interessieren, was für ein "Bild" Du im Kopf hast. Ich frage deswegen, weil ich über 4500 Items von callidomus nach shNG.py überführen will und durchaus viele Items mit eval und mehreren Triggern habe, die auf value reagieren, da ich genau den Wert des triggernden Items für die Auswertung haben will. Wenn shNG hier anders funktioniert (bisher scheint es nicht so) oder anders funktionieren wird, dann ist das für mich durchaus mit Arbeit verbunden.

Deine Frage zu **value** und **trigger** wäre einfacher zu beantworten, wenn man weiß, was für ein Bild Du hast.

Gruß, Waldemar

PS: Ich habe zu lange für die Antwort gebraucht, smai war viel schneller...

[Msinn]

Das Item hat ja auch vorher einen Wert, auf den ich dann aber nur zugreifen kann wenn ich das Item selbst mit sh.<...>() in dem Ausdruck nutze.

[mumpf]

Sehe das genau so wie smai: value ist der neue (nächste) Wert, hat mit dem Item (noch) nichts zu tun.

[mumpf]

Das Item hat ja auch vorher einen Wert, auf den ich dann aber nur zugreifen kann wenn ich das Item selbst mit sh.<...>() in dem Ausdruck nutze.

Genau!

Das war schon immer so. Das macht auch Sinn. Auf den alten Wert kann man so zugreifen, auf den neuen aber nicht, denn man weiß nicht, woher der kommt. Deswegen gibt es das value eigentlich. Es ist NICHT eine abkürzende Schreibweise für den aktuellen Wert.

Gruß, Waldemar

[Msinn]

mumpf Ich bin da offen. Ich hatte es bisher in der Doku die ich gelesen hatte nur anders verstanden: value bezieht sich auf den Wert des Item (bei der Vorbelegung in der items.yaml, in eval Ausdrücken (zumindest in on_update / on_change).

Es geht letztlich darum eine deutliche Dokumentation zu haben, die beschreibt wie es funktioniert.

[mumpf]

Hi Martin,

on_update / on_change ist ja neu, so wie ich das verstanden habe, hast Du das neu zugefügt. Und das hast Du natürlich mit Deinem Verständnis von value gemacht, was auch gut ist. Passt au, denn bei on_update / on_change wurde das Item ja geändert, hat einen neuen Wert soll seinen Wert in andere Items rein schreiben. In diesem Kontext macht es Sinn, dass value den Wert des Quell-Items hat, und zwar auf beiden Seiten: Im on_update/on_change hat es dann den selben Wert wie im eval des Empfänger-Items. Aus meiner Sicht passt das perfekt. Technisch bräuchte es keinen value bei on_update/on_change, da man ja an den Itemwert mit sh.<...>() kommt und an den vorherigen Wert mit sh.<...>.lastvalue().

Und das value in der item.conf bzw. item.yaml: Auch wenn es gleich heißt (was zugegebenermaßen unglücklich ist), ist das ja ein Attribut eines Items und nicht eine echte Laufzeitvariable von Python, was ja die anderen "value" sind.

Technisch (mal unabhängig vom Namen) braucht man beim bisherigen eval eine Variable, die den neuen Wert bereits trägt, ohne dass das Item mit diesem Wert bereits verändert wurde.

So gesehen hast Du Recht: Man muss es passend dokumentieren. Aus meiner Sicht spricht nichts dagegen, value kontextabhängig zu betrachten. Will man neue Variablen, musste man eigentlich 3 neue erfinden: current_value (für on_update/on_change), new_value (für eval) und defalut_value (für item.yaml). Dann müsste man noch überlegen, ob man alle bisherigen User Anpassungen machen will oder trotzdem noch value in seinen multiplen Bedeutungen beibehalten will.

Ich bin für das bisherige value (kontextabhängige Betrachtung) und passender Doku. Aber wie gesagt, Du machst es, also bestimmst Du auch...

Gruß, Waldemar