Automatische Beschattung

[Onkelandy]

Genial! Vielen Dank! Musste den Text zwar 2 Mal lesen, aber jetzt scheint alles so zu klappen wie es soll

[mumpf]

Hi offline,

wow! Das ist jetzt abgedreht. Obwohl ich es schade finde, dass Du nochmal ein "suspend"-Regelwerk neben dran gestellt hast - irgendwie hätte ich es besser gefunden, wenn man nach item/source/caller in den Zuständen hätte abfragen können und sich somit "normale" Zustände definieren könnte, die suspend-Charakter haben.
Ich habe immer wieder das Problem, dass der Suspend gesetzt wird (wodurch auch immer, jetzt durchaus komfortabel einstellbar), und auch nach einer Zeit zurückgesetzt wird, ich aber in der Zeit (ohne externe Logik) nicht die Möglichkeit habe, wichtigere Zustände zu aktivieren.

Typisches Beispiel: Rolladen wurde 10 Minuten vor "Zentral runter" manuell auf 50% gefahren. Wenn jetzt der Befehl "Zentral runter" kommt, ist dieser Rolladen im suspend und geht erst später runter. Hätte ich einen suspend-Zustand, könnte ich den hinter den "Zentral runter" setzen und so selber bestimmen, wer gewinnt.

Versteh mich nicht falsch, ich finde immer noch irre, was Du hier leistest und wie viel komfortabler sh.py mit autoblind wird. Ich habe auch keinen konkreten Feature-Wunsch, denn letztendlich bastle ich mir meine Suspend-Zustände selber und nutze Deinen Suspend-Mechanismus kaum. Ich hätte es irgendwie nur besser gefunden, wenn man den alten Suspend als "Mittel für den Gelegenheits-User" gelassen hätte und einen neuen Suspend in die State-Engine reingezogen hätte, vielleicht mit einem Beispiel, wie man Suspend-Zustände bauen kann. Dann hätte man "item/source/caller" auch bei normalen Regeln zur Verfügung...

Gruß, Waldemar

P.S.: Dieses Feature werde ich wohl nicht testen, da ich es nicht brauche...

[offline]

Hi Waldemar,

ich denke, man kann zwei verschiedene Sichtweisen auf "suspend" (und parallel auch auf "Lock") haben. Auf der einen Seite können das Zustände der jeweiligen Items sein, die sich wie andere Zustände auch verhalten. Auf der anderen Seite können es Betriebs"zustände" des Plugins sein, die damit den Zuständen der jeweiligen Items übergeordnet sind. Von der Programmierung her orientiert sich das Plugin bisher am zweiten Ansatz.

Ich habe mich bisher nicht damit beschäftigt, einen "Suspend" über Zustände zu bauen. Du kannst ja mal ein Beispiel posten wie du das gemacht hast. Evtl. ist das ja ein Thema für das Wiki ...

Nichtsdestotrotz ist es nicht besonders aufwändig, zusätzliche "besondere" Bedingungen zu integrieren, über der "Aufrufer", der die Statusermittlung ausgelöst hat, mit abgeprüft werden kann. Ich habe das mal eingebaut und in den Branch "feature/update_conditions" gepusht. Die Namen der "besonderen" Bedingungen sind "update_caller", "update_source" und "update_dest". Bei den ersten Tests habe ich jedoch gesehen, dass ich hier weniger Informationen bekomme, als bei der anderen Lösung, da jeder Aufruf nochmal durch ein "Eval" geschickt wird, wenn Items über "eval_trigger" überwacht werden.

Grüße
offline

[Onkelandy]

