mediola

Cux Timer

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Werbung


Re: Cux Timer

Beitragvon Cash » 15.05.2017, 11:13

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 :mrgreen:

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

Du könntest auch probieren statt Timer_Stop einfach den Timer auf 0 zu setzen und gucken ob er dann auslöst...
Cash
 
Beiträge: 693
Registriert: 09.01.2016, 18:42
Wohnort: Sauerland

Re: Cux Timer

Beitragvon uwe111 » 15.05.2017, 12:16

dtp hat geschrieben: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.

dtp hat geschrieben: 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.

dtp hat geschrieben: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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 1.11, RFD-Monitor, Vellemann K8055, SSH KeyDir
211 Kanäle in 118 Geräten und 101 CUxD-Kanäle in 47 CUxD-Geräten:
Benutzeravatar
uwe111
 
Beiträge: 3200
Registriert: 26.02.2011, 23:22

Re: Cux Timer

Beitragvon dtp » 15.05.2017, 12:19

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
dtp
 
Beiträge: 3603
Registriert: 21.09.2012, 08:09
Wohnort: Stuttgart

Re: Cux Timer

Beitragvon uwe111 » 15.05.2017, 12:39

dtp hat geschrieben: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.

dtp hat geschrieben: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.

dtp hat geschrieben: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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 1.11, RFD-Monitor, Vellemann K8055, SSH KeyDir
211 Kanäle in 118 Geräten und 101 CUxD-Kanäle in 47 CUxD-Geräten:
Benutzeravatar
uwe111
 
Beiträge: 3200
Registriert: 26.02.2011, 23:22

Re: Cux Timer

Beitragvon dtp » 15.05.2017, 13:46

uwe111 hat geschrieben: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
dtp
 
Beiträge: 3603
Registriert: 21.09.2012, 08:09
Wohnort: Stuttgart

Re: Cux Timer

Beitragvon uwe111 » 15.05.2017, 13:59

dtp hat geschrieben: 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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 1.11, RFD-Monitor, Vellemann K8055, SSH KeyDir
211 Kanäle in 118 Geräten und 101 CUxD-Kanäle in 47 CUxD-Geräten:
Benutzeravatar
uwe111
 
Beiträge: 3200
Registriert: 26.02.2011, 23:22

Re: Cux Timer

Beitragvon dtp » 16.05.2017, 08:18

uwe111 hat geschrieben: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
dtp
 
Beiträge: 3603
Registriert: 21.09.2012, 08:09
Wohnort: Stuttgart

Re: Cux Timer

Beitragvon uwe111 » 16.05.2017, 13:48

Hallo Thorsten,

dtp hat geschrieben:
uwe111 hat geschrieben: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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 1.11, RFD-Monitor, Vellemann K8055, SSH KeyDir
211 Kanäle in 118 Geräten und 101 CUxD-Kanäle in 47 CUxD-Geräten:
Benutzeravatar
uwe111
 
Beiträge: 3200
Registriert: 26.02.2011, 23:22

Re: Cux Timer

Beitragvon dtp » 17.05.2017, 09:31

Hallo Uwe!

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


Ah, dann versuche ich es mal damit.

uwe111 hat geschrieben: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
 
Beiträge: 3603
Registriert: 21.09.2012, 08:09
Wohnort: Stuttgart

Re: Cux Timer

Beitragvon dtp » 18.05.2017, 10:22

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
dtp
 
Beiträge: 3603
Registriert: 21.09.2012, 08:09
Wohnort: Stuttgart

VorherigeNächste

Zurück zu CUxD

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast







© homematic-forum.de & Lizenzgebern. Alle Rechte vorbehalten. Alle Bilder & Texte auf dieser Seite sind Eigentum
der jeweiligen Besitzer und dürfen ohne deren Einwilligung weder kopiert noch sonstwie weiter verwendet werden.