Create (virtual) KNX Thing in OpenHAB with Group Addresses accessible on the KNX bus

Dear Community,

As long as I want to access sensors and actors that are physically located in the KNX TP bus, I managed OpenHAB to communicate with them via a KNX IP interface by addressing the respective group addresses.

However, I would like to create a switch item entirely in OpenHAB and its state should be accessible via a group address for all KNX components in the KNX TP bus behind the KNX IP interface.

In how far is it possible to create a kind of virtual KNX device as thing in OpenHAB, assign a physical address and a channel within the virtual KNX device to be used as switch item and to assign a group address? The idea behind is to have a switch in OpenHab but the status of the switch should be retrieved from other KNX components on the bus.

Best regards,
Peter

Dear Peter,

I guess that the control channel types described in the KNX binding are meant to do exactly that. So basically you define a switch-control channel instead of the normal switch channel and assign the necessary group addresses and connect it to an item.

Now when you toggle that item, a KNX telegram is send from the bridge to the KNX bus, so that knx objects can act upon it.

In theory this should work the other way around. When you create a read request for the group, the telegram should be forwarded by the bridge to the channel/item and then answered with the state of the item to the bus.

But, this never worked for me. I opened discussions both in there forum here as well as on github, but could never make this work. My guess is that either:

  1. It depends on the KNX IP interface as there are people using other interfaces than mine report that it works with them as described in the documentation.
  2. It only works with another channel connected to the item. This are the examples where e.g. a homatich IP wall switch is connected to the KNX bus. The bus receives the updates of the switch in homatic then and delegates read requests from KNX to homematic to answer with the state. I never saw a working example with a virtual item just sitting in opeHAB.

As I said, I never got this particular use case working but some people discussed that this might be my problem.

My use case is having a switch in openHAB indicating that I’m on holiday and if I turn on the switch, some actors (like heating actors) should be disabled. In this direction all works as expected. When I toggle the switch, the telegram is send to the KNX bus.

The other way around does not work. If e.g. a device on the KXN bus gets restarted and sends a read telegram to get the state of the item. The telegram never reaches the bridge and the item and therefore the device on the KNX side might behave wrong because of missing state information.

Kind regards,

Frank

I’ve not seen any of the bindings support that mode of working. It would require the binding to fetch Item state “on demand”, I’m not sure there’s even an openHAB mechanism for that in the event-driven model.

An alternative might be for the binding to cache such a state, the cache being updated as and when the OH Item updates,and the cache used to fulfill external queries.

I cannot say about other bindings, but this is how the KNX binding is supposed to work. The knx binding will answer a value read request from the bus with the actual state stored in OH when the item is a *-control item.

See the forum discussion that I started for this use case dating back to March 2019:
KNX control item doesn’t respond to read request from the bus

1 Like