Wenn ich das jetzt richtig verstehe, wird das Skript doch durch den Statuswechsel des Aktors gestartet. Wie soll dann bei deiner Prüfung im Script auf dem Status des Aktors ein alter Wert rauskommen; wenn das Script doch durch eine Änderung gestartet wurde?
Zeig doch bitte Mal das Script.
Was meinst du mit ‚Status des Aktors abfragen‘? Wie machst du das?
Michael
Du hast Recht, das Skript wird durch Änderung des Status der Aktoren gestartet. Es steht die Änderung von beiden Aktoren im Skript-Ereignis (also 2 Auslösekriterien).
Sagen wir mal, der Aktor wäre aus.
Nun ändert der Aktor seinen Zustand.
Im Skript wird dann der Zustand des Status abgefragt. Wenn es aber 3 oder 4 Sekunden dauert, bis Symcon den tatsächlichen Status übermittelt bekommt, dann ist der Zustand des Aktors immer noch FALSE, obwohl er in Wirklichkeit TRUE ist.
Die Abfrage des Status innerhalb des Skripts erfolgt ganz einfach über IF-Abfragen, so sieht es aus:
$Terrasse = GetValueBoolean(36699); //Variable für Aktor Terrasse Sitzplatz Steckdosen
$SchlafzimmerLinks = GetValueBoolean(34688); //Variable für Aktor für Steckdose links neben Schlafzimmer Tür
if (($Terrasse ==true) && ($SchlafzimmerLinks ==true)) {
RequestAction(14146, 2); // LED Taste oben auf GRÜN
RequestAction(39725, 0.5); // LED Taste oben Helligkeit 50%
} elseif (($Terrasse ==false) && ($SchlafzimmerLinks ==false)) {
RequestAction(14146, 0); // LED Taste oben auf AUS
RequestAction(39725, 0.0); // LED Taste oben Helligkeit 0%
} else {
RequestAction(14146, 1); // LED Taste oben auf BLAU
RequestAction(14146, 0.5); // LED Taste oben Helligkeit 50%
}
Jetzt habe ich es.
Dadurch das ja zwei Aktoren ‚Gleichzeitig‘ per Taster angesteuert werden und somit das Script schneller ist als bis der Status vom zweiten Aktor eingetroffen ist, entsteht dein Problem.
Das wird aber so nie zu 100% funktionieren.
Zum einen sendet auch der Taster nacheinander an beide Aktoren und wartet deren Rückmeldung ab.
Dann übermitteln beide ihren Status an die CCU. Das alles über Funk, wo nur einer zur Zeit senden kann.
Je nachdem welche Aktion jetzt schnell in IPS ankommt, wird das Script gestartet.
Das ist auch innerhalb von wenigen ms durchgelaufen und auf jeden Fall schneller als das beide neuen Stati der Aktoren in IPS bekannt sind.
Starten den beide Aktoren das Script? Weil dann sollte die Anzeige ja nach der verzögert eintreffenden Statusmeldung des zwei Aktors wieder stimmen.
Michael
Ja, es steht die Änderung der Stati von beiden Aktoren als Auslöse-Ereignis.
Dennoch funktioniert es nicht, das Skript läuft zwar zweimal durch (da es ja 2 Ereignisse sind), kommt aber nur bis zum ELSE-Zweig. Es wird also nur der Status von EINEM der beiden Aktoren richtig erkannt.
Ich vermute: Beim ersten Durchlauf werden beide Aktoren als AUS erkannt, beim 2. Durchlauf einer als EIN, der andere als AUS. Somit dann der ELSE-Zweig.
Das Problem ist nicht die Tatsache, das es 2 Aktoren sind, das Problem ist vielmehr das der Status des Aktors in Symcon um 3 Sekunden verzögert ankommt… Trage ich am Anfang des Skripts eine Wartezeit von 5 Sekunden ein ‚sleep(5);‘ dann funktioniert es einwandfrei.
Aber etwas über 5 Sekunden nach Druck des Tasters vor diesem zu verweilen und zu warten bis das die Beleuchtung angeht / ausgeht ist ja nicht Sinn und Zweck der Übung…
Das kann aber nicht sein, weil wenn beide als false erkannt werden, wodurch hätte das Script gestartet werden sollen?
IPS kann das Script ja nicht vor dem Eintreffen des Stati starten.
Michael
Doch, das ist definitiv so
Der Zustand an sich kann nur false oder true sein, das ist richtig.
IPS merkt aber anscheinend eine Zustandsänderung, ohne den endgültigen Status zu haben. Die Ereignisse lauten ja „Änderung des Status“. Als Ereignis für das Skript verweise ich ja nicht auf „bei Status = Wert true“ oder „bei Status = Wert false“
Wenn ich um 12:00:00 Uhr die Taste drückem (Aktoren schalten über die Direktverknüpfung) und Symcon hat auf dem Status den Zeitstempel true = 12:00:04 Uhr, was ist denn dann in den 4 Sekunden dazwischen?
Um 12:00:01 Uhr oder 12:00:02 Uhr steht der Aktor tatsächlich auf true, laut Symcon aber erst um 12:00:04 Uhr. Das der Aktor vor 12:00:04 Uhr schon an ist, das merke ich ja vor Ort (Strom ist da).
Und ich sehe es ja auch am Ergebnis, nachdem das Skript abgearbeitet wurde. Beide Aktoren sind tatsächlich AN, die LED leuchtet aber BLAU, also ist das Skript in den ELSE - Zweig gelaufen. Sprich ein Aktor wurde als AN (true) erkannt, der andere Aktor als AUS (false). Eine andere Möglichkeit gibt es laut dem Skript nicht.
Was passiert denn wenn Du das Skript manuell ausführst und Du damit erst einmal alle Latenzen aus der Gleichung raus nimmst? Funktioniert es dann wie es sollte?
Wie meinst du das genau? Es sollten zwei Ereignisse sein.
Ich vermute, das Skript wird nur einmal aufgerufen.
Es stehen zwei Ereignisse als Auslöser für das Skript:
Aktor 1 / Statusänderung
Aktor 2 / Statusänderung
Dann müsstest du am Zeitstempel der Ereignisse erkennen können, ob auch beide ausgelöst wurden. Ist dem so?
Ja genau, lösen beide aus.
Manchmal zeitgleich (Millisekunden Abweichungen werden ja nicht angezeigt)
manchmal mit 1 Sekunde Versatz
und ich hatte auch schon 4 Sekunden Versatz
Also nach gut Dünken…
Das würde bedeuten, dass das Skript auch zweimal - eventuell sogar fast gleichzeitig ausgelöst wird. Das ist eher mal nicht optimal.
Aber wie soll man es sonst machen, wenn man 2 Aktoren parallel schaltet und sicherstellen möchte ob beide Aktoren geschaltet haben bzw. von beiden Aktoren den Status ermitteln muss?
Demnächst kommt noch ein dritter Aktor hinzu, dann werden 3 Aktoren parallel über eine Taste betätigt. Dann würde das Skript sogar 3 mal aufgerufen werden (zeitlicher Versatz der Schaltzustände der Aktoren)
Bei solchen Anforderungen bleibt eigentlich nur eins.
Mach alles in einem System.
Also entweder alles in der CCU.
Oder alles in Symcon.
Also den Tastendruck in Symcon nutzen um ein Script zu starten, welches dann die Aktoren und die Beleuchtung steuert.
Michael
Du kannst entweder über eine Semaphore oder eine Abfrage des letzten Ausführungszeitpunktes des Skriptes abfangen, dass es nicht parallel oder zu oft hintereinander ausgeführt wird.
Das wäre aber die schlechteste Lösung, denn wenn ich zB aus welchen Gründen auch immer mehrfach den Taster an/aus betätige und damit per Direktverknüpfung die Aktoren schalte und IPS dann die Verarbeitung des Skripts verhindert, dann habe ich nachher undefinierte Zustände (Aktoren an aber Symcon zeigt aus oder dergleichen…)
Ok, also funktioniert das Auslösen des Skripts korrekt und auch die Logik ist korrekt.
Dann vermute ich, das der Schalter mit der dichten Folge von Schaltaufträgen für die LED nicht zurechtkommt.
Kommentiere doch mal den letzten else Zweig versuchsweise aus.