Ablauf von bei Start von shNG oder Wertzuweisungen bei einem Item

[Sisamiwe]

Hallo,

ich beschäftige mich gerade mit dem Ablauf bei Items sowohl bei Start von shNG als auch bei Wertzuweisungen.

Hier habe ich folgendes gefunden: Danke am mumpf

Der Ablauf ist folgendermaßen (nur plakativ, den genauen Ablauf müsste man im Coding nachvollziehen):

• Das Item bekommt einen neuen Wert gesetzt (durch knx, 1-Wire, durch eine Logik oder sonst irgendwas).
• Dieser Wert wird in die variable "value" geschrieben
• Es wird geschaut, ob ein eval existiert, falls nein, wird eval = value angenommen.
• jetzt wird eval(value) ausgeführt
• Das Ergebnis vom eval wird ins Item geschrieben
• jetzt wird noch geschaut , ob der neue Wert anders ist als der alte oder ob enforce_updates = true ist, falls eines zutrifft, werden abhängige Logiken getriggert.

Der obige Ablauf zeigt, dass ein eval IMMER vor dem setzen des Items läuft, aber auch, dass man "value" im eval abfragen kann. Oder noch anders gesagt: Wenn der eval läuft, dann können die Werte vom "value" und vom Item, in dem der eval läuft, durchaus unterschiedlich sein!

Was in obigen Ablauf noch fehlt, sind initial_value, cache, und database.
In welcher Reihenfolge wird das abgearbeitet?

Hintergrund: Mich "nerven" die nichtausführbaren Evals am Start, da die Items, die im Eval verwendet werden, noch keinen Wert haben. Nun versuche ich das zu umgehen.

Wer kann die Reihenfolge komplettieren?
Wäre das nicht auch was für die Doku?

Danke Euch.

[Msinn]

Der obige Ablauf zeigt, dass ein eval IMMER vor dem setzen des Items läuft, aber auch, dass man "value" im eval abfragen kann. Oder noch anders gesagt: Wenn der eval läuft, dann können die Werte vom "value" und vom Item, in dem der eval läuft, durchaus unterschiedlich sein!

Das ist so nicht richtig, da wenn das eval läuft das Update des Items noch aussteht.

Wenn der eval läuft, dann können die Werte vom "value" und vom Item, in dem der eval läuft, durchaus unterschiedlich sein!

Das ist Absicht. Mich hatte das anfangs auch verwirrt, aber damit hat man im eval Ausdruck auf den alten Wert des Items zuzugreifen, was eine Reihe von Usern auch intensiv nutzt.

Wer kann die Reihenfolge komplettieren?
Wäre das nicht auch was für die Doku?

Das Thema ist in Summe um einiges komplexer als Du es dargestellt hat, auch wenn Du mit

Was in obigen Ablauf noch fehlt, sind initial_value, cache, und database.

dort Themen hineinmischst, die mit den eval Ablauf überhaupt nichts zu tun haben.

Über den Rahmen der Anwender Doku geht das was Dir vorschwebt weit hinaus. Selbst für die Anwenderdoku ist das nicht unbedingt etwas, da die Interna von lib.item eigentlich nur für Core-Entwickler von Interesse sind.

evals werden erst ausgeführt, wenn die Initialisierung von SmartHomeNG abgeschlossen ist. Es gab nur (von Anbeginn der Zeiten) einen Bug, der hier im Forum auch diskutiert wurde: Einige Scheduler wurden bereits vor Abschluss der Initialisierung gestartet. Das konnte in der Folge auch zur Ausführung von evals führen, wenn die Trigger des Items von einem solchen Scheduler abhingen. Diser Bug ist im Develop im März vergangenen Jahres gefixt und der Fix wird mit v1.7 generell verfügbar.