Automatische Beschattung

[mumpf]

Ok, wenn da wirklich int steht, dann sind es ja ganze Zahlen... Schade... Dann wohl erst in zukünftigen sh.py Versionen. Was wäre denn dein Anwendungsfall für so kurze delays? Gruß Waldemar

[Onkelandy]

Hmmm, also bei nem Cycle von 0.1 für einen Scheduler gab's jedenfalls mal ne Fehlermeldung...

Die gibt's nun auch beim delay Attribut hier beim autoblind. Hat man hier zB 0.1 angegeben, spuckt das Debuglog aus: invalid literal for int() with base 10
Gleicher Fehler kommt übrigens auch, wenn man versucht, das delay über item:xyz zu definieren, selbst wenn jenes Item einen int Wert hinterlegt hat.. Offenbar wird hier wirklich nur ne Ganzzahl akzeptiert?

[mumpf]

Ich fürchte, der Scheduler arbeiter nur auf Sekundenbasis, da ist nichts "Schnelleres" möglich Falls doch, wäre das Hammer!

Marcus meinte mal auf meine Frage diesbezüglich, dass man den Scheduler wohl auch mit Werten < 1 aufrufen kann, er war nur nicht sicher, wie genau dieser Sekundenbruchteil eingehalten werden kann. Sein Statement damals: Einfach mal ausprobieren,,,
Leider bin ich bisher nicht zum ausprobieren gekommen...

Gruß, Waldemar

[Onkelandy]

Hi offline! Vielen Dank schon mal für die Info und das Update! Sehr cool.

Das mit dem Aufheben von Suspend durch Schreiben des gleichen Lockwerts funktioniert tatsächlich. Problem ist dabei allerdings, dass es wohl eine gröbere Aktion bräuchte, um alle Items gleichzeitig zu un-suspenden. Derzeit ließe sich das extrem einfach über as_set_suspendoff = byattr:jalousie_lock_off managen.. Aber okay, ich hab jetzt mal die zu schaltenden Items manuell definiert und setze diese dann auf den aktuellen lock-Wert, den ich mittels item:xyz.autostate_lock auslese. Klappt prima!

Auch das mit dem Delay scheint zu klappen! Sehr schöne Lösung, danke! Ich fürchte, der Scheduler arbeiter nur auf Sekundenbasis, da ist nichts "Schnelleres" möglich Falls doch, wäre das Hammer!

Merci vielmals!
onkelandy

[mumpf]

Danke, ich werde es aber erst am Wochenende ausprobieren können... Ich gebe dann "Bescheid"... Gruß Waldemar

[offline]

Guten Morgen,

ich habe die Delay-Funktionalität in den develop-Zweig gepusht. Das Delay wird über das neue Attribut "as_delay_[action_name]" angegeben. Der Wert sind entweder Sekunden oder Minuten, wenn hinter der Zahl ein "m" steht.
Eine Auflösung kleiner 1 Sekunde ist im Moment noch nicht implementiert. Theoretisch könnte das möglich sein, ich weiß nur nicht, wie genau der Scheduler von Smarthome.py auflöst.

Zum Löschen des Suspend ohne Aufheben des Lock: Ohne jetzt ins Coding geschaut zu haben, meine ich, dass das Suspend aufgehoben wird, sobald auf Lock ein Wert geschrieben wird. Probiere mal beim Lock-Item "enforce_updates = yes" zu setzen und schreibe dann bei gesetztem Lock mal erneut eine 1 auf das Item.

Die Sache mit der Visu muss ich mal durchdenken.

Grüße
offline

[Onkelandy]

Bin mir nicht sicher
Ich möchte ja in der Visu immer den aktuellen Status sehen, der vom KNX zurück kommt. Ich müsste dann für jedes einzelne Element zwei Items haben.. eines, das auch wirklich den richtigen Wert anzeigt und eines, mit dem ich in den Suspend Mode wechseln kann. Wobei Letzteres dann halt grad anzeigt, was ich zuletzt umgestellt habe und nicht, wo der Aktor tatsächlich steht. Das wäre irgendwie sehr unübersichtlich und kompliziert - oder versteh's ich jetzt falsch?

[mumpf]

Hi,

