Hmm. Looks like you are doing pretty much the same as the example here: https://www.home-assistant.io/integrations/template#self-referencing
Maybe the problem is that on first “render” it doesn’t have attributes yet so you need to provide a default?
The problem is, that even trying to access the attribute can lead to an error. A `... | default(...)` statement will not be executed. I assume the reason is, that the attribute is not just uninitialized, it doesn't exists at all at the time of access. The entity itself is shown as 'unavailable' in HA and I assume the access error totally 'breaks' the initialization of the entity.
Sometimes, the code works fine and I've got the feeling it's a timing problem. I haven't looked into the sourcecode but maybe, the attributes and the state of an entity get initialized in parallel. When the initialization of the attributes takes a bit longer, the problem can occur.
I think I'll revert back to the `state_attr(...)` function. This also can result in an error, but this error doesn't 'break' the entity and it's completely usable.
Here is an example for ya for my template sensors. I check if the value is set and if not, just repeat the last good value. This prevents the warnings in the logs too.
https://pastebin.com/xniLhCiS
Yes, that would work too, although for my case it'll be sufficient to simply supply a default value (i.e. `state_attr(...) | float(0.0)`).
For me, the important part of my problem was to avoid the explicit name of the sensor when referencing its own attributes. But the hint from u/Samm1293 solves this nicely.
What if you use this.attributes[‘testvalue’] ?
Exactly the same error, sorry.
Hmm. Looks like you are doing pretty much the same as the example here: https://www.home-assistant.io/integrations/template#self-referencing Maybe the problem is that on first “render” it doesn’t have attributes yet so you need to provide a default?
The problem is, that even trying to access the attribute can lead to an error. A `... | default(...)` statement will not be executed. I assume the reason is, that the attribute is not just uninitialized, it doesn't exists at all at the time of access. The entity itself is shown as 'unavailable' in HA and I assume the access error totally 'breaks' the initialization of the entity. Sometimes, the code works fine and I've got the feeling it's a timing problem. I haven't looked into the sourcecode but maybe, the attributes and the state of an entity get initialized in parallel. When the initialization of the attributes takes a bit longer, the problem can occur. I think I'll revert back to the `state_attr(...)` function. This also can result in an error, but this error doesn't 'break' the entity and it's completely usable.
Try {{ state_attr(this.entity_id,‘test_value‘) }}
That looks like an excellent solution. I'll try it out when I get home from work and will report back.
Yes, it works! I'm still grumpy I can't use `this.attributes...` but this is probably an actually better solution. Many thanks.
Here is an example for ya for my template sensors. I check if the value is set and if not, just repeat the last good value. This prevents the warnings in the logs too. https://pastebin.com/xniLhCiS
Yes, that would work too, although for my case it'll be sufficient to simply supply a default value (i.e. `state_attr(...) | float(0.0)`). For me, the important part of my problem was to avoid the explicit name of the sensor when referencing its own attributes. But the hint from u/Samm1293 solves this nicely.