We have a number of components that act like “switches” such as input_booleans, binary_sensors and regular switch. The problem with those is that they need to be reset to off which creates a problem: When should they be reset to off? You might say at the end of your automation. I think thats really bad design because it means every single automation that uses this switch has to remember to set it back to off. It should not be the automation components responsibility to main the state of components.
The feature i am proposing is a interface component (or whatever the final name may be). It does not have a state like on or off, all it represents is a complex trigger/condition or automation!
For example:
Say you have a complex MQTT trigger for motion sensors.
Rather than copying that trigger to X different automations (and duplicating information such as MQTT topic, payload etc), this proposed interface component would enable you to create a new interface containing the trigger information.
This then allows you to use interface as a trigger in other automations, easy reuse if required. You would only use an interface in cases where you expect the need to reuse a component in mulitple places.
interface is like a variable storing trigger, actions, service calls and conditions for reuse throughout the configuration.
no, input booleans have state. what im talking about is a component that stores triggers. Think of it as an interface between a device specific trigger (such as MQTT) and the set of automations triggered by it.
Whats its state? Its not on or off, its not 22.3C or 30W. It is stateless, it allows you to use a trigger/action/condition in multiple places without duplicating the trigger/action or condition itself (it may be complex)