Then you can just use VSCode normally. Or notepad++. Or any other text editing software that can search for a string inside files.
1 Like
should I shutdown HA before editing all the files ?
Nope, make sure to exclude hidden files (.storage folder). Make a backup if you are unsure of things. And go 1 by 1 w/ each replacement. I.e. click next, look at the change, click replace if it’s valid, etc.
1 Like
many thanks. I’ll give it a try, but it means I cannot do it from the GUI (locally or remotely) and I need to map the folder to another machine in order to do the search and replace.
Not as convenient as something that could happen automatically in the background by HA but I understand it has not been a priority 
+1 this would be useful. Although I know I and others can achieve the same effect manually, I imagine the lack of an automated refactor feature is a point of frustration for many less technically inclined users that stunts HASS growth.
So since we now have the better automations, can we get some clarification on this. Like does HA team know it is an issue? Why is even the actual name used and not guid / uuid / … (i get advantage when replacing the device with another, but maybe there are more?)
Now I’m at another, and i know it will not be last, rename / clean up spree to be more organized, but I already know I will lose the history etc.
This I do not want to just criticize, HA is the best out there for this kinda (“smart”) home stuff.
Last year lot of things got better, but still I think there is lot of this, kinda, small stuff, that “hurts”.
I see this post WTH when I rename an entity, most of the time it's history is lost? - #6 by bdraco and supposedly history remains, which for me, at least with the energy entries I tried confused me a lot as I still saw the history.
I will try it some more, but for me, loosing data about absolute humidity and temperature and then manually searching the database was much greater pain than fixing the automations, would be awesome if this part of renaming would be solved.
I also got some duplicated entries for esphome devices that broke automations, but probably totally unrelated to renaming
Anyways I see stuff in HA is actually getting updated for the better, which is, sadly, very very rare these days.
Another vote for this. This gets in the way of Z-Wave to Z-Wave LR device migration. The entity IDs have the node ID embedded. Eg button.node_135_ping . When migrating to LR, the device will get a new node ID >256 . Keeping the existing name as is would be very confusing. There should be a way to automatically migrate the device and rename the entity, without breaking existing automations.
And obviously as a user, I sometimes dislike the default entity names for a device if they don’t “speak” to me, and would like to change them, but not at the cost of breaking everything. For context, I currently have 1418 entities in HA. The suggestion that I should manually edit config files to rename them is not scalable.
This is a sorely needed a feature that should have been there years ago.
Find and replace using the vscode addon, takes all of 30 seconds.
It’s not 30 seconds if you have a lot of entities to rename, and among my 1418, there are many that I would prefer to rename.
A VSCode search-and-replace can still be error-prone, especially if there are substrings involved.
The database history also needs to be changed, if I understand correctly, and that won’t be done by VSCode.
This problem is such an obvious need that I don’t understand the reason for the pushback . Is there a technical reason why this is not feasible, or very costly to implement ? Or is it strictly about it not being considered important enough ? Or a decision by UI/UX designers not to do this ?
2 Likes
It’s literally 30 seconds. Edit → Find in Files → Enter the name you want to replace, enter the name you want to replace it with, click “change all”, done.
Here’s a screenshot of all references to my exact entity_id light.living_room and all it’s references.
No it doesn’t. Renaming the entity in the UI takes care of that.
At most, this is 2 steps.
Step 1, rename in UI. Step 2 findall → replace.
Lastly, this is only needed if you use service_calls. If you use device triggers, actions and conditions. The entity_id doesn’t matter and nothing needs to be renamed because those actions use the entry_id for the entity.
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).
yes I did
FYI this has nothing to do with refactoring
That is a separate FR and it is needed. Replacing a device has more importance than a refactor and the 2 aren’t related.
Our posts crossed.
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.
Not sure about the Node RED concerns.
- Delete the old entity (while remembering the name) DO NOT RESTART AT THIS POINT
- Add the new entity.
- Rename the new entity_id to the old entity_id.
→ history merged.
1 Like
I assume you mean rename the entity_id, or do you really mean name?
Ya
Thanks. I wish I had known to do that.
-
What happens if one does restart after step 1 ?
-
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.
Nothing, the way to transfer history is to delete the entity you want to transfer.
1 Like