though today I cheered… 2021.8.2 brought us support in packages for template: top level integration. Or so I read the release notes. Did I cheer to soon, or am I mis configuring my templates in this package section:
template:
- sensor:
- unique_id: solaredge_lifetime_energy
name: Lifetime energy
state: >
{% if state_attr('sensor.solaredge_overview','lifeTimeData') is not none %}
{{(state_attr('sensor.solaredge_overview','lifeTimeData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: &energy
unit_of_measurement: kWh
device_class: energy
state_class: measurement
icon: mdi:counter
attributes:
last_reset: '1970-01-01T00:00:00+00:00'
- unique_id: solaredge_lastyear_energy
name: Last year energy
state: >
{% if state_attr('sensor.solaredge_overview','lastYearData') is not none %}
{{(state_attr('sensor.solaredge_overview','lastYearData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: *energy
- unique_id: solaredge_lastmonth_energy
name: Last month energy
state: >
{% if state_attr('sensor.solaredge_overview','lastMonthData') is not none %}
{{(state_attr('sensor.solaredge_overview','lastMonthData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: *energy
- unique_id: solaredge_lastday_energy
name: Last day energy
state: >
{% if state_attr('sensor.solaredge_overview','lastDayData') is not none %}
{{(state_attr('sensor.solaredge_overview','lastDayData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: *energy
# snip
- unique_id: solaredge_last_changed
name: SolarEdge last changed
state: >
{% if states.sensor.solaredge_overview is not none %}
{{relative_time(states.sensor.solaredge_overview.last_changed)}} ago
{% else %} Not yet initialized
{% endif %}
only brings the final template to life.
all templates used in the package are valid and producing a correct return in the previous config as value_template, and still in the dev-tools. I see no errors in the config check, nor in the homeassistant.log…
tbh, I would expect that package support would mean that the same config we use in regular configuration.yaml, like your template: config in your repo, would be valid in a package. Indeed like automation has always been… Not sure at all why this PR says it supports automation now, they have always been supported.
besides that. the - list indicator is just that, an indicator for a list. If my config doesnt check as a valid list, why wouldn’t that throw an error. Or put differently, why would we need the - indicator for each and every sensor…
I’ll try though and report back
UPDATE
Nope, doesnt work. first tried to C:template reload, nothing. then config/server controls/ Template reload, still nothing. Now a full restart… nothing, only the last template is configured. Maybe the yaml anchors are causing issues?
No it wasn’t that either, it was the fact I had set a unique_id (which was the entity_id of the sensors I had before the migration, hoping not to have to change all that and not have to reconfigure the frontend…)
this seems to work:
template:
- sensor:
- #unique_id: solaredge_lifetime_energy
name: Solaredge Lifetime energy
state: >
{% if state_attr('sensor.solaredge_overview','lifeTimeData') is not none %}
{{(state_attr('sensor.solaredge_overview','lifeTimeData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: &energy
unit_of_measurement: kWh
device_class: energy
state_class: measurement
icon: mdi:counter
attributes:
last_reset: '1970-01-01T00:00:00+00:00'
- #unique_id: solaredge_lastyear_energy
name: Solaredge Last year energy
state: >
{% if state_attr('sensor.solaredge_overview','lastYearData') is not none %}
{{(state_attr('sensor.solaredge_overview','lastYearData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: *energy
- #unique_id: solaredge_lastmonth_energy
name: Solaredge Last month energy
state: >
{% if state_attr('sensor.solaredge_overview','lastMonthData') is not none %}
{{(state_attr('sensor.solaredge_overview','lastMonthData').energy
|float/1000)|round(2)}}
{% else %} Unknown
{% endif %}
<<: *energy
now how to migrate all template sensors to use the former entity_id, without setting the unique_id on the config of the template:
yeah that is a thought I considered, but I have many sensors who’s name isnt identical to the unique_id.
Without using the unique_id, the template: integration doesnt automatically set a unique_id by itself, so the entities aren’t UI configurable… seems a catch 22.
but that seems to be the order: first dont use unique_id, let the system create that, next add that to the config, and adapt the name back to what you like…
