Then the bridge given above should suffice.
There are two options in knx2: Either use the whole knx bus as one “virtual” device, so only define a generic thing, or use every single device as “real” devices and define one thing per device. It’s possible to mix these two options.
address is the individual address (or in german terms physikalische Adresse). You don’t need to set this parameter, and if defining one generic thing for the whole knx bus, in fact, there is no individual address at all.
On the other hand, if defining each device with its individual address, openHAB will show if each device is ONLINE, if pingDevice is set to a reasonable value.
Some additional information may be downloaded and displayed in Paper UI (serial number, ROM mask, manufacturer…) when setting fetch=true (it’s dependent on the device if this option is working correct).
If there is any GA set to be read ( < before GA), openHAB will request a read at startup. As soon as a device answers to the read request, the status is set. Some devices can’t be configured to send their status frequently or even when changing the status, these devices will only answer to read requests. So how to get these channels updated?
readInterval will force openHAB to send read requests to all GA set to be read at startup each <readInterval> seconds, not only at startup. But this option is to be used carefully, as it results in very increased data traffic at the knx bus.
As the absence of correct “automatic send option” is very rare and clearly dependent to the device, this parameter is a thing parameter. Even if using the “generic thing” model, the affected GA should be defined in a “special” generic thing which has the readInterval set. All other GA are set to another generic thing which has not set readInterval.
Even if using per-device-things, there may be some GA which don’t “belong” to a device (i.e. the device holds the status of the GA, think of a knx scene, think of date/time). These GA can be configured to a channel using a generic thing.
In question of the shutters: As knx does not mark the sub DPT within the bus data, a switch will also work, because UP/DOWN is a 1 bit message. But it’s a ugly hack, and there is no good reason to do it this way.
Type switch : ch1 "Rollershutter UP/DOWN" [ ga="1/2/3" ]
Type rollershutter : ch2 "Rollershutter UP/DOWN" [ upDown="1/2/4" ]
These two channels will be used the same way, with a slight difference. ch1 will need ON/OFF as command while ch2 will need UP/DOWN as command. So you will have to use different item types:
Switch rollershutter1 <rollershutter> { channel="knx:device:bridge:generic:ch1" }
Rollershutter rollershutter2 { channel="knx:device:bridge:generic:ch2" }
While you have to set the switch item to use a non-default icon, the rollershutter item will use the correct icon automatically.
In a sitemap you would use a mapping to avoid getting a STOP button or a slided switch:
Switch item=rollershutter1 mappings=[ ON="DOWN" OFF="UP" ]
Switch item=rollershutter2 mappings=[ DOWN="DOWN" UP="UP" ]
in a rule you would use different commands:
rollershutter1.sendCommand(ON) // rollershutter1 DOWN
rollershutter2.sendCommand(DOWN)
At least in a rule you can see the advantage, as there is absolutely no need to write down a comment for the latter item, while the former item is not self explanatory.
