KNX switch vs switch-control

Allgemeine Fragen rund um die "Smart Home" Hardware/Komponenten

Moderatoren: seppy, udo1toni

Antworten
samy1928
Beiträge: 5
Registriert: 14. Sep 2020 17:07

KNX switch vs switch-control

Beitrag von samy1928 »

Hallo,
ich verstehe den Unterschied zwischen einem "switch" und einem "switch-control" nicht so ganz. Mir ist klar das, wenn
ein Schalter eine Rückmeldeadresse hat dann benutzte ich "switch" um die Rückmeldeadresse mit der Schaltadresse zu verbinden.
Soweit ich das verstanden habe, laut Doku soll ich einen "switch-control" benutzen wenn ich keine Rückmeldeadresse habe zu dem Schalter habe. Oder?
Aber ich verstehe den Vorteil darin nicht. Könnte mir das bitte jemanden erklären :) ?.
Danke und Mfg

Benutzeravatar
udo1toni
Beiträge: 9814
Registriert: 11. Apr 2018 18:05
Answers: 131
Wohnort: Darmstadt

Re: KNX switch vs switch-control

Beitrag von udo1toni »

Nein.

Da gibt es häufiger Verständnisprobleme. Aber vielleicht muss man noch ein bisschen vorher ansetzen:

Allgemein ist es so, dass ein an openHAB angebundenes System autark funktioniert. Das heißt, ich habe in dem System zum Beispiel einen Lichtschalter und ein Relais, welches von dem Lichtschalter betätigt wird. openHAB wird dazu nicht benötigt.
Oft nehmen die User an, dass sie von openHAB aus den Lichtschalter betätigen, aber das ist falsch! Es wird lediglich der Aktor (also das Relais) betätigt.
Weiterhin herrscht die Meinung vor, dass der Lichtschalter seinen Befehl an openHAB sendet. Das ist zwar schon korrekt, aber eigentlich nicht in dem Sinne richtig. Richtig ist vielmehr, dass der Aktor eine Information darüber ausgibt, welchen Status er hat (über die 2. GA). Der Befehl vom Lichtschalter kommt lediglich durch "Zufall" auch in openHAB an, da openHAB auch die erste GA empfängt.
Entsprechend kommen alle gesendeten GA in openHAB als Status an, nicht als Kommando.
Dieser Unterschied tritt bei knx unter bestimmten Bedingungen sehr deutlich zutage, z.B. wenn man knx Szenen verwendet, gibt es keinen Zusammenhang zwischen gesendeter GA und Schaltereignis mehr. Bei korrekt aufgesetztem System spielt das aber keine Rolle, alle Schaltzustände werden jederzeit korrekt angezeigt (vielleicht manchmal mit etwas zeitlicher Verzögerung...)
Weiterhin wird eine Rule in openHAB niemals auf received command triggern, wenn das Item aus knx heraus betätigt wurde.
Und genau an dieser Stelle kommt das *-control ins Spiel!
Channel, welche als *-control Channel angelegt sind, erhalten kein Status Update aus knx, sondern nur noch Kommandos, entsprechend triggert eine Rule mit received command.
Wenn man openHAB korrekt aufsetzt (ein korrekt eingerichtetes knx System vorausgesetzt), so werden alle Items mit dem Schlüssel autoupdate="false" versehen. Das führt dazu, dass nur Status Updates den Status des Items ändern, nicht ein vorher gesendeter Befehl.

Konkretes Beispiel:
Wir haben einen knx Schaltaktor, dessen Schalt-KO mit der GA 1/1/1 und 0/0/1 gekoppelt ist. Weiterhin ist das Status-KO des Schaltaktors mit der GA 1/1/2 gekoppelt. Für dieses KO ist das L-Flag gesetzt.
Wir haben zwei Wandtaster, der eine ist der normale Taster, um das Licht an- und auszuschalten. Er sendet auf der GA 1/1/1 und hat zusätzlich die GA 1/1/2 eingetragen(!) Der Taster ist als Toggle konfiguriert, der erste Tastendruck schaltet das Licht ein, der zweite aus und so weiter.
Der zweite Wandtaster soll ein Zentral Aus senden (eine beliebte Funktion...), und zwar über die GA 0/0/1. Der Taster sendet also bei jedem Druck OFF an den Aktor.
(Am Rande: in knx gibt es kein Toggle! Deshalb muss der Taster den Zustand des Aktors kennen, und das ist der Grund, warum die 1/1/2 als 2. GA eingetragen ist.)
Wenn knx korrekt eingerichtet ist, wird das Licht immer ein- und ausgeschaltet, wenn man den 1. Wandtaster betätigt, während der 2. Taster das Licht nur ausschaltet. Aber egal, ob das Licht bereits aus war oder vor dem Zentral Aus eingeschaltet war, wird der 1. Taster aus dem Zustand OFF heraus beim ersten Tastendruck das Licht einschalten, es ist nicht nötig, eventuell den Taster zweimal zu drücken!

