Resolve conflicting triggers with meta-entities - your ideas needed

Configuration
1

TLDR; see QUESTION below

Consider a light in your entry hall. When you arrive home, you might want to trigger the light on for a few minutes. If you’re already home, you might have an indoor PIR trigger the light as you walk toward the hall. Maybe you want the light to turn on for a time when triggered by your doorbell, your garage door, or your alarm. You can control the light with a physical switch, or with voice commands. And you might also bundle the light in scenes or groups that include other lights.

What if you want the light to stay on while you clean the floor? How do you stop the triggers that would turn it off in a few minutes? Or, temporarily you want the light to stay off when it would normally be triggered on. What if you normally only want to trigger the light at night, but right now you want to trigger it day or night?

Code that controls your light could be scattered in scenes, groups, automations.yaml, node red, mqtt etc.

How do you make it all work cleanly?

Given: A physical switch will directly control the light

Thesis: Everything else can control the light through two meta-entities: light-mode and light-future

light-mode determines when triggers are active: stay-on / stay-off / triggered-night-only / triggered-always /

So when a trigger occurs (motion, door, alarm, etc) the automation checks light-mode to determine if it should do anything e.g. if light mode is triggered-night-only but it’s currently daytime, the trigger does nothing. If it’s nighttime, the automation would turn on the light and then set another meta-entity called light-future that would turn off the light after, say 5 minutes

If more triggers occur before light-future executes, they could simply change light-future e.g. more motion extends the light off time

If light-mode changes, for example to stay-off, before light-future executes, an automation could cancel light-future

I’m thinking light-mode could be an input_select

QUESTION
light-future needs to trigger an automation when the time is up. I’ve never used input_datetime – would that work or is there a better choice?

Any other ideas would be appreciated.

Cheers, Richard

2

Turn the light off when there is NO motion detected for x minutes.

Depends on whether temporarily is based on a condition or just whenever you want. You could have a condition in your automation that turns on the light “only when lux level is below xy”, or if you don’t have a condition a button in the frontend that temporarily disables the automation.

Create an input_boolean and in your automation turn light on if evening or input_boolean is turned on, then turn off the input boolean when you don’t want light during the day and turn it on when you want light during the day.

Put all your code that belongs to a certain category in a package to keep it all in the same place.

1 Like
3

^^^^ What he said :rofl:

And I pretty much do all of that

1 Like
4

DITTO the above and,

I recommend defining the logic and conditions for each trigger to turn on or off the light. Then look at the relationships between the triggers (Is it more important for a flick of the wall switch to turn on the light for no set duration, than to have a PIR control the light on and off?) and use that for your meta-entities definitions and control when triggers can act. Time of day, sun elevation, the light is on/off don’t really require meta-entities as they are part of HA, but relationships between triggers is not.

5

Thanks all. So what would be the best way to set up a timer that would execute an automation when it reaches 0 and how could I increase the time before it gets to 0?

6

Use a timer and create an automation that triggers when the timer finishes. To extend the timer you can use the timer.start service with your desired extension time.

But it would be helpful if you describe your exact use case, conditions and requirements from real life.

1 Like