Trigger einer Logik funktioniert nur von KNX aus

[Giase]

Hallo zusammen,



Ich habe eine Logik, die mir die mir für Thermostate die absolut gesetzten Sollwerte auf den entsprechenden Basis-Sollwert mapped. Da dieser Basis-Sollwert wiederum eine Änderung des finalen Sollwerts (=Basis + Verschiebung) haben kann, kann das zu ziemlich hässlichen Schleifen führen. Deshalb wollte ich den Trigger separat als item anlegen:


items.conf:

[Dachgeschoss]
    [[Buero]]
        [[[Temp]]]
...
            [[[[settrigger]]]] # set temperature only and avoid loops
                visu_acl = rw
                type = num
                knx_dpt = 9
                knx_listen =    0/2/7
            [[[[set]]]] # set temperature
                visu_acl = rw
                type = num
                sqlite = yes
                knx_dpt = 9
                knx_send =      0/2/7
                knx_listen =    0/2/2
                knx_init =      0/2/2
...

logic.conf:

[MapSollwert]
    filename = map_sollwert.py
    watch_item = Dachgeschoss.Buero.Temp.settrigger

Aus SmartVisu rufe ich das ganze so auf:

Dachgeschoss.Buero.Temp.set(Wert)

Das hat zur Folge, dass auf dem KNX-Bus die Adresse 0/2/7 entsprechen auf WERT gesetzt wird. Allerdings wird die Logik nicht getriggert. Wenn ich zum Testen per ETS die Adresse 0/2/7 auf einen Wert setze, wird die Logik getriggert.

Kann mir jemand sagen, warum das so ist und mir evtl auch noch gleich erklären, wie ich das ändern kann? Ich habe schon ein bisschen mit "enforce_update" gespielt, das hat aber auch nichts gebracht.

Vielen Dank schonmal!

Gruß,
//giase

[smai]

Mir ist die Ausgangslage nicht ganz klar, aber wenn das watch_item der Logik auf Dachgeschoss.Buero.Temp.settrigger gesetzt ist, wird die Logik natürlich bei setzen von Dachgeschoss.Buero.Temp.set nicht getriggert.

Aber wieso ist die Zeile [MapSollwert] auskommentiert?
Und wie genau rufst du aus smartVISU Dachgeschoss.Buero.Temp.set(Wert) auf?

[mumpf]

Hi,

ich bin auch nicht sicher, ob ich Dein Problem korrekt verstehe.

Du sagst, dass nach

Dachgeschoss.Buero.Temp.set(WERT)

der WERT auf 0/2/7 geschrieben wird. Das passiert aber nur, wenn WERT ungleich dem vorherigen Itemwert ist.

Danach erwartest Du, dass bedingt durch knx_listen = 0/2/7 der Wert von

Dachgeschoss.Buero.Temp.settrigger

auf den WERT gesetzt wird. Hast Du das überprüft? Ich würde auch erwarten, dass dies passiert.
Die abhängige Logik MapSollwert wird allerdings nur getriggert, wenn der neue WERT ungleich dem alten Wert von settrigger ist. Wenn die Logik immer getriggert werden soll, musst Du bei settrigger ein

enforce_updates = true

setzen.

Dir sollte auch klar sein, dass beim senden von WERT auf 0/2/2 zwar das Item

Dachgeschoss.Buero.Temp.set

auf WERT gesetzt wird, aber dieser WERT nicht auf die 0/2/7 gesendet wird. Wenn Du das willst, musst Du statt knx_send = 0/2/7 ein knx_status = 0/2/7 nutzen.

Bitte überprüfe diese Dinge erstmal und schreibe dann genau, was nicht funktioniert bzw. was Du genau getestet hast.

Gruß, Waldemar

[Giase]

Hi und Danke schonmal für die Antworten!

Waldemar, du hast da im Prinzip richtig verstanden.

Noch ein bisschen mehr Hintergrund:
In SmartVisu brauche ich zum Setzen und Auslesen des Sollwertes ein einziges Item. Das ist in meinem Fall

Dachgeschoss.Buero.Temp.set

Das hat in einem Fehlerfall (z.b. update eines items hinkt dem Auslesen hinterher wenn viele updates kurz aufeinander folgen) dazu geführt, dass folgendes passiert ist:

Dachgeschoss.Buero.Temp.set(WERT) -> Logik (arbeitet auf altem Wert für Basis-Temp) -> triggert update von 0/2/2 -> Triggert Logik -> triggert update von 0/2/2 -> ...

Deshalb wollte ich zur Sicherheit als Trigger für die Logik nur 0/2/7 verwenden, und nicht 0/2/2. Soll heißen ich wollte vermeiden dass ein 0/2/2 update wieder die Logik triggert. (Ich glaube mittlerweile ist die Logik robust genug, dass zumindest danach kein update mehr folgen sollte, aber ich traue dem ganzen noch nicht).

Ich hatte bis jetzt immer ein

enforce_updates = yes

(nicht "true") verwendet, da ich das mehrmal so habe und auch dachte dass das funktioniert.

Zu dem hier:

Hast Du das überprüft? Ich würde auch erwarten, dass dies passiert.

