Fehler in yaml-Script?

[Cannon]

Ich möchte meine Rollladen bei Dämmerung herunterfahren. Gleichzeitig sollen diese aber eine Stück geöffnet bleiben, wenn das Fenster offen ist. Leider funktioniert das Skript nicht so recht und der integrierte Syntax-Checker in SmartHomeNG hilft mir nicht so ganz weiter. Das gebe ich im Sytax-Checker ein:

if sh.EG.HWR.Fenster.geschlossen():
    sh.EG.HWR.Rollladen.move(True)
else:
    sh.EG.HWR.Rollladen.pos(76)

if sh.EG.WC.Fenster.geschlossen():
    sh.EG.WC.Rollladen.move(True)
else:
    sh.EG.WC.Rollladen.pos(76)

Und das ist das Ergebnis des Checkers:

%YAML 1.1
---
if sh.EG.HWR.Fenster.geschlossen(): sh.EG.HWR.Rollladen.move(True)
else: sh.EG.WC.Rollladen.pos(76)
if sh.EG.WC.Fenster.geschlossen(): sh.EG.WC.Rollladen.move(True)

Komischerweise werden die else-Statements immer abgeschnitten. Wo liegt denn der Fehler?

[mumpf]

Hi,

der Code ist python! Das hat mit yaml nichts zu tun.

Gruß Waldemar

[Msinn]

Abgesehen davon, dass Logiken in Python geschrieben werden (was Du auch hast), hilft eine Aussage wie

Leider funktioniert das Skript nicht so recht

nicht weiter um Dir zu helfen. Da der Code syntaktisch erstmal ok aussieht, fehlen Infos:

- Wie sind die Items definiert?
- Wie ist die Logik in der ../etc/logic.yaml definiert?
- Was funktioniert "nicht so recht"?
- Was steht im Log vonSmartHomeNG?

[bmx]

Hast Du für Deine Logik auch einen Trigger gesetzt wann das Skript ausgeführt werden soll?

Was passiert, wenn Du das Skript im Backend mal über ausführen startest?

Es hilft Fehler zu finden, wenn Du auch in Skripten eine Debugausgabe über den logger einbaust, z.B.

import logging
logger = logging.getLogger('logics.'+__name__)
logger.info('Aufruf Logik {}'.format(__name__))

if sh.EG.HWR.Fenster.geschlossen():
    sh.EG.HWR.Rollladen.move(True)
else:
    sh.EG.HWR.Rollladen.pos(76)

if sh.EG.WC.Fenster.geschlossen():
    sh.EG.WC.Rollladen.move(True)
else:
    sh.EG.WC.Rollladen.pos(76)
logger.info('Ende Logik {}'.format(__name__))

Jetzt kannst Du bequem im DEbuglog schauen, wo es hakt. Natürlich kannst Du auch weitere loggings einbauen.

Und bei allem was bei knx den gleichen Wert mehrfach bedeutet denke an die ggf. notwendige Nutzung von enforce_updates: yes
In Deinem Fall also bei den Items EG.HWR.Rollladen.move und EG.WC.Rollladen.move

[Cannon]

der Code ist python! Das hat mit yaml nichts zu tun.

Aber die Dateiendung heißt doch sogar yaml?

nicht weiter um Dir zu helfen. Da der Code syntaktisch erstmal ok aussieht, fehlen Infos

In der Überprüfung des Codes sind ja schon die "else" - Statements alle abgeschnitten. Ich habe deshalb gedacht da ist irgendwo ein Fehler.

Es hilft Fehler zu finden, wenn Du auch in Skripten eine Debugausgabe über den logger einbaust, z.B.

Das habe ich probiert. Danke für den Tipp. Alles läuft ordnungsgemäß durch.

Und bei allem was bei knx den gleichen Wert mehrfach bedeutet denke an die ggf. notwendige Nutzung von enforce_updates: yes
In Deinem Fall also bei den Items EG.HWR.Rollladen.move und EG.WC.Rollladen.move

Das heißt für mich, wenn ich mehrfach die gleiche Gruppenadresse benutze muss ich das nutzen. Mir ist nicht ganz klar, was diese enforce_updates macht. Aber ich nutze doch nicht den gleichen Wert mehrfach. Ist doch einmal HWR und dann WC .... ?!

[Msinn]

Aber die Dateiendung heißt doch sogar yaml?

Wenn Du es richtig machst ist die Endung einer Logik .py. Nur Konfigurationsdateien enden mit ,yaml

In der Überprüfung des Codes sind ja schon die "else" - Statements alle abgeschnitten. Ich habe deshalb gedacht da ist irgendwo ein Fehler

Mit einem Syntax Checker für yaml kannst Du keinen Python Syntax prüfen!

[bmx]

wenn ich mehrfach die gleiche Gruppenadresse benutze muss ich das nutzen. Mir ist nicht ganz klar, was diese enforce_updates macht.
Aber ich nutze doch nicht den gleichen Wert mehrfach. Ist doch einmal HWR und dann WC .... ?!

