That is something that I did not try.
It might be that ESPhome stores some info in the NVmemory on the ESP and this causes entities not to fully vanish although they are not existing in the config anymore.
I will try with one ESPhome device to completely zero out the device (need to figure how) and then program the same setup.
For what itās worth, I seem to be having the same problem.
Status of the entity shows as āunavailableā. Itās last seen 2 days ago and canāt delete it.
Aaannnd Iām another one with the same problem. Zombie entities on two ESP devices that havenāt been in the config for a long time (multiple firmware updates and HA restarts in between), with no (simple) way to remove them from Home Assistant.
[EDIT]
Where are the contents of the ādiagnostic informationā that you can download for an esphome device coming from? The entity that shouldnāt exist anymore is still listed in there.
This worked for me.
Remove the integration from the YAML file.
Recompile and reload device.
Restart HA
I faced this issue today, and the only way to fix it was to completely remove the integration entry and add it again. Reloading, reflashing, nothing works.
@petro, you seem to be neglecting this issue. The issue clearly exists, even if itās difficult to reproduce from scratch. Proof that thereās no such entity in the device is that the workaround above works. Otherwise, the entity would be back after integration load.
Yes, I, the guy describing how this works, am neglecting the issue.
Ok, sorry. I had the impression you were neglecting the issue by blaming the userās ESPHome configuration.
I will write an issue against HA core once Iām able to reproduce it again. Thank you.
Fwiw, I also have this issue but only on an old input number entity. The input number is grayed out and doesnāt allow input, but shows up on the device page with its delete button grayed out in its settings.
Iāve cleaned build files, reloaded esphome integration, restarted ha/esp device, deactivated the esphome device, waited and the delete button always stays grayed out. Downloading the diagnostic data shows that the input number is still listed as an entity even though it has been deleted from the yaml for about a month, nothing uses it, it isnāt referenced anywhere in Hass and it is unusable as itās displayed.
I have so many automations, scripts and frontend cards using the device that I absolutely do not want to delete the device and do it all over again.
From my point of view, it seems to be an esphome issue of storing the entity entry (not itās data) somewhere in its internal state. Iām assuming the actual data is a null pntr or something as the entity itself is greyed out and unusable, but obviously something in esphome firmware is referencing it as an entry.
I just came across this topic because I was having the same issue with my old āHuman Readable Uptimeā text sensors which I removed because I had replaced them with the new uptime timestamp sensors.
I tried everything detailed in this post and other stuff I found but unfortunately nothing worked in my case.
What actually worked was the following:
text_sensor occurrences from the .storage/core.entity_registry file."text_sensor": [], in all the .storage/esphome.* files.BTW, I used the following commands to find out the affected files in the config directory:
find . -type f -exec grep -H "text_sensor" {} \;
Nice, Iāll try this tonight. At least we know thereās a bug somewhere in esphome.
Your info sent me in the right direction. I had to edit core.device_registry, core.entity_registry and the esphome.xxxxxxxx file to remove all references to the esphome input_number. After a HASS host system reboot, I could then select the entities and the delete button was no longer greyed out! All sorted!
I have this same issue by making a switch entity internal: true.
The entity remains in HA and cannot be deleted, despite integration reloads and HA reboots.
What doā¦?
Just delete the esphome node and it again, profit! 
Did you delete the esphome node and at it again? 
Simplest thing to do, always worked for me and doesnāt even take 30 seconds 
Nothing getās deleted if you remove a esphome node (beside the node itself obviously!). The moment you add it again everything is (still) there - even the history. 
One if the greatest things about ESPHome is that it is hardware agnostic 
No, I didnāt want to delete the ESPHome node because I had changed entity names, icons and other stuff and I didnāt want to loose that customization.
Thanks, this does work.
I expected deleting it to break everything else but as you mention, it doesnt. So this is a safe workaround
I highly suggest to rather donāt have this type customization done in HA but instead use the power of ESPHome for it!
name: My customized Temperature Name # custom name
unit_of_measurement: "Ā°C" # custom unit
icon: "mdi:water-percent" # custom icon
accuracy_decimals: 1 # custom accuracy
That way changing a device is nothing but a 1 minute job and everything continues like you are used to. 
Itās truly a blessing esphome works like this, for other types of devices (matter, zigbee?) you might waste an full hour fixing the aftermath after (only) changing a deviceā¦ 
The non-deleting entities are hitting me again.
There IS a bug in HA or ESPhome. Is there already a bug report somewhere in github?
Did you create one when I told you to back in October 2023 or did you just ignore me like usual?
Thanks for getting personal.
You where the one that always told me in the beginning that itās my fault.
If you already mentioned to open a ticket, I missed that.
NOW i am ignoring you.
If you reread the post history, you got upset with me trying to help you and made it personal long before this reply. I was just providing information and attempted to guide you to creating an issue however you tried to claim I was blaming you for doing things wrong when I was just explaining how it currently works.
Sorry for getting frustrated and getting personal, but this isnāt the first time youāve gotten upset with me like this.
Yep, I replied to your post, so you got the notification.
Anyways, did some digging to see if felipecrs was able to reproduce the issue and create one, it does not look like he did. So Iād say that there is no issue for this currently. It would be great if someone could create the issue and provide all the details.