please help me memorize where this same issue was discussed, but another solution was suggested, by simply adding the entity_id into the template as a āfakeā x entityā¦? I canāt find it but my memory tells me it was in the WTH thread somehowā¦ not sure though.
It was a much more elegant solution than the one offered in the documentation tbhā¦ btw, never realized this was suggested as far back as jan 2018ā¦
edit
duh, its in the link you already postedā¦sorry for that:
{% set x = states('sensor.date') %}
and no need for convoluted strptime sensors which might not even be used, and need to be added especially for this purpose.
would be nice if the short solution by Petro be added to the official docsā¦
of course this is another proof for the need of global variables (the would also trigger the template) because sensors like this would need it in all templates:
utc_offset:
friendly_name: Utc offset
entity_id: sensor.time
value_template: >
{{now().utcoffset().total_seconds()/3600}}
icon_template: >
mdi:numeric-{{states('sensor.utc_offset')|int|abs}}
or, would the self referencing here be enough to workā¦?
other example:
entities_domains_counter:
# entity_id:
# - sensor.date
# - sensor.count_persistent_notifications
friendly_name: Entities per domain
value_template: >
{{states|count}}
attribute_templates:
headline: >
{{states|count}} entities in {{states|groupby('domain')|count}} domains
alert: >
{{states.alert|count}}
automation: >
{{states.automation|count}}
binary_sensor: >
{{states.binary_sensor|count}}
camera: >
{{states.camera|count}}
climate: >
{{states.climate|count}}
counter: >
{{states.counter|count}}
# continue to list all domains
they now all would need a set x
? I feel being able to set the entity_id: was not that bad, and most certainly has its advantages over these cases. Setting the entity_id for the full template sensor, and by that limiting updating to only that entity_id was sheer powerā¦ Sorry to see that go.
took my chance to ping the merged PR on thisā¦ hope Bdraco wont minor suggests otherwise