Fensterkontakte inkl. gekippt (Logik)

[Msinn]

Hallo Waldemar,

nein da hat sich bei shNG nichts geändert. Das reload der Logiken von sh.py und den bisherigen Versionen ist eine Teillösung gewesen. Dabei wird nur der Bytecode der Logik eu geladen. Eine Veränderung an der Konfiguration (watch_item, cycle, crontab) wurde jedoch nicht berücksichtigt.

Ab dem kommenden Release, werden beim Reload einer Logik die bestehenden Trigger entfernt und die Trigger werden neu aus der Konfiguration geladen. Dadurch kannst Du ohne Neustart die vollständige Logik Funktionalität abändern.

[mumpf]

Hi Martin,

jetzt bin ich aber überrascht. Ich konnte doch schon immer im cli ein reload logic bzw. ein trigger logic machen. Zumindest noch zu sh.py-Zeiten. Hat sich da was in shNG.py geändert?

Gruß, Waldemar

[Msinn]

Was ich bei eval in Items auch unschön finde, will ich daran mal etwas ändern, muss ich erst SmartHomeNG neu starten, eine Logik kann ich einfach zur Laufzeit neu laden.

Vollständig funktioniert das editieren und neu Laden von Logiken aber erst mit dem kommenden Release von shNG.

[magiczambo]

Was ich bei eval in Items auch unschön finde, will ich daran mal etwas ändern, muss ich erst SmartHomeNG neu starten, eine Logik kann ich einfach zur Laufzeit neu laden.

Ok das wäre ein Argument ;-)

[ratzi82]

Ich denke das ist wirklich Geschmackssache, ich bin auch kein großer Fan von eval, finde eine separate Logikdatei wesentlich übersichtlicher und praktischer, Verwendung von debug Log Ausgaben usw.
Was ich bei eval in Items auch unschön finde, will ich daran mal etwas ändern, muss ich erst SmartHomeNG neu starten, eine Logik kann ich einfach zur Laufzeit neu laden.

[magiczambo]

Ich finde die eval-Lösung anschaulicher, zumindest solange es so einfache evals sind und man passende Kommentare spendiert. Alleine schon deswegen, weil es dann direkt am Item steht und nicht in irgendeiner Datei, die ich dann extra öffnen muss, um es zu verstehen.

Für mein Verständnis ist es am Item ohne Logik auch "schöner". Kommentierung, Dokumentierung vorausgesetzt.
Wobei das für mich immer gilt, egal ob ich eine Logik o.ä. bastle. Ohne Doku, Komment werde ich nach einer gewissen Zeit immer erstmal Fragezeichen haben.

Bzgl. eval: Kompliziert nicht, aber es wird schnell komplex wenn du bei Eval durch die Brust ins Auge schießt.

Ist das echt so verquer? Ich find es relativ straight. Nachdem Temp Item dann das Sperr Item, dass durch das drüber stehende Temp Item getriggert wird.

[mumpf]

Eine Logik kannst Du halt m.E. einfacher dokumentieren und der Code selbst ist weniger kryptisch als der Eval...

Hihi,

ich glaube, wir hatten das schon mal... Ich finde die eval-Lösung anschaulicher, zumindest solange es so einfache evals sind und man passende Kommentare spendiert. Alleine schon deswegen, weil es dann direkt am Item steht und nicht in irgendeiner Datei, die ich dann extra öffnen muss, um es zu verstehen.

Aber so gehen die Ansichten auseinander...

Gruß, Waldemar

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

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

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]

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.

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

[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

[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

[magiczambo]

keiner ne Anregung?