Right now the helpers created in UI live only in UI. They’re not saved in any yaml file so we cannot edit them manually and unfortunately some of the options are not available through the UI. Also editor for some helpers does have the same set of features/fields when in edit more when compare to create mode.
So it would be great if we could edit Helpers in the UI the same way automations editor allows switching to yaml code. That way we could use full potential of the available options.
Don’t forget to vote yourself.
Using the UI to create helpers has a lot of advantages over using yaml:
Just to highlight (again) the reason for the request:
unfortunately some of the options are not available through the UI
and
editor for some helpers does have the same set of features/fields when in edit more when compare to create mode.
There is a related WTH about why can’t we edit helpers. The UX around helpers is pretty poor compared to all the improvements that have been made to the Home Assistant UI.
For a number of helpers the settings dialogs don’t even let you see the configuration you supplied to create the helper.
Another related potential WTH is that all helper integrations are labeled as internal but the quality of the implementation varies widely.
For the most part, all helpers can be edited after the fact in the UI with some restrictions. E.g. You can’t modify utility meter source entity because that would change config entry and essentially create a new entity.
For the most part, all helpers can be edited after the fact in the UI with some restrictions.
For History Stats, you can’t even see what entity it is based on.
Maybe it is a gap around the config flow that there isn’t a way to show read-only configuration options, but I’ve had to dig through core.config_entities.json to see what the config is for some helps.
Yes, there’s a WTH about this already showing a read only field when you edit it.
Config entries for these integrations are typically generated from the entity_id, so when you change it, you get a “new config” which is why it’s restricted like that.
Until the UI is improved, seeing a read-only YAML definition (or even the JSON without having to search through the files) would be useful
What do you mean “Until the UI is improved”? Our hands are tied with editing the source entity because that’s the only immutable thing that we can reference for both yaml & UI based entities.
Sorry “until the UI is improved” means be able to go back and see all of the user supplied config even if it isn’t editable.
I don’t know whether not displaying them is due to lacking functionality in config flow for read-only items or a specific integration problem.
Wait, No. At least for History Stats, the Entity ID (The created history_stats entity name) is separate and distinct from the source entity.
The source entity is a binary_sensor which can’t be seen from the UI
Here’s the underlying config entry that has the details. Note that it is the elements of options that should editable (or at least be visible if it needs to be read only) in the settings dialogs.
It would also be great if options was editable in YAML similarly to automations and scripts.
{
"created_at": "2024-10-16T20:14:36.996353+00:00",
"data": {},
"disabled_by": null,
"discovery_keys": {},
"domain": "history_stats",
"entry_id": "01JABFFMY45PHR39JQMMM2FCRB",
"minor_version": 1,
"modified_at": "2024-11-21T19:56:18.946994+00:00",
"options": {
"end": "{{ now() }}",
"entity_id": "binary_sensor.spa_heating",
"name": "Spa Heating Runtime",
"start": "{{ today_at() if now() < today_at(\"23:59\") else now() }}",
"state": [
"on"
],
"type": "time"
},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "user",
"title": "Spa Heating Runtime",
"unique_id": null,
"version": 1
}
As far as a reference there is "entry_id": "01JABFFMY45PHR39JQMMM2FCRB"
The entry_id is generated from the inputs, namely the entity_id of the source.
I said entry_id
anyways, here’s the real reason the options aren’t added
So it likely could be done with how the integration sets up it’s config entry.
As shown above, the entry_id is a UUID which is the reference that ties the core.entity_registry item to the config in core.config_entries.
"entry_id": "01JABFFMY45PHR39JQMMM2FCRB",
{
"aliases": [],
"area_id": null,
"categories": {},
"capabilities": {
"state_class": "measurement"
},
"config_entry_id": "01JABFFMY45PHR39JQMMM2FCRB",
"created_at": "2024-10-16T20:14:37.003027+00:00",
"device_class": null,
"device_id": null,
"disabled_by": null,
"entity_category": null,
"entity_id": "sensor.spa_heating_runtime",
"hidden_by": null,
"icon": null,
"id": "af0a228af17e6378243e9eea459771d7",
"has_entity_name": false,
"labels": [],
"modified_at": "2024-10-16T20:14:37.006804+00:00",
"name": null,
"options": {
"cloud.google_assistant": {
"should_expose": false
},
"cloud.alexa": {
"should_expose": false
},
"sensor": {
"suggested_display_precision": 2
},
"conversation": {
"should_expose": false
}
},
"original_device_class": "duration",
"original_icon": "mdi:chart-line",
"original_name": "Spa Heating Runtime",
"platform": "history_stats",
"supported_features": 0,
"translation_key": null,
"unique_id": "01JABFFMY45PHR39JQMMM2FCRB",
"previous_unique_id": null,
"unit_of_measurement": "h"
}
Tested again with 2024.12.0, Name is a required field for History Stats. if you don’t supply a value it defaults to unnamed statistics. See the screen shot above.
Please understand that you can seed UUID’s with static strings. I have no idea why you have this “bone” to pick with me. I’ve already linked why the options are missing, there shouldn’t be a need to continue this convo with me any more as we now have the real reason the options are omitted.
Here’s the comment pulled from the link above:
It was done on purpose like this as if you would change anything coming from the “page 1” it would distort it’s own statistics.
I was responding to this:
and this:
I tried to clarify by showing what history stats is currently doing in terms of entity naming, whether there is a unique ID, and the configuration data that isn’t visible.
I’m not trying to pick a bone with you.
I’m not talking about entity naming, I’m talking about the generation of the entry_id (and config entry)