Fine tuning modern style template sensor - a little help needed

Mariusthvdb · May 12, 2021, 2:37pm

thanks. made my first tracker.

sensor:
  - unique_id: track_marijn
    state: >
      {{'In huis' if is_state('device_tracker.life360_marijn','home') else 'Uit huis'}}
    attributes:
      friendly_name: Waar is Marijn

so thats promising no editing, no customizing.

otoh, this icon template wont stick, though it should?

    icon: >
      /local/images/family/marijn_bmj_{{'home' if
         is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png

returns a validation error on non whitespace, which I’ve never seen before:

Error validating template result '/local/images/family/marijn_bmj_home.png' from template 'Template("/local/images/family/marijn_bmj_{{'home' if is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png")' for attribute '_icon' in entity sensor.track_marijn validation message 'contains non-whitespace: /local/images/family/marijn_bmj_home.png'

darn, beginners error, using icon: for an entity_picture…

sensor:
  - unique_id: track_marijn
    state: >
      {{'In huis' if is_state('device_tracker.life360_marijn','home') else 'Uit huis'}}
    picture: >
      /local/images/family/marijn_bmj_{{'home' if
         is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png
    attributes:
      friendly_name: Waar is Marijn

it is then, using picture: for entity_picture…

entity card doesnt show the picture, the entities card does:

never realized that tbh, same goes for the fact we can not edit the picture in the editor GUI

but that might be another matter? editing the template: entities and showing them in the frontend

DarrenHill · May 12, 2021, 4:12pm

I’m a little surprised that you’re seeing sensor.track_marijn and not sensor.template_track_marijn .

Every time I tried the set-up like yours (as per the post 7 from 123 above, where he also highlights that limitation) I got the template prefix that I couldn’t get rid of. The only difference is the icon / picture usage as far as I can see. Or did you adjust it in the UI or elsewhere?

123 · May 12, 2021, 5:03pm

Ditto. I pasted the example into my test system and the resulting sensor’s object_id includes the leading word “template”. Would be interesting to know what Mariusthvdb did to eliminate it.

EDIT

Nevermind, I figured it out. You can modify the sensor’s object_id using the dialog-box shown in Mariusthvdb’s post.

So we have control over the object_id but via an extra editing step.

I would prefer if it didn’t prepend “template” and simply used the supplied unique_id verbatim.

I have to say, getting modern format to reproduce what was easily done in legacy format has been quite the puzzle.

DarrenHill · May 12, 2021, 6:36pm

You can, but he does say

so thats promising no editing, no customizing.

That editting was what I was originally trying to avoid when I set mine up. I would also much prefer there was no enforced prefix. It might be worth a feature request perhaps, although it does kind of mirror your existing one about friendly_name as if we have that alongside name then it “should” work like the legacy set-up (I think)?

123 · May 12, 2021, 6:43pm

“No editing, no customizing”

Hmmm. Will wait for Mariusthvdb to elaborate on that claim.

CentralCommand · May 12, 2021, 6:55pm

In the documentation for template there’s a unique_id field which can be set for the entire block (different from the one you can set for each sensor). The doc describes it like this:

The unique ID for this config block. This will be prefixed to all unique IDs of all entities in this block.

Does that allow you to customize the template_ prefix by any chance?

Disclaimer: I’m guessing, I haven’t tried it myself. Normally I would test first but I can’t this time because I have everything in packages and you can’t use the modern config for template sensors in packages. I just thought it sounded similar to the issue you all were having so figured I’d point it out.

DarrenHill · May 12, 2021, 8:51pm

Thanks for the idea, but just gave it a quick test and it’s cumulative. If I set a unique_id at the higher level (for example testing) I get a sensor of sensor.template_testing_darren_desktop

CentralCommand · May 12, 2021, 8:59pm

Ah bummer, oh well

petro · May 12, 2021, 10:24pm

I never had the template_ before my sensor either. I did nothing special

123 · May 13, 2021, 2:17am

I did nothing special either (I used the example posted by Mariusthvdb) and did get template_ prepended so it begs the question “What’s different?”

I tested it with 2021.5.2. The sensor resides in a templates.yaml file along with several others.

DarrenHill · May 13, 2021, 7:10am

Exactly the same set-up as me, although I’m now on 2021.5.3 core since last night (with no difference). Running on a Pi4 using the uSD card image. Templates set up in templates.yaml with a !include from configuration.yaml.

Every time I try the config without the name, I get the forced template_ prefix.

I do also see that the modern way is slowing things up compared to the legacy way. When I first open Lovelace (especially via the mobile app) it can take up to a few seconds before the customizations get applied. I have one which changes the icon on a couple of buttons on my opening LL pane, and often I can see the original icons for a short time before they change to the altered ones.

petro · May 13, 2021, 11:15am

It’s the exact same code, just a different startup and configuration… something else is causing the slowdowns.

EDIT: And looking at the code, under the hood we ‘rewrite the config’ for legacy template sensors into the new method. So both legacy and new template configurations are stored and used in the exact same way. So all configurations from 2021.5 are using the new template integration even with the old template configuration.

petro · May 13, 2021, 11:20am

it’s going to be something with the entity creation process which is the same for all integrations that use a unique_id. There’s methods in place that automatically handle everything for the dev’s of a component. I’ve never bothered looking at the code because it always does what I want. Unique_id’s in general will gain the integration it comes from as a xxx_. There should be a path that creates the object_id from the unqiue_id, and that’s where we’d want to look. Post your entity config for template in question from the .storage/config_entries file.

EDIT: It may have to do with entity_config in general. I was taking existing templates and moving them. This may have caused the object_id to be carried from legacy. I see the code that does this but without debugging into the process while it’s flowing through the legacy ‘conversion’, I can’t see whats in the objects. I can tell you definitively, if this is a new template sensor, omitting the name will cause the unique_id to don ‘template-’ as the first portion of the string.

DarrenHill · May 13, 2021, 12:34pm

The only file in there similar to that is core.config_entries, and there is no template entity entries in there (the only one for Darren-Desktop is from Kodi).

The icon changing (customisation) delay only seems to have started since I moved the templates from legacy to modern, and that’s about the only thing that’s happened recently (aside from updates).

123 · May 13, 2021, 12:37pm

Yes, it’s a new Template Sensor (copied from the example posted by Mariusthvdb).

If I have understood it correctly, you and Mariusthvdb are getting the object_id you want (free of the leading word template and without additional manual editing) only because the entity already existed that way; it had already been included in the entity registry.

DarrenHill · May 13, 2021, 12:41pm

@petro Is there a reason behind why that addition must be done?

It’s quite inconvenient if you want to have full control over the object_id , for example to move an existing sensor from legacy to modern without having to go through everything uses it and add that prefix, or remove that prefix manually from every newly created entity via the UI or other customisation?

I’d honestly have to say for me that is a regression when moving from legacy to modern, compounded by the lack of friendly_name alongside name.

123 · May 13, 2021, 1:04pm

At first I thought the automatic inclusion of “template” might have been considered to be a convenience in the event a sensor was created automatically. For example, an automatically created sensor might be assigned an unfriendly-looking random alphanumeric string (like an automation’s id option) and it is helpful to prepend “template” to it to better understand its provenance.

HOWEVER, that’s all false because this is a Template Sensor, it’s not automatically generated, and its configuration is composed manually. The entity’s object_id ought to be based exclusively on what the user has entered. It deviates from how all other manually configured entities are handled. We don’t see “automation”, “light”, “switch”, etc automatically prepended for other domains.

The irony here is that it mandates the automatic inclusion of “template” yet allows you to remove it in a separate editing step.

petro · May 13, 2021, 2:09pm

I have no idea what you mean “must be done”? You don’t have to switch from legacy if you don’t want to. It’s legacy, it’s not going away unless it’s deprecated. And it’s not deprecated.

Mariusthvdb · May 13, 2021, 2:09pm

Well, it is what it is. I made the config as posted and you see the result.

I didn’t edit it in the ui and I didn’t use customize for the friendly_name

I merely showed the Ui to point to the omission for a picture

DarrenHill · May 13, 2021, 2:11pm

I meant why the template_ prefix must be added.

Was it just a coding decision, or is there something that necessitates the addition?

I know it’s not depreciated (at least for now), but the docs state that it’s recommended to use modern and not legacy from now onward. Which would tend to at least tacitly imply that depreciation may occur in the future perhaps.