KNX Dimmer: sendCommand(70) -> ON & 70% Telegram

Setup, Configuration and Use Runtime
1

Hi,
I was wondering, if there is any way to configure how an dimmer item expresses its commands on the KNX bus.
Currently I have a dimmer item.
When I send a command, lets say 90 to dimm to 90% and the dimmer was off, I can observer an
ON telegram,
an 90% telegram,
an ON reply, and
an 90% reply.

This leads to the lamp going to full brightness, immediatly followed by dimming down to 90%.

Any way to configure this, aside creating an “ON” channel & item, and a dimmer channel & item without the “on/off” connection?

Or did I miss this somewhere on the forum or documentation?

Ideally, when sending “ON” an on Telegram should be generated, and
when sending “90%” only an 90% Telegram should be generated.

(Of course there are legacy dimmers, that frist must be turned on, and the dimmed to the correct intensity)

Sinecerely

2

Please show the exact configuration of the channel, this is not normal behavior.

4

? Problem solved?

5

When I simplified my rules and setup to publish, the “error” disappeared.
I was not sure what the “correct” behavour would be, in the first place.

Thanks for following up. I am currently trying to replicate this, as I definately observed it.

6

Some general tipps then :slight_smile:

A channel should have a state, given by the actuator, controlled by the channel. It definitely should not have more than one source of state.
This is for a dimmer channel: set up a GA for on/off (ga=) and set up two GA for dimm level (position=), but never set up a second GA to on/off, as this is meant as “send only” for the dimmer. Unfortunately the knx binding does not care about the configuration that deep, so it will respect messages of both on/off and level as new state. In question of knx dimmers, you want to control not only the level, but also on/off, as this will give you default on level functionality. At this point, there is no chance to ignore ON messages for on/off from knx (i.e. short press on a wall switch, linked to the dimmer), the only option would be to create exclusive control GA for openHAB to switch the dimmers.

A common knx dimmer has at least five communication objects of interest, that is on/off command, on/off state, level command, level state and relative dimming. There may be others as well, such as scene control or forced operation, but these are not part of a dimmer channel.

Wall switches will use on/off command and relative dimming. If the wall switch has a state LED, it will use on/off state (additional GA to short press, if there is no extra CO for state LED).
Be aware that state is exclusive for every actuator, you must not set the same GA to more than one actuator CO (which then is the only device to send to this GA).

On the other hand, openHAB dimmer channels will use only level command and level state. It’s possible to use on/off command in addition, though (default on level).
In question of relative dimming, nowadays there is no use for outgoing relative dimming, but of course you can use incoming relative dimming to control other hardware. You would use dimmer-control channels for that purpose.

When using sendCommand() in a rule (or by changing a value in the UI, which will also cause a sendCommand()) openHAB will create an additional postUpdate() with the most likely new state. This is for better responsiveness, but for knx it’s unwanted behavior. For example an ON command will cause a postUpdate(100), as this is the most likely new state, but if the default on level is set to another level, this will cause two state changes instead of one, and the first one is wrong. Therefor it’s better to switch off the automatic update of state (done in metadata).