This was a topic of 2020’s Month of “What the heck?!” (WTH no declarative automations?), and it’s very important to me, so I thought I’d repost it.
I’d like to be able to write automations like so:
If the window is open, set the thermostat to X degrees
If and only if movement is detected, turn on the light
A further improvement on this would be to be able to assign priorities to such automations, for example (from lowest priority to highest):
Keep the temperature at 21 (the default state)
If it’s 23:30—08:00, keep the temperature at 18 (i.e. don’t heat at night)
If it’s Tuesday and it’s 07:00–08:00, keep the temperature at 21 (i.e. start heating earlier)
If it’s the weekend and it’s 08:00—09:00, keep the temperature at 18 (i.e. start heating later)
If the window is open, keep the temperature at 18 (i.e. never heat when the window is open)
This would let me describe my temperature automations very neatly. Currently, I have a bit of an elaborate logic of what time to turn the heating on, which makes it quite difficult to create an automation to turn the heating back on when the window is closed. That’s because I have to replicate all the time-based conditions in the “and if” section of the automation. Having declarative automations with fallback to default/previous/lower priority values would really help here.
It’s funny. I was just thinking the exact same thing this morning.
I use kubernetes at work and the “declarative” state model really works well. Actions change the declarative state, then the controller attempts to reconcile the declared state with the real world.
So for temp in a house, you’d have your declared temp ranges over time. The controller would then ensure that it stayed within those ranges.
Similarly, for lights you might keep track fo the on/off and brightness in state. Then the controller would simply ensure that the lights actually matched those values. Actions could be both app/buttons and things like the light switch power changing state.
I’ve found that attempting to write automations or control multiple lights is always a little quirky while having a controller simply reconcile state would hopefully simplify this.
I’d be interested in potentially working on a project like this, if someone can help point me in the right direction.
I’m not an expert on it, but from what I gathered about the way automations and triggers work, this might be a major architecture change. AFAIK the underlying method is to look for state changes, not to look at states continously to see if they match a certain pattern.
I’m not sure if you are interested in workaround suggestions for the specific examples you gave, but if not just ignore them:
You could use a schedule helper that has all the times for heating in it, that way you do not need a lot of logic but you only need to check what the schedule says
If a schedule will not do, you could put the complex logic of what time the heating needs to be on in a separate script, which you call from the automation and that sets a input helper.
For the light, you could make a script that first checks if motion was detected, then turns the light on. In all other automations that would turn the light on, you run this script instead of the ‘light turn on’ action
Just wanted to say I second this. As someone who works primarily in functional programming languages, I’ve ended up using the API to control HA on a lot of occasions just so I can keep my automations declarative.
I’m a HA newbie and I’m actually surprised this isn’t a thing yet.
A declarative approach is just way more natural and probably more concise for most applications.
A declarative approach also enables clean recovery of system state from system failures (imaging HA goes down for 8 hours to to power/hardware failure or human error). Example: Turning off the christmas lights in the evening would be missed if the time to switch off is during the system downtime and then the christmal lights would be on instead of off for the night. An arguably harmless example.
Adding my 2ct to this: I often find myself struggling with devices on the edge of reception, where they regularly disconnect and reconnect.
For example, I’ve got some lamps set up with esphome that turn off 2 hours after sunset. If the smart plug happens to be disconnected at exactly 2 hours after sundown, the lamps will not turn off until 24 hours later (assuming they are connected then).
Declarative states would completely solve this issue here.
As for:
I don’t think it’d be as much of a change for my use case at least. In fact it can already be done, it’s just a bit of a pain right now with a lot of devices.
In essence, what you’d need to do to achieve this is, instead of directly updating a value, you update a helper value. On update of this value, you check if the device is online and running and if so, update it to the new value (essentially the same workflow as the default here, just with the helper value as extra step).
If the device is not online, set a trigger to run the next time the device connects again, and then set the state to the helper value.
The only real deviations from the default flow here are to run a trigger on reconnect and to update to and from a helper state instead of directly.
To reiterate: This is possible in HASS today, with the existing automations system, it just is a pain to set up for every device.
Implementing this natively shouldn’t, as far as I can tell, require that big of an architectural overhaul, and to the user could just be abstracted to a single checkbox.