Read-only KNX item

Add-ons Bindings
1

Hi everyone :slight_smile:

It’s my first question here, so please be kind.

I want to detect if a user/human used a KNX button to switch on/off/dim a KNX light.

With OpenHAB 2.x I used a dimmer-control item for this use case. This old version of the KNX binding had the bug, that a *-control item did not respond to a read request and so I could use them without changing something on the real bus.

With the current version from OpenHAB 3.3 I have the issue that OpenHAB is responding to the KNX-bus at every KNX-button-press and will create a mess on the bus. → light is flickering because OH is fighting against the dim-actor.

If I use the normal dimmer item. I get only the state of the finished dimmed light and I cannot detect if someone pressed on/off, or used the dim function.

Any (other) idea how to solve this issue?

Thanks,
Norbert

1 Like
2

I’m pretty sure this won’t work at all (at least if not lucky).
knx does listen to GA updates from the bus. It then does a scan of all configured channels for the received GA and will send the update to the first channel with the GA.
end.
Now, if you set the same GA for more than one Channel, it depends on the sequence in which the channels were configured, which one will get the update. There is no way to set a GA on multiple Channels to receive from the bus.

In question of “the mess”, just set an additional dummy GA (i.e. one that is not configured at any knx device). openHAB will only answer a read request on the first given GA.

Or set an additional GA to the actuator, so that openHAB is able to send on another GA. Listen to the “wall switch only” GA in an additional channel.

3

Hello @Udo_Hartmann,

just read your reply and out of curiosity and to better understand the mechanism behind:
I doubt that the behaviour only using a single channel linked to a GA, even if channels belong to different things, does mirror the behaviour of physical KNX devices, where each device is reacting if one or more of its communication objects is/are configured to listen to that GA.
Especially the more or less non-deterministic picking of a channel you describe is something giving me creeping horrors. Or did I get that wrong?

Could you elaborate a bit further on the reasons this is the way it works currently? Always willing to improve my knowledge… :wink:

4

openHAB is one Device. There is absolutely no need to use a GA more than once (for receiving states).

Of course it’s best practice to use the same GA more than once, e.g. the definition of a Venetian Blind (Jalousie?) has two channels, one for UP/DOWN/STOP and another for Angle, and that one is the same GA as used for STOP in UP/DOWN, BUT: this is a command GA (i.e. direction is from openHAB to knx).

The behaviour of only updating one channel through a received GA even if more than one channel is linked to this GA is since openHAB2.2(? when knx2 came up).
I never heard of a changed behaviour since then. But to be honest, I never ever used a GA twice in my knx things, as I don’t have Venetian Blinds, and I doubt that there is a valid use case (which can’t be solved in another way).

1 Like
5

Thanks Udo, agreed.
Seeing OH as a single device this makes sense, KNX Things I’d say are more some kind of structuring than reflecting real devices (except e.g. the IP interface) as you could in theory model all channels within one thing (If you ignore the bus address etc)
Using the GA twice is something I don’t do as well, so never experienced the behaviour described before.
If you need it in two places for whatever reason you use multiple items.
Learned something new/old, time to go to bed :wink:
Thomas

6

But this is not the way things are meant.
Of course, as knx is a bus system without any hardware dependency (in question of control), you could organize channels as you like, but knx things can take care of the individual address (i.e. physikalische Adresse), and that’s a hardware dependency.
Things are meant to be a virtual image of the real hardware, so I tend to create one thing per device (even things without any channel for the moment, like wall switches, which are bound to actuators, so the GA is property of the actuator, not the switch) This way I have a virtual image of my whole knx bus. Channels are defined like ch1 "Living room light" so I have information about hardware AND function.

7

Exactly as I do, it was just mentioning that in theory it could work that way if you ignore the physical address (which I don’t). Would never do so in real life.
But we’re heading off-topic.

8

I can not confirm this behavior with openHAB 2.5.10. I use the following channel configuration quite often and both linked items get triggered as expected

