"eval_on_trigger_only: True" sorgt für knx_send, ohne kein knx_send

[ralf9000]

Hallo,

ich weiß nicht, ob das so gewollt oder ein Fehler ist:

Aufgetauch ist es bei mir in SmarthomeNG v1.11.0, als ich einen uralten Rolladenaktor gegen eine neuen Weinzierl KNX IO 520 (1J21) tauschte. Dieser sendet während einer Fahrt ca. jede Sekunde die Position. In einem einfachen Positionskonfiguration alles kein Problem, aber mit eval-Ausdruck und "eval_on_trigger_only: True" taucht ein Problem auf, das bei der ersten Position, die vom Rolladenaktor gesendet wird, SmarthomeNG nun diese Position erneut auf den KNX mit dem Senden-KO sendet, dadurch kommt die Rolladenfahrt dann zum schnellen ungewollten Stop.

Meine Konfiguration sieht wie folgt aus:

                        Position:
                            type: num
                            knx_dpt: 5
                            knx_init: 4/3/210
                            knx_send: 4/2/210
                            eval: sh.Zentral.Rolladen.Position.Sued() if sh...Automatik() else None
                            eval_on_trigger_only: True
                            eval_trigger:
                                - ..Automatik
                                - Zentral.Rolladen.Position.Sued
​

Der Busmonitor zeigt dann diesen abrupten Stop:

Verhalten mit eval_on_trigger_only=True.jpg

Man sieht deutlich wie in vorletzter Zeile SNG einen Schreibbefehl zum KNX-Bus sendet, der Rolladenlauf kommt zum stehen. Verurscher erscheint mir die Zeile "evel_on_trigger_only: True", fehlt diese, wird auch nichts zurück gesendet und die Rollade fährt wie gewünscht zur Zielposition:

Verhalten ohne eval_on_trigger_only=True.jpg

Ist das ein Feature von "eval_on_trigger_only" oder ein Bug?

Grüße, Ralf

[Morg]

Versuche zuerst mal, statt `eval_on_trigger_only: True` besser `eval_on_trigger_only: true` zu schreiben. Auch wenn Python "True" erwartet, wird die Konfiguration von yaml interpretiert, und yaml kennt nur "true"...

[ralf9000]

Versuche zuerst mal, statt `eval_on_trigger_only: True` besser `eval_on_trigger_only: true` zu schreiben. Auch wenn Python "True" erwartet, wird die Konfiguration von yaml interpretiert, und yaml kennt nur "true"...

Das habe ich schon hinter mir, macht leider keinen Unterschied. In anderen Fällen klappt "true" und "True" gleich ...

[ralf9000]

So, ich habe jetzt weiter geforscht, das unnütze (und wahrscheinlich falsche) Senden des knx_send-Objekts gab es auch vorher schon, nur da hat es keine Auswirkung, weil ja die Soll-Position schon erreicht ist. Dieses ungewünschte Senden tritt nur auf wenn die Konfiguration mit

• eval: ... else None
• eval_on_trigger_only: True
• eval_trigger: ....

im Positions-Item auftritt. Das "else None" sollte eigentlich zu nichts führen (da Bedingung nicht erfüllt) und zudem sollte das wegen "eval_on_trigger_only: True" gar nichts machen. Trotzdem sendet er ....

Ralf

[stoepf]

Hier meine Idee, hoffentlich hab ich nichts übersehen.

                        Position:
                            type: num
                            knx_dpt: 5
                            knx_init: 4/3/210
                            eval: sh.Zentral.Rolladen.Position.Sued() if sh...Automatik() else None
                            eval_on_trigger_only: True
                            eval_trigger:
                                - ..Automatik
                                - Zentral.Rolladen.Position.Sued
                            on_change: .Senden = value if sh...property.last_change_by != knx:1.2.35:ga=4/3/210​ else None

                            Senden:
                                type: num
                                knx_dpt: 5
                                knx_send: 4/2/210

Vielleicht geht's auch ohne 2. Item.

Gruß Stefan

[stoepf]

Ohne eval_on_trigger_only wird auch ein Schreiben der Position (auch das vom Aktor oder falls du das irgendwo in der Visu machst) durch den eval Ausdruck geschickt. Dann wird jedesmal wieder die Position auf Zentral.Rolladen.Position.Sued gesetzt und der Rolladen verhält sich wie beobachet. Solltest du jetzt aber die Position des einzelnen Rolladen setzten wird ebenfalls Zentral...Sued angefahren.

[ralf9000]

Hallo Stefan,

Danke, aber ich wollte darauf aufmerksam machen, das sehr wahrscheinlich in der Implementierung von Smarthome in Zusammenhang mit KNX ein Fehler liegt, der Fehler ist das (nun erneute Senden durch Smarthome) des KNX-Objektes ohne Sinn, KNX wird empfangen und direkt wieder zurück gesendet, das macht keinen Sinn. Der Fehler wird auch an anderen Stellen in Erscheinung treten, da bin ich mir sicher ....

Umgehung habe ich schon, indem ich in dem Positionsattribut die eval-Ausdrücke hier gänzlich weg lasse und die Logik in anderen Items rein bringe. Allerdings unschön ....

