Fine tuning modern style template sensor - a little help needed

Configuration
1

I’m trying to migrate some of my legacy type template sensors towards the newer modern style, and whilst it’s mostly working, I need a little help with fine-tuning.

Firstly this is an example of the legacy sensor:

sensor:
  - platform: template
    sensors:
      track_darren_desktop:
        friendly_name: "Darren's Desktop"
        value_template: "{% if is_state('device_tracker.darren_desktop', 'home') %}Connected{% else %}------------------{% endif %}"
        icon_template: >-
          {% if is_state('device_tracker.darren_desktop', 'home') %}
            mdi:desktop-classic
          {% else %}
            mdi:lan-disconnect
          {% endif %}

That takes the device_tracker.darren_desktop entity’s state and creates a second sensor sensor.track_darren_desktop with the templated value and icon (to make it look clearer and nicer under a Lovelace card). The name appearing in the card is “Darren’s Desktop”, as per the friendly name.

Anyway I’ve got something close working under the modern style:

template:
  - sensor:
      - name: Darren's Desktop
        unique_id: Track Darren Desktop
        state: "{% if is_state('device_tracker.darren_desktop', 'home') %}Connected{% else %}------------------{% endif %}"
        icon: >
          {% if is_state('device_tracker.darren_desktop', 'home') %}
            mdi:desktop-classic
          {% else %}
            mdi:lan-disconnect
          {% endif %}

Which works as well, except the sensor name is sensor.darren_s_desktop and so different to the above.

What I’d like to have is the original sensor name (sensor.track_darren_desktop) and the Lovelace name as “Darren’s Desktop”. I know I can go into the entity under the GUI and change both entity ID and name to those, but I’d prefer to do it from the original configuration if possible.

Can it be done, or am I forced to create the sensors with their name and entity ID as the same and then tweak one or both in the GUI?

2

Change the entity_id through the UI.

Or change your name to Track Darren Desktop, and then in the UI change the name to Darren’s Desktop. Or remove the name, and add the name in your customization area.

3

Thanks. I was wondering if there was a way to avoid having to do the UI tweaks (this is one example of a few dozen sensors used to track various devices) by fine-tuning the yaml file entry for them.

The legacy has the ID and the friendly name as distinct properties, but modern seems to use the name for both (I can’t see the unique_id actually doing anything except under the hood).

4

If you just have unique_id, the object_id will be based on the unique_id. You’ll be able to edit from the UI.

If you have name and unique_id, the object_id will be based on the name. You’ll be able to edit from the UI.

If you have just name, the object_id will be based on the name. You won’t be able to edit from the UI.

5

Understood. The “under the hood” bit was that HA is using it to follow it and enable changes via the UI.

So the basic answer is no, I can’t preset everything in the yaml file entry for the template and I need to edit at least one of the properties via the UI.

Fine with that (albeit some work), but wanted to ensure I hadn’t missed something as this is the first time I’m playing with the new modern way of doing them.

6

You can set the name in the customization section of your configuration.yaml. Or set it through the UI.

7

but you have to omit name in the template

8

OK, will have a play later on and see what I can do. Thanks for the info.

9

This won’t provide exactly what you want but I am posting it here for future reference. The result of this will be sensor.template_track_darren_desktop whose friendly_name is “Darren’s Desktop” (assuming I configured the quotes correctly).

template:
  - sensor:
      - unique_id: track_darren_desktop
        state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
        icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"
        attributes:
          friendly_name: "{{ 'Darren''s Desktop' }}"

Reference:

1 Like
10

I don’t think you even need the templates there

template:
  - sensor:
      - unique_id: track_darren_desktop
        state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
        icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"
        attributes:
          friendly_name: Darren's Desktop
11

Hmm. I have a vague recollection of trying that and it wasn’t successful but now I am uncertain. The documentation indicates it expects a template. I’ll try again when I have access to my system.

12

No need to try, I use the attributes area to set flags for items. I have it in all my templates, you can check my github

2 Likes
14

Yes, does exactly that. Almost there but gives the unwanted template_ prefix.

Is there any way around that?

15

No, that’s done automatically by Home Assistant when it builds the sensor’s object_id and there’s no name defined.

It’s why I made the disclaimer that it wouldn’t give you exactly what you wanted; its just for reference purposes, mostly to show how friendly_name can be set in the sensor’s configuration. However, only if there is no name option present otherwise Home Assistant will default to using that for friendly_name. See the linked post to learn about how it behaves when various options (unique_id, name) are included/excluded.

16

Yes I saw the disclaimer :slight_smile:

So I have three basic options here:

  1. Reconfigure all automations etc that use the sensors to the new template_ version.
  2. Use the UI to change the object_id for each of the sensors and strip out the template_ (which is what I was trying to avoid in the first place).
  3. Give up and go back to the legacy set-up, which works out of the box exactly as I want it to.

Any idea what the reasoning is for the automatic addition, as it’s somewhat frustrating. Is there a specific reason that it needs to be done differently in the two routes, as it seems to me that the “modern” version is less flexible than the legacy one?

17

I have no knowledge why it works the way it does; I think only someone involved in the design of ‘modern’ format can provide a factual answer.

18

Fair enough.

Thanks for the help so far anyway. I think I’ll roll back to the legacy method at least for now, and will consider the best way of the other two for the future.

As you say, hopefully someone can cast light on why the prefix is being enforced on the id, as it seems very undesirable to me from the user viewpoint and will end up as a similar roadblock in the future if the legacy method is depreciated and later removed.

19

OK, got it doing what I wanted by using the customization section and letting that handle the friendly name. No unwanted Template_ in the sensor ID, and everything’s working fine.

Seems an oddity that I have to customise a sensor that I just created, but at least it’s working without having to manually tweak anything in the UI.

One note though, it does seem to work with name in the original template, the customize overrides it fine.

Will call this one completed, as a learning experience. Thanks again for the support chaps :smiley:

20

what is your final yaml code now? please post one template: including the customize?

21 
homeassistant: 
  customize:
    sensor.track_darren_desktop:
      friendly_name: Darren's Desktop

template: 
  - sensor:
      - name: track_darren_desktop
        unique_id: track_darren_desktop
        state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
        icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"

That’s a slight edit as I’m using separate files for the customisation and templates (via !include in configuration.yaml), so I’ve sewn everything together for the above example.