In openHAB wird der Aktor nun so angelegt:

Code: Alles auswählen

Type switch : ch1 "Schaltkanal 1" [ ga="1/1/1+<1/1/2" ]
Da wir das Zentral-Aus auch auf Geräte wirken lassen wollen, welche nicht an knx hängen, brauchen wir noch den Taster als zusätzlichen Kanal:

Code: Alles auswählen

Type switch-control : all_off "Zentral Aus" [ ga="0/0/1" ]
AAAH! Hier brauchen wir zwar nicht zwingend ein *-control, aber die Funktion wird hier korrekt eingesetzt, da nun openHAB Befehlsempfänger ist.

Die zugehörigen Items reagieren nun folgendermaßen:
Wird in knx das Licht an- oder ausgeschaltet, so empfängt openHAB für ch1 den Status über die GA 1/1/2, ebenso fragt openHAB beim Start die GA 1/1/2 nach dem aktuellen Status, das heißt, openHAB zeigt von Anfang an den korrekten Status an.
Wird in openHAB das Licht geschaltet, so sendet openHAB den Befehl auf GA 1/1/1 und empfängt die Statusänderung wie gehabt auf GA 1/1/2 (mit autoupdate="false" wird der Status auch erst dann angepasst).
Wird Zentral Aus betätigt, empfängt openHAB ebenfalls die Statusänderung über 1/1/2, schließlich wurde das Licht ja ausgeschaltet. Zusätzlich empfängt es aber auch noch ein Kommando OFF auf dem Channel all_off, und eine Rule

Code: Alles auswählen

...
when
    Item knx_all_off received command OFF
then
...
wird triggern (wir gehen mal davon aus, dass dieses Item mit dem passenden Channel verlinkt ist...)
während die Rule

Code: Alles auswählen

...
when
    Item knx_ch1 received command
then
...
nur triggert, wenn man in openHAB das Licht schaltet, nicht aber, wenn es auf knx-Seite geschaltet wird.

Und weil das noch nicht verwirrend genug war ;) ...
openHAB tritt mit den *-control Channels gegenüber knx als Aktor auf. Es reagiert auf Read Requests (zumindest sollte das so ein) und es sendet Status Updates an knx! Das tut es aber (ganz wie im knx Standard definiert) ausschließlich auf der 1. GA. Und dieses Update wird nicht bei sendCommand gesendet, sondern bei postUpdate!!! Im Fall von Zentral Aus ist openHAB aber nicht zuständig, hier Dinge zu senden ;) das ist nur sinnvoll, wenn openHAB exklusiv als Aktor auftritt.
Wenn man z.B. eine Tradfri Lampe über einen knx Wandtaster ein- und ausschalten will und der Taster den Zustand der Leuchte signalisieren soll, kommt das zum Tragen. Man verknüpft den *-control Channel mit dem gleichen Item, wie die Tradfri Lampe, Befehle werden von knx nach Tradfri geleitet, Statusänderungen werden von Tradfri nach knx geleitet.
Das Zentral Aus sollte dann aber über eine Rule angedockt werden, um die Rückmeldung des Status zu unterdrücken.
openHAB2.5.12 in einem Debian-Container (Proxmox, LXC)

samy1928
Beiträge: 5
Registriert: 14. Sep 2020 17:07

Re: KNX switch vs switch-control

Beitrag von samy1928 »

Ich glaub ich muss mir ein Beispiel Szenario aufbauen um das besser zu verstehen. Aber vielen dank für detailliert Antwort. Mfg

Benutzeravatar
udo1toni
Beiträge: 9814
Registriert: 11. Apr 2018 18:05
Answers: 131
Wohnort: Darmstadt

Re: KNX switch vs switch-control

Beitrag von udo1toni »

Klar. Ansonsten, probiere es einfach aus. Nimm einen Schaltaktorkanal und verbinde ihn einmal mit einem switch channel, dann ändere den Channel auf switch-control.

Schau Dir jeweils an, was im Log von openHAB erscheint, wenn Du den Schaltaktor auf knx-Seite schaltest (bei switch kommt ausschließlich ein changed event, bei switch-control kommt ausschließlich ein received command).
openHAB2.5.12 in einem Debian-Container (Proxmox, LXC)

Antworten