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.

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

1 Like

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…