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

[ralf9000]

Ich denke diese große Lösung ist wirklich für mein initiales Problem wenig zielführend. Mein initiales Problem war und ist, dass er ein "eval:" davorhängt, obwohl die eval-Statements mit "eval_on_trigger_only: true" gar nicht durchlaufen werden/wurden.

Meiner Meinung müsste man die Stelle im Code finden, wo die Bedingung für das Vorhängen und das Vorhängen selber zu finden ist und da noch reinbauen, wenn "eval_on_trigger_only: true" und eval_trigger nicht erfüllt, dann auch kein "eval:" davorhängen.

Ralf

[Msinn]

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

Ich habe es bei mir jetzt so implementiert (noch nicht gepusht), dass ein evtl. vorhandenes eval: im caller vor dem Aufruf von update_item gelöscht wird. Die update_item Methode sieht also nur den Shortname des Plugins.

Ich habe mich dabei nur gefragt, ob das Thema auch noch etwas genereller gelöst werden kann. Bei den Plugins, die ich nutze, ist jeweils der gesamte Code der update_item Methode in ein if caller != self.get_shortname(): geschachtelt und zur Vereinfachtung könnte man diese Abfrage vor den Aufruf von update_item ziehen, falls es nicht Plugins gibt, die in update_items auch etwas tun, wenn der Caller das Plugin selbst ist.

[Msinn]

Ich denke diese große Lösung ist wirklich für mein initiales Problem wenig zielführend.

Wenn der Fix von aschwith für Dich funktioniert, würde "die große Lösung" auch Dein Problem lösen (wäre also auch zielführend).

Meiner Meinung müsste man die Stelle im Code finden, wo die Bedingung für das Vorhängen und das Vorhängen selber zu finden ist und da noch reinbauen, wenn "eval_on_trigger_only: true" und eval_trigger nicht erfüllt, dann auch kein "eval:" davorhängen.

Nicht ganz... Die Lösung ist, wie ich im Post über diesem geschrieben habe, etwas einfacher: Falls der caller mit 'eval:' beginnt, das 'eval:' löschen, bevor update_item aufgerufen wird.

Die Frage nach der "großen Lösung" habe ich nur aufgeworfen, da ich für den Fix gerade die lib.item anfasse und das in dem Abwasch mit erledigt werden könnte.

[ralf9000]

Die Frage nach der "großen Lösung" habe ich nur aufgeworfen, da ich für den Fix gerade die lib.item anfasse und das in dem Abwasch mit erledigt werden könnte.

Ok, dafür reicht mein Verständnis der komplexen Zusammenhänge nicht, aber wenn es zu einer Lösung in absehbarer Zeit führt, ist es gut, auf jeden Fall bin ich sehr dankbar für Deine/Eure Hilfe. Bei mir steht der Austausch mehrerer Rolladenaktoren an und ich würde gerne diesen nehmen, weil er kompatibel mit Unterscheidung von manuellem und automatischem Modi zu den bisherigen ist. Nur er sendet wie gesagt beim Positionslauf diese Updates, die Smarthome extrem stören.

Nochmals Danke, Ralf

[Morg]

Ich habe mich dabei nur gefragt, ob das Thema auch noch etwas genereller gelöst werden kann. Bei den Plugins, die ich nutze, ist jeweils der gesamte Code der update_item Methode in ein if caller != self.get_shortname(): geschachtelt und zur Vereinfachtung könnte man diese Abfrage vor den Aufruf von update_item ziehen, falls es nicht Plugins gibt, die in update_items auch etwas tun, wenn der Caller das Plugin selbst ist.

Ich habe gefunden, was mir im Kopf herumging - das suspend-Item. Ist aber kein Problem, das ist einfach anzupassen. Von meiner Seite her keine Probleme.

[Onkelandy]

Ich glaube avdevice wäre kein Problem.
Aber möglicherweise das uzsu Plugin.
müsste bitte jemand testen, bin im Urlaub

[Msinn]

Ich habe mal in einige Plugin reingeschaut, die ich selber nicht nutze. Dabei habe ich z.B. ein Alexa Plugin gefunden, welches den Code nicht in "if caller != get_shortname()" schachtelt. Ob das nur nicht drin steht, weil es kein Problem schafft, oder ob bewusst Code bei "caller == get_shortname()" ausgeführt werden soll, ist mir dabei nicht klar.

Da es aber einige Plugins gibt, bei denen nicht klar ist, ob die 'große Lösung' Probleme schafft, werde ich erstmal nur die 'kleine Lösung' ('eval:' vor dem Aufruf aus dem caller entfernen) implementieren.

[aschwith]

Danke Msinn. Das klingt gut. Damit haben wir dann eine generische Lösung.

[Msinn]

aschwith Ich habe die Änderung in lib.item gepusht. Du kannst ja mal testen, ob das für Dich tut.

[stoepf]

Ich hab jetzt zufällig beim Autotimer genau das selbe Problem entdeckt.
Codezeile: https://github.com/smarthomeNG/smart.../item.py#L2664
msinn: da könnte man doch auch das caller_for_update_item benutzen, wenn man es vor die if-Abfrage zieht

Viele Grüße
Stefan

[aschwith]

Msinn, danke für die zentrale Lösung. Funktioniert bei mir. Habe die zusätzlichen dezentralen Zeilen aus meinen Plugins enfernt und läuft gut so. Thema für eval: damit aus meiner Sicht gelöst. Ich kann das gerne noch irgendwo dokumentieren, muss aber nochmal schauen, wo genau.

[Msinn]

stoepf Ich habe die Änderung für Autotimer noch mit eingebaut und pushe das nachher.