Verständnisfrage: KNX und SmartHomeNG

[Cannon]

Seit Monaten nutze ich nun schon SmartHomeNg und KNX. Je tiefer man aber einsteigt, je weniger ist mir klar, ob ich alles verstanden habe. ;-) Mir geht es um die item-Funktionen des KNX-plugins. Machen wir mal ein Beispiel:

Ich habe einen Schaltaktor, der über eine GA schaltet und über eine andere GA den Status schalten zurückgibt. Im Moment mache ich es so:

knx_init: Status-GA
knx_listen: Schalt-GA
knx_send: Schalt-GA

Laut Doku wäre aber das listen gar nicht notwenig, wenn ich init verwende. Deshalb ist eigentlich das ganze nicht korrekt. Mir ist nicht ganz klar, wie knx_status zu verwenden ist. Denn wenn ich das so mache:

knx_init: Schalt-GA
knx_send: Schalt-GA
knx_status: Status-GA

erscheint mir das auch nicht richtig. Denn der init-Wert sollte doch erst einmal der Wert sein, den der Aktor mir sendet, weil das der richtigere Zustand ist oder?

.. und dann gibt es ja noch knx_cache.

[MaHe]

Hallo.

Normalerweise brauchst du für die meisten Aktoren nur
knx_init: Status
knx_send: zum Schalten

Wenn du statt init cache verwendest, wird beim Starten von ShNG der Status nicht über den Bus ausgelesen, sondern der letzte bekannte verwendet. knx_listen kannst du dir in den beiden Fällen sparen, da automatisch mit integriert (das wartet sonst nur darauf, ob der Status von Bus gesendet wird)

[Cannon]

Normalerweise brauchst du für die meisten Aktoren nur
knx_init: Status
knx_send: zum Schalten

Das dachte ich mir eigentlich jetzt auch. Allerdings dennoch 2 Fragen:

1. Woher bezieht der den Wert, wenn ich knx_cache verwende? Ausgehend davon, dass ich SmartHomeNG neu gestartet habe?

2. Was ist mit knx_status? Bzw. Ohnehin wäre es ja manchmal eher sinnvoll den Status-Wert auszulesen, anstatt des Schaltwertest. Denn ein Tastsensor beispielsweise liest ja den Schaltwert auch nicht, sondern immer den Statuswert. Im Tastsensor ist der Schaltwert ja nur ein Ausgang.

[smai]

knx_cache liest aus dem Cache des knxd. Ist der Wert nicht vorhanden, wird wie beim init ein read auf dem Bus ausgelöst.

Du verstehst knx_status falsch. Dies hat nichts damit zu tun, ob es eine Schalt- oder Status-GA ist.
Der Unterschied ist in der Doku beschrieben.
Dies wird etwa dann gebraucht, wenn du ein andersweitig angebundenes Gerät als KNX-Gerät simulieren willst.

[Cannon]

Der Unterschied ist in der Doku beschrieben.

Naja trotz 10x lesen, habe ich es dennoch nicht verstanden. Zitat: "Ähnlich wie bei knx_send, sendet aber auch bei Änderungen über KNX, wenn sich der knx_status GA vom Ziel-GA unterscheidet."

Also für mich einfach nicht relevant. ;-)

[Msinn]

knx_status ist nur relevant, wenn ein SmartHomeNG Item sich wie ein KNX Gerät verhalten soll (wenn Du es vom KNX Bus aus ansprichst). Also wie in Deinem anderen Post (relative Dimmfunktion über 2 Lichtquellen).

[mumpf]

Hi,

eigentlich ist es ganz einfach, wenn man sich klar macht, wie KNX in Verbindung mit seinen Flags funktioniert. Einem KO sagst Du durch die Flags, wie es auf einzelne Protokolle reagieren soll. shNG hat Items als Pendant zum KO (also etwas, was einen Wert speichern und behandeln kann). Die knx_*-Attribute sind das Pendant zu den Flags.

knx_listen: Das Item bekommt den Wert der GA (entspricht dem S-Flag), wobei bei shNG knx_listen auch auf replies reagiert (was dem A-Flag entspricht)
knx_send: Der Wert des Items wird auf die GA geschrieben (entspicht dem Ü-Flag)
knx_reply: Der Wert des Items wird auf die GA geschieben, wenn die GA gelesen wird (entspricht dem L-Flag)

