Undo device rename

I’ve just renamed my device. But, after all, I don’t like the new name. I’d like to bring back the old name. Yes, I can type it (if I remember it exactly), but the proposed feature is… UNDO BUTTON.

It could be positioned at the top of the device page after the rename. It may not be there forever, just for the open window/session (remembered in the browser), used for convenience.

Actually, the common command+z shortcut working would also be nice.

What happens if you delete the given name in the rename process?
I have not tried it myself, but maybe the original name comes back then.

Yes, original name comes back.

Assuming I changed the original name to Foo, then to Bar → I may want to come back to Foo, not the original name.

It would probably be a lot of info to store for very little use cases.

A lot? I could do it with a JS snippet saved as a bookmark, ez.

I meant that if you want to undo an entity rename, then HA would have to store every entity renamed in your setup and manage that database for when you replace devices, taking into consideration if you replace the device and want to keep the rename history or replace the device and want a clean rename history.

This of course also have to apply for devices, because they can also be renamed and they are actually independent from entities, so a device can be renamed and then all its entities too.

HA have the option for backup though, which also will include that information, so a regular backup policy should solve that issue.

Nah, I’m proposing something much simpler.

  1. User clicks rename
  2. Frontend (JS) remembers the previous name *
  3. User clicks “Undo rename” button
  4. Frontend does… yet another rename. Just with the old name. No special mechanics, just do another ajax or whatev that made the first rename, but with the previous name this time.

* by “remembers” there are multiple possible tiers:

  • a.) only a JS var → since the rename does not reload the page, the undo button remains as long as the window is not closed
  • b.) local storage / session storage → will work a bit longer
  • c.) backend storage → what you’re suggesting as the “hard” option → yep, hence I’d stick to option A or B.

So if I rename a device and say yes to also get the entities renamed, then I rename a few of the entities and then I decide the device should not be renamed, then what should be undone?

Hah, didn’t think of that!

  1. User has renamed the device name.
  2. User has renamed device entities to custom names (not derived from the device name)
  3. User has renamed the device name again. A pop-up appeared if they wanted to change entity names as well, they confirmed (entity names are no longer custom, but derived from the new device name).
  4. User wants to undo the change.

Options:

  • a.) Don’t touch entities (nah)
  • b.) Revert the entity names as well (my recommendation)
  • c.) Show a pop-up for the user to decide (there was a pop-up on the rename, so why not on the rename-back)

Actually, with reverting entity names, I’d say the Feature Request is twice as attractive then when I originally thought of it. Because if u’d wanted to “manually” go back to the previous device name (by doing another rename), u’d have to rename entities as well, while remembering their (possibly all custom) names → the undo/revert feature should do the job much easier.

Current behavior:

When renaming devices, it’s entities that start the same way are included in the rename. Those you renamed are not included if they do not start with the same thing.

So if the device and all it’s entities start with 1, you rename the individual entities to start with 2, and then rename the device from 1 to to 3, no entities rename because they do not start with the same thing.

If you proceed to rename the device to 2, same. But then, if you rename the device from 2 to 3, all entities starting with 2 are again included, because they start with the same thing. So current behavior is not that bad. It saved me a lot of work one or twice.

That is the current behavior with a rename, but when you do an undo, then it is harder for the user to figure out what that undo will then do, because you might end up with a rename behavior as current, but that is really not an undo.