As I’m diving into more automations there’s one thing that still eludes me a little: how to handle that some rules overrule or mutually exclude each other from a resource.
Let’s take a simple example: a motion sensor and a light bulb. The basic rule is: When presence is detected turn on the bulb. Also, when there’s no presence detected for 10 minutes, turn off the bulb. Pretty straight forward automation.
Now we add a button. The motion sensor should still do its work, BUT if the button is pressed to turn on the light all presence detection (someone there or not) should be suppressed. In other words, the button now has the bulb resource until someone manually turns it off again, and then motion sensor logic can take over again.
As I see it, two things need to happen: I need a flag that indicates that the bulb was manually turned on. I’d intuitively choose input boolean that follows the state of the bulb, but is specifically not the bulb state because that alone wouldn’t indicate anything about what turned it on. Also, the sensor automation needs to be extended to check the flag and not do any work if the flag is true.
This could work. But now enters a 3rd rule… if someone rings the doorbell, the bulb needs to show green light for 30 seconds. Now things start to get a little fuzzy, because the light can be on already or not, and after the 30 seconds it should either turn off the light or go back to previous state.
The concrete permutations aren’t really that interesting here, because it’s a simplified example. But the fact that we have some foundation rule, that can be overruled by another rule, and that these two rules are subject to being overruled as well I find interesting.
It’s a sort of state machine issue, so I’m wondering what would be a well established method of solving this i HA.
Make your automation small, never set long waits and and make it handle the permutations inside itself. I follow those and it’s never bitten me. If you have an automation you need to know if it’s running and lockout either use a nonnreentrant script (set it exclusive) or set an input select on start and turn it off on exit if you just need a flag it’s running.
In short don’t try to consume the state machine and cover everything all the time make each automation small and handle its own business… Including defense code.
I guess there is a slight difference in distinction here as well in that I think of rule 1 and 2 as inherently connected in this example case, because they’re related to, say, rules about Room X. So essentially light up the room, either automatically or manually.
The doorbell is something external to this. The room lighting up is a consequence from “outside” the room domain. The tight automation as you say for the room should react to this and decide on it’s own how to resolve the priorities. But HA also allows for just applying a Doorbell-scene across all devices, which is technically great and easy to work with, but not so great if there are specific rules in the corners of the house, so to say.
The flag-while-script-is-running scenario is not so applicable here as I see it.
The only downside I see in using an Input Select is that while it can hold several values, only one value can be selected at a given time. So in the cae of the doorbell scenario, it wouldn’t be easy to conclude which state to return back to after 30 sec: the manually set on state or motion sensor.
I can see multi select has been discussed but also put on pause and is not planned.
If the light switch is turned on manually and people are still in the room, the motion sensor will keep the light on anyway. If everyone leaves the room, the light will not be needed and will turn off after 10 minutes.
The situation where you want to override the motion sensor is a different one. You might be working just out of range of the motion sensor, in which case you want to keep the light on. In this case an input_boolean condition to stop the motion sensor automation will do it. That’s not the same as turning the light on manually.
Break it down into three main elements. The main formula I use is:
a) triggers
b) occupancy
c) inhibits
The triggers, trigger the automation to turn on the lights
The inhibits are automation conditions that prevent the light from turning on. Ones I use include - I’m not home, it’s bright outside,
The occupancy expression going to false (perhaps for 5 minutes), triggers the automation to turn off the light.
Build up the triggers, occupancy, inhibits from other templates.
Ah yes, it’s a detail from the real version of this challenge where the motion sensor doesn’t cover the whole room because of its layout. It basically covers the doorway to the room (turn on lights if someone enters - or exits, but that’s less of interest). More specifically it’s my sons room, where his bed is outside the range of the sensor. So he might turn on the light when he wakes up.
The intent for the original post was to discover the solutions models inside the box (per the problem definition, premise and devices in play) and outside the box (change solution perspective, add more devices what not).
I’m still fairly new to HA but I can see how things can turn into the equivalent of spaghetti code if one doesn’t seek out some tried and tested solution patterns. Especially as one ventures into to more detailed automations that can’t just be boolean on / off.
Over design is always a consideration of mine. But I felt like I had to discuss this type of challenge to learn about ways to not over design
