CUxD TIMER_GET funktioniert nicht als Programm-Kriterium

[rentier-s]

Hallo zusammen,

ich versuche seit Tagen relativ erfolglos, den TIMER_GET Wert eines CUxD Timers als Kriterium in einem Programm zu verwenden. Das Ziel ist abzufragen, ob die Lichtschranke mindestens 5 Sekunden, maximal 120 Sekunden blockiert war.

Leider springt mir das Programm immer in den Sonst-Zweig, obwohl der Timer eigentlich innerhalb des gewünschten Bereichs wäre.

Frage ich den Timer innerhalb des Skripts ab, funktioniert das ganze. Tut auch was ich will, trotzdem würde ich gerne das Problem verstehen.

Code: Alles auswählen

var timer = (dom.GetObject(ID_CHANNELS).Get("CUxD_Timer_09_Lichtschranke")).DPByHssDP("TIMER_GET").State();
if ( (timer < 115) && (timer > 0) ) {
  ...
}

[Baxxy]

Spekulation:
A:
Der CUxD Timer erzeugt während seiner Laufzeit keine Events (nur bei Start/Stop), somit hat die ReGa keine Kenntnis über den aktuellen Timer-Stand.
(Man hätte sonst jede Sekunde einen Protokolleintrag.)

Kann aber auch nicht passen denn wenn der Startwert in der ReGa verfügbar wäre müsste die Prüfung auf < Startwert (während der Timer läuft) immer Wahr ergeben.

B:
Die ReGa hat überhaupt keine Kenntnis vom Timerwert. Und das Programm kann den Wert nicht prüfen weil es .Value() nutzt wo nichts bei rauskommt. Im Script verwendest du ja .State().

Logikschicht "alles loggen" könnte Erkenntnisse bringen.

[rentier-s]

Der CUxD Timer erzeugt während seiner Laufzeit keine Events (nur bei Start/Stop), somit hat die ReGa keine Kenntnis über den aktuellen Timer-Stand.
[...]
Kann aber auch nicht passen, denn wenn der Startwert in der ReGa verfügbar wäre, müsste die Prüfung auf < Startwert (während der Timer läuft) immer Wahr ergeben.

Ja doch, das würde schon Sinn machen. Zum einen würde <Startwert schon Falsch ergeben, nur <=Startwert wäre Wahr. Außerdem prüfe ich auf <Startwert-5 (SET 120, GET <115), weil ich wissen will, ob die Lichtschranke mindestens 5 Sekunden blockiert war.

Im Script verwendest du ja .State().

Stimmt, das war mir gar nicht wirklich bewusst, eigentlich reine Gewohnheit bei CUxD State() zu verwenden, weil CUxD keinen duty cycle verursacht. Bidcos und HmIP frage ich immer mit Value() ab. Ich probiere nachher mal den Unterschied von Value() und State() während der Laufzeit des Timers.

OK, dann wird es wohl in diesem Fall darauf raus laufen, die Prüfung weiterhin im Skript zu machen. Ansonsten müsste ein zweiter Timer her, Timer1 5s und Timer2 120s, und im Programm dann prüfen, ob Timer1 =0 und Timer2 >0. Wird mir zu unübersichtlich.


Ich habe noch einen zweiten Fall, wo ich den aktuellen Wert des Timers brauchen würde. Skript scheidet da aus, weil ich abhängig vom Stand des Timers in den nächsten Sonst Wenn... rutschen will. Da muss ich mir dann was anderes einfallen lassen, oder das komplette Programm inkl. aller Zweige zu einem großen Skript umbauen.


Das ganze bringt mich aber gerade auf eine Idee, wie man bei HM Rollladenaktoren abfragen könnte, ob sie gerade fahren. So einen Anwendungsfall hätte ich nämlich. Erst Value() holen, dann State(), und wenn die unterschiedlich sind, hat der Aktor das Erreichen der Zielposition noch nicht gemeldet.

[Xel66]

Das ganze bringt mich aber gerade auf eine Idee, wie man bei HM Rollladenaktoren abfragen könnte, ob sie gerade fahren.

Dafür gibt es den "WORKING"-Datenpunkt. Allerdings bei klassischen HM nur per Script erreichbar. Bei HmIP hast Du teilweise "fährt hoch" und "fährt runter". Mit "WORKING" hatte ich mir mal was gebastelt, weil ein Aktor aufgrund seiner exponierten Lage manchmal (beim gleichzeitigen Fahren aller Rollladen) Schwierigkeiten hatte, seine Endlage abzusetzen. Ist wohl im Funkgewitter der anderen Statusmeldungen untergegangen. Die Ansteuerung war entzerrt, und trotzdem... Einfach nach einer Minute per Script noch mal "WORKING" auf true geprüft und wenn ja, dann nochmal einen Befehl nachgejagt (man hätte auch nur .State() prüfen können).

So einen Anwendungsfall hätte ich nämlich. Erst Value() holen, dann State(), und wenn die unterschiedlich sind, hat der Aktor das Erreichen der Zielposition noch nicht gemeldet.

Wird nicht funktionieren, da sie zwar geschwätzig sind, aber soviel dann noch nicht senden. Es wird nur kurz nach dem Losfahren gesendet mit einer Behanghöhe kleiner als Ausgangsbehanghöhe. Und dann erst wieder beim Erreichen der Endlage.

