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.
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
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
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.
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 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?
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?
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.
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
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?