zu b): Sollte das nicht jetzt schon gehen? Du musst doch nur ein Item haben, dass nur auf die Visu (und nicht auf den Status des Aktors) hört und dieses Item im Autoblind für suspend nutzen... oder habe ich Deine Anforderung falsch verstanden?

Gruß, Waldemar

[Onkelandy]

Hehe, cool Ja, mir ging es tatsächlich einfach nur um eine Art "Makro" mit ner Abfolge von Befehlen, die nicht alle gleichzeitig erfolgen sollen. Derzeit bräuchte es halt ne Logik dafür mit einem timer oder sleep/wait Befehl. Optimal wäre natürlich, wenn sich auch Sekundenbruchteile realisieren ließen, also auch 0.1

Jetzt nochmals ein anderes Thema und zwar das SUSPEND Item:
a) Gäbe es irgendeine Möglichkeit, das Suspend zu deaktivieren ohne auch das Lock zu deaktivieren? Also ich möchte einfach alle auf händisch umgestellten Item "resetten", aber nicht die gesperrten.
b) Ich fände es extrem praktisch, wenn man die Items per Visu manipulieren und damit in den Suspend Mode wechseln könnte. Also zB Höhe der Jalousien oder Intensität der Lichter. Momentan beißt sich diese Funktion ja mit den Rückmeldungen des KNX Buses. KNX sendet ja nach jeder Änderung den aktuell angefahrenen Wert, was auch sehr vernünftig ist. Wäre es nicht doch möglich, für den Suspendmode nur die Änderungen über die Visu herzunehmen oder das im Item definieren zu können..? Wäre sehr cool!

Vielen lieben Dank!!!

[mumpf]

... denn man kann ja mit dem Timer einfach das AutoBlind-Item verzögert auf 1 setzen und damit wird die Zustandsermittlung neu getriggert.

Daran habe ich nicht gedacht... Und bin natürlich glücklich!

Gruß Waldemar

[offline]

Hi offline,
Das finde ich geradezu perfekt - ist so etwas wie ein selbstgemachter cycle, der aber über entsprechende Zustände abgeschaltet werden kann. Und - nicht zu vernachlässigen - es könnte auch ein ganz anderer Zustand gültig werden, dann wär das Plugin nicht in der Zwischenbedingung, sondern ganz wo anders - das ist ja das tolle mit Zuständen...

Grundsätzlich stimme ich dir da schon zu (zumal das die einfacher zu implementierende Variante ist). Ich befürchte jedoch, das diese Variante für andere User, die unter Umständen nicht so IT-Affin sind, schwieriger zu verstehen ist und mir (bzw. dem Forum) dadurch mehr Arbeit macht

So wie ich das verstehe, willst Du genau dann den Timer löschen, wenn das gleiche Item durch den Timer und den neuen Zustand geändert werden soll. Ich sehe hier schon Probleme (hab ich auch noch nicht wirklich durchdacht):

• Was ist, wenn der neue Zustand wieder einen Timer setzt? Gilt das als "verlängern" (alten Timer löschen) oder als "dann nochmals setzen" (weiteren Timer zufügen)? Kann man das im Plugin festlegen oder braucht es dafür einen weiteren Parameter?

Technisch gesehen wäre das der Fall, dass ein neuer Zustand aktiv werden soll, bevor der vorherige Zustand vollständig erreicht wurde. Hier muss man überlegen, ob man mit dem aktivieren des neuen Zustands den vorherigen Zustand als obsolet betrachtet und den Timer gundsätzlich verwirft, oder ob man versucht, dem vorherigen Zustand so nahe wie möglich zu kommen. In letzterem Fall würde man den Timer des vorherigen Zustands nur verwerfen, wenn die Restlaufzeit länger als die Laufzeit des neuen Timers ist.

• Den Timer bekomme ich nicht einfach so gelöscht, nur indem ich im neuen Zustand das Item mit dem eigenen Wert setze - das ändert aber "age" (könnte relevant sein)

Aus dem Plugin kann ich den Timer löschen ohne den Wert des Items zu schreiben. Age etc. sollten dabei unangetastet bleiben.

• Du gehst davon aus, dass das Ziel-Item nur vom Autoblind geändert wird. Es könnte aber auch durch ein anderes Ereignis geändert worden sein. Mit meinem Ansatz könnte man dies vor dem Ändern noch überprüfen und so eine weitere (unerwünschte) Änderung verhindern.