So, hab die Sache jetzt ordentlich getestet, sieht sehr gut aus. Hier mein Codebeispiel, vielleicht bringt's wem was:

            
            as_suspend_watch = essen.l45d_deckenlicht.kalt | essen.l45d_deckenlicht.warm # Schalten des Lichts
            as_suspend_watch_IgnoreKnxReply_warm = !essen.l45d_deckenlicht.warm:KNX;1.1.3 # Rückmeldung vom Schaltaktor ignorieren
            as_suspend_watch_IgnoreKnxReply_kalt = !essen.l45d_deckenlicht.kalt:KNX;1.1.3
            as_suspend_watch_dimmwert_warm = essen.l45d_deckenlicht.warm.dimmen:Visu # Direkte Werteingabe Dimmwert nur berücksichtigen, wenn sie über die Visu getätigt wird, KNX Status wird somit ignoriert
            as_suspend_watch_dimmwert_kalt = essen.l45d_deckenlicht.kalt.dimmen:Visu
            as_suspend_item = essen.l45d_deckenlicht.autostate_suspend
            as_suspend_time = 60

Oder könnte ich das irgendwie einfacher aufsetzen?
Fraglich wär jetzt noch, ob die suspend_time nicht auch über ein Item definiert werden könnte Klar ist dann die Frage, was passiert, wenn man den Wert während einer Suspend-Phase ändert, aber das könnte man ja einfach ignorieren, da der Timer ja eh schon gesetzt ist..?

mumpf Prinzipiell wäre es ja möglich, einen Zustand "über das Suspend" einzureihen, indem man dort einfach den Lock-Wert auf Null stellt, könnte mit by_attr gut funktionieren? Aber ein eigener Zustand "manuell" ist ja auch nicht unbedingt ein Nachteil gegenüber dem Suspendmodus.

[mumpf]

Hi offline,

hier mal ein Beispiel, wie ich den Suspend für Rolläden mache:

[Test]
    [[Rollo]]
        [[[Sued]]]
            ...
            [[[[Move]]]]
                type = bool
                visu_acl = rw
                enforce_updates = True
                knx_dpt = 1
                knx_listen = 3/1/0
                knx_send = 3/1/0
            [[[[Stop]]]]
                type = bool
                visu_acl = rw
                enforce_updates = True
                value = 1
                knx_dpt = 1
                knx_listen = 3/1/2
                knx_send = 3/1/2
            [[[[Manuell]]]]
                type = bool
                name = Manuelle Bedienung
                eval = not sh.Test.Rollo.Sued.Manuell()
                eval_trigger = Test.Rollo.Sued.Move | Test.Rollo.Sued.Stop
            ...
            [[[[AutoBlind]]]]
                ...
                [[[[[Rules]]]]]
                    ...
                    as_item_Manuell = Test.Rollo.Sued.Manuell
                    eval_trigger = Test.Rollo.Sued.Manuell
                    ...
                    [[[[[[Suspend]]]]]]
                        type = foo
                        name = Manuell aus
                        [[[[[[[enter_Manuell]]]]]]]
                            as_agemax_Manuell = 1
                        [[[[[[[enter_Stay]]]]]]]
                            as_value_laststate = Test.Rollo.Sued.AutoBlind.Rules.Suspend
                            as_max_age = 1800
                    ...

Ich brauche für Move und Stop noch ein Hilfsitem Manuell, da sich der Age eines Items wohl nicht ändert, wenn er nochmals mit dem gleichen Wert beschrieben wird (auch bei enforce_updates nicht, was ich für inkorrekt halte).
Auf dieses Manuell-Item reagiere ich dann in Autoblind, nicht auf einen spezifischen Wert, sondern auf eine frische (jünger als 1 Sek) Änderung. In dem Zustand bleibe ich dann 1800 Sekunden.

Das entspricht so ziemlich Deinem Suspend-Verhalten, sobald das der erste Status ist, wobei ich nicht die Uhrzeit (suspended bis xxx) in den Status schreibe. Ich kann allerdings auch "wichtigere" Stati davor schieben...

Gruß, Waldemar

[offline]

Hi mumpf

in der Tat wird "age()" (und auch "prev_age()", "last_change()" und "changed_by()") trotz enforce_updates nur neu gesetzt, wenn tatsächlich eine Wertänderung stattgefunden hat. Ich denke aber, dass die Lösung mit den "Hilfsitem" einen weiteren Vorteil hat: Sie kapselt alle Items, die beim Suspend-Status berücksichtigt werden sollen. Ehrlich gesagt ist das die Idee, die mir bei meinen Überlegungen, einen Suspend über einen Zustand zu bauen, noch gefehlt hat.

