It is stated already before in this post: You can edit the entity_id, so you can decide if existing automations and other things reference the new device or not. So instead of replacing id’s in all places, you give your entity the right id. Once you change your way of thinking, you have all the flexibility you need.
There are also reasons why HA does not have the refactor you ask for (but instead chose a different approach to address the same problem). One of the reasons is that it would require HA to edit manually written yaml files. Also, when an integration decides to remove a device, or a device is no longer present in a yaml file, how would refactor work? Please replace some device that does not exist anymore, and which I do not know the unique identifier of, with a new device?
So the solution to replacing entities is there, but it involves renaming entity_id. Finding broken references is done quite well using Watchman and Spook integrations. Refactoring won’t help against broken references if integrations can choose to no longer expose a device.
I do not use node red, but I hope it uses entity_ids. HA would not be able to refactor unique identifiers in Node Red. Now it does not have to, as long as it uses entity_ids, and you decide which device has that entity_id.
Many people run HA on devices that simply cannot install the VS Code extension, for example, on Raspberry Pi. And as I said, it is an error prone process. For example, replacing the string node_1 will match a ton of Z-Wave devices and entities. You didn’t address the history issue. Should the user issue manual sqlite commands, too ?
The renaming should be automatable for non-LR to LR Z-wave migration to be seamless.
There are lots of other possible use cases for this feature to be automated, for example, replacing a failed device with a new one of the same model. I had to do that with my Flume water meter last year. It wasn’t seamless. Same with a solar gateway that got replaced, but in this case the model was different. In both cases, I had multiple sensor history, before and after, and had to combine them in the energy dashboard. It was a bit confusing to see missing device warnings for the sensors belonging to the failed devices. My history kept getting corrupt on Virtualbox, so I no longer have that old history, but it’s been completely reliable under VMWare Player (now Workstation Pro, since it is free).
Thanks for the explanation. The issue about manually written files make sense.
As far as the question on missing devices/sensors, in my mind this would be enabled by some migration tool. Obviously it can be very specific depending on use case, but I presented the case of energy & water meters, and I think it’s compelling to merge the history of an old failed sensor with the new one. Obviously the devil is in the details, but IMO doing that it requires some automated feature to rename sensors.
Thanks for mentioning Watchman and Spook. I will look into them. Even with dead entities, refactoring can still help, in the context of migration.
what happens if the new entity is added first ? That has been the case with my Flume and Enphase devices when configuring integrations - the new devices appear, perhaps automatically in the integration in some cases, with new sensors and different names. It definitely didn’t happen automatically with Enphase, but I think it might have for Flume. But for sure I added the devices as soon as they were physically installed, ie. beore step 1.
seems like we are back to the topic of this thread I am not going to restate my points, but note that there are 750 others who would like to see some sort of improvement to have this feature in the HA UI. And it is the 4th most voted on issue in the WTH category.
I very much realize that there are some technical obstacles that were mentioned. But I’m confident that the smart HA developers can come up with a solution, if and when there is a will.
I’m not sure, but no reason to risk it. There’s a chance nothing happens. There’s a chance that entity will be purged from the DB…
I see. Do you mean it could happen in the nightly DB purge, or immediately ?
Nothing, the way to transfer history is to delete the entity you want to transfer.
I get that, but if doing it in the wrong order for whatever reason, one ends up with 2 sensors with separate histories. At that point, is there any way to merge them ? And if so, what would the process be ?
I’m surprised to see you pushing this solution, find and replate in VSCode addon doesn’t find references in UI driven lovelace dashboards, nor does it find the device definition itself. For a device or entity that I have in “devices & integrations” and in a Lovelace dashboard, results in VSCode are “not found”.
Under the hood I would imagine all of these UIs are backed by configs (the dashboards even let you edit config fragments), why not provide a way to update them all at once? VSCode could be this solution, but it needs to include all configs, not just config dir.
Yes it can. You have to include the .storage folder.
I’m not pushing it, I’m explaining that it’s 1000x easier than people are making it out to be. This thread is filled with horror stories about spending hours making changes, and I personally find that a bit ridiculous when tools exist today to make this at most a 15 minute task.
Would it be nice to have this in the UI?
Yes.
Does it exist to a certain extent via the UI?
Yes. Device triggers, conditions, and actions use a config entry as the reference.
Would it be possible to have a button in the UI?
Maybe
Would it be a massive amount of work to get done correctly without issues?
Ah! Didn’t realize it was .storage under ~/config . I’ve removed .storage from the exclude list* for VSCode (instructions below for anyone who finds this) and restarted HA — but still not getting the results I expect.
I have a mqtt sensor defined in config.yaml: sensor.kids.temp, that sensor is used in UI based lovelace dashboard as sensor.kids_temp. Searching for the former only finds results in config.yaml, searching for the latter only finds results in home-assistant.log.1. Restricting search to the .storage folder gives no results for either.
Is there some step missing to make this work?
*For anyone else who finds this, the VSCode plugin excludes .storage by default, so you have to remove it from the exclude list. Go to File > Preferences > Settings then search for files.exclude and remove .storage from that list.
if it’s only finding things in config, that means it’s not defined in .storage. Well it most likely is but there’s nothing to change in it. If you’re trying to change dashboards, the files are named lovelace.<dashboardname>
I am not going to restate my points, but note that there are 750 others who would like to see some sort of improvement to have this feature in the HA UI. And it is the 4th most voted on issue in the WTH category.