Das ist richtig, nach Ablauf des Timers wird zwingend das Item gesetzt.

• Zustände, die kein Item setzen, haben keine Chance, eine Folgeaktion verzögert anzutriggern.

Speziell der letzte Punkt liegt mir am Herzen. Liegt vielleicht daran, wie ich Autoblind benutze - als echte State-Engine. Ich habe somit auch (Übergangs-)Zustände, die nichts schalten, sondern eine Bedingung für Folgeaktionen darstellen. Und hier wäre es schön, wenn man das "Wann" für die Folgeaktion auch bestimmen bzw. verändern könnte!

Wenn ich mir eure Postings nochmal durchlese, dann denke ich, dass eure Anforderungen in zwei verschiedene Richtungen gehen. Zum einen sollen einzelne Items mit (geringem) Zeitversatz gesetzt werden, Zum anderen soll die Zustandsermittlung vorzeitig getriggert werden. Die erste Anforderung lässt sich zwar mit Hilfe der vorzeitigen Zustandsermittlung realisieren, erfordert aber zusätzliche Zustände, was in meinen Augen für diese einfache Anforderung zu kompliziert ist.

Ich denke aber, dass auch mumpf mit der Implementierung der von Onkelandy angeregten Timer-Lösung geholfen ist, denn man kann ja mit dem Timer einfach das AutoBlind-Item verzögert auf 1 setzen und damit wird die Zustandsermittlung neu getriggert.

Grüße
offline

[mumpf]

Hi offline,

diesmal sind wir und wohl nicht einig - oder ich habe Deinen Vorschlag nicht verstanden...

ich denke schon, dass eine Verzögerung sinnvoll wäre. Mir fällt spontan auch die ein oder andere Sache ein, die man damit tun könnte.

Da bin ich noch voll bei Dir...

Beim Lösungsvorschlag von mumpf sehe ich das Problem darin, dass "Zielbedingung" nach X Sekunden auch nicht erfüllt sein kann. Das Plugin bleibt dann in der "Zwischenbedingung" stehen und der vorzeitige Trigger wird ggf. erneut gestartet. Aus diesem Grund finde ich die Idee von Onkelandy, das über eine Zusatzangabe in as_set zu implementieren eigentlich besser.

Das finde ich geradezu perfekt - ist so etwas wie ein selbstgemachter cycle, der aber über entsprechende Zustände abgeschaltet werden kann. Und - nicht zu vernachlässigen - es könnte auch ein ganz anderer Zustand gültig werden, dann wär das Plugin nicht in der Zwischenbedingung, sondern ganz wo anders - das ist ja das tolle mit Zuständen...

Hier ist es meiner Meinung nach am simpelsten, wenn man beim Einstieg in einen neuen Zustand prüft, ob ein Timer für ein verzögertes Schalten aktiv ist und diesen Timer einfach löscht, sofern das Item im neuen Zustand geschaltet werden soll. Wenn das Item im neuen Zustand nicht geschaltet werden soll, dann kann der Timer weiterlaufen, denn das Ergebnis entspricht ja dem gewünschten Ergebnis des Zustands, der den Timer definiert.

So wie ich das verstehe, willst Du genau dann den Timer löschen, wenn das gleiche Item durch den Timer und den neuen Zustand geändert werden soll. Ich sehe hier schon Probleme (hab ich auch noch nicht wirklich durchdacht):

• Was ist, wenn der neue Zustand wieder einen Timer setzt? Gilt das als "verlängern" (alten Timer löschen) oder als "dann nochmals setzen" (weiteren Timer zufügen)? Kann man das im Plugin festlegen oder braucht es dafür einen weiteren Parameter?
• Den Timer bekomme ich nicht einfach so gelöscht, nur indem ich im neuen Zustand das Item mit dem eigenen Wert setze - das ändert aber "age" (könnte relevant sein)
• Du gehst davon aus, dass das Ziel-Item nur vom Autoblind geändert wird. Es könnte aber auch durch ein anderes Ereignis geändert worden sein. Mit meinem Ansatz könnte man dies vor dem Ändern noch überprüfen und so eine weitere (unerwünschte) Änderung verhindern.
• Zustände, die kein Item setzen, haben keine Chance, eine Folgeaktion verzögert anzutriggern.

