Feature request: DPT2.001, 2 bit force option for lights (and if applicable maybe other stuff with a more generalized approach)

[MrFaul]

Some KNX light controllers have an options for forced/prioritized switching and dimming.
In most cases forced/prioritized dimming is is a simple matter of a normal 1 byte DPT 5.001 % value as a separate GA which is reset when set to 0%.

However switching is a bit more involved.
Depending of the manufacturer there are different methods for locking a device.
Some use two separate 1bit GAs for locking a device and prioritized switching (ignoring the lock),
which would be easy to automate e.g. in HA but there are also devices that use a 2bit GA combining those functions.

Forced switching uses a 2bit DPT2.001 whereas the first bit is a prioritized switching command and a second bit is a locking flag that allows the of locking the device while still being able to switch freely with the first bit.

This requires three new fields for group addresses and some additional logic:
group_address_forced_switch, group_address_device_lock and group_address_device_lock_state.

Now the tricky part...
First off there needs to be new states and methods implemented for devices "lock" and "force" so XKNX can represent that state.
On a side note: Locking and forcing KNX devices is a fairly common practice and should be added to the common XKNX device class not just lights.

Then there is the issue of resolving which method to use in the light device.
This can be done explicitly with configuration flags or inferred thru the configured GAs:
When no normal "switch" GA is set XKNX should try to use the "forced_switch" GA to send switching command.
But with a caveat:
Then if "forced_switch" and "device_lock" have different GAs no real logic is required, they are independent.

If "forced_switch" and "device_lock" have the same address it's 2bit GA
"forced_switch" sends the switching command respecting the lock state,
"device_lock" sends the (un)locking command respecting the switch state.

Now you may ask for my reasons for requesting this:
The answer is simple, I want to reuse existing KNX switches without reprogramming the entire KNX system.
KNX is by its nature decentralized and I want to keep it that way.
If I normally want to use Home Assistent as centralized "logic" provider for actions I would need to decouple all KNX sensors from their actors to prevent cross talk and unwanted actions, meaning Home Assistent would need to act as proxy between all sensors and actors. But that's a problem, when HA dies, so dies the entire KNX system without somebody to relay the commands.
Now KNX has concepts of "locking" and "forcing" to allow central authorities to overwrite behavior but that functionally is currently rather lacking in XKNX.
With proper support Home Assistent could take complete control without compromising on KNXs decentralized nature.
Basically the KNX system has a default functioning fallback when HA is down.

[farmio]

In most cases forced/prioritized dimming is is a simple matter of a normal 1 byte DPT 5.001 % value as a separate GA which is reset when set to 0%.

Can you give an example of devices having that? I have never seen it.

When no normal "switch" GA is set XKNX should try to use the "forced_switch" GA to send switching command.

Would just setting the priority GA to the switch-address result in the same behaviour?

Automatically un-/setting locks could also result in unwanted behaviour. Some actuators support receiving state updates (eg. on/off) while locked and will turn to that state when the lock is released.

Afaik DPT 2 can't be thought of 2 DTP 1 objects combined - it is specified as a 3-way switch. When the control bit is unset, the function bit shall be ignored.

Regardless, the real tricky part is that HA entities don't support any of these concepts. You can define additional switches, or even DPT2 as select entity in HA to toggle KNX locks or priorities.

See also
https://community.home-assistant.io/t/add-lock-a-switch-option/539971
https://community.home-assistant.io/t/locking-and-unlocking-a-knx-switch/506928
#435
#1251
and many more 😬

[MrFaul]

MDT dimmers have under locking/forcing an option for forced dimming, they a have drop down with three options:
1bit = normal locking function DPT1
2bit = prioritized switching DPT2
1byte = forced dimm value DPT5

Would just setting the priority GA to the switch-address result in the same behavior?

Not sure if we are on the same page, not quite sure what you mean.
If "forced" is DPT2 than "switch" would be still DPT1 and vice versa?
Generally forced_switch and switch are quite redundant, but if the DPTs differ it would be a conflict.
My idea behind that was to minimize the potential to go "boom"

Afaik DPT 2 can't be thought of 2 DTP 1 objects combined - it is specified as a 3-way switch. When the control bit is unset, the function bit shall be ignored.

Well... apparently there are different interpretations of that, on device/manufacturer basis 😑
Why would it be easy, wouldn't it...

Automatically un-/setting locks could also result in unwanted behavior. Some actuators support receiving state updates (eg. on/off) while locked and will turn to that state when the lock is released.

Regardless, the real tricky part is that HA entities don't support any of these concepts. You can define additional switches, or even DPT2 as select entity in HA to toggle KNX locks or priorities.

Yes, I know, didn't meant to set anything automatically.
But I would have to setup a lot of scripts to force a KNX device when its locked.

My train of thought was to throw a "lock all actors" toggle in HA to block out the "normal" KNX behavior and control the KNX devices via HA. That way if somebody presses a KNX button the telegram still could be read.
That way you repurposed those without reprogramming the KNX devices.

[farmio]

apparently there are different interpretations of that, on device/manufacturer basis

That's the reason we stick to the specifications for such things (and take implementations of some specific manufacturers with a grain of salt 🙄)

I think this is where our understanding of this issue differs:

But I would have to setup a lot of scripts to force a KNX device when its locked.
My train of thought was to throw a "lock all actors" toggle in HA to block out the "normal" KNX behavior and control the KNX devices via HA. That way if somebody presses a KNX button the telegram still could be read.

I do not understand HA as replacement logic engine for any other KNX device(s), but as supplementary system. Therefore there is no need to "block out normal KNX behaviour" and I don't consider fallback logic so another system can hop in if HA goes down (which didn't happen to me in the last 5 years).
So forcing a light/cover etc. when it is locked doesn't really make sense to me - as there is probably a reason it is locked. If it should be switched, I'd unlock it first. Same for button presses - these should imho always yield the same results - and these will be reflected in HA.
YMMV, maybe I just don't get the specific use case you are having.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please make sure to update to the latest version of xknx (or Home Assistant) and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.