Ich denke, dass es da von Seiten des Plugins ein paar Stellen gibt, an denen man noch etwas tun kann, um deine Suspend-Lösung noch etwas komfortabler zu machen.
Man könnte für Items neben "value", "item" und "eval" noch ein "var" einführen, über das dann "Variablen" des Plugins verwendet werden können. In deinem Beispiel z.B "var:this_state" statt "Test.Rollo.Sued.AutoBlnd.Rules.Suspend" (Copy&Paste tauglicher, weniger Möglichkeiten für Tippfehler) und "var:suspend_time" statt "1800" (dynamischer, könnte man aber auch über ein Item machen). Das "as_agemax_Manuell" müsste mit der letzten Änderung schon durch "as_value_update_source" ersetzbar sein. Hier könnten dann auch die weiteren Bedingungen geprüft werden, ggf. müsste man da aber aus dem Manuell-Item per eval noch ein paar mehr Daten bereitstellen.

Grüße
offline

[mumpf]

Hi,

in der Tat wird "age()" (und auch "prev_age()", "last_change()" und "changed_by()") trotz enforce_updates nur neu gesetzt, wenn tatsächlich eine Wertänderung stattgefunden hat. Ich denke aber, dass die Lösung mit den "Hilfsitem" einen weiteren Vorteil hat: Sie kapselt alle Items, die beim Suspend-Status berücksichtigt werden sollen. Ehrlich gesagt ist das die Idee, die mir bei meinen Überlegungen, einen Suspend über einen Zustand zu bauen, noch gefehlt hat.

freut mich, wenn meine Idee hilfreich ist. Die Abstraktion mit dem Zusatzitem finde ich auch gut, das Item kann einfach auf alles hören, was manuelle Bedienung repräsentiert: Andere Items, GA, Network Interface (z.B. für irtrans) etc.

Man könnte für Items neben "value", "item" und "eval" noch ein "var" einführen, über das dann "Variablen" des Plugins verwendet werden können.

Grundsätzlich eine gute Idee, an so etwas habe ich noch gar nicht gedacht!

"var:this_state" statt "Test.Rollo.Sued.AutoBlnd.Rules.Suspend"

Wär natürlich super, vor allem weil ich die Selbstreferenz auf den aktuellen Zustand durchaus öfter verwende (Das Pattern mit enter_Xxx gefolgt von enter_Stay kommt bei mir immer wieder als Hilfszustand vor, nicht nur um Zeiten abzuwarten, sondern z.B. auch um abzuwarten, bis ein bestimmter Stellwert über-/unterschritten wird).

(Copy&Paste tauglicher, weniger Möglichkeiten für Tippfehler)

Ich habe mir eine eigene kleine "Entwicklungsumgebung" für sh.py gebastelt, die relative Adressierung unterstützt und auch sowas wie Dein "use" abdeckt (bei mir Template genannt). Insofern habe ich schon eine Copy&Paste unterstützung . Aber für andere ist das sicherlich eine Erleichterung.

"var:suspend_time" statt "1800" (dynamischer, könnte man aber auch über ein Item machen).

Das verstehe ich nicht so ganz: suspend_time wäre doch nur ein Verweis auf die global gesetzte bzw. am Autoblind-Item gesetzte as_suspend_time, oder? Ich finde natürlich, dass ein Zugriff auf diese Variable Sinn machen würde, aber inwiefern ist das dynamischer? Über ein Item ist es natürlich dynamisch, klar.

Das "as_agemax_Manuell" müsste mit der letzten Änderung schon durch "as_value_update_source" ersetzbar sein.

Deine aktuellste Änderung wird wohl erst über Weihnachten den Weg in mein System finden, noch keine Zeit gehabt, das zu holen. Aber das mit "as_value_update_source" ist klasse, da man damit ja auf das Event und nicht "hintenrum" über eine kurze Update-Zeit des Items reagiert.

Hier könnten dann auch die weiteren Bedingungen geprüft werden, ggf. müsste man da aber aus dem Manuell-Item per eval noch ein paar mehr Daten bereitstellen.

