Setting a friendly_name or unique_id on a Rest sensor?

I tried a few suggestions from https://community.home-assistant.io/t/add-bring-back-friendly-name-to-template-sensors, but I am unable to add a friendly name to rest sensors (nor a unique ID).

For instance:

- resource: https://particulier.edf.fr/bin/edf_rc/servlets/ejptempodaysnew?TypeAlerte=TEMPO
  scan_interval: 3600
  headers:
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Content-Type: application/json
    User-Agent: Wget/1.20.3 (linux-gnu)
  sensor:
        - name: edf_tempo_blue_remaining
          value_template: "{{ value_json.PARAM_NB_J_BLEU | int }}"
          unit_of_measurement: "d"
        - name: edf_tempo_white_remaining
          value_template: "{{ value_json.PARAM_NB_J_BLANC | int }}"
          unit_of_measurement: "d"
        - name: edf_tempo_red_remaining
          value_template: "{{ value_json.PARAM_NB_J_ROUGE | int }}"
          unit_of_measurement: "d"

How could I add a user-friendly name to these, while keeping a tractable “unique_id”. I could give a user-friendly name with name:, but the ID would probably be a mess.

1 Like

OK, that works from the “customization” menu in Homeassistant, thank you!

That will do for now, but I would have liked something a bit more portable, that would be easier to share together with the rest sensors configuration.

throw it all in 1 package, and its as portable as you can get it. (ofc, except for friendly_name support in the sensor.)
You could also chose a better name: …and still keep it unique

  - platform: rest
    name: Hue 2 config
    resource: !secret hue_2_config_resource
    method: GET
    value_template: >
      {{value_json.name}}
    json_attributes:

no need for customization at all?
Getting off topic though…

You’re having issues because rest sensor and template sensors have different attributes, thats why nothing in the FR worked. They are unrelated integrations. Always consult the docs, you’ll notice that rest does not support unique_ids.

Well, thanks for your help, and for moving the topic.

I was initially reading up on the sensor platform, then rest sensor + template, and had not realized I was not using the template base anymore.

I initially had a hard time wrapping my head around the documentation, especially as the syntax is different on the RESTful Sensor page and the rest page, and inconsistent: the rest sensor page uses the old syntax from the templates sensors page

Old format:

sensor:
  - platform: rest
  - platform: template
    sensors:
      sensor1:
        friendly_name: something
        unique_id: uuid-something
      sensor2:
        state: 42

vs new format:

sensor:
  - platform: rest
  - platform: template
    sensor:
      - name: sensor1
        friendly_name: something
        unique_id: uuid-something
      - name: sensor2
        state: 42

vs rest sensor:

rest:
  - sensor:
    - name: sensor1
      # no `unique_id` or `friendly_name` possible here
    - name: sensor2
      state: 42

I’m not sure if there’s a rationale for these properties not being supported there. Would a patch be accepted? Why wouldn’t rest sensors inherit from template sensors? At least not being able to set a uid seems unnecessarily restrictive.

1 Like

The customization in that case is for localization: have a friendly name in the local locale, and keep the code and attributes in English. That’s a personal preference, but I try to be mindful of whoever might reuse my code.

uh, you still got mix ups all over the place.

Old rest with old template

sensor:
  - platform: rest
    resource: http://192.168.1.12/status.xml
    # no `unique_id` or `friendly_name` possible here

  - platform: template
    sensors:
      sensor1:
        friendly_name: sensor 1
        unique_id: something       
        # Templates fields are 100% unrelated to rests platform.

old rest with new template

sensor:
  - platform: rest
    resource: http://192.168.1.12/status.xml
    # no `unique_id` or `friendly_name` possible here

template:
- sensor:
  - name: sensor 1
    unique_id: something
    # Templates fields are 100% unrelated to rests platform.

new rest

rest:
  - resource: http://192.168.1.12/status.xml
    sensor:
    - name: sensor 1
      # no `unique_id` or `friendly_name` possible here

2 Likes

never realized this was Old versus New rest sensor, and, tbh, I find the New a bit lacking in the yaml config ease…

however, Ive remade one for testing purposes:

  - resource: !secret se_overview_resource
    scan_interval: 400
    sensor:
      - name: Solaredge overview
        value_template: >
          {% if value_json is defined %}
            {{value_json.overview.currentPower.power|round(2,none)}}
          {% else %} Currently unavailable
          {% endif %}
        unit_of_measurement: W
        json_attributes_path: '$.overview'
        json_attributes:
          - lastUpdateTime
          - lifeTimeData
          - lastYearData
          - lastMonthData
          - lastDayData
          - currentPower
          - measuredBy

and discovered a non documented feature: the unit_of_measurement works fine :slight_smile: And I find the name: option sufficient for friendly_name, just like it is in the template format… so why bother ? It provides all one needs?

no you should not add a customized friendly_name to an entity that has a name:. Better chose a friendlier name…

Would it not be easier if the rest platform allowed you to create a unique_id for each sensor, and ideally assign an icon at the same time ?
Is this raised an an enhancement request anywhere I can vote on it or support it?

2 Likes

I think the ability to set friendly name in a rest templated sensor is useful in some cases.

My use case is for beer taps.

I have 4 taps, want the sensor entities named tap1, tap2 etc for simplicity in referencing, but I want the friendly names to reflect the actual beer on tap (Accessed via rest from brewfather).

eg:
sensor.brew1 friendly name “pale ale”
sensor.brew2 friendly name “stout”

My dashboard always just lists sensor.brew1, sensor.brew2 but the friendly name reflect what is on tap.

And - then I use the sensor state to reflect the date it was kegged … allowing me to easily see how “old” the beer is.

then you can use customize for that.

I don’t think I can programmatically customise

I want the rest sensor fetch to set all the values

Looks like I will have to create templates from the rest entities (which will also let me set friendly names!!)

I was trying to avoid duplicate entities.

You mean the rest: sensor format where all sensor are taken from the same resource? Maybe you could try the

sensor:
  - platform: rest

format and have 4 individual beer tap sensors…

still, if you have 4 sensors, you can set their friendly_name, in either format. Unless you have these as attributes for the 1 sensor. In that case yes, create template sensors on those attributes, and be done with it :wink:

He meant