Timer nicht zuverlässig (in Kombination mit Zeitsteuerung?)

[DrTob]

Sorry, das ist mir dann aber doch etwas zu sehr von hinten durch die Brust
...

Naja, alle paar Sekunden mit einem Script zu prüfen "ist es soweit?" Nein. "Jetzt?" Nein. "Vielleicht jetzt?" Ne "jetzt"? Ist da nicht gerade besser (-> es ist die deutlich schlechtere Idee...)

[dfeng]

Sorry, das ist mir dann aber doch etwas zu sehr von hinten durch die Brust
...

Naja, alle paar Sekunden mit einem Script zu prüfen "ist es soweit?" Nein. "Jetzt?" Nein. "Vielleicht jetzt?" Ne "jetzt"? Ist da nicht gerade besser (-> es ist die deutlich schlechtere Idee...)

Also ich meine alle paar Minuten mal ein Skript auszuführen sollte das Gerät schon hinbekommen... ich rede ja nicht von 5sek.-Takten.

Mal eine blöde andere Frage:
Ich habe die CCU beim Einrichten von CUxD ja mehrfach neu gestartet und hatte diese Probleme.
Nun musste ich die mal ein paar Minuten vom Netz nehmen und der Timer scheint das alte Programm sehr zuverlässig alle 89Sek. auszulösen.
Ein neuen, später eingerichteten Timer für das Sonnenstandskript hat allerings Aussetzer beim Auslösen des Programms.

Kann das sein, dass man die CCU strmlos machen muss, wenn man neue Timer angelegt hat?

[dfeng]

Kann das sein, dass man die CCU strmlos machen muss, wenn man neue Timer angelegt hat?

Ne, hat sich erledigt, läuft unrund wie eh und je...
...und ich bin immer noch für Ideen (jenseits von Werksreset und alles neu anlernen) dankbar.

Auf den Screenshots sieht man das Programm und das Protokoll, der Timer steht auf 239sek.

[alchy]

Ahja. Nur mal nebenbei. Du protokollierst das Ergebnis eines Scriptes welches in einem Programm eingebettet ist.
Und da dieser Wert unregelmäßig "erzeugt" wird, muss es der Timer sein, der das Programm triggert, welches das Script ausführt, was den Wert berechnen soll.

Mit Verlaub, das ist unlogisch.
Wenn du behauptest, der Timer läuft unregelmäßig, solltest du dann nicht zumindest auch den Timer protokollieren und posten?

meine 2cents, die Aussage von DrTob

alle paar Sekunden mit einem Script zu prüfen "ist es soweit?" Nein. "Jetzt?" Nein. "Vielleicht jetzt?" Ne "jetzt"? Ist da nicht gerade besser (-> es ist die deutlich schlechtere Idee...)

trifft es doch sehr genau.
Du rennst doch auch nicht alle 20 Sekunden zur Klingel und schaust ob wer klingelt, statt zu warten, das der KlingelGong Krach macht, oder etwa doch?

Grundsätzlich hast du natürlich Recht.
Natürlich sollte das Zeitmodul der CCU so etwas trotzdem abdecken können.
Der Kiste sollte es schließlich egal sein, ob du alle 10 Sekunden checken willst ob die Klingel geklingelt hat.
Es wird ja auch angeboten, also muss es auch gehen. Zur Not auch mehrfach im Sekundentakt ausgelöste Timer.
Denn es gibt keine Begrenzung in der Klickibunti zu dem Scheduler.
Nach meinen Erfahrungen macht der Scheduler der CCU bei vielen Usern so etwas nicht zuverlässig mit. Andere sind da anderer Meinung. CUxD Timer laufen meiner Erfahrung dem Gegenüber doch sehr viel zuverlässiger.

Trotzdem sollte man sich immer überlegen, ob es nicht doch anders geht, als alle 5 Sekunden nachzuschauen ob es geklingelt hat.

Alchy

PS: Die Zeiten des Sonnenauf und untergang kann man auf vielfältige Art verschieben.
z.B. von mir gern benutzt: einfach den "Wohnort" in der CCU anpassen unter Einstellungen / Systemsteuerung / Zeit- und Positionseinstellung. Die Suche im Forum sollte dir das schnell zeigen.

[EDIT]
Und nun habe ich gleich mal einen Test durchgeführt mit den CUxD Timern:
Kleines Programm
Wenn CUxD Timer_30sek: Timer EVENT
dann Systemvariable per Script berechnet und gespeichert.
Beides geloggt exportiert analysiert
Ergebnis: alle 30 Sekunden wird der Timer ausgelöst und die Variable gespeichert.

dann selbes Programm auf TIMER_GET <=0 Aktualisierung
Beides geloggt exportiert analysiert
Ergebnis:
Alle 30 Sekunden wird der Timer ausgelöst, die Variable jedoch NICHT immer gespeichert.

Ich meine zwar gelesen zu haben, das es eigentlich genau umgedreht sein hätte sollen, aber vielleicht hilft es dir ja trotzdem.
[/EDIT]

Alchy

[dfeng]

Ahja. Nur mal nebenbei. Du protokollierst das Ergebnis eines Scriptes welches in einem Programm eingebettet ist.
Und da dieser Wert unregelmäßig "erzeugt" wird, muss es der Timer sein, der das Programm triggert, welches das Script ausführt, was den Wert berechnen soll.