Weitere Bedingungen? Meinst Du "update_caller" und "update_dest"? Das wäre schön, aber ich fürchte, diese Infos sind nur beim trigger des Manuell-Items verfügbar, und nicht mehr, nachdem Dein plugin durch das Manuell-Item getriggert wurde, oder?

Auf jeden Fall danke ich Dir für Deine Unterstützung (selbst wenn ich sie gar nicht haben will ). Ich bin ja in vielen Fällen mit Hilfsitems um Probleme "drumrum" gekommen, aber wenn ich es kompakter und übersichtlicher formulieren kann, dann bin ich immer dabei. Es ist schon so, dass ich mit autoblind derzeit fast alle meine Abläufe löse. Und viel wichtiger: Meist funktioniert das, was man als Regelwerk ausdrückt, auch auf Anhieb - wenn es Probleme gibt, liegen die im unerwarteten sh.py-Verhlaten (wie z.B. die Tatsache, dass enforce_updates keine Auswirkung auf age() etc. hat).

Leider bin ich kein Python-Programmierer (ich kann es lesen, würde aber niemals so elegant die Lösungen hin bekommen), hoffe aber wenigstens als Ideenlieferant und Tester beitragen zu können.

Danke und Gruß, Waldemar

[mumpf]

Hallo offline,

nochmal zu den Variablen "var:xxx": Wäre es nicht sinnvoller (falls überhaupt möglich), diese Variablenwerte als Plugin-Funktionen zur Verfügung zu stellen, so dass man in einem "eval:" drauf zugreifen kann? Ich bastele gerade an einem eval, der den stateName genau so wie Du mit einer Ende-Zeit ausgibt. Da fiel mir auf, dass ich ja auch im eval den Zugriff auf "suspend_time" bräuchte, wenn ich die Regel davon abhängig mache...

Mir kam der Gedanke, dass man mit "eval:sh.autoblind('suspend_time')" irgendwie auch an die Variablen des aktuellen Items käme - und wenn es wirklich nur so kurz ginge, dann könnte man sich das var: schon fast sparen...

Gruß, Waldemar

[ivande]

Hallo offline,

kann im neuen "suspend_watch_xy" auch wie bisher ein ODER eingebaut werden?

as_suspend_watch_VisuOnly = Eg.Kueche.Jalousie.Tuer.AutoBlind.Position:Visu | Eg.Kueche.Jalousie.Tuer.AutoBlind.Lamellenposition:Visu

oder muss ich nun zwei suspend_watch_Position + suspend_watch_Lamellenposition anlegen?

Gruß Ivan

[offline]

Hallo Ivan,

nein, ein ODER geht da nicht, du musst mehrere Einträge machen (daher kann man die auch unterschiedlich benennen ...)

Grüße
offline

[offline]

(...)
Ich habe mir eine eigene kleine "Entwicklungsumgebung" für sh.py gebastelt, die relative Adressierung unterstützt und auch sowas wie Dein "use" abdeckt (bei mir Template genannt). Insofern habe ich schon eine Copy&Paste unterstützung . Aber für andere ist das sicherlich eine Erleichterung.

Habe ich gesehen, das stellst du ja in einem anderen Thread vor. Verwende ich jedoch bisher nicht, da ich daheim (dank ETS leider nur fast) Microsoft-frei arbeite.

Das verstehe ich nicht so ganz: suspend_time wäre doch nur ein Verweis auf die global gesetzte bzw. am Autoblind-Item gesetzte as_suspend_time, oder? Ich finde natürlich, dass ein Zugriff auf diese Variable Sinn machen würde, aber inwiefern ist das dynamischer? Über ein Item ist es natürlich dynamisch, klar.

Es ist in sofern dynamischer, dass du darüber mit deinem eigenen Zustand auf die Werte zugreifen kannst, die beim Item bzw. global gesetzt werden. Wenn du die Suspend-Zeit ändern willst, musst du nicht alle Zustände suchen und ändern, sondern kannst das an zentraler Stelle tun. Aber wahrscheinlich wird das in deinem Fall auch durch dein Template abgedeckt ...

