I have an automation that triggers 15 minutes before sunset and - if nobody is home - turns on the lights in the family room and plays some talk radio through one of our ChromeCast audios. If one of us comes home there’s another automation that turns that stuff off, and a third automation that will turn it off at 11pm even if we’re still not home.
To accomplish all this I needed to store a variable that tells the second and third automations if the first one was triggered. Without that the lights and chromecast would turn off at 11pm even if the reason they’re on is that we’re home and using them (i.e., we turned them on rather than the automation).
My solution was to create an input_boolean and add a customization to hide it from the UI. If the first automation triggers then it turns on the input in addition to the lights and the ChromeCast. Automations 2 and 3 are conditional on the input being turning on, and will turn it off in addition to the lights and the ChromeCast.
This works just fine, but is there a better way of storing variables from scripts and/or automations? I feel like I’ve hacked something together that should have been easier to accomplish.
I agree, this is your best solution. Its not really a hack since the input_booleans were implemented initially for your exact reason. To be utilized as a state to determine what should and shouldn’t be triggered. Obviously you can still use them in the frontend as a switch to trigger scripts, scenes, etc directly, but there was a major call for a means to store a state to be checked against.
This is an automation system, so I think it is very fitting to use a “device” if you will (in this case, a virtual switch) rather than variables. It is an easier concept for non-programmers to understand and just fits right in with the idea of IoT, where everything is an object that can be utilized
I have many, many input_booleans used for the exact same purposes as you.
Another option, if you are fond of the variables concept, is to use the built-in MQTT broker to store values in MQTT topics and simply have a template sensor attached to that topic. You can then either use the sensors value in a condition of an automation, or you can trigger an automation when the value changes. The built-in MQTT broker is pretty much Home Assistants only version of a variables system, and it does quite a nice job at it too.
Along with my input_booleans, I am also using MQTT for some of my other automations.
Awesome, thanks both for your responses, and @jbardi great suggestion on using MQTT to store stuff.
In the back of my mind I was thinking about how I’d persist a variable across HA restarts, or store something more complex than the various input_* components allow. Not that I have any particular reason to do either… yet.
Are there any limits to the input_booleans? I have several switches that it would be beneficial to know whether the light was turned on due to automation or due to the manual switch being thrown.
Also I haven’t played with MQTT. Would a local MQTT broker be a good way to store variables associated to a specific person (as identified by their iphone)? I’m not completely sure of my logic here yet so that request may not sound as good as it does right now, in another 15 minutes.
For this exact situation it is not necessary to store any state, because you can directly test the last time an automation has triggered. Here is a condition I used on an automation where I wanted it to be able to fire once a day once other conditions were met. This is the condition that prevents it from re-triggering until some time (most of a day) has elapsed:
Nothing magic about 36000 seconds, it’s just chosen to be longer than the daily window where this trigger is active (according to another condition: time).
