In Anhang mal 2 Bilder, hier sieht man die Abweichung von Kanal 4…
Komischerweise stimmt der Zeitstempel von Kanal 4 in Symcon mit dem Zeitstempel des Kanal 3 in der CCU überein… (??)
Korrigiere im Setup von dem Aktor auf der CCU doch mal die Event-Latenzzeiten für den Statuskanal.
@Kronos
Wie funktioniert das denn?
Und was genau bewirkt das? Den Kanal 3 frage ich ja in keinem Skript ab…
Was mich nur wundert: Wieso stimmt der Zeitstempel in Symcon (Kanal 4) mit dem Zeitstempel der CCU (Kanal 3) überein?
Nicht das hier der Fehler liegt, das der Symcon Kanal4-Zeitstempel in Wirklichkeit der CCU-Kanal3-Zeitstempel ist (was ich nämlich gerade vermute)
Wie funktioniert das denn?
Auf der CCU unter „Geräte“ den Aktor suchen und in die „Einstellungen“ gehen. Die Default Latenz (3 Sekunden) + die Zufallsverzögerung (1 Sekunde) entspricht in etwa der von Euch festgestellten Verzögerung. Daher mein Verdacht.
@kronos
Habe sowohl die Event- als auch die Zufallszeit auf „inaktiv“ gesetzt.
Beim Versuch auf 2 Schaltaktoren mit den oben genannten Einstellungen zeitgleich ein RequestAction auf den „STATE“ Kanal 4 abzusetzen, schmiert der Homematic Socket ab…
Ich denke irgendwas läuft da verdammt schief 
Aber wie gehe ich nun mit dem Problem um? Gibt es hier eine Lösung / Lösungsweg?
Ich schalte per Direktverknüpfung (Taster -> Aktor 1, Taster -> Aktor 2) also über einen Taster 2 Schaltaktoren ein/aus
Per Skript frage ich den Zustand der Aktoren ab, angetriggert wird dieses Skript über Zustandsänderung von beiden Aktoren.
Über das Skript wird dann je nach Zustand der Aktoren die beleuchtete Wippe ein/ausgeschaltet.
Beide Aktoren ein = grün, 50% Helligkeit
Einer von beiden Aktoren ein = blau, 50% Helligkeit
Sonst = Aus, 0% Helligkeit
Das Problem sind eigentlich nun 2 Probleme:
- Anscheinend werden die Aktoren minimal verzögert über die Direktverknüpfung angesteuert (meinetwegen Millisekunden-Bereich)
- Demzufolge wird das Skript nicht ordentlich abgearbeitet.
Ich stelle es mir das Prozedere so vor (um es mal etwas aufzudröseln:
- Druck auf den Taster
- Aktor 1 ändert den Zustand, das Skript wird angetriggert
- Über Skript werden die Zustände von Aktor 1 und Aktor 2 abgefragt
- Symcon erkennt, das Aktor 1 und Aktor 2 AUS sind (Aktor 1 ist zwar AN, hat jedoch den Status noch nicht übermittelt)
- Das Skript läuft in den ELSE-Zweig = Tasterwippe nicht beleuchtet
- Ein paar Millisekunden nach Punkt 2 ändert Aktor 2 seinen Zustand
- Das Skript wird erneut angetriggert
- Da Aktor 1 mittlerweile seinen Zustand übermittelt hat (AN), Aktor 2 jedoch nicht…
- Das Skript fragt die Zustände von Aktor 1 und Aktor 2 ab
- Aktor 1 wird als AN erkannt, Aktor 2 als AUS (obwohl er an ist)
- Die Tasterwippe leuchtet blau (würde bedeutet nur 1 Aktor ist an), in Wirklichkeit sind aber beide an.
Die o.g. Punkte laufen natürlich im Bruchteil einer Sekunde ab, ich habe es mal versucht so aufzudröseln, damit ihr das Problem nachvollziehen könnt.
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