"Read-only" mode for entities

[farmio]

Describe your request

Introduce a standardized "read-only" mode across all Home Assistant (HA) entities, where the current state remains visible to users and automations, but any attempt to set or change the state (e.g., via UI, service calls, or automations) is blocked (or postponed).

The existing "unavailable" state partially addresses this by preventing state changes, but it also hides or invalidates the entity's current state, making it unusable for monitoring or reference.

The frontend could disable action buttons for entities flagged as 'read-only' and optionally display a message explaining the reason.

Use cases

• Cover: Manual or automated opening/closing is disabled when a safety condition is active (e.g., strong wind, fire alarm, rain). The integration still can read the position, but it can't be set until the safety condition is released.
• Switch: A socket is in "timer mode" and can't be operated manually until this mode is changed to "manual". It still has a state of ON/OFF that might be interesting for a user.

What areas might this affect?

Probably the base entity model, automations and the frontend.

Anything else?

There is an architecture discussion about this same topic, but for covers only: home-assistant/architecture#545

[edenhaus]

To add some other use cases for this feature...

• Some entities can only be controlled when certain conditions are met. For example, smarthings washing machines are only controllable after the user clicks a physical button on the machine (which locks the door). Currently, we have two entities for the same thing: a sensor and a select entity. It would be nice to have only a select entity, which prohibits any changes if the device is not controllable

[Petro31]

Another usecase:

This could potentially allow us to have automations create and use entities. The entity would be generated by the automation and only the automation could alter it.

[thecode]

I would like to add to the above, one of the devices I worked on support (this is not released yet due to manufacture decision) has an option to disable remote control for a Switch (safety feature, so that only local control works).
This usually used as a temp option to protect someone working on the circuit, currently this is problematic to support. We need to do one of the following to workaround this:

• Create a switch and move it to unavailable when it can't be control, but the user can't see the current state like this (the switch is still on or off)
• When remote control is disabled switch to a binary sensor, no user friendly, problematic with history
• Show an error when the user try to control the switch

So having something that will show that an entity is currently read-only would solve this issue in the most user friendly way

[chefdeit]

Conditional read-only entity state would be great.

Use cases:

• Some HA scenes, particularly involving large Z-wave & other meshes that span distances, take a few sec to execute. I've seen a situation when a user with a habit of tat-tat-tat pressing any & all buttons 3 to 5 times (including the elevator buttons etc), did this with such an HA scene, and HA sort of momentarily hiccuped re-executing the scene. At that point this user saw fit to press the button like 15 times in a row to help it along.
• Some Actions take a certain time, and would add to wear and tear if repeated several times in a row without a rest / cooling off period, including: large TV or projector on/off; motorized projection screen raise/lower; awnings/pool covers etc., whose motors are stipulated by the manufacturer to be allowed to cool off between actuations / are not designed for continuous on-off-on-off operation.
• Some Actions may involve lights dimming slowly by design, i.e. with a transition period of, say, a couple minutes. To some users that may look like nothing is happening, and if they re-trigger the automation that transition restarts, exacerbating their confusion.
• Kids. Guest kids who've never played with a smart home before. Guest kids who've never played with a smart home before, who belong to a key client. Guest kids who've never played with a smart home before, who belong to a key client & who outrun you (dirty martini in hand) up and down your stairs.

So, if an Entity triggers an Automation which is set to a Single mode, that Entity should ideally visually reflect when its Automation is currently in progress (and show that progress if possible), and remain read-only while it is. It'd be good to have something like that for scenes also, or any entities. Specify an "unavailable time period till next repeated activation" - stackable on top of the scene's or Single mode automation's execution time.

As @thecode said, it's pretty key to let the user know the reason they can't have it right now (not in a system log but via dashboard UI pop-up or voice), to avoid them jabbing at at tablet screen or wall keypad button. In fact, if the entity triggers an Automation and that Automation has the And if that isn't being satisfied, HA should just tell the user that too "because (name of the entity in the condition check that's false) isn't (condition required)". The end user shouldn't have to navigate to the Automation's Traces to find out why; they should be able to see or hear why right then & there.

In addition to making some entities conditionally read-only, I'd like certain other entities to remain controllable, but through the "Are you sure? Because (condition)" pop up confirmation, not single-tap. This would be handy for turning the lights on to full blast in the bedrooms between say 1AM and 5AM, which in 99.9% of cases I want read-only as protection against unintended fumbling at night, but in the 0.1% cases I might really need those lights at full brightness NOW. So the "Are you sure? Because it's between 1 and 5 am" confirmation pop-up would address that use case.

So: hidden < read-only < controllable, but with a confirmation pop-up not single-tap, < controllable fully, incl single tap
... based on the user's role, X seconds passed since previous activation, time of day, additional conditions as listed by the OP and other folks above.

[Mariusthvdb]

was the Area-card already mentioned?
having read-only mode entities there would help a lot, in showing the area, but not accidentally switching off critical devices