Grüße,

Ralf

[aschwith]

Moin Ralph,

Ja, über das Problem bin ich auch schonmal gestolpert. Ist aus meiner Sicht ein Designproblem von SmarthomeNG. Ich habe das Thema schonmal mit Msinn besprochen , wir sind aber damals nicht weitergekommen. Das Problem ist folgendes:
1) Seit v10 hängt SHng beim Ausführen von evals dem caller Attribut ein Eval: voran. Dies Verhalten wurde neu mit der v10 eingeführt.
2) Ein Statusupdate von z.B. knx führt erstmal zu caller = knx.
3) Gibt es ein eval wird dann der caller auf eval:knx geändert und das Item getriggert.
4) In jedem plugin gibt es in der update Methode eine Codezeile
If caller != plugin_name
Damit soll verhindert werden, dass Statusupdates der Plugins direkt wieder als Befehl gesendet werden. Das greift aber nicht mehr, sobald zusätzlich ein eval im caller steht.
Lösung: In jedem plugin müsste der code in der update Methode leicht geändert werden. Schau dir dazu mal das Enocean Plugin an, dort habe ich es mal exemplarisch gemacht. Probier das gerne mal bei Dir aus.

VG
Alex

[ralf9000]

Hallo Alex,

vielen herzlichen Dank für die Erklärung, jetzt verstehe ich die Beobachtung.

Ich werde mir heute Abend nach der Arbeit mal das Plugin ansehen (mit meinen mangelhaften Python-Kenntnissen). So wie ich Dich verstanden habe, gibt es irgendwo in der Update-Methode eine Abfrage (ist jetzt nur logisch, noch kein Python-Code) "caller != knx" und die müsste in "( caller != knx AND caller != eval:knx )" geändert werden ....

Grüße,
Ralf

[aschwith]

Hi Ralph,

Ganz genau. Ich sehe gerade, dass ich die Enocean Änderung nur lokal habe, liegt nicht im Repository. Bin gerade unterwegs und kann es erst Ende der Woche hochladen. Versuch Dich mal dran, idealerweise stimmen wir einmal eine Lösung ab, die wir in alle Plugins ausrollen.
Viel Erfolg!

[ralf9000]

Hi,

ich habe jetzt nochmal nachgedacht: eigentlich ist das logisch nicht die richtige Stelle, wegen "eval_on_trigger_only: True" macht er ja gar nichts mit den eval-Ausdrücken, also sollte er doch dann nie aus "knx" eine "eval:knx" machen.

In meinen Augen wäre das die richtige Stelle, einfach bei einem KNX-Update wo mit "eval_on_trigger_only: True" ein Ausführen des eval-Statements ja gar nicht stattfindet, auch kein "eval:" davor zu schreiben. Ist das evtl. vergessen worden bei der Einführung mit v10 ???

Ralf

[Msinn]

Hi Ralph,

Ganz genau. Ich sehe gerade, dass ich die Enocean Änderung nur lokal habe, liegt nicht im Repository. Bin gerade unterwegs und kann es erst Ende der Woche hochladen. Versuch Dich mal dran, idealerweise stimmen wir einmal eine Lösung ab, die wir in alle Plugins ausrollen.
Viel Erfolg!

aschwith Schick mir mal was Du im Plugin gemacht hast. Ich schaue dann mal, ob man eine passende Lösung so implementieren kann, dass sie vor dem Aufruf des Plugins greift und nicht alle Plugins angefasst werden müssen.

[aschwith]

Hi Msinn,

ich habe die kleine Änderung ins plugin Repo geschoben. Kann es gerne wieder rausnehmen, wenn Du eine zentralere Lösung findest.

Danke Dir und besten Gruß!

[Msinn]

aschwith Ich habe die Stelle identifiziert wo ich den caller anpassen kann bevor update_item aufgerufen wird.

Dabei kam ich auf die Idee, ob man dort nicht auch zentral ` if caller != self.get_shortname():` prüfen könnte, ohne das in jedem Plugin machen zu müssen. (Diese Prüfung in der update_item Methode jedes Plugins rührt noch aus dem alten smarthome.py her). Ich bin mir jedoch nicht sicher, ob es Plugins gibt, die auch Code ausführen sollen, falls caller dem Shortname des Plugins entspricht.

[Morg]

Ich bin mir jedoch nicht sicher, ob es Plugins gibt, die auch Code ausführen sollen, falls caller dem Shortname des Plugins entspricht.

Ich meine, im smartdeviceplugin ist eine Mechanik, dass man das tun kann. Ich glaube, eins von Onkelandy s AV-Plugins nutzt sowas, müsste aber auch erst schauen. Wenn die Lösung ist, dass update_item nur aufgerufen wird, wenn caller nicht shortname oder fullname enthält, finden wir einen Weg, das auch im sdp umzusetzen.

Wäre es sonst auch möglich, auf caller.endswith(self.get_shortname/get_fullname) zu prüfen? Dann wären Prefixe wie eval oder so unerheblich...? (Müsste aber auch zentral oder in jedem Plugin umgesetzt werden...)