I frequently run into two related issues when using ESPHome devices with HA, related to the fact that the device “unique id” is derived from its mac address.
Problem 1
As previously flagged if I have a hardware failure and replace the device with identical hardware, and the same firmware, it’s not recognised by HA as the same device since the MAC address is different. A new device gets created with munged entity names.
Problem 2
If I have been testing on a particular dev board that has been adopted into HA, then flash a different config onto the same board, without having deleted the previous device from HA, I get a cryptic error when trying to add it to HA - “Device already configured”. The fix is to delete the original device - but there is no easy way of finding out which one it is - the error gives no clue, and searching by MAC address doesn’t work. Simply reporting the name of the conflicting device would be a nice start.
Both these problems stem from the use of the MAC address for a purpose for which it was not intended - it is there for networking purposes, but HA has repurposed it as a device identifier. From my point of view the “device” is identified by its “name” as configured in the ESPHome yaml - it’s not actually a name, it’s an ID, subject to corresponding lexical rules (the real name is the “friendly_name”). The device exists as an implementation of a specific configuration, and I would expect that configuration to not be tied to a specific piece of hardware. Every different “device” I use has a different name (kind of essential since mDNS is in use.)
I am aware that in 2022 (before I started using HA) there was a change that replaced the use of the “name” with the MAC address, which on the surface seems like a design error, but since I don’t have the complete context of that change I can’t fully comment.
I am however going to assume that the chances of getting that change reversed are small.
So, if the MAC address is to be used to identify a device, it needs to be handled better. Swapping out a failed hardware device should not require deleting the device metadata completely from HA, and the penalty for forgetting to remove a now unused device should not be endless frustration.
That may be true, but if you don’t know to delete the old device first, you end up with two devices and have to delete both of them, so it’s still a trap for those who have not been bitten a few times. There are plenty of posts on here from people who don’t know how to manage that.
And maybe you did lose nothing, but most people would not expect that when deleting a device. I mean, something has to go, right? It’s a deletion of data, it’s certainly not obvious that all the data gets restored. Especially when the delete dialog says “Its devices and entities will be permanently deleted.”
I think that recorder data doesn’t get deleted, but the average Joe (e.g. me until recently) doesn’t even know the recorder exists.
As an aside, the ESPHome integration list of devices shows this:
So is it ever possible for an entry in the list of devices to show anything other than “1 device”? It is in other integrations, so I assume the format for the entries list in an integration is standard, but they don’t title the list “Devices”.
If you are replacing a device, the logical first step is to remove the existing device. I don’t see how it would work otherwise, you can’t have 2 devices with the exact same name.
Replaced an ESP32 device today and both appeared with same device name but all entities had a _2 on the end of the name for the new device. I could have made it easier for myself if I had deleted the old device first.
Hell I was typing this as you posted tom_I so now it looks a bit redundant.
That’s what I said in my original post “A new device gets created with munged entity names.”
The point is that, to the uninitiated, it’s an unexpected result - it causes confusion, requires manual repair, and raises the spectre (real or not) of data loss.
I appreciate that as as a seasoned user of HA (or anything) it’s hard to step back and see things from the perspective of a newbie, but the vast majority of HA users have much less knowledge of how things work internally, and it’s quite reasonable IMO to expect the UI to detect and flag anomalous situations and guide the user through a resolution.
The existence of a workaround though doesn’t make this not a bad experience though or extremely surprising behavior.
From a practical perspective, the name of the device is the unique identifier in almost every other part of the ecosystem - i.e. it’s what is broadcast as the mDNS name, included in the entity names, and ESPHome has support to make the name parameter unique by automatically appending a MAC-derived suffix to devices for bulk flashing - which is what vendors I’ve bought pre-flashed devices from do.
The MAC address is the one hard to change component of the configuration, but it’s also not related in anyway to identity of an ESPHome device for doing ESPHome-things.
Well, it didn’t work for me. I replaced a device with identical hardware, same firmware, deleted the old device first, then added the new one, now I get lots of these:
When I look at the new device (same name as the old) I see that sensor.ac_voltage is now sensor.power_meter_ac_voltage which means all my dashboards and automations that refer to that entity don’t work any more.
Same for all the other entities. What the hell happened and how do I fix it??
Well, I think I fixed it - I had to manually rename all 19 of the new entities. That was better than trying to find every place they were referenced and update those, but it probably means if I have to replace that device again, I will have the same problem.
Well, the “default” must not be well defined, for HA to have created two different versions of the same entity from the same device at different times. I can assure you I did not manually edit them until now.
Is there a procedure I can use that will rename the entities and automatically update any references to them?
So I think I figured out why the entities were renamed - if a device is added to HA that has no friendly_name then the entities are just named using the ESPHome entity name. If a friendly name is set, it’s munged into the entity name as a prefix to the name from ESPHome.
So when that device was first added, it had no friendly name, now it does.
Basically this means you can’t change the friendly name - which I find a bit unfriendly!
There is a perfectly good name always provided by ESPHome, which is even subject to ID-style lexical rules, so much more suitable for use without munging - why is that not used instead of the entirely optional friendly name?
If you have a comment, it helps to actually make it, rather than post something with no new content and relying on others to interpret what you meant.
I am going to assume you are implying that there is a disconnect between those two statements - if that’s not the case then please clarify.
When the device was first added, 8 months ago, it had no friendly name. That name was added about 6 months ago, with no impact on anything in HA. No entities were renamed, nothing was flagged as being unusual.
Then yesterday I replaced the device with one running the same firmware image as the old one had immediately prior to its removal. Then, per your instructions, deleted the old device from HA, and adopted the new one.
The result was unexpected. If there had been an actual procedure to undertake this swap, then nothing would have changed except the device’s unique ID - the entities would not have been deleted, and re-created with a new name.
It would be helpful to at least acknowledge the problem, and suggest paths by which it might be addressed. I don’t expect someone else to just come up with a magic fix, and I’m quite happy to do some work myself, but there’s no point starting on that before there is some agreement on what the best path forward is, which requires a adult discussion on what the underlying problem is and how best to fix it.