Type dimmer:          ch_2_dimmen      "ch_2_dimmen"       [ switch="1/1/30", position="1/1/33+<1/1/35" ]
Type dimmer-control : ch_2_dimmen_ctr  "ch_2_dimmen_ctr"   [ switch="1/1/30", position="1/1/33", increaseDecrease="1/1/32"]

With openHAB 3.3 also both linked items changed the state but then I get an endless loop for the control item (here I11_01_Sofa_ctr). Also if I remove the normal channel and only use the control channel I get a endless response from openHAB every 40ms with the same state.

2022-07-12 21:38:36.817 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa' received command ON
2022-07-12 21:38:36.896 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa_ctr' received command ON
2022-07-12 21:38:36.897 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'I11_01_Sofa' changed from 0 to 100
2022-07-12 21:38:36.897 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'I11_01_Sofa_ctr' predicted to become ON
2022-07-12 21:38:36.900 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'I11_01_Sofa_ctr' changed from 0 to 100
2022-07-12 21:38:36.923 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa_ctr' received command ON
2022-07-12 21:38:36.924 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'I11_01_Sofa_ctr' predicted to become ON
2022-07-12 21:38:36.962 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa_ctr' received command ON
2022-07-12 21:38:36.963 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'I11_01_Sofa_ctr' predicted to become ON
2022-07-12 21:38:37.003 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa_ctr' received command ON
2022-07-12 21:38:37.003 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'I11_01_Sofa_ctr' predicted to become ON
2022-07-12 21:38:37.064 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'I11_01_Sofa_ctr' received command ON
2022-07-12 21:38:37.066 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'I11_01_Sofa_ctr' predicted to become ON

I think you mean something like the following dimmer-control config, right? This seams to work for the dimmer-control item. But the normal dimmer item is not working anymore. I think this linked to your statement, that every GA can only be used once.

Type dimmer-control : ch_2_dimmen_ctr   "ch_2_dimmen_ctr"   [ switch="12/0/0+1/1/30", position="12/0/1+1/1/35", increaseDecrease="12/0/3+1/1/32"]

I don’t get this part. Can you give an example, please?

9

It’s odd behavior as expected :slight_smile:

No valid reason to configure the same GA more than once, the difference between dimmer and dimmer-control is, all received GA are kept as commands for control, while all received GA are kept as status updates for non-control. In addition, a *-control Channel will send all updates to the bus, while it won’t for commands, and a non-control Channel will only send commands to the bus, but no status updates.

But the Binding itself can’t differ between sent and received messages, or there is a problem with ACK messges, don’t know, anyway, it’s not safe to check if the command was sent from knx or not through this method (at least for current versions).

sure, you have to set the dummy GA only for the *-control channel (you want to omit the messages to the real GA).

Actuator Command CO: 1/1/1, 1/2/1.
Actuator Status CO: 1/3/1

openHAB Switch channel: ga="1/1/1+<1/3/1"
openHAB Sense channel: ga="1/2/1"

Wallswitch: 1/2/1, 1/3/1

Now, if using the wall switch, the actuator will receive the command through 1/2/1. openHAB will receive status change through 1/3/1 and also will receive the “switch initiated action” messge through 1/2/1.
If using openHAB to switch, the actuator will receive the command through 1/1/1, openHAB and the wall switch will receive the new state through 1/3/1, but there will be no message though 1/2/1.

This does also apply to dimmers, no need to add GA for INCREASE/DECREASE, as openHAB will not use them to send, so if there is a received message on INCREASE//DECREASE GA, it’s from knx bus.

10

@Udo_Hartmann: I get your basic idea.

But this will not work, since a wall switch can only send to one GA.

It seems that I can not use my previous logic with openHAB 3.3 :frowning:

11

Yes, it does. Every CO (Commnuication Object) in knx is only capable to send to one GA (or none at all), the other GA are only to listen to. And this is, how it’s working: The Actuator will listen to both GA and will send its Status through one GA. openHAB will send to one GA and will listen to the other GA, and in addition to the GA, which is used by the Wall switch. The wall switch will send to one GA and will listen to the other, so it’s aware of the current state of the actuator (toggle function). This is a fundamental principle in knx.