[erledigt] eigene letzte Laufzeit eines Programms abfragen

[Baxxy]

Ich mag ja solche "Spezialitäten". Daher würde ich (wie von @MichaelN vorgeschlagen) den Ausführungs-Zeitstempel des Programmes (ganz am Ende des Scripts) in eine SysVar schreiben. Am Anfang des Scripts wird dieser eingelesen und mit aktuellem Zeitstempel verglichen. Stimmen die Bedingungen dann weiter, ansonsten Abbruch.

Die Ausbaustufe wäre dann auf die SysVar zu verzichten und Blacks Ansatz mit den Metadaten des Programmes zu nutzen.

Ist auch für mich Neuland, aber @Black schreibt da bestimmt mal ein HowTo dazu wie das per Script aussehen muss.

[MichaelN]

Das scheint relativ einfach zu sein:

Code: Alles auswählen

object oID = dom.GetObject(ISE_ID);
! anlegen
oID.AddMetaData ("Schluessel","IchBinDerNeueWert");
! setzen
oID.MetaData ("Schluessel","IchbinderNeueWert");
! abfragen
WriteLine (oID.MetaData ("Schluessel"));

(ungetestet)

[Xel66]

In meinen Augen ist der ganze Ansatz schon falsch gedacht, denn die Verzögerung des Schaltbefehls wird on der CCU gesetzt und das Programm sofort beendet. Die Laufzeit zu überwachen ist somit dem Zweck nicht dienlich. Und warum soll das Script wiederholt aufgerufen werden? Es hat doch im ersten Durchlauf seine Schuldigkeit getan. Irgendwie strange...

Gruß Xel66

[MichaelN]

Mein Reden, aber

Das ist Deine subjektive Meinung, ich bin anderer.

[rentier-s]

Puh, OK. Nochmal der Reihe nach, obwohl ich eigentlich all das bereits erklärt habe:

An 359 Tagen im Jahr fährt der Rollladen genau so hoch wie er soll, nämlich eine halbe Stunde nach allen anderen. An manchen Tagen will ich diese halbe Stunde aber manuell abbrechen, und zwar direkt am Aktor.

Der hat zwei Tasten. Wenn ich die Zu Taste drücke obwohl der Rollladen noch unten ist, kriegt die CCU im Abstand von knapp 2 Sekunden jeweils Behanghöhe 0 gemeldet. Ich reagiere auf Behanghöhe = 0 bei Aktualisierung, weil das die einzige Möglichkeit ist, genau diese Situation zu erfassen. Das funktioniert sogar ganz hervorragend und zuverlässig.

Im Skript prüfe ich, ob LastValue auch 0 war, d.h. der Rollladen bereits unten war als ich gedrückt habe, also die gewünschte Situation vorliegt.

Falls dem so ist, setze ich ein LEVEL.State(0, 500, true) ab, damit die laufende Verzögerung abgebrochen wird.

Der dritte Parameter der State(Wert, Verzögerung, re-trigger) Anweisung erlaubt das abbrechen laufender Verzögerungen in einem Skript.

So, und jetzt kommen wir zum kritischen Punkt:
Dieser Befehl veranlasst den Aktor erneut, zuerst die aktuelle Behanghöhe zu melden und knapp 2 Sekunden später die neue, beides natürlich 0, denn der Rollladen ist ja unten.
Darauf springt mein Programm an, was es ja soll.
Genau an der Stelle muss ich prüfen, wer gedrückt hat, ich oder das Programm. Hat nämlich das Programm gedrückt, darf es das nicht nochmal, weil das in einer Endlosschleife enden würde.

Meine wunderbar funktionierende bisherige Lösung, ich setze einen CUxD Timer auf 30 Sekunden und frage im Skript dessen Restlaufzeit ab. Das hat gegenüber Systemvariablen den Vorteil, dass ich mich nicht um das Zurücksetzen oder was auch immer kümmern muss, und ich brauche auch nicht mit Zeiten rum rechnen.

Aber, ich brauche dafür einen CUxD Timer. Das stört mich dahingehend, weil ich mir dachte es könnte auch ohne funktionieren und dann hätte ich einen CUxD Timer weniger in der Geräteliste. Idee, das Skript soll stattdessen auslesen, wann das Programm zum letzten mal lief. War das vor weniger als 10 Sekunden, hat offenbar das Skript den Aktor angesprochen, die Verzögerung ist also bereits abgebrochen.

Warum ich für die 30 Minuten Verzögerung nicht gleich einen Timer nutze, weil ich dann in sämtlichen anderen Programmen, die irgendwas mit dem Rollladen anstellen, auch immer noch ein TIMER_STOP einbauen müsste. Da ist die Verzögerung praktischer. Ich will dafür nicht noch zig andere Systemvariablen und sonst was, ich möchte eine möglichst aufgeräumte CCU.

Da es offenbar keine (halbwegs dokumentierte) Möglichkeit gibt, dass das Skript die letzte Laufzeit ermittelt, bleibe ich bei meinem Timer, der sozusagen das Programm sperrt und somit eine Endlosschleife verhindert, und sich danach selbsttätig wieder schlafen legt.

