Support KNX locked states

[henfri]

Hello,

based on
https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/1992352-korrekte-status-anzeige-bei-gesperrtem-aktor/page2#post1992693

If a channel in KNX-Actor is locked, the Status in HA may not reflect the status of the Actor-Channel.
Example:

• Channel is Locked and Off
• Status in HA is correct (off)
• User switches Channel externally on --> all good, status remains off in HA
• User switches Channel in HA UI on --> Switch in UI turns ON, but Actor stays OFF and does not send a status (as it only sends on change; as per KNX Standard the old value remains valid - state driven)

To fix this, the following would be needed:

• UI does not react directly on User interaction
• Instead UI waits for Status from Actor

A workaround could be to request the status after pressing the button. This would mean that the UI is wrong for a brief moment (ON in the example above) and correct after the status comes (OFF).

In both cases, I think it makes sense to make this behaviour configurable.

Considering that this issue is rare and the full fix seems quite laborous to implement, whilst the workaround seems fairly easy, I think the workaround is worth considering.

Whilst the issue may be rare, I think it is important to fix, as I see the impact of a wrong status quite high.

• A door may be unlocked, while it shows locked
• A water pump may be running, while it shows not running
• A Sauna Oven may be running, while it shows not running

Greetings,
Hendrik

[farmio]

Hi 👋!
For reference, here are some links (more or less) related links to that topic

home-assistant/architecture#545

XKNX/xknx#435
XKNX/xknx#72
XKNX/xknx#1261

#4

[farmio]

UI Considerations

I don't think there is much we can do from an integration point of view. If a frontend switch is clicked, it will toggle. IMHO it would be bad UX otherwise - a user might try multiple times thinking of missed click/touch target etc. Same for adding extensive delays.

The way other integrations handle such things (eg. API requests resulting in errors) is to raise an exception - resulting in a user visible toast message - and set the state back to the previous one. So the switch auto-disables as soon as the error is known.

Since we could potentially know the locked-state beforehand, another way would be to set the entity "unavailable" when locked. This would result in not being able to see the current state or use any frontend UI element.

[userwithoutpassword]

So HA doesnt have an option for "locked" entities?

[farmio]

No. An entity can be in normal state, "unknown" or "unavailable". Nothing else.

[henfri]

So, unless in the core the locked option is implemented, we have these Options:

• optional function of a switch (cover, ...) to
  a) wait a specified time for the Status. If it does not change, put the switch back
  b) wait a specified time for the Status, if it does not change send a read-request to the state adress
• raise an exception (I am not sure what consequence that would have, i.e. this entity becoming unavailable?)

Do you see other options?

Greetings,
Hendrik

[farmio]

Another option is to just set the entity "unavailable" when locked, thus preventing any user (or automation) interactions. Afaik this can be configured for template or MQTT entities too.

Raising an exception leads to a user visible toast message (like stated above). This looks like

[farmio]

Some actuators may even accept new commands when locked. These are applied when the lock is released. In such a case it might be desirable to show the target state, not the current state. An example:

A light is ON, something locks it ON -> state is "ON"
User turns it OFF -> state is "OFF" now as it is the last received target state.
Lock is cleared -> light turns OFF

If the state was "ON" a user wouldn't be able to see the results of the manual interaction - the state when the alarm is released - which might lead to false assumptions. I guess this is a matter or preference.

[ColdFireIce]

Hi,
I was wondering the same thing:
home-assistant/core#130948

If the state was "ON" a user wouldn't be able to see the results of the manual interaction - the state when the alarm is released

Actually I think this would be correct, as the device is on. No need to show intentions. That's the base problem here.
HA is optimistic and show's what it thinks should happen and not what is really happening.
The "buffered" state will be shown as soon as the lock is released as an status telegram.
I would really love the option to define an status update timeout for this optimistic behavior with an optional fallback to the last received state or a readValue.
KNX is not supposed to be optimistic. That's what state addresses are for.
If you don't have a dedicated state address you could always use the "setter" address as a state address.
For locks there is often no state address but you can use the setter as such. Just enabling the read flag and you can even often request the state.

Best regards
Daniel