Ich habe zumindest im Busmonitor gesehen, dass 0/2/7 gesendet wird. Ich vermute dass smarthome irgendwie "weiß", dass es den Wert gerade selbst geschrieben hat, und es deswegen nicht

Dachgeschoss.Buero.Temp.settrigger

auslöst.

Zur Frage von smai:

Und wie genau rufst du aus smartVISU Dachgeschoss.Buero.Temp.set(Wert) auf?

            {{ device.rtr('buero_heizen', 'Temperatur', 'Dachgeschoss.Buero.Temp', 'Dachgeschoss.Buero.Temp.set', 'Dachgeschoss.Buero.Temp.mode', 'Dachgeschoss.Buero.Temp.mode', 'Dachgeschoss.Buero.Temp.mode', 'Dachgeschoss.Buero.Temp.state') }}

Ich kann gerade nicht ran, versuche das aber später zu schaffen.

[mumpf]

Hi,

wie gesagt, ich würde erwarten, dass ein knx_listen auf eine GA ein Item auf jeden Fall aktualisiert (außer das Item hat schon diesen Wert). Ich könnte mir aber vorstellen, dass es für folgende Situation coding gibt:

[itemname]
    type = bool
    knx_dpt = 1
    knx_listen = 2/3/4
    knx_send = 2/3/4

In diesem Fall willst Du nicht, dass direkt nach dem knx_send gleich ein knx_listen aufgerufen wird. Für das gleiche Item ist das sinnlos. Ich kenne den code nicht, aber es könnte sein, dass der Empfang über knx_listen für eine soeben gesendete GA grundsätzlich unterdrückt wird und nicht nur für das sendende Item.
Wäre meiner Meinung nach falsch, könnte aber trotzdem der Fall sein.

Ich kann Dir leider keine einfache Lösung für Dein Problem sagen, dazu müsste man das Gesamtszenario kennen. Mein Gefühl ist, dass Du zur Loopvermeidung Deine Idee der Item-Trennung konsequent durchziehen musst. Manuelle Änderungen (von der Visu oder über KNX 0/2/7) gehen immer nur an settrigger, triggern die Logik und diese setzt dann set. Wie die 0/2/2 da rein passt, weiß ich nicht.

Gruß, Waldemar

[Giase]

Hi Waldemar,

Ich habe eine ähnliche Vermutung, und habe ziemlich viel experimentiert um das rauszufinden. Es scheint schon so zu sein dass das so einfach nicht geht. Eine andere Möglichkeit wäre, mal zu versuchen SmartVISU anzupassen, damit man den set-sollwert und read-sollwert dort trennen könnte... Alles nicht so straight-forward.

Zudem habe ich immer wieder gemerkt, dass meiner Berker Taster sehr suboptimal dazu sind. Z.B. musste ich feststellen, dass man die Basis-Temperatur zwar schreiben, aber nicht auslesen kann. Hätte ich nicht so erwartet und es hat mich einige Zeit gekostet, das rauszufinden.

Zusätzlich habe ich ein Problem wenn ich am Taster die Sollwertverschiebung ändere. +0.5 führt zum Beispiel dazu, dass zuerst der neue Sollwert auf dem KNX landet, und dann erst die KNX GA für die Sollwertverschiebung auf +0.5 upgedated wird. Das führt dazu dass die Logik in dem Fall von den +0.5 noch nichts weiß und mit 0.0 rechnet... Alles in allem ziemlich Bescheiden.

Ich werde den ganzen Ansatz nochmal überdenken müsssen... Dachte eigentlich ich kann das einfach mal schnell hinschreiben und dann passts...

Danke für Eure Hilfe! Meldet euch bitte trotzdem falls euch noch was dazu einfällt.

Gruß,
//giase

[smai]

Eine andere Möglichkeit wäre, mal zu versuchen SmartVISU anzupassen, damit man den set-sollwert und read-sollwert dort trennen könnte.

In der develop-Version gibt es als 11. Parameter item_offset, könnte das dein Problem nicht lösen?

Es ist übrigens irgendwann geplant, dass man bei jedem Widget mehrere Items angeben kann (siehe Issue 137). Das wäre dann wie die hörenden GA bei KNX. Aber für 2.9 wird das leider nichts mehr.

[Giase]

In der develop-Version gibt es als 11. Parameter item_offset, könnte das dein Problem nicht lösen?

Ich denke das könnte mein Problem lösen... Ich versuch das evtl. mal. Kannst du mir hier kurz nen link posten, wo ich die aktuelle dev-version herbekomme? (Ist schon eine Zeit lang her...) Wann ist denn 2.9 und Nachfolger geplant?

Danke Dir!

[smai]

Unter https://github.com/Martin-Gleiss/smartvisu/tree/develop oder per

git clone -b develop https://github.com/Martin-Gleiss/smartvisu.git

Wann ist denn 2.9 und Nachfolger geplant?

Wenn alle aus meiner Sicht zwingenden Issues erledigt sind, siehe auch in #246.

Ich glaube, ich mache bald einen Wiki-Artikel dazu auf

[Giase]

Danke Dir!