Doch das tust Du. Stell Dir mal vor Du schickst aus SmartHomeNG an den Rolladenaktor einen Befehl "runterfahren" und dann drückst Du irgendwo im Haus auf den Stop Button so das der Rolladen anhält.
Wenn Du ohne enforce_updates jetzt SmartHomeNG anweist nochmal runterzufahren dann weiß SmartHomeNG das das der gleiche Wert für die Gruppenadresse ist wie vorher. Daher wird der Wert nicht nochmal gesendet. Der Wert würde nur dann gesendet, wenn Du das Item auf hochfahren setzen würdest.
Das enforce_updates sorgt nun dafür, das der Wert ganz explizit nochmal gesetzt und damit auch gesendet wird egal ob das vorher der gleiche Wert war oder nicht.

Daher brauchst Du enforce_updates: yes bei allen Items woe Du z.B. auf den knx immer einen Trigger sendest. Also alle Fahren oder Stop Befehle, Zentral Aus oder ähnliches.

[Cannon]

Daher brauchst Du enforce_updates: yes bei allen Items woe Du z.B. auf den knx immer einen Trigger sendest. Also alle Fahren oder Stop Befehle, Zentral Aus oder ähnliches.

Ich verstehe das dennoch nicht. Und auch aus der Anleitung geht das so nicht hervor. Denn jede KNX-Gruppenadresse ändere ich ja auch von außen. Und wenn das bei jedem Element notwendig ist, welchen Grund gäbe es dann denn das nicht einzufügen.

Laut meinen Tests wird das auch so in SmartHomeNG aktualisiert. Allerdings ist natürlich die Frage, ob das nicht eher für die VISU beötigt wird, die dann Änderungen automatisch erkennt.

Wenn Du es richtig machst ist die Endung einer Logik .py. Nur Konfigurationsdateien enden mit ,yaml

Da habe ich wohl was durcheinander gebracht, weil ich die items manuell editiere und die Logiken aus dem Backend heraus. Und bei letzterem sehe ich ja die Endung gar nicht ... ;-)

[mumpf]

Das heißt für mich, wenn ich mehrfach die gleiche Gruppenadresse benutze muss ich das nutzen.

Hi,

das ist eine falsche Schlussfolgerung! enforce_updates ist für genau eine Sache da:

• normalerweise (ohne enforce_updates) leiten Items ihre Werte nur weiter, wenn der neue Wert anders ist als der alte.
  Wenn also ein Item z.B. von der Visu auf 1 gesetzt wird, und das Item vorher 0 war, geht das Item auf 1 und sendet den Wert an KNX weiter (genauer gesagt: An alle von diesem Item getriggerten Objekte, das sind Logiken, Plugins und andere Items).
  Wenn das Item schon 1 war und es erneut auf 1 gesetzt wird, passiert einfach gar nichts.
• Mit enforce_updates wird jede Item-Auktualisierung unabhängig vom Wert weitergeleitet, also auch bei gleichen Werten
  Wenn also ein Item z.B. von der Visu auf 1 gesetzt wird und es vorher schon den Wert 1 hatte, behält das Item seinen Wert und sendet es trotzdem an KNX weiter. So etwas brauch man immer nur bei Items, die Wiederholt den gleichen Wert gesetzt bekommen können und trotzdem was machen sollen. Üblich bei Szenen, absoluten Positionen, Fahrbefehlen, konstanten Werten.

Somit hat enforce_updates gar nichts mit mehrfacher Verwendung der gleichen GA zu tun. Und Du solltest es auf keinen Fall bei jedem Item einsetzen.

Gruß, Waldemar

[Msinn]

Ich verstehe das dennoch nicht. Und auch aus der Anleitung geht das so nicht hervor.

Nur als Nachfrage zur Verbesserung der Dokumentation: Was ist hier unklar?

[Msinn]

weil ich die items manuell editiere und die Logiken aus dem Backend heraus. Und bei letzterem sehe ich ja die Endung gar nicht ... ;-)

Sowohl in der Liste als auch auf der Editor Seite (oben) sehe ich ein .py. Wo wird es nicht angezeigt?

[Cannon]

So

Jetzt kannst Du bequem im DEbuglog schauen, wo es hakt. Natürlich kannst Du auch weitere loggings einbauen.

Also das mit den Loggings hat mir jetzt geholfen und der Fehler ist gefunden. Mir ist nicht aufgefallen, dass ich bei dem Log mehr als eine Seite habe und der leider nicht komplett auf einmal angezeigt wird. Und da war auch ein Fehler in der item-Zuweisung.

Nur als Nachfrage zur Verbesserung der Dokumentation: Was ist hier unklar?

Trotz Anleitung und trotz Erklärung verstehe ich es einfach nicht. Mir ist das schon unangenehm, aber irgendwie will die Logik nicht in meinen Kopf.

Normalerweise (ohne enforce_updates) leiten Items ihre Werte nur weiter, wenn der neue Wert anders ist als der alte.

