Yes, that would be an even better way to do it if you want to fully switch over.
Either way you do things it’s going to be tedious completing the migration.
I’m pretty sure you can use that method to swap back and forth. But openzwave uses a stupid naming convention for entity_ids based on all the information provided by the client. So you’ll always be ‘renaming’ when moving back to openzwave. But if you use the supervisor you can just reload your config from an old snapshot.
I am looking at the same thing, and dreading renaming everything again, as I just went through that once.
Is there a way to script this? If you dumped all your ozw entity names, could you programmatically generate the equivalent zwjs2m names, and then run a sed script to map them back? Or maybe you don’t know what “node id” will be used for a given entity until zwjs2m picks one?
all zwave entities from ozw have node_id as an attribute. So, using the template editor…
entities:
{%- for s in states | selectattr('attributes.node_id', 'in', range(255)) %}
- {{ s.entity_id }}
{%- endfor %}
output will be:
entities:
- binary_sensor.flood_light_relay_heat_overheat
- binary_sensor.garage_door_sensor_access_control_door_window_open
- binary_sensor.garage_door_sensor_home_security_tampering_cover_removed
- binary_sensor.garage_door_switch_sensor
- binary_sensor.garage_door_tilt
- binary_sensor.garage_entrance_door_sensor_sensor
- binary_sensor.garage_entry_door
- binary_sensor.main_door
- binary_sensor.main_entrance_door_se
... etc...
EDIT for even more information…
nodes:
{%- for node_id, statelist in states | selectattr('attributes.node_id', 'in', range(255)) | groupby('attributes.node_id') %}
{{ node_id }}:
{%- for s in statelist %}
- {{ s.entity_id }}
{%- endfor %}
{%- endfor %}
output is:
nodes:
3:
- switch.game_room_switch
4:
- switch.game_room_wall_outlet
... etc...
32:
- binary_sensor.office_motion_sensor_home_security_motion_detected
- binary_sensor.office_motion_sensor_home_security_tampering_cover_removed
- binary_sensor.office_motion_sensor_sensor
- sensor.ms_humidity
- sensor.ms_temperature
- sensor.office_motion_sensor_battery_level
- sensor.office_motion_sensor_illuminance
- sensor.office_motion_sensor_ultraviolet
... etc...
1 Like
And just to clarify (since that statement seems imply a possible misunderstanding)…
The node_id’s aren’t assigned by HA/ozw/zwavejs. They are assigned by the controller when the device is paired. HA/ozw/zwavejs just reads that info from the controller and updates the database accordingly.
So all of those systems will always have the same node_id’s for each device
2 Likes
Very cool, thank you.
To people familiar with the naming conventions, does this look like an accurate entity id translation from ozw to zwjs? On the left are the custom names I’ve set up in ozw, on the right are the anticipated generated names coming out of zwjs.
I guess this can’t be complete yet because it generates redundant names for zwjs. But maybe it’s getting close.
(node 2): switch.front_porch_lights => switch.node_2_switch
(node 4): switch.kitchen_lights => switch.node_4_switch
(node 9): switch.master_lights => switch.node_9_switch
(node 12): climate.general_thermostat_v2_mode => climate.node_12_climate
(node 12): climate.general_thermostat_v2_mode_2 => climate.node_12_climate
(node 12): sensor.general_thermostat_v2_air_temperature_2 => sensor.node_12_sensor
(node 12): sensor.general_thermostat_v2_air_temperature_3 => sensor.node_12_sensor
...
Generated by:
{%- for node_id, statelist in states | selectattr('attributes.node_id', 'in', range(255)) | groupby('attributes.node_id') %}
{%- for s in statelist %} {%set type = s.entity_id.split('.')%}
(node {{node_id}}): {{ s.entity_id }} => {{type[0]}}.node_{{node_id}}_{{type[0]}}
{%- endfor %}
{%- endfor %}
What I’m after here is to generate a search/replace script that would run the reverse mapping to replace the entity names created by zwjs to the names you currently have in ozw. I’m assuming these are set in some text config file and could be swapped out by editing that file.
1 Like
Ok, so I started bringing in a couple entities through zwjs to look at the entity naming scheme, and while this approach might work for simple things like switches, it seems to face a very uphill battle for more complex devices. For example, for a smart switch I have, I get a default zwjs entity name of:
sensor.nodeID_3_electric1_a_meter_66817_value
for the amperage sensor.
It’s not clear where “66817” came from (at a minimum), so I don’t know how I could anticipate this default name for programmatic renaming purposes.
I guess this dev branch is not the same as the “:latest” docker image, since I don’t see it yet.
It is not. To get the dev branch pull it with the :dev tag instead of :latest.
1 Like
Got it. Any thoughts on how would I get it to “rediscover” with new entity names if I changed the template and saved the new settings?
… (answering my own question)
I deleted the device, then restarted HA, and it seemed to rediscover the device/entities. However, it didn’t seem to change how the entities were named. Hmm.
Would someone mind running me through how to install via docker and then how to get into the ui of this after
How is the device compatibility? I was thinking of testing this by spinning up a container.
That depends on how you installed HA (HASSOS, Supervised, Container, Core)?
once you get it installed you just go to the IP of the macine where it is installed and whichever port you assigned it in the docker install. Default port is 8091.
I have it Supervised version installed as a VM on a synology nas. I was able to get the repo installed for portainer into HA. Ive never installed a docker container in the supervised version through portainer. How is this part accomplished?
If you’re using Portainer, create a new “Container” following the zwavejs2mqtt instructions. Here’s my setup for zwavejs2mqtt in Portainer. Note second picture: you need to add your zwave USB hub device
The volume mapping above is optional. I did that so I can have access to the files and tinker a bit. You can omit the Volume setup completely if you want, until you have some need to edit the files.
1 Like
I don’t know if this is what you have run into, but Hass and its device registry love to prevent re-use of a device id. …even when it is the same device through a new service or a replacement for a dead device. It drives me stark raving mad. The only solution I’ve found is to shutdown Hass and then manually delete the devices at issue from the device registry file. I suspect that I could delete the entire file and let it be rebuilt. …this isn’t the only reason for devices to get “new” ids, but it is the reason I most often run into. Hate it! Hate it! Hate it!
1 Like
Appreciate the help with this!
Delete the Mqtt integration, shutdown ha, start ha, add the MQTT integration back. Everything will be auto created as long as the discovery configs are sent on startup. I would assume zwave2jsmqtt would do this.
Edit: don’t do this if you renamed the entity_ids. You’ll have to name them all again.