Speziell der letzte Punkt liegt mir am Herzen. Liegt vielleicht daran, wie ich Autoblind benutze - als echte State-Engine. Ich habe somit auch (Übergangs-)Zustände, die nichts schalten, sondern eine Bedingung für Folgeaktionen darstellen. Und hier wäre es schön, wenn man das "Wann" für die Folgeaktion auch bestimmen bzw. verändern könnte!

Ich will hier gar nichts gegen den aktuellen Vorschlag sagen, er ist komfortabel und straigt-forward, ich möchte Dich nur bitten, wenn Du sowieso an einer Verzögerung bastelst, auch ein verzögertes antriggern vom Autoblind zuzulassen (also eine re-evaluation aller Zustände). So wie ich das sehe, ist das, was ich mir wünsche, eine Basis-Funktionalität und euer (Deiner und der von Onkelandy) die Komfort-Funktion oben drauf...

Natürlich bleibt es Dir frei zu entscheiden, Du bist ja schließlich derjenige, der es programmieren muss...

Gruß, Waldemar

[Onkelandy]

Hi Leute!

Danke für die rasche Rückmeldung. So wie offline das im letzten Absatz beschreibt, wäre es meiner Meinung nach perfekt. Ist das Item in einem anderen Zustand anders gesetzt, wird der Timer abgebrochen und neu gesetzt. Ansonsten läuft er einfach weiter.

Freu mich schon
Grüße,
onkelandy

[offline]

Guten Morgen,

ich denke schon, dass eine Verzögerung sinnvoll wäre. Mir fällt spontan auch die ein oder andere Sache ein, die man damit tun könnte.

Beim Lösungsvorschlag von mumpf sehe ich das Problem darin, dass "Zielbedingung" nach X Sekunden auch nicht erfüllt sein kann. Das Plugin bleibt dann in der "Zwischenbedingung" stehen und der vorzeitige Trigger wird ggf. erneut gestartet. Aus diesem Grund finde ich die Idee von Onkelandy, das über eine Zusatzangabe in as_set zu implementieren eigentlich besser.

Nichtsdestotrotz ist der Einwand von mumpf natürlich berechtigt. Was ist, wenn die verzögerte Schaltung zu einem Zeitpunkt kommt, wenn ggf. bereits ein neuer Zustand aktiv ist, der das entsprechende Item anders setzt? Hier ist es meiner Meinung nach am simpelsten, wenn man beim Einstieg in einen neuen Zustand prüft, ob ein Timer für ein verzögertes Schalten aktiv ist und diesen Timer einfach löscht, sofern das Item im neuen Zustand geschaltet werden soll. Wenn das Item im neuen Zustand nicht geschaltet werden soll, dann kann der Timer weiterlaufen, denn das Ergebnis entspricht ja dem gewünschten Ergebnis des Zustands, der den Timer definiert.

Grüße
offline

[mumpf]

offline: Wenn ich so meine letzte Antwort lese, dann würde es für so Verzögerungs-Sachen doch sinnvoll sein, noch eine Art as_set_timer = n zu haben, der in n Sekunden den autoblind nochmal Triggert (einmalig). So etwas kann man derzeit nämlich nur sehr umständlich hin bekommen...

Onkelandy: Ich weiß, dass es sich so anhört wie Dein Vorschlag, aber der Unterschied ist, dass man gar nicht sagen muss "Setze Wert x nach n Sekunden". Das Problem mit solchen Kombi-Settings ist immer, wie nehme ich so einen verzögerten Setter wieder zurück? Es kann ja sein, dass sich die Situation wieder ändert und nach n Sekunden der Wert x gar nicht mehr gewollt ist. Und ich behaupte, dass viele mit einem solchen Setting eigentlich ein "Setze Wert x nach n Sekunden, sofern nicht vorher ein anderer Wert gesetzt wurde" meinen, was dann ganz bescheiden zu implementieren ist.

Wenn man aber einfach nach n Sekunden wieder den Autoblind triggert, kann der Enduser sich einen Zustand basteln, der genau nach diesen n Sekunden wiederum enter-Bedingungen testet und so selbst entscheiden kann, ob dieses Setting jetzt geschehen soll oder nicht.

Gruß, Waldemar