• Wenn also ein Item z.B. von der Visu auf 1 gesetzt wird, und das Item vorher 0 war, geht das Item auf 1 und sendet den Wert an KNX weiter (genauer gesagt: An alle von diesem Item getriggerten Objekte, das sind Logiken, Plugins und andere Items).
  Wenn das Item schon 1 war und es erneut auf 1 gesetzt wird, passiert einfach gar nichts.
• Mit enforce_updates wird jede Item-Auktualisierung unabhängig vom Wert weitergeleitet, also auch bei gleichen Werten
  Wenn also ein Item z.B. von der Visu auf 1 gesetzt wird und es vorher schon den Wert 1 hatte, behält das Item seinen Wert und sendet es trotzdem an KNX weiter. So etwas brauch man immer nur bei Items, die Wiederholt den gleichen Wert gesetzt bekommen können und trotzdem was machen sollen. Üblich bei Szenen, absoluten Positionen, Fahrbefehlen, konstanten Werten.

Somit hat enforce_updates gar nichts mit mehrfacher Verwendung der gleichen GA zu tun. Und Du solltest es auf keinen Fall bei jedem Item einsetzen.

Mir ist ja wirklich schon peinlich nachzuhaken. Ich verstehe es aber dennoch nicht. Ich versuche es mal mit einem Beispiel - eben diese Rollläde hier. Ich öffne meine Visu und sehe die Rollläden. Die Position steht meinetwegen auf 50. Jetzt ändere ich von außen die Position mittels Tastsensor. Diese wird doch jetzt automatisch in die VISU übernommen richtig?

Entschuldige nochmal, dass ich das irgendwie nicht raffe ....

Sowohl in der Liste als auch auf der Editor Seite (oben) sehe ich ein .py. Wo wird es nicht angezeigt?

Habe ich wirklich nicht realisiert, weil ich das eben nicht "per Hand" bearbeite, sondern aus dem Backend und darauf gar nicht achte.

[Msinn]

Zum enforce_updates:

Zum Verständnis, vergiss erstmal Deine KNX Anbindung und versuche in "Items" zu denken.

Wenn sich der Wert eines Items ändert, löst das eine Reihe von Aktionen aus:

• eval Statements in anderen Items werden getriggert, wenn in anderen in den Items ein eval_trigger auf das geänderte Item verweist.
• on_change Definitionen des Items werden ausgewertet
• on_update Definitionen des Items werden ausgewertet
• Plugins, die mit diesem Item verbunden sind, erhalten eine Info über den neuen Wert

Wenn ein Item ein Update erhält, welches identisch zu dem bisherigen Wert ist, passiert nur folgendes;

• on_update Definitionen des Items werden ausgewertet

Wenn jetzt in SmartHomeNG ein Item den Wert True erhält (und vorher False war), passiert genau das im ersten Fall beschriebene.

Wenn das Item erneut den Wert True erhält (und ja vorher True war), passiert das im zweiten Fall beschriebene. Plugins erhalten also keine Info, dass das Item ein Update mit dem selben Wert erfahren hat.

Erst wenn das Item auf False wechselt, werden die Plugins über den Wechsel des Wertes informiert.

Wenn Du jetzt in Deinem Fall immer wieder nacheinander z.B. das Item stop auf True setzt, ohne dass irgendwoher das Item zwischendurch auf False gesetzt wurde, wird das KNX Plugin nur im ersten Fall die Info erhalten und ein True auf die Gruppenadresse senden. Ein erneutes senden auf den KNX Bus würde erst erfolgen, wenn das Item vorher auf False gesetzt wurde.

Dieses Verhalten kann für Fälle wo es sinnvoll ist (wie für das stop), angepasst werden. Wenn Du für das Item enforce_updates auf True setzt, wird immer verfahren wie im ersten Fall. Auch wenn sich der Wert nicht ändert. Es wird also immer, wenn dem Item ein True zugewiesen wird, win KNX Bus Telegram ausgelöst.

[Msinn]

Habe ich wirklich nicht realisiert, weil ich das eben nicht "per Hand" bearbeite, sondern aus dem Backend und darauf gar nicht achte.

Aber diesen Teil der Doku hast Du gelesen, oder?

[Cannon]

Dieses Verhalten kann für Fälle wo es sinnvoll ist (wie für das stop), angepasst werden. Wenn Du für das Item enforce_updates auf True setzt, wird immer verfahren wie im ersten Fall. Auch wenn sich der Wert nicht ändert. Es wird also immer, wenn dem Item ein True zugewiesen wird, win KNX Bus Telegram ausgelöst.

Grundsätzlich ist verstehe ich die Problematik. Allerdings lese ich doch den Wert des Items (ob Stop oder nicht) auch ein. Das heißt, wenn jemand per Tastsensor "Stop" drückt, dann weiß doch SmartHomeNG das, weil es doch eine Info bekommt? Die Logik sieht doch so aus, dass Stop False ist, dann True wird und danach wieder False ist. Damit ergibt sich doch ständig ein Wechsel oder?