Ich danke Euch für Euren Einsatz, für mich ist das Thema hiermit erledigt. Ihr dürft Euch gerne weiter drüber auslassen, wie sinnlos das alles doch ist.

[MichaelN]

Aber, ich brauche dafür einen CUxD Timer. Das stört mich

Ja, irgendwas ist immer. Aber Du wirst eben nicht umhin kommen dir igrnedwie zu merken ob das Programm schon gelaufen ist. Ob Cuxd-Timer, Systemvariable oder Meta-Tag. Ganz ohne geht es eben nicht.

Im übrigen finde ich die Lösung gar nicht so doof. Beim 3. Erklären habe ich es dann auch verstanden.

[Xel66]

Genau an der Stelle muss ich prüfen, wer gedrückt hat, ich oder das Programm. Hat nämlich das Programm gedrückt, darf es das nicht nochmal, weil das in einer Endlosschleife enden würde.

Dann solltest Du Alchys Programmauslöserscript zurate ziehen, denn über die Variable Dollar src Dollar (mein Smartphone kann kein Dollarzeichen!) Kann man den Programmauslöser eines Programms innerhalb eines Scriptlaufes feststellen (steht auch so in der Doku Part 1 IRC) und immer Falle "Trigger nicht Behanghöhe des Aktors" einfach abbrechen. Natürlich kannst Du so nicht unterscheiden, ob das Script jetzt initial oder wiederholt aufgerufen wurde. Oder eben explizit beim Trigger "Behanghöhe" eine Routine aufrufen und abbrechen. Geht auch.

Gruß Xel66

[rentier-s]

immer Falle "Trigger nicht Behanghöhe des Aktors" einfach abbrechen.

Der Trigger ist immer die Behanghöhe. Einen anderen habe ich nicht, weil es ein klassischer HM Aktor ist, bei dem es kein Tastendruck Ereignis gibt.

Natürlich kannst Du so nicht unterscheiden, ob das Script jetzt initial oder wiederholt aufgerufen wurde.

Aber genau das ist doch mein Problem, wiederholtes Aufrufen abfangen, sonst Endlosschleife.

[Xel66]

Der Trigger des Abbruchs der Hochfahrzeit muss doch nicht zwangsweise in einem Script und schon gar nicht innerhalb des gleichen Scripts abgehandelt werden. Das kann man auch in ein vollständig separates Programm auslagern. Mit dem allgemeinen Hochfahrbefehl setzt man eine Systemvariable (ggf. zeitbegrenzt) und durch die Behanghöhe 0% ein weiteres Programm, welches bei WAHRer Systemvariable und Behanghöhe 0% bei Aktualisierung, den Runterbefehl zum Löschen der laufenden Verzögerung und das Rückseiten der Variable absetzt. Der Befehl muss in diesem Falle nur an den gleichen Kanal gehen.

Aber ohne Kenntnis der aktuellen Programmierung ist das alles nur Kafeesatzleserei und Glaskugelempfehlung.

Gruß Xel66

[rentier-s]

Aber ohne Kenntnis der aktuellen Programmierung ist das alles nur Kafeesatzleserei und Glaskugelempfehlung.

Ich glaube, ich habe es mittlerweile ausreichend erklärt

Ein Programm macht die übrigen Rollläden hoch und startet den Countdown im Schlafzimmer.

Ein anderes Programm soll diesen Countdown bei Bedarf abbrechen. Dieses Programm wiederum wird durch Behanghöhe gleich 0 bei Aktualisierung ausgelöst. Einen anderen Auslöser bekomme ich nicht, wenn ich die "Zu" Taste am Aktor drücke, bei HMIP Aktoren gäbe es ein Taster Ereignis.

Dieses Programm beinhaltet ein Skript, dass bei Value=0 && LastValue=0 ein LEVEL.State(0) an den Aktor schickt, um die 30 Minuten Verzögerung abzubrechen, die das Öffnen Programm zuvor gesetzt hatte.

Dadurch kriege ich allerdings erneut den Status Behanghöhe 0% vom Aktor mitgeteilt, was das "Abbruch Programm" erneut auslöst. Da alle weiteren Bedingungen ebenfalls zutreffen, würde das Skript ein weiteres mal LEVEL.State(0) schicken, wodurch der Aktor wieder Behanghöhe 0% meldet, damit das Programm triggert usw., bis der Duty Cycle voll ist.

Klar kann man dieses Verhalten durch Systemvariablen o.Ä. sperren. Ich verwende für solche Zustandserkennungen CUxD Timer oder Exec Schaltaktoren, die haben 16 Kanäle auf einmal und sind mir lieber als 16 einzelne Systemvariablen, ist aufgeräumter und weil sie sich zur Not auch schnell per GUI schalten lassen.

Solange mir niemand sagen kann, wie ich ohne irgendwelche händisch zwischengespeicherte Werte raus bekomme, wann das Programm vor der aktuellen Instanz zuletzt lief, oder alternativ abfragen ob noch eine Verzögerung für einen bestimmten Datenpunkt aktiv ist, wir das weiterhin ein Timer erledigen. Das funktioniert seit zwei Jahren, gefällt mir halt nicht und wie Frauen nunmal sind stören mich solche Kleinigkeiten oft mehr als alles andere, aber geht wohl nicht anders.