Ah. Es gibt beim knx Binding eine Besonderheit, die es von allen anderen Bindings unterscheidet.
Zunächst mal ist Kommunikation fast immer gerichtet, über einen Kanal (nicht Channel!) kommen Nachrichten nach openHAB, über einen anderen Kanal gehen Nachrichten aus openHAB in Richtung der Hardware.
Im Thing werden gewöhnlich beide Richtungen zu einem Channel zusammengefasst. Beispiel mqtt: da gibt es ein
stateTopic und ein
commandTopic (getrennte Wege rein/raus), der Channel selbst ist aber sowohl für Befehle als auch für die Status zuständig.
Weiterhin wird grundsätzlich ein von außen kommendes "Datenpaket" als Status gewertet, ein abgehendes Datenpaket wird grundsätzlich durch einen Befehl ausgelöst - entsprechend den beiden Methoden
.postUpdate() für den Status und
.sendCommand() für den Befehl.
"Grundsätzlich" heißt aber, dass es Ausnahmen gibt. Bei verschiedenen Bindings (z.B. mqtt) kann man einen Channel dann als Command markieren (
isCommand=true), das heißt, ein ankommender "Status" wird nun als Befehl weitergeleitet. Bei anderen Bindings läuft es über spezielle Event Channel, die dann als Event in Rules verwendet werden können.
In knx ist es so, dass man jeden Channeltyp zweimal hat, einmal "normal", einmal als "control" Variante. Es gibt also z.B.
switch und
switch-control.
Bei
switch-control wird ein
kommendes Datenpaket dann als
Befehl gewertet und auch so an den internen Bus weitergeleitet - das verlinkte Item wird per
.sendCommand() angesprochen.
Zusätzlich werden bei knx Statusänderungen - also was per
.postUpdate() im Item landet - an die *.control Channel weitergeleitet.
Auf diese Weise ist es möglich, z.B. eine mqtt Schaltsteckdose
direkt mit einem knx Wandtaster anzusteuern - mitsamt Rückmeldung des Schaltzustands,
ohne eine einzige Zeile Code.
Mit dem Profile "follow" kann man einen Channel dazu bewegen, jede Statusänderung eines Items als Befehl zu werten (und somit an die angebundene Hardware weiterzuleiten). Das funktioniert für alle Bindings, ob sie das nun von Haus aus unterstützen oder nicht.
Für die Weiterleitung von externen Messwerten auf den knx Bus ist aber die control-Variante die saubere Wahl.
z.B. (wie immer als Text Definition):
Things:
Code: Alles auswählen
Thing ntp:ntp:local [ ... ]
Bridge openweathermap:weather-api:api "OpenWeatherMap Account" [ ... ] {
Thing weather-and-forecast local "Local Weather And Forecast" [ ... ]
Bridge knx:ip:bridge [ ... ] {
Thing device virtuell "GA ohne Device" {
Channels:
Type dateTime-control : time [ ga="10.001:15/7/1" ]
Type number-control : temp [ ga="15/7/2" ]
}
}
Item:
Code: Alles auswählen
DateTime Zeit "Zeit" { channel="ntp:ntp:local:dateTime", channel="knx:device:bridge:virtuell:time" }
Number Temperatur "Temperatur" { channel="openweathermap:weather-and-forecast:api:local:current#temperature", channel="knx:device:virtuell:temp" }
Mehr braucht es nicht, um Zeit und Temperatur auf den Bus zu bringen. Da ich auf der Arbeit bin, sind die Things ausgedacht, aber es geht ja auch nur ums Prinzip
