This is something that only just occurred to me today, but wouldn’t it be nice if we could access inputs of automations, just from an attribute on the automation entity?
This would let you use that input as a variable inside of other automations or even template sensors and the like.
I’ve made a quick change in my local HA instance, which does expose them in this way. It adds an input map as an entity attribute for any blueprinted automation, so accessing them is as easy as:
We were actually discussing it in the Discord a while ago. The use case that inspired me to do this was as such:
@hunterjm created a (pretty comprehensive ) blueprint for Frigate notifications, that includes a “silence” feature, with an input for “how long to silence”. We were discussing the possibility to make a template sensor which counts the time remaining before the “silencing” is over, which we got with something like:
sensor:
- platform: template
sensors:
frigate_back_porch_expires:
friendly_name: Frigate Back Porch Expires
device_class: timestamp
value_template: >
{% set last_triggered = state_attr('automation.frigate_back_porch_notification', 'last_triggered') %}
{% set current = state_attr('automation.frigate_back_porch_notification', 'current') %}
{% if current > 0 and now() > last_triggered + timedelta(seconds=60) %}
{{ last_triggered + timedelta(minutes=60)}}
{% else %}
{{ now() }}
{% endif %}
This feature would allow using the input value from the automation in the timedelta calls, rather than a “hardcoded” value (in place of the 60, for example), so that simply changing the input for the automation would keep this sensor updated correctly.
Technically, it’s the input value from the blueprint used to generate the automation.
If the value was in a traditional automation (not generated by a blueprint), it would be a hard-coded value or referenced from an existing entity’s state or attribute (so exposing it as an attribute of the automation would be unnecessary).
The goal here is to expose the user-supplied values to templating by entities other than the blueprint-generated automation itself.
What’s interesting about this suggested feature is that it overlaps with a long-standing request for native global variables. Once the user supplies values, they will be exposed as automation attributes to everything else, effectively behaving like user-supplied global variables (whose types can be something other than just string).
Did this ever get implemented. I came here looking for just this.
I have a blueprinted automation that I run a couple of copies of with different thresholds in them. I’d light to be able to display the threshold values as they are used for a time period. Rather than having store then externally.
) blueprint for Frigate notifications, that includes a “silence” feature, with an input for “how long to silence”. We were discussing the possibility to make a template sensor which counts the time remaining before the “silencing” is over, which we got with something like:
Yes, this would allow blueprints to make “global” variables, I suppose.