Fensterkontakte inkl. gekippt (Logik)

[Msinn]

Hier das Beispiel zur Nutzung der relativen Item Adressierung:

Im ersten Schritt habe ich die Item Struktur etwas angepasst (noch ohne relative Adressierung), so dass der Raum nur noch in einem Item Namen vorkommt:

Test:
    Buero:
        v:
            type: num
            knx_dpt: 1
            knx_cache: 4/1/5
            visu_acl: rw

        g:
            type: num
            knx_dpt: 1
            knx_cache: 4/1/6
            visu_acl: rw

        zu:
            type: bool
            enforce_updates: yes
            eval: True if sh.Test.Buero.v() == 1 and sh.Test.Buero.g() == 1 else False
            eval_trigger:
              - Test.Buero.g
              - Test.Buero.v

        gekippt:
            type: bool
            enforce_updates: yes
            eval: True if sh.Test.Buero.g() == 1 and sh.Test.Buero.v() == 0 else False
            eval_trigger:
              - Test.Buero.g
              - Test.Buero.v

        offen:
            type: bool
            enforce_updates: yes
            eval: True if sh.Test.Buero.g() == 0 and sh.Test.Buero.v() == 0 else False
            eval_trigger:
              - Test.Buero.g
              - Test.Buero.v

Nun können die absoluten Referenzen (Test.Buero) durch die relative Referenz auf ein Geschwister-Item (..sister) angepasst werden Dabei wird aus Test.Buero.v ..v.
Zu beachten ist, dass im eval wo ja ein sh. vorangestellt werden muss dann 3 Punkte stehen, also sh...v()

Test:
    Buero:
        v:
            type: num
            knx_dpt: 1
            knx_cache: 4/1/5
            visu_acl: rw

        g:
            type: num
            knx_dpt: 1
            knx_cache: 4/1/6
            visu_acl: rw

        zu:
            type: bool
            enforce_updates: yes
            eval: True if sh...v() == 1 and sh...g() == 1 else False
            eval_trigger:
              - ..g
              - ..v

        gekippt:
            type: bool
            enforce_updates: yes
            eval: True if sh...g() == 1 and sh...v() == 0 else False
            eval_trigger:
              - ..g
              - ..v

        offen:
            type: bool
            enforce_updates: yes
            eval: True if sh...g() == 0 and sh...v() == 0 else False
            eval_trigger:
              - ..g
              - ..v

Nun kann der gesamte Block unterhalb von Buero: unter einen anderen Raum kopiert werden, ohne dass nachfolgend noch etwas angepasst werden muss.

[mumpf]

Zu beachten ist, dass im eval_trigger wo ja ein sh. vorangestellt werden muss dann 3 Punkte stehen, also sh...v()

Hi Martin,

kleiner Tippfehler: Oben muss statt "eval_trigger" ein "eval" stehen, dann stimmt es.

Gruß, Waldemar

[Msinn]

mumpf Danke, so was passiert wenn man unter Zeitdruck ist...

[magiczambo]

Msinn : Danke für deinen Beitrag, auch wenn ich schon alles mittels Copy & Paste; Suchen & Ersetzen absolut gemacht habe . Aber für die Zukunft ist das natürlich schicker.

[magiczambo]

Andere Frage. Kann ich in diesem Beispiel aus dem Wiki:

 
 # items/sensor.yaml Temperatur:     Trigger:         # Wird wahr, wenn die Temperatur über 20 Grad wird und falsch, wenn nicht.         type: bool         eval: 1 if sh.Temperatur() > 20 else 0         eval_trigger: Temperatur

dem Trigger auch gleich eine GA mit geben?
Also das bei erreichen einer Temperatur eine GA geschrieben wird? Oder muss ich das separat machen?

[mumpf]

Hi,

natürlich, das geht, dafür sind die Items da. Jedes Item kann eine beliebige Kombi der beschriebenen Attribute haben und die lösen dann auch das beschriebene Verhalten aus. Also in Deinem Beispiel

knx_dpt: 1
knx_send: 1/1/1

würde dann eine 1 schreiben, wenn die Temperatur erreicht worden ist. Wobei man in den Fällen, in den shNG.py der Wertelieferant ist, wohl eher

knx_dpt: 1
knx_status: 1/1/1
knx_reply: 1/1/1

nehmen würde, dann kann das Item auch über knx gelesen werden.

Gruß, Waldemar

[magiczambo]

Ok danke.

Habe gerade noch ne kleine Blockade:

Ich brauchte eine Kombination aus einer Schalt GA und einem Temperatur Sensor.

Hatte mir das so in der Art vorgestellt:

