Are you sure your KNX Binding is working fine (besides the described problem)? Can you for example switch a light?
A knx communication object will never send on more than one GA, itās always only the first GA which is used to send.
If you want to send on more than one GA, you have to use more than one channel. furthermore, there is no real difference between a command and a status in question of knx bus (although there is some differenceā¦)
Please be aware that a communication object will always react to a read request if the R-Flag (or L-Flag in Germany) is set to true, regardless, which GA is requested. The communication object will always answer on the first GA.
You have to link the channel to an Item to use it. Please consider to use much shorter names like this:
Thing:
Bridge knx:ip:bridge "My knx bridge" [
//...
] {
Thing device virtual "virtual channels" {
Type switch-control : ch1 "switch" [ ga="0/1/6+0/0/6" ]
}
}
Item:
Switch ZentralfunktionFernsehen "Szene Fernsehen" { channel="knx:bridge:device:virtual:ch1" }
Now you should receive commands to GA 0/0/6 and 0/1/6 on Item ZentralfunktionFernsehen and openHAB should send the status of ZentralfunktionFernsehen to GA 0/1/6.
1 Like
Many thanks for your your quick response.
I think you meant
channel="knx:device:bridge:virtual:ch1"
in the item definition
Switch ZentralfunktionFernsehen "Szene Fernsehen" { channel="knx:device:bridge:virtual:ch1" }
After trying around to solve my issue with your hints I found 2 Problems in my setup.
a) apparently xxx-control works only if I do not add a āaddress=ā in the thing-definition.
Bridge knx:ip:bridge [
type="TUNNEL",
ipAddress="10.10.1.50",
portNumber=3671,
localIp="10.10.20.80",
readingPause=50,
readRetriesLimit=3,
autoReconnectPeriod=20,
localSourceAddr="1.0.245"
] {
Thing device generic [
fetch=false,
// donĀ“t use: address="1.0.246"
pingInterval=300,
readInterval=0
] {
b) my ETS5 groupmonitor does not display messages sent from OH. (devices on the bus do get the messages, though).
seems like a problem with my ets, or EIBD gateway or so.
Udo, IĀ“m wondering why you mention to use shorter names? I wrote a tool to import items and things from a ETS-Project & I build the names based on the mainGroup-name , middleGroup-name, groupaddress-name to avoid name-conflicts. Is there a particular reason why you suggest to shorten the names?
A virtual channel has per definition no device, so there is absolutely no point in setting an address.
A control Channel is per definition owned by openHAB itself, so no address either.
These GA will be sent from the localSourceAddr.
But this address must not be owned by any device! This is: the individual address must not match the individual address of the gateway nor any other device in knx.
Of course, you could create a dummy device in ETS (letās say another gateway, which isnāt present at the bus), name it openHAB, set an individual address for this dummy device and set this individual address to openHAB as localSourceAddr.
This way ETS Group Monitor should log the messages of openHAB if openHAB does not use the same gateway as ETS.
Please be aware that some gateways will filter messages which were sent from itself.
In question of shorter names: Itās more easy to read and to write, there is no point of extra long names other than auto-creating with some sort of software. You always have to deal with them. It makes things much more complex (but as said, itās only a suggestion, do whatever you want 
)
The channel name is long enough without extra long channel names, I think 
1 Like
ok, many thanks!
I just was not aware that putting an address in the thingdefinition harms the functionality.
Aha. IĀ“m using the very same gateway for OH and the ETS. Thanks for saving me some hours searing for the reason!
Jep, regarding long names I see your point.
Thanks for solving my problem!