@petro … can you clarify how to delete this?
They are read-only and there is no option to delete it. These are rest sensors
1 Like
Restart and you’ll be able to delete them if they are removed from yaml.
So the process would be:
- Remove them from YAML
- Reboot
- Check to see if they still exist and delete any that do
- Reboot?
- Re-establish them in the YAML
- Reboot
Seems a bit crazy. I guess I do not know the real, underlying reason for the “_2” stuff, I assume it is because they exist in history or something? I would have thought it would have been much better to make “_2”, “_3” … refer to the old ones and leave the “real” one alone.
Just to note, I am not sure what caused it but I assume it started when I had to add an attribute from the JSON response. So this then caused that sensor to have “_2”. BUT, another sensor I had has REST resource_template based on the sensor without _2 … which eventually caused it to fail and many Automations and Scripts also failed because of this.
It is not easy for folks building out such things as we test a bit and change a lot and we have no idea that underlying this things are renamed without us knowing.
The real reason for getting duplicates is when you don’t use a unique id and you reload the integration. Use a unique id and you’ll never run into this.
Without a unique id, ha doesn’t know which one is the “real” one when you reload. So you just get a duplicate entity with an _2.
1 Like
OK. So how is that done? Like for instance this is my sensor, what am I missing:
##
## Random Pokemon
##
- platform: rest
name: Random Pokemon
scan_interval: 360000
resource_template: >
{% if states('input_select.select_pokemon_mode') == 'Increment' %}
https://pokeapi.co/api/v2/pokemon/{{ state_attr('sensor.random_pokemon','id') + 1 }}
{% elif states('input_select.select_pokemon_mode') == 'Decrement' %}
https://pokeapi.co/api/v2/pokemon/{{ state_attr('sensor.random_pokemon','id') - 1 }}
{% elif states('input_select.select_pokemon_mode') == 'Name' %}
https://pokeapi.co/api/v2/pokemon/{{ states('input_select.pokedex') }}
{% else %}
https://pokeapi.co/api/v2/pokemon/{{ range(1, 1008) | random }}
{% endif %}
value_template: "{{ value_json.name }}"
json_attributes:
- abilities
- base_experience
- forms
- game_indicies
- height
- held_items
- id
- is_default
- location_area_encounters
- moves
- name
- order
- past_types
- species
- sprites
- stats
- types
- weight
You’re missing unique_id…
Keep in mind, when you add it for the first time and reload you’ll get a duplicate entity. Restart and you wont.
After adding it reloading or restarting will keep it the same. As long as you don’t change the unique id
Thanks! I just saw that and now I understand. I have over the years made an erroneous assumption that the name was the unique_id. Now I understand these are two completely different things.
Although documentation is lacking, I assume I can call this whatever? Like can I call it “sensor.random_pokemon” which is the actual name or?
The name makes the entity_id but reloading gets in murky waters when you don’t have a unique_id and all yaml integrations behave differently. Best rule of thumb is to add a unique id to ensure you don’t get duplicates when reloading. typically yaml integrations without unique_id as an option don’t have this issue.
I have just had the same issue with a generic camera integration. My automation stopped working because the entity is now unavailable and a new entity with the same name but prefixed with a “_2” appeared. generica camera does not accept a unique id, and it also cannot be deleted from the web ui. It’s a bit of a pain really.
Don’t reload the integration, restart only. Also, make sure other integrations don’t use the same name.
I didn’t reload the intergation. The _2 randomnly appeared after a full HA restart at some point. And there are no other integrations with the same name, it’s just a really annoying thing that HA does occasionaly for no apparent reason.
There are a couple of other generic cameras that weren’t affected, just one of them.
I see this _2 thing quite a bit with various different integrations, sometimes a new media_player will appear, sometimes it happens with esphome and I feel sure there are others. I can clean it up, but it’s really annoying not being able to remove them from the web ui. Editing the config state files is boring and fraught with danger.
Oh and lastly, generic camera can be integrated via the UI, it’ll have a unique_id attached to it if you do that.
1 Like
oh really? I didn’t know that, I will have to ask Google about it
You didn’t relaod yaml at all?
You don’t have to google that, just go to the integration page in HA and add the cameras. Or just view the HA documentation that shows you the steps.
1 Like
well, only in the sense that HA must have reloaded it after a restart, I didn’t touch the yaml, haven’t since I set it up.
@petro: What I really do wonder is the implementation in it’s current form.
Upon a code change:
the old entity becomes unavailabe while keeping it’s name whereas the new one gets a _2 added Somewhat stupid since it won’t inherit the links from the old object. Means the linked objects do still expect being fed by an entity with the old name (cards for example).
Yes you simply wipe the unavailable entity and then removed the _2 from the new one and you’te done. But I do buy computer to help me not for being asked to help them across the day 
I do wonder why it wasn’t implemented the other way round.
So that an old object gets a trailer in the form “_orphaned” with the benefit that the original name gets free so that the the new one could use it straight. With the benefit that things linked to it simply work straight.
And yes you would have to clean your system from time to time because of bunches of orphaned unavailable entities.
Impossible? Am I wrong with this idea?
The problem is, HA doesn’t know which configuration is which. It comes from yaml, and HA tries to just create the entities. If the entity already exists in the list of entities, HA will just create a second one using _2. This should never happen in most cases. So even in your scenario, it doesn’t know which one is _orphaned, it just knows what order it received the configuration.
And just so you know, 99% of the time these _2 issues boil down to a bad yaml configuration or the use of reload on a yaml integration that does not have a unique_id.
2 Likes
I have this on 2024.1.5 with rest sensors that grab data from an API in my network. Have had these sensors for years, but I discovered a flaw (in the system providing the API) so I changed the value_template to correct. Now I have _2 versions of the sensors and it’s voiding my history since the change.
I’ll play around with the unique_id, but if that’s the cause, you might want to consider changing the sensor.rest page, it shows unique_id as being optional, gives no explanation and never mentions it again.