Mit Verlaub, das ist unlogisch.
Wenn du behauptest, der Timer läuft unregelmäßig, solltest du dann nicht zumindest auch den Timer protokollieren und posten?

...

[EDIT]
Und nun habe ich gleich mal einen Test durchgeführt mit den CUxD Timern:
Kleines Programm
Wenn CUxD Timer_30sek: Timer EVENT
dann Systemvariable per Script berechnet und gespeichert.
Beides geloggt exportiert analysiert
Ergebnis: alle 30 Sekunden wird der Timer ausgelöst und die Variable gespeichert.

dann selbes Programm auf TIMER_GET <=0 Aktualisierung
Beides geloggt exportiert analysiert
Ergebnis:
Alle 30 Sekunden wird der Timer ausgelöst, die Variable jedoch NICHT immer gespeichert.

Ich meine zwar gelesen zu haben, das es eigentlich genau umgedreht sein hätte sollen, aber vielleicht hilft es dir ja trotzdem.
[/EDIT]

Alchy

Danke dir

Also zu oben...klar protokolliere ich das Ergebnis des Programms.
Ob der Timer läuft ist mir ja auch wurscht, mein Programm soll regelmäßig laufen. Dem Timer traue ich schon, eher der Schnittstelle Timer/Programm nicht, daher passte das schon. Den Timer hatte ich aber auch schon geloggt

Was das "schauen ob wer klingelt" betrifft... nicht alles was hinkt ist ein Vergleich, gell?
Wenn was klingeln würde, also ein Event käme, wäre das ja super für ein eventbasiertes System, wie die CCU.
Blöderweise warte ich nicht auf ein klingeln, sondern auf eine Uhrzeit, d.h. wenn ich auf der Couch liege und um 20:30 los will, muss ich wohl oder übel alle paar Minuten auf die Uhr schauen
Klar kann ich einen Wecker stellen, was die CCu auch halbwegs gut könnte, nur sobald ich einen dynamischen Offset will, geht das nicht mehr. Und das genau will ich... mich 10 min. vor Sonnenuntergang entscheiden, dass die Rollos heute mal länger oben bleiben

Was ich natürlich tun könnte, wäre morgens die Uhrzeit berechnen, zu der eine gewisse Elevation erreicht wird, und dann einen Timer setzen, denn ich dynamisch anpasse, wenn ich einen Offset möchte... und dann genau mit Ablauf dieses Timers die Rollos steuern. Das wäre evtl. gar nicht so blöd Aber jetzt zu schauen, ob ich aus dem Sonnenstandskript die Uhrzeit zu einer Elevation zu bekommen kann...oder das Skript morgens solange zu iterieren bis ich die gewünschte Elevation habe... ach, so langweilig ist mir nicht. Aber cool wäre es schon

So genug philosophiert... hat alles seine Berechtigung, wenn es zum Anwendungsfall passt.


Viel wichtiger, ich hatte heute früh noch das Skript auf Timer-Event umgestellt und beobachte gerade genau das, was du auch schon sagtest: So läuft das Ding absolut stabil was das auslösen des Programms betrifft. Entgegen der Anleitung.

Damit wäre mein Problem erstmal gelöst und ich lasse in Zukunft das Sonnenstandskript 24/7 an der Tür gucken ob es gleich klingelt und lass mir von dem dann sagen, dass ich die Tür aufmachen muss

Danke euch allen!
df

[alchy]

Also zu oben...klar protokolliere ich das Ergebnis des Programms.
Ob der Timer läuft ist mir ja auch wurscht, mein Programm soll regelmäßig laufen. Dem Timer traue ich schon, eher der Schnittstelle Timer/Programm nicht, daher passte das schon. Den Timer hatte ich aber auch schon geloggt

Du kannst so nicht behaupten der Timer ist unzuverlässig. Der ist es nicht, war es auch nicht.
Genau so hätte innerhalb deines Programmablaufes, oder Script ein Fehler sein können.
Aber dir ist es ja wurscht, wie du schreibst.

Was TIMER_EVENT vs. TIMER_GET angeht, wird Uwe hier schon mitlesen und was draus machen.
Ich habe die cuxd Anleitung nicht zur Hand.

Alchy

[dfeng]

Du kannst so nicht behaupten der Timer ist unzuverlässig. Der ist es nicht, war es auch nicht.
Genau so hätte innerhalb deines Programmablaufes, oder Script ein Fehler sein können.
Aber dir ist es ja wurscht, wie du schreibst.

Was TIMER_EVENT vs. TIMER_GET angeht, wird Uwe hier schon mitlesen und was draus machen.
Ich habe die cuxd Anleitung nicht zur Hand.

Alchy

Hm, ja, ne, doch, kann ich wohl.
Letztlich liegt es vermutlich nicht am Timer bzw. CUxD aber das zeigt dann ja ansatzweise der Verlauf des Threads.

Beim Titel geht's ja schon darum, dass man möglichst schnell sein Problem wiederfindet und das genau tut der Titel auch.

Die Entwickler von Addons sind hier niemals angeklagt worden, alles gut, ich bin sehr dankbar.

Nix für ungut, aber: Nicht hilfreich.

Gruß
df