It would be great if we would protect certain entity states via a condition. If the condition is not met then the entity does not move to the new state.
For example, I have recently integrated a switchable outlet and attached my 3d printer to it. I would like to be able to protect the light.turn_off service call with a condition that verifies that the 3d printer is not currently printing using the Octoprint integration.
I know I can create a script with the condition and reference the script everywhere but as I am not the only HA user that does not give me peace of mind that someone won’t accidentally turn off my printer during a print.
If a user tries to change an protected entity into a protected state and the defined condition is not met then nothing changes.
And you could use a template switch.
Is this any different from using a script? AFAIK, there would still be nothing actually preventing HA from toggling that outlet. The only methods I know of that can even come close are just an interface to the existing switch that must be remembered to be used at all times or the “protection” is gone.
I want protection from an unknowing user, a misclick, or even an automation mishap.
if the switch has a hardware button, and someone switches it ? Do you want HA to toggle it back, or have some hardware where you can block the manual switching of the switch through HA ?
I would imagine that this would be protection at the HA service call layer. If an integration changes the state “internally” then it should reflect reality.
Toggling it back into the protected state feels like something that could be (and maybe should be) handled by a normal automation.
Now that you’ve pointed that out, if there’s no way to tell an “internal” state change from an “external” one then this would probably be pretty hard to implement.
Have the only way the outlet can be shut off as a software command, no hard wired switches. Then the off command is a value template. The value template would always be the same for the printer. You’d use it rather than switch.turn_off in your automations.