Cux Timer

[Cash]

Ich für meinen Teil nutze ausschließlich Timer_Event als Trigger... Im Handbuch steht ja eigentlich nur das es nicht immer zuverlässig funktioniert. Das verstehe ich nicht als Warnung

Auf meiner CCU arbeit der Trigger seit über einen Jahr 100% zuverlässig. Und ich nutze mehr als 16 Timer

Du könntest auch probieren statt Timer_Stop einfach den Timer auf 0 zu setzen und gucken ob er dann auslöst...

[uwe111]

Hatte nämlich gedacht, dass TIMER_STOP den Timer anhält, ohne ihn auf Null zu setzen.

Nein, TIMER_STOP beendet den Timer und ist das gleiche wie TIMER_SET=0.

In Verbindung mit "TIMER_GET kleiner oder gleich 0 bei Aktualisierung" führt das dann zu einem ungewollten Auslösen.

Es gibt da noch den STATE Datenpunkt zum Triggern.

Im Moment löse ich mein Problem durch die Verwendung der Timer-Sperr- und Entsperrfunktion. Funktioniert auch; aber ist das auch so gewollt?

Ja, dafür gibt es diese Funktion.

Viele Grüße

Uwe

[dtp]

Hintergrund meiner Frage sind das dritte und vierte Programm in diesem Posting.

Wenn ich im dortigem dritten Programm statt "CCU CUxD Timer Tagesriegel sofort Sperrung aktiv" "CCU CUxD Timer Tagesriegel sofort TIMER_STOP" verwenden würde, dann hätte dies ein sofortiges Triggern des vierten Programms mit dem Neusetzen des Timers zur Folge, so dass ich bis zum Sanktnimmerleinstag jede Stunde eine Nachricht erhielte. Würde der Timer mit "TIMER_STOP" stattdessen einfach angehalten werden, dann wäre alles in Ordnung. Aber wie gesagt, mit dem Sperren und Entsperren des Timers funktioniert's auch so. Wollte nur sichergehen, dass ich den Timer damit nutze, wie ursprünglich vorgesehen.

EDIT: Antwort von uwe111 kam zeitgleich. Insofern werde ich es einfach so belassen, wie es jetzt ist.

Wann macht es denn explizit Sinn, mit TIMER_STOP den Timer-Wert auf Null zu setzen? Sprich, braucht man eine zusätzliche Pausen-Funktion überhaupt?

Und warum gibt es die Warnung bzgl. TIMER_EVENT? Oder ist die evtl. gar nicht mehr gültig?

EDIT2: Toll wäre aber dennoch eine Möglichkeit, den aktuellen TIMER-Wert kontinuierlich im ioBroker angezeigt zu bekommen. Oder wäre das dann zu viel Traffic?

Gruß,

Thorsten

[uwe111]

Wann macht es denn explizit Sinn, mit TIMER_STOP den Timer-Wert auf Null zu setzen? Sprich, braucht man eine zusätzliche Pausen-Funktion überhaupt?

Das macht auf jeden Fall Sinn, wenn Du einen sich wiederholenden Timer abbrechen möchtest. Mittels Sperr-Funktion läuft der Timer ja unsichtbar im Hintergrund weiter. Es werden nur keine Events mehr generiert.

Und warum gibt es die Warnung bzgl. TIMER_EVENT? Oder ist die evtl. gar nicht mehr gültig?

Möglicherweise ist das Problem mit dieser FW-Version bereits behoben: viewtopic.php?f=26&t=36623
Das müsste mal jemand testen.

Toll wäre aber dennoch eine Möglichkeit, den aktuellen TIMER-Wert kontinuierlich im ioBroker angezeigt zu bekommen. Oder wäre das dann zu viel Traffic?

Das wäre m.E. eine Aufgabe des User-Interfaces. Auf der CCU würde es dem periodischen Aufruf von TIMER_GET entsprechen und deshalb für mich keinen Sinn machen. Um sowas synchron im User-Interface zu implementieren könnte ich über einen Datenpunkt den absoluten Zeitstempel des aktuellen Timers zurückgeben. Damit könnte man die Anzeige dann z.B. komplett und CCU unabhängig in Javascript realisieren. Ist so ein Datenpunkt interessant?

Viele Grüße

Uwe

[dtp]

Ist so ein Datenpunkt interessant?

Hallo Uwe,

also für mich wäre so ein Datenpunkt durchaus interessant, auch wenn ich es aktuell löse wie hier im ioBroker-Forum beschrieben. Problem ist dabei jedoch, dass der CUxD-Timer und der ioBroker-Countdown aufgrund eines Delays zwischen dem ioBroker und der CCU2 nicht gleichzeitig enden.

