[KNX] Distinguish between command and status GA in configuration

[Tokamak (Marcus)]

Hi all,

I am using OH in order to connect my KNX devices with the remaining world, and started with OH2.4 and the KNX2 binding for this.

From the beginning the knx2 binding and myself are not best friends. The integration of the OH and the KNX bus is not perfect, mainly because the command and the status is not distinguished well, and the usage of the -control channel configuration is not self-explaining.

I like the differentiation between command and status in OH. Usually the same is done on the KNX side. So why not try to map both worlds?

Most of the KNX configurators distinguish between groups addresses used for commands (e.g. 1/2/3 for “switch on”) and status (e.g. 1/2/103 for “is switched on”).

This can be configured in the todays .things configuration by specifying

switch light : [ ga="1/2/3+1/2/103" ]

or

switch light : [ ga="1/2/3+<1/2/103" ]

and an item

Switch Light {channel="...:light"}

For simple channels where command and status are more or less the same this works like a charm.
In the case of special situations one gets into trouble.

Think about a switch-on delay of 5 seconds of the light above, configured in the KNX actuator channel.
If one sends a

Light.sendCommand(ON)

the status of the Light is changed directly to ON in OH, even though the light switches on 5 seconds later, which then is sent by the actuator in 1/2/103.

In order to avoid this one must configure

Switch Light {channel="...:light", autoupdate="false"}

This is not nice, because you need to model the KNX behavior in two different places, things and items.

Additionally, it doesn’t help if one switches the light on via the KNX bus using 1/2/3. Then the autoupdate=“false” does not work, and the state of the light switches to ON in OH immediately, although it is not switched on due to the delay. Technically this is understandable, because OH cannot distinguish between 1/2/3 and 1/2/103.

Therefore, in case of e.g. a switch-on delay, one must configure two channels and two items to distinguish between command and status.

Therefore I would want to discuss the following proposal:

• The basis is that one can distinguish the ga types “command” and “status” in configuration. As a consequence one need not to set autoupdate.
• With a slight enhancement we could get rid of the -control channels.

New Configuration
Taking the example above one would configure

switch light : [ cmd="1/2/3" state="1/2/103" ]

and

Switch Light {channel="...:light"}

For sending a command (Light.sendCommand()) the cmd ga 1/2/3 is used, for maintaing the state the status ga 1/2/103.
autoupdate=“false” is intrinsic, because the state is not changed by the command via 1/2/3. So the switch-on delay is visible to OH, because only the status ga is used for maintaining the OH states, as long as postUpdate() is not used.

If one wants that the state is maintained by the cmd ga also, it must be specified:

switch light : [ cmd="1/2/3" state="1/2/103+1/2/3" ]

Then it works like today by [ ga=“1/2/3+1/2/103” ]

With

switch light : [ cmd="1/2/3" state="<1/2/103" ]

one can configure that the state is read from KNX while starting, like today.

And, in order to get rid of the control items, one could configure

switch light : [ cmd="1/2/3" state=">1/2/103" ]

which shall mean that the KNX binding responds to a GroupValueRead on 1/2/103 and send the state to the bus in case that is changed using postUpdate(), like in the todays -control channel / item.

switch pure_status : [ state=">1/2/103" ]

is an non-command channel then. sendCommand() has no effect.

This enhancement an be used for other channel types as well. E.g. the

Type rollershutter : rs [ upDown="4/1/71", stopMove="4/1/72", position="4/1/73" , state="4/1/173" ]

gets its percentage state from 4/1/173. The other entries are used for commands only.

What do you think?

[Udo_Hartmann]

Well, I’m no developer, but… no. I think you don’t get the point.

Every time, when openHAB does a sendCommand, it also performs a postUpdate. This is default behavior. The idea is to get a feedback immediately. But this isn’t desirable in case of items with real status feedback. Therefor there is a parameter autoupdate="false". Please be aware that this is only openHAB Bus.
You would need to change the core to change the behavior (and this will not happen).

Furthermore, there is no explicit difference between status and command in knx (it’s only about th communication objects).
In question of the knx, one could argue that there are different CO, but this is not true for e.g. a simple switch. Although a wall switch has a control LED, there is no additional CO (at least there are a lot of knx switches without additional CO for the LED). And the switch will do it exactly like openHAB with its items i.e. send an ON and switch ON the LED immediately
And if you are using a wall button to toggle the actuator and use scene control, you have to link the status additionally to the only switch CO to keep the toggle function working.

To prevent a false immediate ON because of a received command on a GA, you can add another “openHAB exclusive” GA for command CO. But to be honest, there is no guarantee for immediate status feedback at all in openHAB (openHAB is asynchronous and no real-time system).

openHAB acts like a wall switch for channels of “no -control” type and it acts like an actuator for channels of “-control” type.
In fact, yes, it’s an odd behavior that you have to use postUpdate to send the status to the knx bus, but it seems acceptable.

[Tokamak (Marcus)]

Hi Udo,

if it was intended that command and state are more or less the same, because a postUpdate() is performed in general, I have to accept it. Fortunately one can add autoupdate=“false” to change the behavior, and I am fine with this.
(BTW: In the KNX binding the autoupdate=“false” is not working when the command comes from the KNX bus)

I also said that for easy - and of course the most - KNX situations like lights the current implementation is working perfect. In these cases the command and the status can be treated as to be the same. I don’t care for milliseconds, especially because of the asynchronicity.

Although I have some places where I decoupled the sending ga and the listening ga in wall switches, to control the LED, this was not my point.

In my eyes one could integrate the OH bus and the KNX bus to behave like one bus. And I don’t see any reason why it should not be implemented in a KNX binding.