Da shNG eine Logikengine ist und Items nicht nur per KNX, sondern auch durch andere Ereignisse geändert/beeinflusst werden können (Visu, andere Plugins, andere Items, Logiken), gibt es noch weitere knx_*-Attribute:

knx_init: enthält knx_listen, nur wird beim Start von shNG auf die GA ein Read-Request abgeschickt, um den Wert zur Initialisierung (als Anfangswert) zu erhalten. Die Antwort auf den Read-Request wird durch das enthaltene knx_listen ausgewertet. Das KNX-Pendant hierzu sind Einstellungen in der Applikation, die so ähnlich heißen wie "Eingänge nach Busspannungswiederkehr abfragen".
knx_cache: enthält knx_init, nur wird zuerst versucht, den Wert der GA aus dem knxd-cache zu lesen. Wenn dies fehlschlägt, geht es wie bei knx_init weiter. Dazu gibt es kein Pendant im KNX, da es dort auch nicht so was wie einen knxd als Zusatzservice gibt.
knx_status: Ist wie knx_send, nur wird der Wert auf jeden Fall auf die GA geschrieben, auch wenn die Wertänderung durch ein knx_listen erfolgt ist. Ein knx_send macht das nämlich nicht. Deswegen ist knx_status "gefährlicher", damit kann man nämlich "Protokollschleifen" erzeugen, bei denen ein knx_status wieder (direkt oder transitiv) wieder zu einem knx_status führt und so den Bus zumüllt. Gedacht ist es für die Fälle, bei denen ein Item ausschließlich von einer anderen Quelle aus verändert wird (network plugin oder 1-Wire) und seine Werte dann immer auf den Bus senden soll. Sollte dann auch mit knx_reply verwendet werden.

Gruß, Waldemar

[Msinn]

Hallo Waldemar,

danke für die ausführliche Erläuterung. Die Erklärung übernehme ich gerne in die Anwenderdoku.

[Cannon]

eigentlich ist es ganz einfach, wenn man sich klar macht, wie KNX in Verbindung mit seinen Flags funktioniert.

Danke für die super Anleitung. Das hat mir auch gleich noch mal das Thema KNX-Flags näher gebracht. Denn auch damit habe ich mich bisher nicht beschäftigt. Es hat mich nur irretiert, wieso das lesen von GA's oftmals auch Aktionen ausgelöst hat und wieso dann auch meist noch eine Schreibaktion auf dem Gruppenmonitor zu sehen war. :-) Da lässt sich dann möglicherweise mit dem entfernen von Flags etwas entschlacken.

[mumpf]

Gerne.

Gruß Waldemar

[thesing]

Noch als Ergänzung: Es gibt inzwischen auch ein I-Flag in ETS. Dies funktioniert so wie knx_init. Allerdings unterstützen das noch nicht alle Geräte.
Siehe zu den Flags auch https://support.knx.org/hc/de/articl...03188089-Flags

[mumpf]

Es gibt inzwischen auch ein I-Flag

Mist, ich wusste dass ich was vergessen habe... Ich gehe mal davon aus, dass dann auch das A-Flag gesetzt werden muss, oder? Aber eigentlich ist das hier OT.

Gruß, Waldemar

[Cannon]

knx_reply habe ich jetzt des öfteren schon genutzt. Das funktioniert auch wie erwartet.

Was mir aber noch nicht ganz klar ist, ob man knx_init bzw. knx_cache durchaus mit knx_listen kombinieren kann? Das wäre z.B. sinnvoll beim Start von SMartHomeNG mit init den Wert aus dem Aktor auszulösen (Status) und auf einer anderen Gruppenadresse auf einen Tastendruck zu reagieren. Geht das?

[smai]

Funktionieren müsste das schon. Beachte aber, dass knx_init wie auch knx_cache gleichzeitig ein knx_listen implementieren. In deinem Beispiel würden also auch Statusänderungen des Aktors nach dem Start übernommen.

[mumpf]

Hi,

meiner Meinung nach wäre es ein Fehler, wenn es nicht gehen würde. knx_init kann ja logischerweise nur von einer GA kommen (um eindeutig zu bleiben), ein Item kann aber auf mehrere GA über knx_listen hören. Somit muss man neben der knx_init-GA auch weitere GA bei knx_listen angeben können.

Ich weiß auch, dass ich es zu sh.py-Zeiten genau so verwendet habe und glaube nicht, dass sich hier was in shNG geändert hat.

Gruß, Waldemar