How about if you go to Configuration / Devices and Services/ Integrations find the removed Shelly device there and delete its instance of the integration (three dots icon)?
So, this is totally a hack, but I think most of you would find it helpful. I was able to remove some of my orphaned entities simply by inspecting the HTML and removing the "disabled attributes(s) from the DELETE button when viewing an entity popup. I’ve uploaded a video to demonstrate.
6 Likes
Brilliant. I still have this happening sometimes and it’s frustrating especially when I want to rename an entity id to the same name as one of these, but it usually resolves on its own. Thing is I can’t figure out what causes it to straighten itself out. Seems like a few reboots? Mine are mostly MQTT sensors in configuration.yaml and not from an integration.
Your video would have been a lot more useful with some narration or a written script because it’s almost impossible to follow a schizophrenic mouse jumping all over the page.
1 Like
I have two which are absolutely “undeletable”. E. g.:
On the second I choosed to delete it. Now it is still there but in the same state as the one showing above.
Recorder - Home Assistant also did not work.
Restarted HA, didn’t change at all.
Seems they are some kind of “ghost entities”, as they are not even showing up in the entity registry anymore:
So how to delete them?!?
Update: it seems that
a) restarting HA further times removed one of the two entities and
b) a frontend caching error occured, which is why the deleted one was still shown (custom:auto-entities)
Let’s see what happens with the remaining one.
I see plenty of entries inside “core.entity_registry” inside “deleted_entities” section. like this:
"deleted_entities": [
{
"config_entry_id": null,
"entity_id": "input_boolean.testing_every_minute_controlled",
"id": "688ff009f7f761760016408593446101",
"orphaned_timestamp": 1688858690.9584615,
"platform": "input_boolean",
"unique_id": "testing_every_minute_controlled"
},
{
"config_entry_id": null,
"entity_id": "cover.kitchen_window",
"id": "54b304c71227525f81a4fdb2b660c052",
"orphaned_timestamp": 1688950399.840828,
"platform": "demo",
"unique_id": "cover_1"
},
{
"config_entry_id": null,
"entity_id": "cover.hall_window",
"id": "d82d64ff2a0755315cbb7d79a3899be8",
"orphaned_timestamp": 1688950399.840828,
"platform": "demo",
"unique_id": "cover_2"
},
These entities are not listed in Settings → Entities list.
Currently there are 99 entries:
- 52 entities from “Demo” integration - this integration was added and then deleted, but all entities are still here;
- 13 entities from “Scrape” integration - same, was added and then deleted, but entities are still here (filled in issue for this);
- 3 entities with “automation.new_automation” ID;
- 11 entities from “Mobile App” integration for some iPad - and entities with SAME entity_ids are also present as “normal” and functioning;
- 1 entity from “Virtual” integration - same story: integration was added in yaml, then deleted;
- 19 helpers added via yam, then deleted.
I wonder what is a purpose of this “deleted_entities” section?
it’s a complete mess when it comes to orphaned entities. users that aren’t comfortable editing core files can almost be locked out of adding devices with the silly “device already configured” error.
seriously lacking.
3 Likes
There is a new integration called watchman that helps to some extent with this issue. Give it a shot!
2 Likes
-
Thank you, I know about this integration, I find this integration GREAT. But I keep it DISABLED and run it periodically - to track “missing” entities only; to monitor “unavailable” & “unknown” using my own methods.
-
For me the whole point is not only about “how to track & remove orphaned entities” - but about “WTH these orphaned entities are kept in core.entity_registry?”. Seriously, I think integrations should “clean up” the entity registry; for instance, there are orphaned entities for some “XYZ” integration - even when this integration is deleted.
1 Like
Yes that is why I said “to some extent”. I believe the safest way is to give them new names as having a “1” or something like that appended to the old name you prefer. Then, after the DB has cleared away the unused old ones, you would rename them. (I think that is typically 3 months? But I cannot remember.)
From what I understand it is a tricky and dangerous way to actually go into the master HA DB and make the changes manually, but from what I understand one little error in there could make your HA unuseable… I would loove to dig into the guts of how all that happens - but don’t even have the time 
This is a new thing for me, never heard about that.
What I believed is:
– assume some sensor.xyz is NOT excluded from Recorder;
– the Recorder keeps history for this sensor for some period (“purge_keep_days”, 10 days by default now);
– assume this sensor is deleted;
– we cannot see a history for this deleted sensor;
– in 8 days this sensor is restored (same entity_id);
– we can see a history for this sensor with a gap=8days;
– assume this sensor is deleted again;
– in 10 days there will be no history for this sensor in DB.
But as I already said, removing these “orphaned” entities is not a problem for me (so far at least), I just wonder why it happens in general.
Possibly keeping info about deleted entities in Entity Registry is a good thing - but it should have some documented logic.
Have you tried to use the delete all orphaned entities service from the Spook Addon?
1 Like
First it’s an integration (not an addon), second I‘m not sure if it adds actual benefits or is just a sarcastic way of ruining ones HA. That introduction and large parts of the documentation reads just too funny. Third I think the not that dangerous stuff with benefits for many users could be easily added to core, as it‘s maintained by Fraenk.
Anyway, interesting to see what this service does… (I won‘t test this 
).
Sorry for mixing up addon and extension.
I stumbled upon this one completly accenditly. In HACS i first thought it’s something for halloween, until i noticed that is one awesome swiss army tool made by Frenck himself.
Have you tried to remove a few hundred orphaned entities from the UI? Sure it’s dangerous to just call the service - it will indeed remove ALL currently unavaivable items - i guess that’s why it’s not just added directly into the core. But i guess people having such issues are more on the experienced side. Backup is easy to do and strongly recommended.
It helped me to get rid of a few thousands (honestly) of BLE tracker entites which have been added mainly from the random Airtag trackers over time. It completly broke my frontend. The known_devices file was 17 MB…
1 Like
Well, there’s a (huge) difference between entities in state unavailable (or unknown) and actually orphaned ones. If the service does what you’re looking for (remove unavailable ones), be happy.
So far we’re still looking for a bulletproof (and safe, so withouth fiddling around by shooting with delete statements at the database/heart) way to remove orphaned entities.
1 Like
perfect. Seemed easier than previous times when I’ve had to stop the core and edit core.device_registry and/or core.entity_registry
1 Like
Uff. I had a look at that UI hack. Seems to do what it proposes, but I‘m pretty sure the dev teams have good reasons for not showing the DELETE button for certain circumstances (like it is true for all entities provided by an integration usually). I‘d fear some side effects using this.
I actually use both Watchman and Spook. For watchman I have it run once a day in the celendar, and then examine it’s output file from time to time. Please note spook is managed by “…/Frenck”, who as you might notice is not only the person managing the AdGuard Home integration but also is the name you see on the bottom of most announcements for the updates to HA Core. It appears that he lives, eats and breathes HA as a passion. So if I were you I would reconsider. I use both. Spook is O.U.T.S.T.A.N.D.I.N.G… It runs quietly in the background and only shows you an issue under “Settings” for items that could be safely cleaned up such as with exact details on what non-existent object was found being referenced in an automation or the like. Other than that it is completely quiet and stands out of the way, You don’t need to “test” it - it is already pretty welll tested… It has found a couple of things in my setup which I rectifid and other than that is pretty much silent (like a ‘Spook’)
3 Likes
These are talking about the issue of not being able to delete unavailable\orphaned entities:
and this:
so it might be worth having a vote!