Deine aktuellste Änderung wird wohl erst über Weihnachten den Weg in mein System finden, noch keine Zeit gehabt, das zu holen. Aber das mit "as_value_update_source" ist klasse, da man damit ja auf das Event und nicht "hintenrum" über eine kurze Update-Zeit des Items reagiert.

Weitere Bedingungen? Meinst Du "update_caller" und "update_dest"? Das wäre schön, aber ich fürchte, diese Infos sind nur beim trigger des Manuell-Items verfügbar, und nicht mehr, nachdem Dein plugin durch das Manuell-Item getriggert wurde, oder?

Was hälts du davon, wenn das Plugin auch das Manuell-Item überwacht und direkt die Statusermittlung triggert? Dann hätte man vollen Zugriff auf die Quelle der Änderung.

(...)

Leider bin ich kein Python-Programmierer (ich kann es lesen, würde aber niemals so elegant die Lösungen hin bekommen), hoffe aber wenigstens als Ideenlieferant und Tester beitragen zu können.

Ich bin eigentlich eher auch in C#, ABAP und PHP daheim ... Ideen und Tests helfen aber auf jeden Fall eine Menge. Vor allem, weil ich bei deinen Ideen auf eigene "Ideen" komme, was ich bei mir daheim alles noch so automatisieren kann ...

Grüße
offline

[offline]

Ich habe den heutigen Tag genutzt um einiges am AutoBlind Plugin zu tun. Ich habe testweise für einen meiner Raffstores eine Sperre und ein Suspend über Zustände gebaut, analog der Beschreibung von mumpf. Parallel habe ich auch den Ausschluss bestimmter caller/sources realisiert was sich als etwas tricky herausgestellt hat, aber letztendlich doch funktioniert.

Im Detail sind folgende Dinge geändert worden:

Trigger-Ursache
Die "besonderen" Bedingungen zur Prüfung der Trigger-Ursache wurden aus dem Branch "feature/suspend-limit" übernommen, sie sind aber umbenannt und heißen jetzt

trigger_item
trigger_caller
trigger_source
trigger_dest

Variablen
Bei Prüfungen und Actions können die Werte aus Variablen ermittelt werden. Prefix dafür ist "var:". Im Moment stehen drei Variablen zur Verfügung:

item.suspend_time --> Suspend_Time des jeweiligen Items
current.state_id --> Id des Zustands, in dem die Variable verwendet wird
current.state_name --> Name des Zustands, in dem die Variable verwendet wird

Die Variablen können auch über eine eval-Funktion zurückgegeben werden:

eval:autoblind_eval.get_variable(varname)

liefert den Wert der Variable "varname".

Sperre der Update-Routine
Beim Testen hatte ich das Phänomen, dass mehrere Items das Manuell-Item direkt nacheinander getriggert haben und daher die Update-Routine zweimal parallel aufgerufen wurde. Die Update-Routine hat daher eine interne Sperre bekommen, so dass sie erst wieder aufrufbar ist, wenn der erste Durchgang abgearbeitet ist.

Quell-Änderung der Trigger-Ursache
Die trigger_*-Bedingungen erhalten Informationen zum aktuellen Trigger, der das Update ausgelöst hat. Gerade wenn der Trigger über das Manuell-Item kommt sind diese Daten aber nicht unbedingt aussagekräftig (caller = "Eval", source = "<manuell_item>"). Für sinnvolle Prüfungen benötigt man eigentlich die Quell-Änderung, die die Kette der eval_trigger ausgelöst hat. Diese Quell-Änderung wird nun ebenfalls ermittelt und im Log angezeigt. Über die "besonderen" Bedingungen [CODE]original_item
original_caller
original_source{/CODE] stehen diese Daten auch für Bedingungen zur Verfügung.

autoblind_eval-Funktion "get_item"
Die neue autoblind_eval-Funktion "get_item" liefert eine Item-Id relativ zum AutoBlind-Hauptitem.

get_item(subitem_id, parent_level)

bewegt sich vom AutoBlind-Hauptitem um <parent_level> Ebenen nach oben und liefert von dieser Stelle aus das untergeordnete Item <subitem_id>.
Beispiele: AutoBlind-Hauptitem ist my.autoblind.item

