HomeMatic-Forum / FHZ-Forum

Sowie es JRiemann beschreibt habe auch ich es interpretiert.
Da ich noch nicht so lange "dabei" bin, habe ich aber keine Referenz zu den älteren CUxD Versionen.
Aus meiner Sicht wäre es toll, wenn vielleicht Uwe was dazu sagen könnte,
sprich ob das ein Bug ist, oder eine Fehlinterpretation der Funktionalität bzw. des Handbuches.

JRiemann hat geschrieben:Das ist so auch nicht richtig. STATE=TRUE, STATE=FALSE, TIMER_NUM, TIMER_GET und TIMER_EVENT sind die Standardauslöser.

Das es beim Timer noch andere Möglichkeiten gibt ein Programm auszulösen war klar und nutze ich ja auch. Ich meinte das man sofern man Timer_Get benutzt nur mit kleiner gleich 0 Triggern kann.

Ich bin mir eigentlich relativ sicher das man noch nie mit einen anderen Wert als 0 dort triggern konnte. Wenn es so wäre bräuchte ich viele viele Timer weniger.

Aber Uwe wird sich bestimmt melden und es klarstellen.

Wie gesagt, ich bin nicht zu 100% sicher da ich fast ausschließlich Multi_Timer per TRUE/FALSE nutze.
Was aber sicher ist, ist die Tatsache das aktuell TIMER_GET 0 bis kleiner 0 bei Aktualisierung/Änderung bei mehreren Usern nicht funktioniert.

Um weniger Timer zu nutzen könnte Dir die neue Funktion TIMER_NUM helfen.

Cash hat geschrieben:Ich bin mir eigentlich relativ sicher das man noch nie mit einen anderen Wert als 0 dort triggern konnte.

Genau so ist es! Alle vom CUxD generierten Events kannst Du im CCU-Systemprotokoll des Kanals sehen.
Wenn das Triggern trotzdem nicht funktionieren sollte, dann ist es ein Problem der CCU Logikschicht.
Deshalb gibt es auch die in der CUxD-Doku beschriebenen alternativen Trigger Möglichkeiten.
Per HM-Script kann man den Wert .State() des TIMER_GET Datenpunktes jederzeit direkt abfragen.

Cash hat geschrieben:Wenn es so wäre bräuchte ich viele viele Timer weniger.

Dafür eignet sich der Multi-Timer. Hie kannst Du dafür den TIMER_NUM Datenpunkt abfragen/triggern.

Viele Grüße

Uwe

Hi!

TIMER_NUM erhält im Triggermoment aber immer den Wert des kommenden Timers, richtig?

Wenn ich z.B. einen Multitimer mit 00:00, 04:00, 18:00 und 22:00 habe und den NUM Wert im Systemprotokoll anschaue, dann ist der um 18:00 auf 3, was aber die Nummer für den 22:00 Timer ist.

Gruß
Gerti

Hallo Gerti,

Gerti hat geschrieben:TIMER_NUM erhält im Triggermoment aber immer den Wert des kommenden Timers, richtig?

Richtig!
Ich denke man sieht das auch sehr gut an den Beispielen auf Seite 94 der aktuellen CUxD-Doku (1.9).

Viele Grüße

Uwe

Hallo zusammen,

ich habe nun eine Verständnisfrage zu den Timmer_Num Möglichkeiten. Ich habe einen Multi-Timer erstellt, der um 7:15, 8:15, 16:15 und 22:00 auslösen soll. Das steuert jetzt die Weihnachtsbeleuchtung im Haus.

Das soll so funktionieren, dass die Außbeleuchtung nun um 7:15 angeschaltet werden soll und ausgehen soll um 8:15. Habe im Programm als Auslöser zum Einschalten Timmer_Num 0 genommen, da 7:15 auch 0 ist. Beim Erreichen von 8:15 sollte ja Timer_Num auf 1 wechseln und so abschlaten, da ich im Programm bei Abfrage Timer_Num 1 im Ausschaltzweig ist. Kann das so funktionieren?

Hallo Mirko,

shamen7777 hat geschrieben: Kann das so funktionieren?

Den Wert von TIMER_NUM kannst Du Dir zum Testen auch im Systemprotokoll der WebUI ansehen (vorher die Protokollierung des Timer-Kanals aktivieren).
Zum zeitgesteuerten Ein/Aus-schalten würde ich beim Einschaltvorgang aber gleich die Einschaltdauer setzen. Das macht den ganzen Ablauf sicherer und erspart das Ausschalten per Funkbefehl.

Viele Grüße

Uwe

Vielen Dank für deine schnelle Antwort. Habe das Programm mal angehangen, vielleicht geht dies so auch nicht wirklich. Ich habe jetzt das so beobachtet, dass der Timer_Num schon beim Eintritt in die zweite Zeit schon nach oben gezählt wird und somit nicht als Auslöser dienen kann. Zumindest wie ich das im Programm gemacht habe. Vielleicht ist auch die Abfrage wie ich es gemacht falsch.

Und was ich auch nicht in dem Dropdown Menü finde ist State=True. Es wird Time_Set, Timer_Event, Schaltzustand:Ein, Schaltzustand:Aus, Timer_Get, Timer_Num, CMD_RET, Sperrung aktiv, Speerung inaktive und TS.

Habe das Programm jetzt mal so umgestellt. Der CUxD Timer ist auf 7:15:00/16:30:00 eingestellt.