Aber grundsätzlich sollte TIMER_GET funktionieren. Nutze ich auch, allerdings prüfe ich nur zum Zeitpunkt des Setzens und da meldet der Timer ja seinen Stand an die ReGa. Ich setze dort einen gerade gesetzten (Lüftungs-)Timer bei Frostgraden noch mal runter.

Gruß Xel66

[rentier-s]

Aber grundsätzlich sollte TIMER_GET funktionieren. Nutze ich auch, allerdings prüfe ich nur zum Zeitpunkt des Setzens und da meldet der Timer ja seinen Stand an die ReGa. Ich setze dort einen gerade gesetzten (Lüftungs-)Timer bei Frostgraden noch mal runter.

TIMER_GET >0 oder TIMER_GET =0 funktioniert. Nur dazwischen halt nicht.

allerdings prüfe ich nur zum Zeitpunkt des Setzens und da meldet der Timer ja seinen Stand an die ReGa. Ich setze dort einen gerade gesetzten (Lüftungs-)Timer bei Frostgraden noch mal runter.

Kannst Du das mal irgendwie grafisch verdeutlichen? Ich verstehe Dein Vorgehen gerade nicht wirklich. Ist das ein Programm oder Skript? Weil im Skript kriege ich den aktuellen Stand ja mit State(). Und im Programm kann ich vor dem Abfragen nichts setzen, zumindest wüsste ich nicht wie.

[Xel66]

Kannst Du das mal irgendwie grafisch verdeutlichen? Ich verstehe Dein Vorgehen gerade nicht wirklich.

Klar. Der Ablauf ist folgender. Der Timer-FensterAUF wird durch ein anders Programm auf 1800s gesetzt (wenn eines der überwachten Fenster auf ist). Ziel ist eine Info per Sprachansage nach 30 Minuten. Bei Frostgraden wird diese Überwachungszeit auf 900 Sekunden automatisch reduziert, ohne dass ich das andere Programm anfassen und um die Frostabfrage ergänzen muss. Anbei der Programmausdruck. Die SONST WENN und SONST sind nur, um den aktuellen Status des Timers und den Timerstand in zwei Systemvariablen zu schreiben und hat keinerlei sonstige Funktion in diesem Zusammenhang. Ist nur zum Debuggen und überwachen.

Gruß Xel66

[rentier-s]

OK, das sind andere Voraussetzungen. Du reagierst direkt auf das Setzen des Timers und hast da den Startwert in TIMER_GET.

Ähnlich habe ich jetzt ein anderes Programm aufgebaut. Hat was mit dem Licht in der Garage zu tun. Da prüfe ich nicht wie geplant, ob der Timer beim Schließen der Haustüre eine Restlaufzeit von weniger als einer Minute hat, sondern nur ob der Startwert drei Minuten war. Dann weiß ich, welches Programm den Timer gesetzt hatte und überschreibe ihn davon abhängig.

Meine Lichtschranke habe ich ohne Timer gebaut. Da ich sowieso ein Skript brauche, verwende ich stattdessen den Wert aus LastTimestamp.
Wenn Lichtschranke aus => Skript: If (LastTimestamp zwischen 5 und 120 Sekunden alt)

[uwe111]

Das Ziel ist abzufragen, ob die Lichtschranke mindestens 5 Sekunden, maximal 120 Sekunden blockiert war.

Du könntest auch einfach einen Multi-Timer mit TIMERSET=5/120 anlegen und in der Programmverknüpfung TIMER_NUM prüfen.

Viele Grüße

Uwe

[rentier-s]

Du könntest auch einfach einen Multi-Timer mit TIMERSET=5/120 anlegen und in der Programmverknüpfung TIMER_NUM prüfen.

Hm, da muss ich glatt mal ein wenig rum experimentieren. Die Lichtschranke funktioniert jetzt wunderbar mit den Timestamps, aber ich habe ja noch einen zweiten Anwendungsfall.

Wenn ich die Doku richtig verstehe, könnte ich mit TIMER_SET=10/20/30/40/50/60 den Timer sozusagen auf insgesamt 1 Minute stellen und mittels TIMER_NUM>3 feststellen, ob davon weniger als 30 Sekunden übrig sind.

Was ich nicht ganz verstehe ist

Das ! (Ausrufezeichen) am Anfang eines Teilstrings verhindert den CMD_EXEC Aufruf beim Start des Bereiches.

Ich verwende nämlich CMD_EXEC, um damit eine Taste der virtuellen Fernbedienung zu drücken, damit ich als Trigger für Programme ein richtiges Ereignis habe. Müsste ich dann TIMER_SET=!10/!20/!30/!40/!50/60 setzen?

[uwe111]

Wenn ich die Doku richtig verstehe, könnte ich mit TIMER_SET=10/20/30/40/50/60 den Timer sozusagen auf insgesamt 1 Minute stellen und mittels TIMER_NUM>3 feststellen, ob davon weniger als 30 Sekunden übrig sind.

Nein, die angegebenen Zeiten addieren sich. In meinem vorherigen Beitrag hätte es richtig heißen müssen: TIMER_SET=5/115
Also in Deinem Beispiel dann: TIMER_SET=10/10/10/10/10/10

Ich verwende nämlich CMD_EXEC, um damit eine Taste der virtuellen Fernbedienung zu drücken, damit ich als Trigger für Programme ein richtiges Ereignis habe. Müsste ich dann TIMER_SET=!10/!20/!30/!40/!50/60 setzen?

Das müsstest Du testen. Meines Erachtens sollte es so funktionieren:
TIMER_SET=10/!10/!10/!10/!10/!10

Viele Grüße

Uwe