Just to step back for a moment, is your sensor showing the same value literally all the time? Like is full date actually a hard-coded date and your sensor is just showing its value formatted? If so then yea I guess petro’s solution works but I don’t think this is a general solution if that’s what you’re hoping for.
Normally the state of entities keep changing. And when that happens you’ll be back to this fundamental issue:
(emphasis mine)
Which means you kind of can’t do what you’re trying to do. Variables in templates are only available within that template. And you can’t stuff values into attributes and expect them to be available in other templates because they resolve out of order.
If you want a general solution, it’s to use a trigger template sensor instead of a template one. This way you can control the order of operations by doing something like this:
template:
- trigger:
- id: real
platform: homeassistant
event: start
- id: full_date_update
platform: state
entity_id: sensor.some_name
attribute: full_date
to:
- id: timestamp_update
platform: state
entity_id: sensor.some_name
attribute: timestamp
to:
- sensor:
- name: Some name
state: >-
{{ states('sensor.some_name') if trigger.id != 'timestamp_update'
else state_attr('sensor.some_name', 'timestamp')
| timestamp_custom('%-d %B', True, default = 'unknown') }}
attributes:
full_date: >-
{{ state_attr('sensor.some_name', 'full_date') if trigger.id != 'real'
else ... }}
timestamp: >-
{{ state_attr('sensor.some_name', 'timestamp') if trigger.id != 'full_date_update'
else as_timestamp(strptime(state_attr('sensor.some_name', 'full_date'), '%Y-%m-%d'), default = 2147483647) }}
With a trigger template entity you can forcibly sequence the order of operations like this. You basically have a trigger per each attribute/variable that is only used to update one part of the entity. That update triggers the next one until the entire entity is up to date in the order you want it to go.
If my understanding of your use case is correct then this is overkill and you should do what petro showed. But if you’re looking for a general solution to this problem where the real
trigger can be anything (and not just used to set a constant at startup) then I think this is it.
But tbh you really have to consider whether this is worth it. With all the extra triggers the code is not only longer and more complex its almost certainly less performant then just copying and pasting the variables code.
EDIT: Btw if full_date
is in fact a constant then another option is to use customization to set its value. That way it will be set when the entity is loaded into the state machine before any of these templates run. That won’t help you with timestamp
since that is actually a template but at least you can always bank on full_date
existing that way.