According to the latest release announcement:
And, bonus, when you rename a device on the device page, it will now also rename the entities of that device if they contain the device name. When you are in advanced mode, it can also rename the entity id’s for you
Haven’t tried it myself, though.
Seems to work for me. I didn’t even notice this part of the release notes!
I only noticed it when I was bored and read the notes the other day.
Sorted - thanks all for the advice. I used the service “zwave.rename_node” to rename the Node, it managed this, and the Entities attached to the node. 48 hours later, I have over 100 devices moved from Fibaro to Home Assistant, and I’m working on new automations already!
With that said, I have one remaining question. I think I have some orphaned nodes in Home Assistant. I want to make sure I start with a clean setup.
If I go to Configuration \ Z-Wave and open the “Nodes” drop-down from the “Z-Wave Node Management” section, I can see all my Z-Wave nodes, all correctly named.
But if I go to Configuration \ Devices I can see duplicated entries. For example:
From what I can see, of these two, one will not have a ZWave entity included with it. My gut is telling me that this is the result of the entity name change, and that the old ‘records’ were not fully removed. So question:
Cheers,
Chris
Yes, entity by entity.
Maybe, I’ve screwed up things by attempting to rename stuff, but using zwave.rename_node only seems to change the friendly name of the subordinate devices, not the entity_ids.
I find myself wishing there was a service I could call that would rename the entity_id (and perhaps friendly_name), and then I’d just hack up a shell script and hass-cli to do this easily. I also have the same problem as an earlier poster - I just got 2 of the Greenwave 6 outlet power strips and these things create a pile of entities, 5 or 6 or every outlet. I’m afraid to connect and include the second one until figure out a good path forward to arranging to have sane names.
I really don’t want to turn off Home Assistant and run sed over the files in the .storage folder if I can avoid it.
Hmm, this looks promising, maybe:
$ hass-cli entity rename --help
Usage: hass-cli entity rename [OPTIONS] OLDID [NEWID]
Rename a entity.
Options:
--name TEXT
--help Show this message and exit.```Yeah, I think this might work.
louie@kzin[13] $ hass-cli entity rename sensor.greenwave_reality_inc_powernode_6_port_previous_reading_12 sensor.greenwave_reality_inc_powernode_6_port_previous_reading_12_xyzzy
- id: 1
type: result
success: true
result:
config_entry_id: f832cc06006748b5b4d3ad331d2481c6
device_id: 4b5492f4c8da4f82b76a259d1ae044f9
disabled_by:
entity_id: sensor.greenwave_reality_inc_powernode_6_port_previous_reading_12_xyzzy
name:
platform: zwave
and now in Developer Tools/States, the entity actually did change its name as expected (just appending _xyzzy as a test)
So this is very encouraging, and if I can also update the Friendly Name at the same time, that would be great.
Yeah, this approach works. Here’s what I used to rename all the sensor and switch entities:
for e in $(hass-cli --columns entity_id entity list | egrep '^(sensor|switch).*greenwave' ); do \
new=$(echo $e | sed -e 's/_reality_inc_powernode_6_port/_powernode1/'); \
hass-cli entity rename "$e" "$new"; \
done
And you can rename the friendly_name field by doing something like this:
hass-cli state edit --merge --attributes "friendly_name=GreenWave PowerNode1 Energy 1" sensor.greenwave_powernode1_energy_1
Do not forget the -merge option, or you will blow-away all of the other attributes, which is probably not what you want to do!
Just a big shout-out and thanks to those that brought us hass-cli. If you’ve not heard of this tool, see https://www.home-assistant.io/blog/2019/02/04/introducing-home-assistant-cli/ and https://github.com/home-assistant/home-assistant-cli for more info. Also Introducing Home Assistant CLI aka. hass-cli .
If you want to attempt a similar thing, just some additional info on my environment. I don’t use hass.io; I just run the standard Home Assistant docker container off of docker hub. Even so, for this particular effort, I am using hass-cli installed on my MacBook Pro, remote from the Ubuntu Linux system that runs all my docker containers. So even Hass.IO users could do a similar thing if they have a UNIX shell somewhere to run hass-cli. I would imagine this would work regardless of how you happen to have Home Assistant running, as it just uses an API to do its work.
Can you help me understand your script a bit? What values should I edit as the Input & Output? To confirm, I’ll need to update all my automations to use the new entity name, is there anything else that is likely to break?
The core part that you need to understand is:
hass-cli entity rename sensor.this_is_the_old_ugly_name sensor.this_is_the_nice_new_name
The rest of that shell for loop is to just invoke that command with the old and the new entity names. You could just manually build a shell-script that invokes that command a number of times; I just managed to wrap it into a loop to do that mechanically based on my specific needs.
So
hass-cli --columns entity_id entity list
will print to standard output a list of all the entities in Home Assistant. So I pipe that into an egrep command that uses a pattern and selects out only the lines/entities that start with either sensor or switch at the start of the line (the ^ anchor) and then contains a string of any characters (the .* pattern) and then the string greenwave.
Enclosing those two commands within $( ... ) causes each line to be expanding “in place” so that the for command can iterate over them, one at a time, putting the “current” value in the $e shell variable.
Then the next line pushes each entity_id (in $e) through the sed command that does a substitution of the string using the s/old_pattern/replacment/ command that sed understands. The result is captured in the $new shell variable.
Then finally the hass-cli command is invoked to do the rename from the old name to the new name, and the done shell command denotes the end of the for loop, and the next iteration begins.
The takeaway here is that hass-cli can use an API to do the renaming operation. There’s nothing special about shell-script wrapped around it, other than that it was easy (for me) to cobble up quickly to solve the problem. I’ve used the UNIX shell to write one-off scripts like this for 25 years, so this was a natural solution and familiar pattern for me. You could choose do do this differently lots of different ways.
I hadn’t intended this to be a shell script / programming tutorial, and apologize that the core aspect of using hass-cli as a means of solving the renaming problem got obscured by the junk I wrapped around it. But it illustrates how handy of a tool hass-cli is, since it is a really nice building block that’s easily used inside shell scripts to do stuff like this. Thanks again to the author(s) of that tool!
Yes, my goal was to rename the entity_id of a bunch of entities without having to click on that gear icon. So the old ones will be gone and your automations (and all the other things that reference the entity_id) will need to be updated, like the lovelace UI, for instance.
This is super helpful thanks. It seems like modifying the (sensor|switch).*greenwave section will change what entities this will affect and _reality_inc_powernode_6_port is effectively the find and _powernode1 is the replace. Did I get all of that right?
Yes, you’ve got it about right. I would strongly recommend that you try out those individual shell commands, especially hass-cli ... | egrep sequence to make sure it’s selecting and changing what you intend. Building regular expressions can be tricky if it’s something new to you.
Also, for a “dry run”, put an echo in front of the hass-cli entity rename .... command so you’ll see it print out the command it was going to run, without actually executing it.
Or just unroll the loop and build each of the commands yourself with a text editor. Many different ways to solve the problem and/or hang yourself 
great suggestions. I do know my way around regex, but its always smart to test before you click go 
One final warning/bit of information - I was running that on my macOS system, so I don’t know if the BSD-based version of egrep is 100% the same in options, etc. as the Linux/GPL’d version of egrep they use, if you happen to be running this on a Linux system.
ahh, thanks for pointing that out. Im planning on running all this from my Pi. I’ll check the man pages to confirm the options are the same. I’ll report back if I have to make any modifications.
…and just to note that I did a pattern there to select only sensor and switch entity domains because that’s what that device exposed, and I explicitly wanted to exclude the zwave.foo entity_id because I had already done something with it. Other devices with other entity_types (like binary_sensors, for example) would need some different pattern if you wanted to apply the same editing to the entity_id created for each of them.
Again, I had a bunch that I needed to do the exact same thing, so this sort of think worked. You might imagine an alternative approach where you have a CSV file with old and new entity_ids that you construct somehow, and then a shell script that iterates over each line. Or something. Nothing magic about my particular approach, only that it seemed a natural way to my to solve my particular problem I was just very pleased to discover that hass-cli would let me do this at all…
I did not realize the importance of this message when I first read it… Just read up on this great tool. Just got it working on my mac and already seeing the utility!
In the coming days I was going to move some 30 Zwave devices from SmartThings to HA. When I do so I want to set the entity_ids and friendly names to something relative at the beginning, so creating automation, scenes and scripts will go smoothly.
I included a couple devices, not only do they have long ids/names some have 4 child sensors under the single device ie:
(friendly name)
Inovelli NZW-30 Smart Switch W Scene 2 energy
Inovelli NZW-30 Smart Switch W Scene 2 power
Inovelli NZW-30 Smart Switch W Scene 2 reading
Inovelli NZW-30 Smart Switch W Scene 2
Inovelli NZW-30 Smart Switch W Scene 2 light
(ids)
sensor.inovelli_nzw30_smart_switch_w_scene_2_energy
sensor.inovelli_nzw30_smart_switch_w_scene_2_power
sensor.inovelli_nzw30_smart_switch_w_scene_2_reading
zwave.inovelli_nzw30_smart_switch_w_scene_2
light.inovelli_nzw30_smart_switch_w_scene_2
so I was thinking hass-cli method would come in handy.
but I have 1 problem and 1 question
I don’t know much about Linux, but I was able to install a Raspbian image under a VM on my windows machine than installed homeassistant-cli. I then entered the 2 environment variables to connect to HA.
I can run info and state list:
$ hass-cli info
BASE_URL LOCATION REQUIRES_API_PASSWORD VERSION
https://xxx.duckdns.org:8123 Home True 0.108.5
PROBLEM:
but if I run the below, I get the following error:
$ hass-cli --columns entity_id entity list
error: AttributeError: module 'homeassistant_cli.hassconst' has no attribute 'WS_TYPE_ENTITY_REGISTRY_LIST'
$ hass-cli entity rename sensor.zooz_zen15_power_switch sensor.power_switch
error: AttributeError: module 'homeassistant_cli.hassconst' has no attribute 'WS_TYPE_ENTITY_REGISTRY_GET'
Run with -x to see full exception information
Then I’m unclear how to form a script to rename all the entity_ids and friendly names for the example to something like:
light.entry_hallway Entry Hallway Light
sensor.entry_hallway_power Entry Hallway Light Power
any help would be appreciated
it sounds like there’s some sort of problem with the hass-cli tool installation based on that error. I just tried hass-cli on my system (installed some months ago) and it works against 0.108.5 that I have running.
I don’t know how you might have installed hass-cli; I used pip on my system to do that.
Ha, ha, I just upgraded my homeassistant-cli package from 0.7.0 to 0.9.0 and I now have the same problem as you! I’ll have to see if I can revert it in the near term, and maybe open an issue on github.