Interface Component

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.

I may be misunderstanding but could you not do this with an input boolean?

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.

That makes no sense to me. If it is storing triggers then it has a state.

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)

interfaces:
  set_strip_color:
    parameters:
      - name: colour
        default: [150,0,0]
      - name: transition_time
        default: 2
      - name: entity
        required: true
    reference:
      service: light.turn_on
      data:
        entity_id: {{entity}}
        white_value: 255
        brightness: 200
        rgb_color: {{colour}}
        transition: {{transition_time}}

andthen you use it in automations like this:

actions:
  - interface: set_strip_color
    paramaters:
      - entity: light.tv_led
      - colour: [100,100,0]

I suppose you can use scripts for this. Wrote this mqtt processor component to help with my RF code use case:
MQTT interface component