[chefdeit]

https://github.com/orgs/home-assistant/discussions/205

[farmio]

Imho is this a different topic. A read-only entity attribute (as I see it) would disable any control of an entity - because it can't currently be controlled
Not showing controls for an entity that could be controlled in a specific frontend part would be a frontend decision - independent of backend.

[chefdeit]

Imho is this a different topic

@Mariusthvdb asked re: Area-card and that having read-only mode entities there would help a lot. The linked #205 discusses precisely that, esp in the most recent two comments.

Not showing controls for an entity that could be controlled in a specific frontend

I agree that for safety or access control purposes it'd be not the same as read-only (and imho architecturally pretty ugly - as discussed in #22 ), but was that suggested anywhere in the #205 I mentioned that I overlooked?? It only discussed space saving options, and besides those also expanded discussion to read-only for safety purposes, to which I also suggested adding controllable but with the "Are you sure?" confirmation.

[farmio]

My reply was intended for Marius' answer.

[sveinse]

There is also a use case for buttons:

• Buttons. There are use cases where buttons should only be clickable by the user in certain states. E.g. pressing the "Charge now" button on a electric car charger which isn't connected to a car makes no sense. The function should be visible, but disabled for the user.

This is not the same as being unavailable, which means that the entity is not connected to the integration cloud- or back-end. A suggested alternative is to have the button available but give an error message when the user press the button and the device is in the wrong state. IMHO this is not great UX, as it requires the user to press the button to find out if its disabled or not.

Edit: Actually, this line of reasoning will hold for any user-input entity types. (Binary) switch, button, number, etc. An entity may be connected to the integration back-end and thus be available, but be functionally disabled due to some state of the device that prevents the use of it.

[chefdeit]

Actually, this line of reasoning will hold for any user-input entity types.

I 100% agree.

A suggested alternative is to have the button available but give an error message when the user press the button

I also agree as stated, but I think if your 1st idea is implemented, being the UI user-input entity is visibly and functionally disabled and the user taps on it anyway, it conversely becomes a great UX if an HA-generated explanation appears, informing why or till when it'll remain disabled, such as "Awning can be operated again in 0:45" or "Music station selection during Dinner Service hours is by management only" or "Chain saw locker can only open when John is in the house". With an admin-controlled option whether or not to show it, either inline or as a pop-up.

The reason this option can be good UX is, it prevents the "it's not working" thinking, or jabbing the screen like mad.

[EDelsman]

One major use case I have for a configurable or settable read only state is for covers. I have a lot of blinds hanging in front of inward opening windows. Operating those while the window is open creates a terrible mess as the blind unfolds on top of the window. I currently have over 12 template covers, a lot of scripting and a lot of "unsafe" hidden covers that would no longer be needed if I can just make the original cover read only when the window is open.

[elupus]

I think override support using automations would, so automations could still operate the entity when blocked if needed. Say a cover that cant be operated in windy conditions. You still want lt to close. Maybe the confirmation variant would work here, with a way to mark an action as confirmed from the start.

[EDelsman]

Allowing close could also be accomplished by adding the window state to the read only state. If a blind is already open, there is no need to make it read only to prevent opening. You'd block it as soon as it is closed (and of course close it when the wind picks up). Just using automations does nothing for the UI or for voice activation. I do not want a cover to be activated by voice if it is in a bad state. I want it to ignore the command. The only way for that is to disable the controls themselves. It does require the read only state to be set by template or otherwise by a service.

[elupus]

My intention was some additional override/confirm parameter to automations to bypass the block. So would not by default be allowed. But yes, ensuring closed before blocked works reasonable.

[chefdeit]

...so automations could still operate the entity when blocked if needed. Say a cover that cant be operated in windy conditions. You still want lt to close.

The italicized part amounts to us wanting to restrict NOT the whole cover entity in question, but only a subset of its actions: cover.open_cover, cover.toggle, cover.open_cover_tilt, cover.stop_cover_tilt, cover.toggle_tilt.

Based on @elupus 's example, blocking needs to be more granular than entity level. Sounds like some use cases call for restricting a given entity's specific actions - not the entire entity.

But if "thing X" is restricted, an automation shouldn't get a free pass with the outright "can't use" restriction being relaxed into a de-facto weaker "proceed with confirmation" restriction. If such a weaker "proceed with confirmation" restriction is appropriate for a particular entity or entity-action, then that's what should be in place for the UI and automation both, in the first place. Because it doesn't matter whether an automation trigger kicks it off or a UI input (both might run awry of the intended protection).

Maybe the confirmation variant would work here, with a way to mark an action as confirmed from the start.

Yes. So we have entire-entity or per entity - action protection levels:

1. None (default): Entities and entity-action combinations that are available, same as now.
2. With Confirmation: Entities and entity-action combinations that prompt the initiator user "This can [impact] because of [condition]. Proceed?" (in as human a language as possible interpreting the associated logic - not hard-coded). In the case of an automation that doesn't set the override "and yes, I'm sure" by design, the confirmation should pop up as a notification & confirmation box for the admin / other appropriate users.
3. With Approval: Entities and entity-action combinations that prompt the initiator user as above. If confirmed, then also ask approval of the admin or whatever RBAC - Role Based Access Control (Users & Groups rights) #22 role in the future may exist for special-case approvals.
4. Restricted: Entities and entity-action combinations that are restricted, period.

Further to @elupus 's point "with a way to mark", entities and entity-action combinations 2...4, should be distinctly marked/decorated in dashboard UI and also blueprint var screens, HA editor for automations, scripts, scenes as (a) those for which restriction logic exists, and (b) those for which that restriction logic is currently active / the restriction is in effect).

[sveinse]

Encountered another use-case in the integration I'm maintaining:

The API vendor (which the integration works towards) requires that the integration does not send a value change request if in a specific mode. This value is represented as a number entity in HA. Normally, changing the value will send an update command to the API, except when in this specific mode. Yet, the entity is not unavailable.

Currently the only way to handle this is to leave the number entity enabled, but give an error to the user if the user attempts to set a value when in the mode that doesn't permit update. There is no way the user can see that state without adjusting the number entity.

[ivanfmartinez]

More use cases :

• sunblinds should not be opened with winds over a threshold
• when running the house on batteries I dont want some devices to be turned on

A generic suggestion can be to have an optional template on entities that are controlable. HA will check for existance and execute this template before the command execution commands and this template can return true or false indicating if the command should or not be executed.
When no template defined anything can be executed (making it still on same current behaviour), to make a entity readonly just return false every time, and for all other cases the template should decide what to do.

This template should receive the current state, command requested to make the decision, this can allow blinds/cover to be closed but not opened on winds and maybe all other conditions that are suggested here, including checking other entities.

[farmio]

I think there are 2 different cases which sometimes seem to be discussed as same:

• the entity can't be controlled - it's API or whatever just doesn't allow to do so currently.
• the entity shouldn't be controlled - the user would like HA to not control it due to some logics. Control from eg. a first party App or physical switch may still be possible.

For the example of covers with wind sensors, both could apply. A cover can have a "hardwired" wind sensor or a user could have an external wind sensor (maybe of a different manufacturer or protocol) and wants to couple its state to a cover via HA.

IMHO latter could be achieved via some helper (like switch-as-x).

[sveinse]

I think those two cases are about severity. But there are grey zones.

• If the user have blinds that gets destroyed if operated while windows is open, that automation shouldn't quickly becomes a can't. Or at least the severity is high.
• In a car charger API you can issue "Start Charge" command if the car is not connected, but you shouldn't.

As a side-note: I had a power switch installed on the large amplifier rack in my home cinema. I had to remove the "toggle" feature altogether from HA, because if a user accidentally double tapped the toggle button when the power was on , the power would go off and then quickly on again. This made the amplifier go POFFF and the circuit breaker would blow. Now I have a distinct on button and another off button, where you cannot turn on the power unless the power have been on for 30 seconds to protect the amps. This is a safety feature.

When I queried around in the HA communities, the opinions were clear that its not HAs role to enforce safety. This has to be provided by other means. Which can be hard to do if these controls are ordinary entities that are available in the GUI.

[chefdeit]

I think those two cases are about severity

Precisely. And grey zones can be catered to by adding two parameters to "Read-only" mode for entities feature being requested here:

1. Granularity: being able to restrict not just entity but entity-action (e.g. cover-open if windy)
2. Severity: allowed < "Sure?" confirmation request (to user at dashboard or via notifications if via automation) < same confirmation request + admin approval who gets notification < restricted.

[chefdeit]

When I queried around in the HA communities, the opinions were clear that its not HAs role to enforce safety. This has to be provided by other means. Which can be hard to do if these controls are ordinary entities that are available in the GUI.

Other means ... like what?? We're NOT asking HA to enforce safety on our behalf. We're asking for the HA platform to include a parameter whether a particular entity's action(s) are restricted at levels of "none" (default) or "confirm" or "approve" or "outright", be it with a bit mask + "reason" text field or however else they choose. Then it'll be up to us - not HA devs - to set those, and for UI entity widgets to reflect a given restriction level being (a) present and (b) currently in effect.

[sveinse]

Safety limits can be considered a subclass of "things the user should not be able to do", which is also the same as disabling an entity e.g. to not open or close the blinds if the window is open.

[iMicknl]

For Overkiz this would be really relevant as well. Covers and other entities can be locked. This lock can be set by users via remote or based on other sensors/data. E.g. block cover opening with wind, open pergola automatically and block closing with snow.

An (optional) override option would be great here. Currently we can't easily add an override option to Overkiz as the frontend doesn't support this.