Diverses:
    Dusche_Heizung:
        Schalten:
            type: num
            knx_dpt: 1
            knx_send: 1/1/60
            knx_listen: 1/4/60
            visu_acl: rw
            enforce_updates: yes
            eval: 1 if sh...trigger() == 1 else 0
            eval_trigger:
              - ..trigger

        temp:
            ow_addr: 28.9C37F2040000
            ow_sensor: T
            type: num
            visu: 'yes'
            sqlite: 'yes'
            knx_send: 2/1/11
            knx_reply: 2/1/11
            knx_dpt: 9
            visu_acl: rw
            enforce_updates: yes
        trigger:
            # Wird wahr, wenn die Temperatur über 26 Grad wird und falsch, wenn nicht.
            type: num
            enforce_updates: yes
            eval: 0 if sh...temp() > 26  else 1
            eval_trigger:
              - ..temp
              - ..Schalten

Ich will das quasi so habe, dass wenn ich die Duschheizung einschalte und Temp > x Grad ist, dass die wieder ausgeschalten wird ansonsten eingeschalten bleibt. Zugleich sollte die Heizung ausgeschalten werden wenn die Temperatur im Velauf X Grad übersteigt. Leider habe ich wohl nen Knoten im Kopf.

[magiczambo]

keiner ne Anregung?

[Sandman60]

Mach es mit einer Logik. M.E. ist es für einen Eval zu komplex und führt genau zu der erwähnten Blockade

[bmx]

Nur so 'ne Idee:

Diverses:
    Dusche_Heizung:
        Schalten:
            type: bool
            knx_dpt: 1
            knx_send: 1/1/60
            knx_listen: 1/4/60
            visu_acl: rw
            enforce_updates: yes
            eval: True if sh...temp() < 26 and value else False
            eval_trigger:
                - ..temp

        temp:
            ow_addr: 28.9C37F2040000
            ow_sensor: T
            type: num
            visu: 'yes'
            sqlite: 'yes'
            knx_send: 2/1/11
            knx_reply: 2/1/11
            knx_dpt: 9
            visu_acl: rw

[magiczambo]

Nur so 'ne Idee:

Danke mal klingt schlüssig, allerdings wäre hier im worst case die Heizung für einen cycle eingeschalten trotz Überschreitung der Temperatur da der eval_trigger erst bei Änderung bzw. Schreiben von temp ausgeführt wird oder?

[magiczambo]

Ich glaube um auf Nummer sicher zu gehen werde ich dass jetzt ein bißchen anders lösen. Ich benutze das Sperrobjekt des Aktorkanals ist irgendwie galanter finde ich.

Diverses:
    Dusche_Heizung:
        Schalten:
            type: num
            knx_dpt: 1
            knx_send: 1/1/60
            knx_listen: 1/4/60
            visu_acl: rw
            enforce_updates: yes

        temp:
            ow_addr: 28.9C37F2040000
            ow_sensor: T
            type: num
            visu: 'yes'
            sqlite: 'yes'
            knx_send: 2/1/11
            knx_reply: 2/1/11
            knx_dpt: 9
            visu_acl: rw
            enforce_updates: yes

        Sperre:
            # Wird wahr, wenn die Temperatur über 26 Grad wird und falsch, wenn nicht.
            type: num
            knx_dpt: 1
            knx_send: 1/7/60
            knx_listen: 1/7/60
            enforce_updates: yes
            eval: 0 if sh...temp() < 26  else 1
            eval_trigger:
              - ..temp

Gibt es noch eine Möglichkeit, der "Sperre" zu sagen, dass Sie nicht auf den Bus schreiben soll, wenn sich ihr Wert nicht verändert? Sonst wurde ja alle 2 min (cycle=120) die "Sperre" auf den Bus geschrieben.

[Sandman60]

Ja, lass das enforce_updates weg. Aber hat Deine Sperre nicht die gleiche GA wie Dein schalten?

Und trotzdem... und Du denkst wirklich das Du dieses Syntax und Logik in 2-3 Jahren noch verstehst und warten kannst?

[magiczambo]

Ja, lass das enforce_updates weg.

Ah ok gut.

Aber hat Deine Sperre nicht die gleiche GA wie Dein schalten?

Nein. Ich benutze das Sperrobjekt des Aktors (AKS 2016.02)

Und trotzdem... und Du denkst wirklich das Du dieses Syntax und Logik in 2-3 Jahren noch verstehst und warten kannst?

Ja wieso? So kompliziert ist das doch jetzt nicht!

[Sandman60]

Hi, wegen der Sperr-GA: Sorry, hatte mich verlesen, sah für mich gleich aus.

Bzgl. eval: Kompliziert nicht, aber es wird schnell komplex wenn du bei Eval durch die Brust ins Auge schießt. Habe selbst die Erfahrung aktuell gemacht, dass ich bei einigem Code rund 1-2 Jahre lang gar nix mehr gemacht habe und dann hat es meist lange gedauert bis ich mich in die Hinrwindungen wieder hineingefunden habe...
Eine Logik kannst Du halt m.E. einfacher dokumentieren und der Code selbst ist weniger kryptisch als der Eval...