get_item("anotheritem", 0)

liefert "my.autoblind.item.anotheritem"

get_item("anotheritem", 1)

liefert "my.autoblind.anotheritem"

get_item("anotheritem", 2)

liefert "my.anotheritem"
Dadurch können die Werte für die "besonderen" Bedingungen "trigger_item" bzw. "original_item" in Default-Konfigurationen hinterlegt werden, die Ermittlung der tatsächlichen Werte erfolgt dann in den abgeleiteten Bedingungssets. Für die Zukunft ist geplant, dass diese Funktion auch bei den as_item_<Bedingungsname/Aktionsname>-Attributen verwendet werden kann.

Wertlisten
Bei einer Bedingung "as_value_<Bedingungsname>" können nun mit "value:" nicht nur Einzelwerte, sondern auch Wertlisten angegeben werden. Die einzelnen Werte in der Wertliste werden dabei mit dem Zeichen "|" getrennt. Die Bedingung ist erfüllt, wenn der tatsächliche Wert ein Element der Wertliste ist. Wenn die Bedingung negiert ist, ist sie erfüllt, wenn der tatsächliche Wert nicht in der Wertliste enthalten ist.

Filtern von caller/source bei eval
Eine besondere Schwierigkeit war das Abprüfen des callers bzw. der source bei der Verwendung eines "Manuell"-Items. Über die neu eingefügten "besonderen" Bedingungen können bestimmte caller bzw. sources vom Auslösen des Suspend-Zustands ausgenommen werden. Wenn der Suspend-Zustand jedoch erreicht ist und solche Trigger kommen, wird jedesmal das Manuell-Item geändert und dadurch der Suspend-Timer zückgesetzt. Das ist unschön und nur zu verhindern, in dem man caller/source direkt in der Eval-Funktion im Manuell-Item prüft. Ich habe dafür im AutoBlind-Plugin zwei Methoden ergänzt, die für diese Prüfung verwendet werden können.

is_changed_by(self, caller, source, changed_by)

liefert True wenn die Quell-Änderung durch einen bestimmten caller/source ausgelöst wurde, ansonsten False

not_changed_by(self, caller, source, changed_by)

liefert True wenn die Quell-Änderung durch nicht einen bestimmten caller/source ausgelöst wurde, ansonsten False.
caller und source können dabei im eval direkt übernommen werden, changed_by ist eine Liste von callern und sources im Format "<caller>:<source>" gegen die geprüft werden soll. Für "caller" und "source" kann dabei jeweils auch "*" angegeben werden, was für alle caller bzw. sources steht.

