- √ - Die innere Uhr: UTC/CEST Debugging

[2ndsky]

PS: Die Funktion des Schedulers in SH.py würde mich immer noch interessieren, vielleicht hat Marcus ja ein wenig Zeit das zu erläutern...

Was interessiert dich da genau? Der scheduler macht eigentlich nichts anderes, als das du ihm sagen kannst, wann er eine bestimmte Funktion mit welchem Wert aufrufen soll. Das kann nun eine Logik sein, das Setzen eines Item Wertes oder eine eigene Funktion innerhalb eines Plugins. Der scheduler sorgt dann dafür, dass die Funktion zu der Zeit aufgerufen wird und das genügend Workerthreads vorhanden sind. Nicht mehr und nicht weniger.

[chriscrown]

Ich meine so etwas:

2014-06-19 15:44:48,953 DEBUG    Scheduler    env_stat next time: 2014-06-19 15:49:48+02:00 -- scheduler.py:_next_time:289

oder:

2014-06-19 16:09:39,924 DEBUG    Scheduler    env_loc next time: 2014-06-19 16:39:39+02:00 -- scheduler.py:_next_time:289

oder:

2014-06-19 16:09:36,772 DEBUG    Scheduler    eBusd next time: 2014-06-19 16:13:36+02:00 -- scheduler.py:_next_time:289

Kann man das so verstehen, dass der Scheduler immer zu diesen Zeiten env_stat, env_loc und ebusd aufruft? Wo wird denn z.B. festgelegt, wie oft diese (fest eingebauten) Logiken aufgerufen werden? Bei den eigenen Logiken wird dann der Scheduler durch so etwas wie crontab konfiguriert!?

Und wie funktioniert das mit eval_trigger? Ändert der Scheduler das überwachte Objekt und eval_trigger wird dann benachrichtigt (so Observer-Pattern-mäßig?), oder pollt eval_trigger die ganze Zeit auf dem überwachten Objekt (und wenn ja, wie ist das Polling-Intervall)?

[2ndsky]

Ich hab jetzt keine Zeit im Code nach zu sehen, wo genau das definiert wird. Bei wiederkehrenden unregelmäßigen Item Änderungen, gibt man dem Scheduler nicht das Item selber, sondern eine Funktion an. Der Scheduler triggert diese Funktion zum angegebenen Zeitpunkt. In der Funktion ändert man nun das Item, berechnet gleichzeitig den nächsten Zeitpunkt und übergibt diesen wieder an den Scheduler. Daraufhin erscheinen dann die Log Meldungen, wenn eine Funktion das nächste mal getriggert wird.

Als Besonderheit kann der Scheduler aber auch mit crontab und cycle umgehen. Man kann also den exakten Zeitpunkt angeben und den nächsten dann selber berechnen, so wie ich z.B. im UZSU Plugin, oder man nutzt crontab oder cycle für wiederkehrende Aufrufe.

eval_trigger ist nochmal was anderes. Jedes Item hat eine Liste an Logiken und Methoden die bei Itemänderung getriggert werden sollen. Wenn du bei einem Item einen eval_trigger angibst, trägt sich das attributierte Item bei dem angegebenen Item als Methode ein, die bei Änderung getriggert werden soll. Damit kann das attributierte Item auf Änderungen des angegebenen Items reagieren. Da diese Methoden des Items öffentlich sind, kann sich aber auch jedes Plugin oder auch eine Logik etc. für Itemänderungen eintragen. Entspricht also dem Observer-Pattern.