Gruß,

Thorsten

[uwe111]

Problem ist dabei jedoch, dass der CUxD-Timer und der ioBroker-Countdown aufgrund eines Delays zwischen dem ioBroker und der CCU2 nicht gleichzeitig enden.

Wenn Du den Zeitstempel des CUxD-Timer-Ablaufs auslesen könntest (Datenpunkt), dann ist die Verzögerung ja völlig egal.
Wichtig ist hier nur, dass beide Systemuhren synchronisiert sind.

Viele Grüße

Uwe

[dtp]

Das macht auf jeden Fall Sinn, wenn Du einen sich wiederholenden Timer abbrechen möchtest.

Hm. Aber das würde doch genau so funktionieren, wenn TIMER_STOP den Timer einfach anhält, ohne ihn auf Null zu setzen.

Ich persönlich fände es viel einfacher und auch logischer, wenn ich mit TIMER_GET für den Wert Null - wie auch bisher - einen Trigger setzen kann, TIMER_STOP diesen Trigger aber nicht auslösen würde, weil der Timer einfach angehalten wird. Das hätte auch den Vorteil, dass ich ihn entweder mit TIMER_START (ja, ich weiß, gibt's noch nicht) an der Stelle weiterlaufen oder mit TIMER_SET wieder neu setzen könnte. Mit TIMER_RESET (gibt's auch noch nicht) könnte man ihn dann ja explizit auf Null setzen, um ein vorzeitiges Auslösen über TIMER_GET zu ermöglichen. Das Sperren und Freigeben des Timers bräuchte man dann eigentlich nicht mehr.

Nur so ein paar Gedanken.

Übrigens gibt es natürlich auch mit den vorhandenen Timer-Parametern eine Möglichkeit, mit TIMER_SET, TIMER_STOP und TIMER_GET auszukommen. Man kann nämlich TIMER_GET so konfigurieren, dass der Timer bei Eins auslöst. Dann führt TIMER_STOP mit dem Wert Null nicht zum Auslösen. TIMER_SET muss man dann ggf. einfach um Eins höher setzen, um dieselbe Zeitspanne, wie vorher, zu haben. Nicht unbedingt elegant, aber ein Workaround.

Gruß,

Thorsten

[uwe111]

Hallo Thorsten,

Das macht auf jeden Fall Sinn, wenn Du einen sich wiederholenden Timer abbrechen möchtest.

Hm. Aber das würde doch genau so funktionieren, wenn TIMER_STOP den Timer einfach anhält, ohne ihn auf Null zu setzen.

Mit dem Unterschied, dass ein periodischer Timer bei aktivierter Sperre im Hintergrund weiter läuft und keine Events mehr sendet. Durch deaktivieren der Sperre werden dann wieder Events gesendet.

Zum Triggern gibt es doch mittlerweile noch viele andere Möglichkeiten (z.B. STATE=TRUE). Hier hast Du mit TIMER_STOP kein Problem. Und mit der neuen ReGa von Jens könnte sogar TIMER_EVENT wieder zuverlässig funktionieren. Wenn Du die Protokollierung des Timer-Kanals aktivierst, dann kannst Du im Systemprotokoll der CCU alle Timer-Events sehen.

Mit TIMER_GET wirst Du nicht auf Eins auslösen können. Aber das siehst Du auch im Systemprotokoll.

Viele Grüße

Uwe

[dtp]

Hallo Uwe!

Zum Triggern gibt es doch mittlerweile noch viele andere Möglichkeiten (z.B. STATE=TRUE).

Ah, dann versuche ich es mal damit.

Mit TIMER_GET wirst Du nicht auf Eins auslösen können.

Stimmt. Hatte ich ganz vergessen. Sorry.

Es gibt so viele Timer-Parameter. Da verliert man schnell den Überblick.

Danke für Deine Unterstützung.

Gruß,

Thorsten

[dtp]

Hab mir gestern mal den Parameter STATE im ioBroker angesehen. Bei mir blieb der Wert aber immer auf TRUE, unabhängig davon, ob der Timer lief, oder nicht. WORKING änderte sich dagegen nach Ablauf des Timers von TRUE auf FALSE. Mir fiel auch auf, dass TIMER_SET immer leer blieb, während beim Start des Timers TIMER_GET auf den Sollwert gesetzt wurde. Ich meine mich zu erinnern, dass in älteren CUxD-Versionen noch TIMER_SET beim Start des Timers gefüllt wurde. Oder irre ich mich da?

Gruß,

Thorsten