Is there a reason I’m not considering why attributes can not be added to some template entities? Or is it just not implemented?
As per the template docs only some device types allow setting them.
Attempting to load the following templates it generates this in the logs due to attributes included in a number template.
2025-11-15 10:15:50.135 ERROR (MainThread) [homeassistant.config] Invalid config for 'template' at configuration.yaml, line 32: 'attributes' is an invalid option for 'template', check: number->0->attributes
input_button:
foo_button:
name: Press Foo Button
template:
- triggers:
- trigger: state
entity_id: input_button.foo_button
sensor:
name: foo_sensor
state: hello
attributes:
my_attribute: foo
- triggers:
- trigger: state
entity_id: input_button.foo_button
number:
name: foo_number
state: 123
# This is not allowed
attributes:
foo: bar
set_value:
- action: system_log.write
data:
message: Updated state to {{ value }} this={{ this.entity_id }}
But, it’s possible to set attributes via customize:
homeassistant:
customize:
number.foo_number:
attributes:
foo: bar
Also, the set_value actions don’t run when the state changes from “unknown” to (in this example) 123 when triggered. The same trigger in an automation would trigger from “unknown”. I guess that makes sense – as its state isn’t really set until triggered the first time?
It’s probably worth a feature request just to make it consistent across all the template entities.
My use case was a kind of queue, so using the number template as the index into the queue and the queue itself stored in an attribute within the same entity.
Some event, like a button press, dynamically creates the queue list and then update of the number triggers processing the queue.
I can use a sensor, which allows attributes, that triggers with the button and saves the current time as the state. Then trigger on the time (state) change in another automation or trigger-based template.
What I’m not clear on is if there’s a race where the state change trigger could happen before the sensor’s attributes are updated.
template:
- triggers:
- trigger: state
entity_id: button.run_queue
variables:
queue: "{{ ... build the queue ... }}"
name: Foo Queue
state: "{{ now() }}"
attributes:
queue: "{{ queue }}"
# Could this trigger before the "queue" attribute is updated?
# Can't trigger on the attribute change as the queue might not change.
- triggers:
- trigger: state
entity_id: sensor.run_queue
...
...
Also, the set_value actions don’t run when the state changes from “unknown” to (in this example) 123 when triggered.
The set_value sequence never preformed in changes of the state value. It’s only preformed when it’s actively changed, either in the GUI or with the number.set_value action.
The same applies to all other template entities, like select, light, switch, etc.
Is there also a plan for an action to add/replace and delete an attribute?
I’m failing trying to find a trick using a template to update an attribute synchronously (or waiting for it to update).
I'm missing something
Trying to force the template to update and waiting on it to be the new state.
input_text:
current_state:
input_button:
update_template:
template:
- triggers:
- trigger: state
entity_id: input_button.update_template
sensor:
- name: Some Template
state: "{{ states('input_text.current_state') }}"
attributes:
foo: The attribute is now {{ now() }}
script:
update_template:
sequence:
- variables:
new_value: "{{ as_timestamp(now())|int }}"
- action: input_text.set_value
target:
entity_id: input_text.current_state
data:
value: "{{ new_value }}"
- action: system_log.write
data:
message: |-
Updated input_text with {{ new_value }}
And state is {{ states('input_text.current_state' ) }}
And template {{ states('sensor.some_template' ) }}
- action: input_button.press
target:
entity_id: input_button.update_template
- wait_template: "{{ is_state('sensor.some_template', new_value ) }}"
timeout:
seconds: 10
- action: system_log.write
data:
message: |-
{{ 'completed' if wait.completed else 'timed out' }}
Set state to =={{ new_value }}
Template state={{ states('sensor.some_template') }}
2025-11-16 09:28:42.362 ERROR (MainThread) [homeassistant.components.system_log.external] set_value
Updated input_text with 1763314122
And state is 1763314122
And template 1763313846
2025-11-16 09:28:52.369 ERROR (MainThread) [homeassistant.components.system_log.external] After wait
timed out
Set state to ==1763314122
Template state=1763314122
Your is_state call is wrong. You defined new_value as an integer. But when you read a state, it’s always a string. Use new_value | string in your is_state call
there’s really no reason to add that. Just have the template output None, anything that uses the attribute will see it as the None object which you can treat in other templates as missing.
This script and automation seems pointless, why are you doing this? Your output shows that it’s working as expected.
You set the input_text and then write the state and template. They will be out of sync at this point because you ran the button press.
you then press the button and the state of the template entity updates immediately before your wait even starts.
Then your wait times out because it already changed state, and you see both values being in sync.
Aside from all this, I’m getting an XY problem vibe from this post. What is your actual overall endgoal?
Yeah, you are right. Should have started a new topic.
The overall goal is to, at some event (e.g. button press), to save off a dynamically created list and begin processing that list, like a queue. Could be longer than a state can hold, so that leaves storing it in an attribute. Processing the list should survive a HA restart.
Only way I know of to update an attribute dynamically is via a trigger-based template. And even then I’m not sure how to know when it was updated.
Just make a trigger based template sensor that has a list as an attribute. You’ll have 2 triggers, one that adds, one that removes.
Then you have an automation or script that processes the queue by getting the first item, then call the remove event, then process the item, and move on to the next.
- repeat:
while:
- condition: template
value_template: "{{ (state_attr('sensor.queue', 'queue') or []) > 0 }}"
sequence:
- variables:
item: "{{ (state_attr('sensor.queue', 'queue') or []) | first(None) }}"
- condition: template
value_template: "{{ item is not none }}"
- event: remove_from_queue
event_data:
id: "{{ item.id }}"
#Process your item here.
It won’t survive restarts, it would if you made an automation that was always running and only processed data when an input boolean was on. Something like that.
I don’t really understand the async event processing, which I’m sure you can tell.
Are you saying if I do the input_button.press action in a script it will wait until the triggered template has been updated, and therefore there’s no need for the wait_template?
Your question suggests to me that you still haven’t really shared enough about what exactly you want to do.
(And the answer to your question is no.)
What’s going to be in the queue, and where does it come from; what triggers additions; what triggers deletions? There’s honestly quite likely a better way to do what you want than implementing a pop/push using a trigger-based sensor–which is actually tricky unless you are pretty adept with Jinja.
it’s async, that means it just does the action asap. You will run into race conditions if you’re trying to pair this with a service like you’re trying to do. The behavior will be different every time you try to wait for that value to change because the abstracteventloop may have a ton of things it’s already doing or it may be empty. It’s the nature of async.
Still, I’m not sure why you’re focused on this, there’s no reason to care if it’s updated or not. A proper queue just pulls items out.
Exactly. Which is why I was doing the wait, and then still wondering if that could mean the template’s state was updated but not sure if that would really mean the attribute was also updated at that point. (A script triggers the template to save the list, then once the list is saved the script starts the processing of that list.)
Since it is the triggered-template’s attribute that builds the list then I can’t start using that attribute’s value elsewhere until I know it’s really saved. That’s why.
Ok, clearly I’m trying something the wrong way. Or hard way.
The jinja part isn’t much of an issue. Probably a bit of a race, but I’m using a index into the list to keep track of where in the list I am, so not really a queue.
Stepping back, this is for queuing up irrigation valves to run. It’s similar to building a playlist of songs, except you specify how long to run each. Then click “go”, then the “playlist” is built and then that “go” script starts running thought the list. And should handle restarts.
Here’s one probably better way: use timers. One timer per thing you want to turn on.
Open your valves, and set a timer for each.
Have an automation that triggers when the timer finishes and based on the timer, shut off the valve.
Timers survive HA restarts.
Unless there is a lot more nuance to your use case, like a constantly changing list of valves, the queue-based approach you’re contemplating seems absolutely overkill.
