Ein paar Fragen

[HenryBlake]

Die Doku konnte meine Fragen nicht gänzlich beantworten, deshalb noch ein paar Fragen.

Ist das WOL-Skript http://mknx.github.io/smarthome/_mod...s/wol.html#WOL obsolet? Es wird ja auch nicht mitinstalliert.
Hatte es testweise mal eingebunden, leider ohne Funktion. (Falls es noch aktuell ist, poste ich die Fehlerbeschreibung)

Wenn knx_init genutzt wird, ist die knx_listen überflüssig?

Was ist der genaue Nutzen von knx_listen, -init?
Klar er lauscht auf dem Kanal ob Statusänderungen geschrieben werden und aktualisiert sie für sich mit, aber
habe das Gefühl ich nutze es falsch, ich sehe häufig das für send und listen/init zwei verschiedene GA genutzt werden.
Ist mir noch nicht ganz klar

Auszug aus meinem Code:

        [[[LEDBand]]]
            type = bool
            visu_acl = rw
            knx_dpt = 1
            knx_listen = 5/0/81
            knx_send = 5/0/81
            [[[[dimmen]]]]
                type = num
                visu_acl = rw
                knx_dpt = 5
                knx_send = 5/1/81
                knx_init = 5/1/81
                .
                .
                .

Danke für deine Mithilfe

[DerSeppel]

Aus der Doku:

knx_listen

You could specify one or more group addresses to monitor for changes.

knx_init

If you set this attribute, SmartHome.py sends a read request to specified group address at startup and set the value of the item to the response. It implies ‘knx_listen’.

Warum man unterschiedliche Adressen nutzt kann verschiedene Gründe haben. Beispiel: Du willst den Init-Wert von einer speziellen Adresse mit L-Flag, nachher dann aber auch die Status-GA von einem Schaltaktor hören. (Wobei man die auch i.d.R. lesen kann)

In deinem Beispiel sendest und hörst du auf der gleichen GA. Sicher dass es in deinem Fall so richtig ist?

[mumpf]

Hi,

das mit den knx_* Attributen hat weniger mit sh.py-Doku zu tun, sondern mit der Tatsache, dass KNX ereignisorientiert ist. Im KNX hat jedes KO auch Flags, die das Verhalten des KO gegenüber dem Bus beschreiben. Ein sh.py-Item ist gegenüber dem KNX-Bus nichts anderes als ein KO, dem eine oder mehrere GA zugeordnet werden. Die knx_* Attribute beschreiben auch das Verhalten gegenüber dem Bus, sind somit mit den Flags vergleichbar. Durch den Ansatz mit knx_* Attributen kannst Du sogar verschiedenen GA unterschiedliche Flags geben, das geht bei einem "normalen" KO nicht.

Ein Item durchlebt einen "lifecycle", und auf diesen kann man über Attribute Einfluss nehmen:

• Beim Start von sh.py werden alle Items erstmal erzeugt, ein Item hat dann noch keinen Wert.
• Dann wird das Item initialisiert, dazu können verschiedene Attribute verwendet werden, z.B. value = 0, aber auch knx_init oder knx_cache. Bei knx_init wird wirklich ein Lesetelegramm auf den Bus geschickt, um den initialen Wert zu ermitteln. Bei knx_cache wird der eibd gefragt, ob er den Wert aus seinem internen cache liefern kann. Wenn ja, geht das schnell, wenn nein, gibt es wieder ein Lesetelegramm.
• Wenn das Item einen Wert hat und sonst alle Initialisierungen durchlaufen hat, kann es nun seine Funktion übernehmen: Werte über irgendeinen Kommunikationskanal empfangen und diese über alle Kommunikationskanäle senden - aber immer nur wenn es gewünscht ist. Dazu gibt es:
  • knx_listen: Das hört auf eine (oder mehrere) GA und sobald auf dieser GA ein Wert gesendet wird, übernimmt das Item diesen Wert
  • knx_cache: Funktioniert wie knx_listen, aber es kann nur eine GA angegeben werden.
  • Natürlich auch alle möglichen anderen Plugins, Logiken, Trigger, die Werte verändern können, die hier aber nicht Thema sind.
• Natürlich soll ein Item seine Wertänderung auch senden können, dazu gibt es:
  • knx_send: Hier können eine oder mehrere GA eingetragen werden, das Item sendet seine Wertänderung auf alle angegebenen GA, sofern die Wertänderung nicht durch den KNX-Bus (knx_listen, knx_cache) veranlasst wurde
  • knx_status: Wie knx_send, nur wird immer eine Wertänderung gesendet, auch wenn sie durch den KNX-Bus veranlasst wurde
  • Auch hier wieder alle möglichen anderen Plugins, die Werte senden können...
• Und last but not least will man auch ein Item über den KNX-Bus nach seinem Wert fragen können, damit z.B. ein Taster beim Neustart seine Status-LEDs korrekt setzen kann:
  • knx_response: Hier gibt man die GA an, auf deren Leseanfrage reagiert werden soll. Über diese GA wird dann auch die Antwort gesendet.

Das sind alles "natürliche" Funktionen, die sich durch den Bus ergeben. Meiner Meinung nach fehlt noch eine Art knx_listen, der aber nur auf "Write"- und nicht auf "Response"-Telegramme reagiert, aber das hätte ich bisher nur einmal gebraucht.

Best Practices hierbei:

• knx_init / knx_listen, wenn sie beide auf die gleiche GA gehen, unbedingt durch knx_cache ersetzen
• knx_listen / knx_send sollte eher unterschiedliche GA haben: knx_listen hört auf eine Status-GA, während knx_send die Schalt-GA bedient.
• knx_status sollte man meiden bzw. wissen, wann man es verwendet, und dann ergibt sich (fast) immer, dass man auf die gleiche GA auch ein knx_response macht.
• knx_status sollte nie (zumindest ist mir kein Fall bekannt, wo das sinnvoll wäre) die gleiche GA haben wie knx_init, knx_cache oder knx_listen.

So, das ist erstmal etwas Theorie, zu Deinem Beispiel oben kann man allgemein nur sagen, dass knx_listen und knx_send eher unterschiedliche Adressen haben sollten (s.o.). Es gibt fälle, bei denen die gleiche Adresse Sinn macht, aber da sollte man wissen, was man tut und Deine sehr algemeine Frage impliziert, dass Du dieses Wissen noch nicht hast. Also würde ich eher sagen, so nicht. knx_send auf die Schalt-GA (Aktor-Eingangs-Kommunikationsobjekt), knx_listen (oder besser: knx_cache) auf die Status-GA (Aktor-Ausgangs-Kommunikationsobjekt) .

Gruß, Waldemar