also das ShutterControl macht mir was Kopf zerbrechen.
Ich habe auf einen Taster ein Ereignis gelegt der dann ein Script mit folgenden Zeilen aufruft …
Jetzt ist es ja so, das wenn ich ja mehrere Rolläden mit einem Taster fahren möchte, geht das schon, nur da sich ja ein Sleep Aufrufe im ShutterControl befindet, werden alle Rolläden nach und nach herunter gefahren. Das bedeutet auch wenn ich z.B. unsere großen Rolläden im Wohnzimmer fahre, die mal fast 30 Sekunden benötigen bekomme ich ja Probleme mit der Laufzeit im Script.
Anders herum möchte ich aber auch nicht das man für jeden Rolladen ein extra Ereignis mit einem Script erstellt und dann das ganze auch noch für den Stop. Wobei, wenn ja dann der Aktor fährt nicht das Sleep unterbrochen werden kann, meine ich zumindest. Würde bestimmt gehen kann ich aber jetzt nicht im IPS erklären wie das geht.
Oder denke ich da falsch oder benutze ich das ShutterControl falsch oder wie auch immer…
Alles was du sagst ist schon korrekt.
Außer das mit dem Stop.
Weil der Sleep wartet ja nur bis zum Zeitpunkt für Stop. Und wenn schon vorher der Aktor Stop bekommt, passiert nicht mehr viel nach dem Sleep
Es gibt in IPS aber Befehle um weiter Scripte zu starten um eine quasi parallele Ausführung zu ermöglichen.
Diese Frage, explizit für das ShutterControl wurde bestimmt schon zig Mal gestellt: Shutter Control mit Timer
Michael
ja das habe ich im Vorfeld schon gemacht. Aber dann blicke ich die Abarbeitunsgreihenfolge nicht.
Ok, also das mit dem RunScript habe ich verstanden und funktioniert auch.
Was passiert mit dem SC_Move etc. Das sind Funktionen die schon aus irgend einer Klasse vorhanden sind und die man im IPS aufrufen kann. Ist das Richtig ?
Im Script wird doch wahrscheinlich durch den Aufruf z.B. von SC_Move irgendwie das ShutterControl Script aufgerufen, die nötigen Parameter übergeben. Ist das richtig ?
Aber im SC_Move ist doch vermutlich das Sleep versteckt oder?
Zumindest sieht es ja so aus wenn man ohne das RunScript die Funktion SC_Move aufruft das dann das Script an der stelle blockiert bis dann SC_Move fertig abgearbeitet ist. Ist das richtig ?
Wenn ich das so richtig sehe, wird die Funktion SC_Move aufgerufen, dann alles an ShutterControl übergeben, dann über die Auswertung im ShutterControl der richtige Aktor angesteuert mit seinen Schnittstellen und zu guter letzt
wartet doch die aufrufende Stelle darauf das SC_Move fertig in seiner internen Abarbeitung wird. Ist das richtig ?
Das Runscript macht dann im Hintergrund Threads auf. Ist das richtig?
Puhh wie soll man das alles in Worte packen damit man das verstehen kann …
Ich verstehe leider noch nicht die Abarbeitung von Scripte und übergreifend Scripte etc …
Nicht Klasse. Es ist eine Funktion einer Instanz vom Typ Shutter-Control.
Ja, steht auch in der Doku.
Ne, der ist im ShutterControl-Script.
Ja, weil alle Instanz-Funktionen immer nacheinander abgearbeitet werden und auch auf die Beendigung der Aktion gewartet wird bzw. die Rückmeldung von einem Gerät das ein Befehl ausgeführt wurde.
Das ist in den allermeisten Fällen auch sehr gut so, sonst würden viele Scripte nicht funktionieren.
Und dort, im Shutter Skript, ist auch der IPS_Sleep bei fast jeder Hardware vorhanden.
Ja.
Übergreifend ist da doch nix.
Dein Skript welches z.B. SC_Move aufruft, hat keine direkte Verbindung zum Shutter Skript.
Es führt eine Instanz-Funktion vom Shutter-Control aus und wenn diese beendet wurde, geht es weiter.
Das dass Shutter-Control intern noch ein Skript startet, ist dabei Nebensache.
Wichtig ist nur, dass dein Skript erst den nächsten Befehl abarbeitet wenn das Shutter-Control seine Aktion beendet hat.
Auch wenn gerade eine Aktion von Shutter-Control ausgeführt wird (also im IPS_Sleep ist) und du einen SC_Stop sendest, beendet es nicht den IPS_Sleep. Aber es startet das Shutter-Skript erneut mit dem STOP-Befehl.
OK, also das muss ich nochmal aufgreifen mit dem Scripten und IPS.
Sollen wir das hier weiter bereden oder soll ich mal ein neues Post dazu aufmachen …
Mich würde sehr interessieren wie sich das IPS Sleep mit den aufrufende Scripte funktioniert …
das mal kurz zum Abschluss zu bringen. Im Shutter Control wird das IPS_Sleep verwendet.
Das ist ein eigenes Thread Objekt. An dieses Thread Objekt kommt man nicht dran um es abbrechen zu können, das heißt das Script läuft durch, aber der Thread vom Sleep läuft weiter.
Ruft man den Stop vom ShutterControl wieder erneut auf wird wieder erneut ein Thread eröffnet.
Das heißt der Aktor fährt so zu sagen in dem einem Thread z.B. rauf.
Kommt der Stop wieder erneut über, hat man zwei Thread Objekte und der Aktor kann stoppen.
Daher läuft auch die Berechnung für das eine Threadobjekt weiter. Also ist rein theoretisch wie ein anderes Forenmitglied sagt, eher das ShutterControl vermutlich für die Aktoren gedacht die keine direkte Rückmeldung als Poositionswert vom Aktor erhalten.
Anderseits hat man grundsätzlich zum jetzigen Zustand das Problem mit dem IPS_Sleep weil es als Threadobjekt nicht zu beenden ist.
Man müsste das ganze Event basierend erstellen so z.B. „Schluer“ das geamcht hat. Müsste man prüfen in wie weit das mit der aktuellen Version noch funktioniert …
ich habe hier ein kleines Problem mit dem Shutter Modul.
„Eigentlich“ funktioniert alles, bis auf den Punkt, dass wenn ich die Rollladen mit den dezentralen Tastern (Enocean) bediene, der Status nicht an das Modul übertragen wird, welches folglich dazu führt, dass das Modul nicht richtig funktioniert.
Kann es sein, dass es daran liegt, dass ich die Variable~ShutterMoveStop oder ~ShutterMoveStep nicht gesetzt habe? Ich weiss leider nicht wie das geht, werde aus der Doku nicht wirklich schlau, über kurze Hilfestellung wäre ich sehr dankbar.
Melden die EnOcean Taster sauber den Status wieder zurück, sodass die Status Variable sich korrekt ändert? Denn genau das ist notwendig, damit die manuelle Steuerung funktioniert.
das Problem habe ich und viele andere User auch da die Rollos nicht so richtig unterstützt werden.
Rückkanal wird nicht ausgewertet von den Rollos. Sprich wenn du den Rollo über einen Taster fährt kennt IPS die Position nicht mehr.