My real world example is: I wanted to measure the time between the blind DOWN command and the point in time when the blind is closed. If it takes more than a certain amount of time (~ distance), I need to adjust the slats, because they sometimes jam, by setting them to 0%, then 100%.

The first approach was to create the following channel and item:

Type rollershutter : blind [ upDown="4/3/1", stopMove="4/3/2", position="4/3/3+<4/3/103" ]

Rollershutter Blind {channel="...:blind"}

Blind.sendCommand(DOWN) sends the DOWN command to the KNX bus. But - it changed the state of the item directly to 100 = CLOSED. This is not true.
In difference to the simple case “switching on a light” there is some time between the command and the terminal position.

The first approach was to add autoupdate:

Rollershutter Blind {channel="...:blind", autoupdate="false"}

Ok then, but not final.

Next problem: The Item Blind does not react on any command coming from the KNX bus, which means,

when
    Item Blind received command DOWN

is not triggered from the KNX bus.

One need a control item to evaluate the commands from the KNX bus:

Type rollershutter-control : blind_ctrl [ upDown="4/3/1", stopMove="4/3/2", position="4/3/3 ]

Rollershutter Blind_KNX {channel="...:blind_ctrl"}

As a consequence one need to define 2 channels, 2 items and have to look for 2 items in order to receive a command either from OH or KNX:

Type rollershutter : blind [ upDown="4/3/1", stopMove="4/3/2", position="4/3/3+<4/3/103" ]
Type rollershutter-control : blind_ctrl [ upDown="4/3/1" ]

Rollershutter Blind {channel="...:blind", autoupdate="false"}
Rollershutter Blind_KNX {channel="...:blind_ctrl"}

when
    Item Blind received command DOWN or
    Item Blind_Ctrl received command DOWN

Unfortunately, you cannot evaluate the status of the item Blind, because it is changed to 100 directly when the DOWN command is sent on KNX the bus. The autoupdate=“false” has no effect in this case (if this was not intended, it is a mistake in implementation).

The only solution I found was to add a pure status channel and item:

Type rollershutter : blind [ upDown="4/3/1", stopMove="4/3/2", position="4/3/3" ]
Type rollershutter-control : blind_ctrl [ upDown="4/3/1" ]
Type rollershutter : blind_pos [ position="<4/3/103 ]

Rollershutter Blind {channel="...:blind", autoupdate="false"}
Rollershutter Blind_KNX {channel="...:blind_ctrl"}
Rollershutter Blind_Pos {channel="...:blind_pos"}

That means, I needed to create 3 channels and 3 items in order to measure the time between the command DOWN and state CLOSED (=position 100) - for 23 blinds.

Of course this can be implemented by following naming conventions. But it is very hard to understand and took some time for analysis in order to find the common solution.

What I would have expected that it doesn’t matter whether the command is sent in OH or on the KNX bus.
And I would have expected that the state of the item reflects the state and not a prediction which state it might become in 30 or more seconds.

In case of a rollershutter the idea is to add a state ga and let the state ga control the state of the rollershutter item (by applying autoupdate=“false”). So one would define

Type rollershutter : blind_new [ upDown="4/3/1", stopMove="4/3/2", position="4/3/3", state="4/3/103" ]

Rollershutter Blind_new {channel="...:blind_new", autoupdate="false"}

This Blind_new should receive commands from OH and KNX bus, independent from where it was sent, should send commands to KNX if they are sent in OH, and it should change its state only according to 4/3/103 due to autoupdate=“false”.

The same is true for dimmers. Most of my dimmer channels have a startup value less than 100%. But OH assumes that switching on a dimmer item leads to a state of 100, which is changed soon to the correct value provided in the dimm value ga send by the actuator. As a consequence you are not able to look for “changed to 100” w/o an additional item.
This could be changed by introducing a state ga.

If the same is done for general switches - and not only simple light switches w/o any delay - one would come to a solution I proposed in the first post.

After being able to distinguish between command and state gas one could get rid of -control items by by adding the > to the state ga. So < means: Read from the KNX bus initially, > means: Send to the KNX bus if changed or requested from KNX.

With extensions like this - state gas, receive commands from either side, act as sensor (nothing or ‘<’) or actuator (’>’) and autoupdate=“false” - the OH bus and the KNX bus are fully integrated.
Perhaps something is blocking this approach on OH side. I hope not.

[Udo_Hartmann]

@Tokamak

if it was intended that command and state are more or less the same, because a postUpdate() is performed in general

No, it’s not the same but very different. a command is a command, a state is a state. e.g. a dimmer item will accept commands ON, OFF, INCREASE, DECREASE and numbers from 0 to 100. On the other hand, the status will be a number 0 to 100 or NULL (maybe UNDEV is also possible)
There are different triggers for status and command.
But the point is, whenever a command is send, the item state should change accordingly, and there are some bindings which won’t send status updates at all. Yes, I would prefer the default behavior to be opposite (autoupdate=“false”) and one would have to set autoupdate=“true” for these items.

@Tokamak

Unfortunately, you cannot evaluate the status of the item Blind, because it is changed to 100 directly when the DOWN command is sent on KNX the bus. The autoupdate=“false” has no effect in this case (if this was not intended, it is a mistake in implementation).

But that is exactly how knx does. every GA which is linked to a CO will send immediately to the CO (as long as Write is enabled). As mentioned above, you can solve this issue by using an additional GA and you won’t need an additional channel.

In question of received command: knx1 did no differentiation between command and status. This lead to serious problems in openHAB2, therefor the author of knx2 split the status and command.

To be honest, imho your use case is very special.

openHAB will only send from the first GA (as knx does), so there is no need for a >