Heads up! Upcoming breaking change in the Template integration

Configuration
221

Nah, I think you have me confused with another Dave. I was born here, parents were English though

222

Fixed in https://github.com/home-assistant/core/pull/40388

223

Iā€™ve been out of the loop for a couple of weeks but have a simple question:

If I upgrade to 115 will it fail if I donā€™t remove entity_id from all my template sensors beforehand?

Or will HA start but give a load of warnings/errors in the log?

I.e. Do I need to make the edits before upgrading or can I use the error log to point me at the changes I need to make?

I use entity_id a lot and I canā€™t think of a simple way to search for them all without the search returning a ton of unrelated entity_id.

1 Like
224

No.

Just warnings.

1 Like
225

No, it wonā€™t fail

Edit: Bugger, Tom is quick

1 Like
226

You both were pretty fast. Thanks!

227

still, be carefulā€¦

youā€™d best check if you have a few templates using {{states|...} because these will now be updated constantly, creating listeners on all states) and if you have more than a few states, and count all of these, will draw life from your instanceā€¦
remember the counter templates: well, until an updated PR is merged, youā€™d best take these out before updating.

228

Further to Marius, my cpu usage went from 3 to 4% (used to vary during the day) down to a rock solid 1%
His went up by (if I recall correctly) about 10%
I have about 20 count sensors, most of the rest pretty vanilla

229

trying to create this automation (and script for manual updating) wasnā€™t the challenge> Made the as a solid way to do what we need to do here. They are ready to be filled with unavailable entities :wink:

My issue now is how to use another integration that would support more than 255 charactersā€¦
As said, id the list of unavailable or unknown sensors is quite long due to circumstances to be solved, the 255 char limit makes this rather useless.

Ive thought about sensor.file or even markup lovelace cards, but they all use the sensor domain we are trying to avoid.

Whihc made me wonder: before we had attribute_templates on template sensor, this same 255 char limit plagued us. So cool we could finally use the templates state for the counter, and the attribute_templates for the listings. Couldnā€™t some kind of attribute be added to another domain, thinking of the input_text here though that might feel awkward, with which we could achieve the same end goal: have a text of more than 255 characters displayed in the frontend, without it being a template sensorā€¦

without that, the whole exercise of rebuilding the former once updated template sensor to an automation with an input_text is futile.

Could this be done via a python_script a la:

count_all = 0
domains = []
attributes = {}

for entity_id in hass.states.entity_ids():
    count_all = count_all + 1
    entity_domain = entity_id.split('.')[0]
    if entity_domain not in domains:
        domains.append(entity_domain)

attributes['Domains'] = len(domains)
attributes['--------------'] = '-------'

for domain in sorted(domains):
    attributes[domain] = len(hass.states.entity_ids(domain))

attributes['friendly_name'] = 'Entities'
attributes['icon'] = 'mdi:format-list-numbered'

hass.states.set('sensor.overview_entities', count_all, attributes)

which would allow a Lovelace representation like:

230

What about a simple python_script for those ā€˜countā€™ things?

count = 0
attributes = {}

for entity_id in hass.states.entity_ids():
    state = hass.states.get(entity_id).state
    if state in ['none', 'unavailable', 'unknown']:
        attributes[entity_id] = state
        count = count + 1

attributes['friendly_name'] = 'Unavailable Entities'
attributes['icon'] = 'mdi:message-alert-outline'

hass.states.set('sensor.unavailable_entities', count, attributes)

Auswahl_392
Auswahl_392759Ɨ226 24.5 KB

3 Likes
231

well, I be daā€¦ we cross posted that. yes, that was what I was looking for. would you help me rebuild my full template sensor like this?

maybe let me create a dedicated thread first?

232

You could split the output into 255 character chunks
So text 1 = blah [0:255]
text = blah [255:510]
Etc.

The problem with this is that you can only assign ONE VALUE per Template, so youā€™d have to run the same template multiple times under the action

It strikes me, that you are creating sensors for sensors sake
Or that you like collecting statistics for stuff you donā€™t need and are never going to look at.

I think your greatest optimisation would be to discard as many sensors as you can
Sorry, but this is what Iā€™ve learned from your many posts on this issue

233

Thanks but it was too late for the warning. The ā€˜all clearā€™ from tom and mutt was all I needed to press the button.

I can see my CPU has gone from around 2-3% to around 7% so I can live with that while I wait for the PR you mentioned, and while I sort out all the issues with my config following the upgrade.

If I was one to complain about breaking changes (and Iā€™m not) I would have plenty to complain about this time around! Iā€™ve got all sorts of new errors and warnings in my logsā€¦

I can see that Iā€™m going to be busy today :wink:

234

You enjoy it really !
:+1:

235

I just updated to 0.115.2.

I removed all my entity_id definitions from my binary sensors and sensors. Only a dozen or so required the date or time to be added to the template ( I used {% set update = states('sensor.time') %} or {% set update = states('sensor.date') %}. I have reasonably simple templates with no use of all states or expanded groups.

Iā€™ve seen up 50% increase in processor use.

Summary

My background processor use range has changed from 2-3% up to 3-4%. :rofl:

2 Likes
236

Blatant sensationalism at its finest. Well done sir, nicely done

1 Like
237

Iā€™m wondering ā€¦

i have a few sensors that evaluate, then i use the sensor itself to update the icon.

Logic tells me that iā€™m forcing a double evaluation, yet if i split it out into two FULL templates in the same sensor, Iā€™m doing that anyway

Could yours be related to that ???

Edit: but as no states have changed in the first template, does it skio that and jump to a simple evaluation in the second ???
:thinking:

238

The pitchfork emporium hasnā€™t been doing very much business lately. Have to drum up sales somehow.

239

Yes a relatively quiet release.

240

I also have friendly_name_templates in some cases.

Iā€™m waiting to see if they update correctly as there was one entity not included in the value template that I used to use for additional updates.

From this:

    bom_forecast_1:
      entity_id:
        - sensor.bom_hobart_max_temp_c_1
        - sensor.bom_hobart_min_temp_c_1
        - sensor.bom_hobart_chance_of_rain_1
        - sensor.bom_hobart_icon_1 ### <------ not in the value template, only the picture template
      friendly_name_template: >
        {%- set date = as_timestamp(now()) + (1 * 86400 ) -%}
        {{ date|timestamp_custom('Tomorrow (%-d/%-m)') }}
      value_template: >
        {{states('sensor.bom_hobart_max_temp_c_1')|round(0)}}Ā°/{{states('sensor.bom_hobart_min_temp_c_1')|round(0)}}Ā°/{{states('sensor.bom_hobart_chance_of_rain_1')|round(0)}}%
      entity_picture_template: >-
        {{ '/local/icons/bom_icons/' ~ states('sensor.bom_hobart_icon_1') ~ '.png' }}

To this:

    bom_forecast_1:
      friendly_name_template: >
        {%- set date = as_timestamp(now()) + (1 * 86400 ) -%}
        {{ date|timestamp_custom('Tomorrow (%-d/%-m)') }}
      value_template: >
        {{states('sensor.bom_hobart_max_temp_c_1')|round(0)}}Ā°/{{states('sensor.bom_hobart_min_temp_c_1')|round(0)}}Ā°/{{states('sensor.bom_hobart_chance_of_rain_1')|round(0)}}%
      entity_picture_template: >-
        {{ '/local/icons/bom_icons/' ~ states('sensor.bom_hobart_icon_1') ~ '.png' }}