Der Haken dabei ist, dass man aus der Eval-Funktion in das AutoBlind-Plugin greifen muss, was mit der aktuellen Version von smarthome.py nicht möglich ist. Abhilfe schafft hier ein Pull-Request, den ich bereits vor einiger Zeit auf github angelegt habe (#181, https://github.com/mknx/smarthome/pull/181). Hier wird eine Funktion zum direkten Zugriff auf ein Plugin bereitgestellt. Sollte jemand einen besseren Weg kennen, wie man Funktionen zur Verwendung in "eval" bereitstellen kann bin ich für jede Info dankbar.

Das eval-Attribut eines Items "test.rollo.manuell" kann dann beispielsweise wie folgt aussehen:

eval = not sh.test.rollo.manuell() if sh.return_plugin("AutoBlind").not_changed_by(caller, source, ["Init:*", "KNX:1.1.1"]) else sh.test.rollo.manuell()

Hierbei wird das Item nur umgeschaltet, wenn die Änderung nicht von der Initialisierung ("Init:*") oder von einer bestimmten physischen KNX-Adresse kam. Wenn das Item kein "enforce_updates" gesetzt hat, passiert ansonsten garnichts.

Ich denke, diese Lösung ist auch für Onkelandy besser, als die Lösung über die zusätzlichen as_suspend_watch_*-Attribute. In onkelandys Fall müsste das "Manuell"-Item dann bei als "as_suspend_watch" mit angegeben werden.


Die Änderungen habe ich gerade auf GitHub in den develop-Zweig gepusht. Die Änderungen aus den Zweigen "featre/update_conditions" und "feature/suspend_limit" werden nicht weiter verfolgt. Diese Zweige werden nicht in den develop-Zweig gemerged werden. Ich werde sie in den nächsten Tagen löschen.

Grüße
offline

[mumpf]

Hi offline,

wow! Das ist eine Menge Holz. Ich werde das sicher noch ein- bis zweimal lesen müssen, um alles zu verstehen, aber Du scheinst an alle Fälle gedacht zu haben. Im Nachhinein freue ich mich, dass ich heute keine Zeit hatte, Deine vorherigen Änderungen einzubauen

Ich hoffe, ich komme morgen dazu, sonst wird es erst was nach meinem Winterurlaub...

Danke und Gruß,
Waldemar

[Onkelandy]

Hi offline!

Wow, ich bin auch etwas erschlagen Das sieht alles sehr mächtig aus.. Was mir noch nicht ganz klar ist.. warum lässt sich die suspend_time nicht durch ein item:autoblind.settings.suspendXYZ setzen? das mit dem get_variable scheint mir etwas inkonsequent..?

Wie funktioniert das denn nun mit den autolock, suspend, id und name Items für die Autoblinds? Offenbar wird nun ja ALLES als State heran gezogen. Also meine Items landen nun alle in autostate_lock, weil ich die vier Autoblind-spezifischen Items als Erstes eingetragen habe. Wird das so bleiben, dass man diese vier Standarditems unter die tatsächlichen States schieben muss bzw. Lock und Suspend nun ein as_use bekommen sollten?

Vielen Dank erstmal. Im Großen und Ganzen scheint der Rest gut zu funktionieren, wobei ich die ganz neuen Features nicht getestet habe. Bräuchte da wohl konkretere Beispiele, um's zu kapieren

Gute Nacht!

[Onkelandy]

Konnte es nicht lassen. Mit dem Suspend funktioniert es, sofern man auch wirklich für jedes zu schaltende Objekt eigene Autoblind Einträge hat. Zumindest bei mir kam es sonst, dass sich das Manuell Item und Autoblind einen Kampf um Off/On gegeben haben. Ansonsten funzt das soweit..
Hier die Autoblind Config:

      
[autoblind]
[[default]]
[[[light_suspend]]]
            type = foo
            name = Ausgesetzt
            [[[[enter_Manuell]]]]
                as_agemax_Manuell = 1
            [[[[enter_Stay]]]]
                as_value_laststate = eval:autoblind_eval.get_item('suspend', 0)
                as_value_Manuell = 1
                as_max_age = 1800 # Alternativ item:xyz

Und dann im Item:

[kueche]
    [['l47_occhio']]
            type = foo
            as_plugin = active
            as_lock_item =  kueche.l47_occhio.autostate_lock
            as_laststate_item_id = kueche.l47_occhio.autostate_id
            as_laststate_item_name = kueche.l47_occhio.autostate_name
            as_item_Manuell = kueche.l47_occhio.SA.Manuell
            eval_trigger = kueche.l47_occhio.SA.Manuell | autoblind.lichttrigger | autoblind.settings.*.*.l47_occhio | kueche.l47_occhio.SA.BWM | kueche.l47_occhio.SA.Taster
            #as_suspend_watch = kueche.l47_occhio.SA
            #as_suspend_watch_IgnoreKnxReply = !kueche.l47_occhio.SA:KNX;1.1.1
            as_suspend_item = kueche.l47_occhio.autostate_suspend # obsolet?
            as_suspend_time = 3600  
            [[[night]]]
                type = foo
                as_use = autoblind.default.light_night
            [[[suspend]]]
                type = foo
                as_use = autoblind.default.light_suspend
            [[[kinomodus]]]
                type = foo
                as_use = autoblind.default.light_heimkino
....

Sehe ich das richtig, dass das Suspend_item sowie die suspend_watch Ansätze prinzipiell obsolet sind, wenn man's so macht wie oben, ja?

Ausgebrochen aus dem Suspend-Modus wird dann auch einfach, indem das Manuell Item auf False gesetzt wird?