Automatische Beschattung

[offline]

Hallo Ivan,

die Implementierung der Attribute "as_suspend_watch_*" ist wesentlich komplexer als das Aufbauen eines separaten Suspend-Zustands zumal man mit dem separaten Suspend bzw. Lock-Zustand noch flexibler ist, als mit zusätzlichen "as_suspend_watch_*" Attributen. Ich habe mich daher entschieden, dass diese Attribute nicht in den Develop-Zweig aufgenommen werden. Ich bin ehrlich gesagt auch am überlegen, die Lock- und Suspend-Funktionalität komplett aus dem Plugin rauszunehmen, so dass diese Funktionen grundsätzlich über entsprechende Zustände gebaut werden müssen. In den nächsten Tagen werde ich die Doku mal auf den aktuellsten Stand bringen und das Vorgehen zum Aufbau von eingenen Lock/Suspend-Zuständen dort einbauen. Es gibt da auch noch einige weitere "Zustandskonstruktionen" die ich in den letzten Tagen gebaut habe und die allgemein Interessant sein könnten.

Für deine eigene Bedingung kannst du dich eigentlich recht eng an mein Beispiel halten.

• Das Item "Manuell" musst du anpassen, bei eval_trigger müssen alle Items aufgeführt werden, die den Suspend Auslösen sollen.
• Statt "not_changed_by" verwendest du "is_changed_by" und gibst nach caller und source noch

  ["Visu:*"]

  mit

Damit wird das Suspend nur ausgelöst, wenn ein Item über die Visu geändert wird.

Grüße
offline

[ivande]

Hallo Offline,

die Funktion "as_suspend_watch_VisuOnly = xy.Jalousie.Position:Visu" wird somit nicht weiter eingebaut?
wie benütze ich stattdessen die Prüfung via "trigger_caller"?

Gruß Ivan

[offline]

Guten Morgen Onkelandy,

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..?

Ich habe gerade eine neue Änderung in den develop-Zweig gepust, mit der as_suspend_time, as_startup_delay und as_repeat_actions auch den plugineigenen Datentyp "AbValue" unterstützen und man die Werte damit auch über items bzw. ein eval setzen kann.
Für die weitere Verwendung beispielsweise in den Bedingungen (siehe unten) ist meiner Meinung nach der Zugriff über die Variable (unabhängig ob über "var:suspend_time" der "eval:autoblind_eval.get_variabe("suspend_time ")") geschickter. Das hat zwei Gründe:

• Wenn bei einem Item keine separate "suspend_time" angegeben hat, so enthält die Variable den Wert der in der Plugin-Konfiguration definierten suspend_time_default.
• Der Wert des Items könnte sich in der Zwischenzeit geändert haben. Die Variable enthält den Wert, mit der das Plugin aktuell arbeitet. Dieser Wert wird zwar auch bei Bedarf aktualisiert, aber sicher ist sicher ...

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..
(...)

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?

Ja, wenn man das über eigene Zustände macht, braucht man keine as_suspend_item und as_suspend_watch Attribute.

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

Wenn du das "Manuell"-Item so aufbaust, wie mumpf es beschrieben hat, dann wechselt dieses Item bei jeder manuellen Aktion seinen Wert. Daher ist es ungeschickt, in der Suspend-Bedingung auf den Wert des Manuell-Items abzuprüfen. Sonst deaktiviert sich der Suspend-Zustand ggf. bei der zweiten Manuellen Aktion wieder. Ich habe das bei mir so gemacht, dass ich auch die Sperre über einen Zustand realisiert habe, der vor dem Suspend definiert ist. Dadurch wird der Suspend-Zustand beim Setzen der Sperre aufgehoben. Man kann es aber auch so machen, dass man weiterhin ein suspend-item hat, das den Suspend-Zustand anzeigt. Dieses Item setzt mal im Zustand "Suspend" auf 1, in allen anderen Zuständen auf 0. Im Bedingungsset "enter_stay" des Suspend-Zustands kann man nun prüfen, ob dieses Item noch auf "1" ist. So kann man den Suspend-Zustand durch setzten des Suspend-Items auf 0 wieder verlassen.

Die Steuerung für meinen Test-Raffstore ist im Moment wie folgt aufgebaut:
Default-Konfiguration:

    [[default]]
        [[[Lock]]]
            type = foo
            name = Gesperrt
            as_set_suspend = False
            [[[[enter]]]]
                as_value_lock = True
        [[[Suspend]]]
            type = foo
            name = Suspend
            as_set_suspend = True
            [[[[enter_manuell]]]]
                as_value_trigger_source = eval: autoblind_eval.get_item("manuell",1)
            [[[[enter_stay]]]]
                as_value_laststate = var:current.state_id                            
                as_agemax_manuell = var:item.suspend_time
                as_value_suspend = True

AutoBlind-Konfiguration für den Raffstore:

[room]
[[raffstore]]
[[[seite]]]
[[[[automatik]]]]
    [[[[[lock]]]]]
        type = bool
        knx_dpt = 1
        knx_send = x/x/x
        knx_listen = x/x/x
        visu_acl = rw
        cache = on
    [[[[[suspend]]]]]
        type = bool  
        knx_dpt = 1                                     
        knx_send = x/x/x
        knx_reply = x/x/x
        knx_listen = x/x/x
        visu_acl = rw
    [[[[[manuell]]]]]
        type = bool
        name = Manuelle Bedienung
        eval = not sh.room.raffstore.seite.automatik.manuell() if sh.return_plugin("AutoBlind").not_changed_by(caller, source, ["Init:*", "KNX:x.x.x"]) else sh.room.raffstore.seite.automatik.manuell()
        eval_trigger = room.raffstore.seite.aufab | room.raffstore.seite.step | room.raffstore.seite.hoehe | room.raffstore.seite.lamelle                    
    [[[[[autoblind]]]]]
        type = bool
        as_plugin = active
        eval_trigger = autoblind.trigger | room.raffstore.seite.automatik.manuell | room.raffstore.seite.automatik.lock | room.raffstore.seite.automatik.suspend
        as_item_manuell = room.raffstore.seite.automatik.manuell
        as_item_lock = room.raffstore.seite.automatik.lock
        as_item_suspend = room.raffstore.seite.automatik.suspend
        [[[[[[Lock]]]]]]
            as_use = autoblind.default.Lock
        [[[[[[Suspend]]]]]]
            as_use = autoblind.default.Suspend
        (...)

Grüße
offline

[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?

[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!

[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

[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

[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]

Hallo Ivan,

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

Grüße
offline

[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

[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

[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

[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 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

[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.