Update durch Logic

[ivande]

Beim Start von SH 1.9.3 werden bei mir einige Item's durch "Logic" getriggert. Da eines dieser Items als Folge auch ein priv_plugin triggert, führt dies zu unerwünschten Reaktionen.

Wie kann ich herausfinden durch welche "logic" die Item beim starten getriggert werden? Im Log finde ich am entsprechenden Zeitpunkt 11:58:11 keinen Logeintrag.

trigger_by_logic.jpg
Gruß Ivan

[Msinn]

Da hilft es nur, die Wertezuweisungen in Logiken mit der Quelle zu versehen. Ich habe das bei mir in allen Logiken gemacht.
Also zum Beispiel statt:

    sh.wohnung.wohnen.tuer.liftfreigabe(False)

die Zuweisung so

    sh.wohnung.wohnen.tuer.liftfreigabe(False, 'Logic '+logic.name)

machen. Dann erscheint auch der Name der Logik in update durch bzw. change durch.

[ivande]

danke für die Hilfe,

ich hab's bei den Wertzuweisungen in allen meinen Logiken eingebaut. Hat leider nichts gebracht.. immer noch "update durch Logik".
Anschließend hab ich komplett alle Logiken deaktiviert (logic.yaml komplett geleert) und immer noch das gleiche "update durch Logik"

Das Update des Items beim Hochfahren des Systems (beim Starten von SH) kann dann wohl nur von einen Plugin kommen?

[Msinn]

Du hast keine Wertzuweisung übersehen?

Wie ist das Item denn definiert (eval bzw. Plugin spezifische Attribute)?

Du könntest für das Item einen Change-Log definieren (als WARNING). Dann siehst Du im Log genauer wann die Wertzuweisung erfolgt.

[ivande]

ich hab doch noch eine Wertzuweisung innerhalb eines eval gefunden! - das auslösende Item (set-item) wird nur von "Init" getriggert.
Wird bei "Init" das eval auch ausgelöst - bzw. kann ich das verhindern?

Das Problem - beim Starten von SH öffnet mir seit kurzem das Dachfenster, und auch die Raffstoren beginnen sich selbstständig zu machen. Ich hab das schon einige Jahre ohne einen Trigger beim Starten von SH so am Laufen. (stateengine ist zu dem Zeitpunkt wo der Spuk beginnt, noch nicht angelaufen, da 5Minuten Start-Verzögert).

Was ich geändert habe - ich bin mit dem komplette System von einer VirtuellenMaschine (PC) auf einen raspy3b+ umgezogen, da ich den PC für einige Zeit außer Betrieb nehmen möchte,.. alle notwendigen Dateien (Items,. Konfigs, Datenbank, VisuPage, auf das raspi-Image kopiert). Bis auf das etwas langsamere Starten und das Selbstständigmachen beim Starten vom Dachfenster, und Raffstoren, ... läuft alles wie bisher auf der virtuellenMaschine.

Hatte am Raspi am ersten Tag noch SH1.9.2 im Einsatz, und bin dann auf 1.9.3 ge-gitpullt. Mit 1.9.2 war das Problem aber auch schon am Raspy.

Dachfenster:
    Auf_ab:
        type: bool
        visu_acl: rw
        enforce_updates: True
        knx_dpt: 1
        knx_send: 4/2/114​
    State:

    set_item:​
        eval: sh.Dachfenster.Auf_ab(value)
        eval_trigger: Dachfenster​.State
        enforce_updates: True

[Msinn]

Evals werden seit jeher bei Start von SmartHomeNG ausgewertet. Bisher gibt es keine Möglichkeit das zu verhindern/abzuschalten.

Ich schaue mal in den Code ob (und ab welcher Version) Änderungen am Code das geänderte Verhalten Deiner Installation erklären könnten. Welche Version von SmartHomeNG hattest Du in der virtuellen Maschine laufen?

[ivande]

auf der virtuellen Maschine lief auch 1.9.2 - vielleicht hat es mit dem langsamen Start am Raspi zu tun,..

das Init ausklammern könnt ich damit versuchen:

sh.Dachfenster.Auf_ab(value) if not sh.Dg.Flur.Dachfenster.Auf.property.last_update_by.startswith('Init') else None

[ivande]

sh.Dachfenster.Auf_ab(value) if not sh.Dg.Flur.Dachfenster.Auf.property.last_update_by .startswith('Init') else None

damit ist das Problem gelöst.

last_update_by liefert ein "Init:None" deshalb noch das startswith('Init') dazu

Ich hab die VirtuelleMaschine nochmal gestartet. Da werden die Item's auch durch Init getriggert, nur blieb dort das Dachfenster stehen - eigentlich hätte es dort auch aufgehen sollen - da hatte ich einfach Glück bisher,..