A simple question: is there a way to pass data from one automation run to another and/or discern what kind of a state the automation was in before it was triggered. Would automation context be of help here, and what exactly would I be looking for?
And now some context: I have a deceptively simple scenario (one that probably everyone encounters when they start dabbling with automations) - I have a light in the bathroom triggered by motion and set to turn off after a couple of minutes. If motion is detected, the automation restarts.
The tricky part - Instead off immediately turning off, I want the light to dim down over a course of about ~30s .However, light is integrated via KNX (it’s a DALI light downstream), and only DPT 1.001, 3.007 and 5.001 are exposed (no ScalingSpeed DPT 225.001). So, I decided to roll my own, and in my automation when light needs to be turned off I call a script (running in single mode) that lowers brightness of the light entity by 2 percentage points every second, until light is off.
The problem here is that this actually changes the state of the light, and when light is turned back on it will be at 1-2% brightness. Right now I’m handling this by turning the light on with fixed brightness when automation triggers, but this is at a cost of flexibility of using the physical controls for the light. I’ll probably add an if to check if light is already on with a higher brightness to at least somewhat mitigate this.
I have a couple of ideas on how to deal with this, but I’m missing lower-level knowledge of how to update state/attributes and if it’s even allowed/possible:
-
At the start of the automation determine whether
context.parent_idis defined, and if not (that is the initial trigger, and not a restart) store the current light brightness as an extra automation attribute, and read from that attribute when automation has restarted (there is parent_id in context). Then at the end of automation, light brightness would be set to initial value, and immediately afterwards light would be turned off (if there’s no debouncing, I think this should work with no visible effect) -
Same as above, but perhaps just some virtual light entity (is that possible?) that would mirror non-script updates to the light, and use it as a source when initialising the automation. Tricky part here is how to discern non-script updates from any other (even external to automation) one. I guess, as a hack, I could compare old and current state of the light entity and just ignore any 2% downward shift in brightness. This setup might be better suited when trying to implement something like a cooldown period for the automation when light is manually triggered from a switch.
I had some other ideas, but the above ones are what came out of the process of filtering them for sanity.
BTW, I do have node-red set up and integrated in home assistant, but I haven’t used it yet to create any automations, so maybe it would be helpful here? Maybe if its setup with its own user, context user id might be helpful?
I also read some more while I was writing this, and I see there is something called Entity Controller, which might be of help?