You may need to restart after deleting the unavailable one before you can rename the _2 one
I’ve never had to do that. Whenever this happens I simply remove the ‘bad one’, rename the good entity_id. In that order. Home assistant doesn’t care that it’s being used in automations.
It only happened with deconz for me, but if definately makes a difference in my case
I vaguely remember having to restart before being able to rename my Lifx (or maybe ESPHome) duplicates.
Delete all unavailable (orphan) items and restart Homeassistant.
Now all is working as before
1 Like
there’s a number of ways to get to it. Typically, if you click on an entity of a device a popup will appear. In the upper right corner there’s a cog for that popup. If you can adjust the entity_id, that page will be filled with a form that allows you to do so. Otherwise there will be some cryptic error about ‘unique id’… which basically means “you can’t change the entity_id”.
Thanks, @petro. Indeed, I get the message:
I thought that ‘unique ID’ and ‘entity ID’ were two different fields, but based on your response it seems to be one and the same field.
In my YAML config file, I created mqtt binary sensors. As I wanted these sensors to have a stable ID, independent of their name, I specified unique IDs. This however generated duplicates of that entity.
I removed the unique IDs from my configuration.yaml, and then removed the duplicate entities.
The remaining entities had a “_2” at the dnd of theor ID, and I saw no way of changing that.
However, after a full restart, the _2 have disappeared from the ID.
Is there another way of having a stable entity ID, which does not depend of its label? Could I specify a label using ‘alias’?
Apparently this has never been fixed, as I’m also having issues with this. I have some devices which use MQTT discovery to register their sensors with HA. I made sure every sensor registers and uses a unique_id in the hopes of getting a stable ID to use in automations.
However, when the devices restart or re-establish wifi connection, I sometimes get duplicate sensors with the same label but a different ID. This prevents automations from triggering, even though everything looks fine on the dashboard.
If it comes through discovery, that means your unique_id is not persistent. You can look in the entity_registry to confirm that. Look for your entity with out the _2 and with the _2 and you’ll see what the registered unique_id is.
@petro - how to make the id persistent, because I do have exactly the same problem. I have sonoffs dual r3 and whenever they do restart (i.e. due to me doing some changes) I do see duplicate ids with _2 being active and the previous ones that are used in dashboards and everywhere being inactive and thus not working. This is quite annoying.
That depends on how you integrated the switches and what you did when you made changes.
@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.