So when looking for where to change it in integrations I see all those old entities but only on the integrations page not on the entity registry page… I also looked through the files in .storage and don’t see it those entries anywhere … no option to delete just those items anywhere. Does anyone have any idea where it’s storing these entries?
I’ll check mine and get back to you when I get home.
Am I going about this all wrong? Is there another issue with it just not recognizing the devices anymore? Like the wrong OZW or something… I just removed the whole integration and when re-adding my Schlage locks were identified automatically… does the regular version of python-openzwave support the Gd00z-4? I was pretty sure I read that a “hack” was no longer necessary but when looking in the config dir I don’t see a file for GD00z-4 but I do see it in the manufacturer_specific.xml … sorry about my level of knowledge with this… I’m pretty new to the zwave integration
You may have an older version of the config files stored in a python3.5 directory that’s being referenced. What’s really odd is that it’s looking to update files into
/etc/openzwave/ instead of in the venv path.
So I looked and I definitely see the XML for my opener in my HA Venv python_openzwave dir… I just have no idea how it could have decided to use a different path in the first place as I just use the integration… and when trying to specify a location using the configuration.yaml I could’t even get z-wave to start… I wonder where it’s coded to decide what path it’s looking in.
I find the OZWCP helpful in these situations… have you tried using it?
Is this only for hass.io? I am using HA in a venv on Ubuntu
Sorry - didn’t catch that. I don’t think it will work on HA stand-alone.
You mention that you tossed your whole zwave config. Are you still seeing the node in the xml file?
That got rid of the old devices in the integration, but now I’m back to the cover entity not being generated…it seems it HA doesn’t know it’s a GD00z-4
I also struggled with getting the cover to show up. It found the other entities first and I kept pressing the inclusion button while healing/refreshing the node until the cover appeared. It took several reboots and tinkering to get them to show up.
Once they show up, be sure to save config in the Z wave panel. Don’t be surprised if they disappear again after a reboot, but they will eventually stick.
Hope this helps!
I checked my core.config_entries and didn’t see the config_path set there, but it is pulling it from my configuration.yaml:
zwave: config_path: /srv/homeassistant/venv/lib/python3.7/site-packages/python_openzwave/ozw_config
So after multiple reinstalls of python-openzwave… and ultimately removing the node from zwcfg_xxx.xml… it is recognizing the opener… but now I have no entities at all… anyone know how to get it to regenerate the entities? Or does that mean something is still not right? I’m at work so I can’t exclude and include right now but was hoping I could force HA to make them again.
Refresh Node in the zwave menu?
No luck there … I think I’m gonna reboot the whole system in a minute… or maybe try removing the node from zwcfg again but this time refresh and be more patient in case it was just taking awhile? Really at a loss…
You could just
Stop Network then
Start Network, basically just restarts Zwave for you.
It really is an exercise in patience with these devices. It took several reboots, pressing the inclusion button while refreshing the node for all the entities to appear. Also bring your zwave controller as close as possible to the device and be sure to use “Add Node Secure”. Are all of your devices securely added?
Yes every one is securely added… I guess I’ll try again when I get home tonight… thanks guys
I’ve honestly had 0 issues with mine. It included straight away from the garage, I had to do no rain dances to get it to work.
One more thing - if you haven’t already done so, check the xml file to ensure the nodes are actually being added in secure mode. HA will not notify you if the node is added unsecure.
Regarding the config files, if
zwave.update_config is trying to update files in
/etc/openzwave it means you have the debian (or whichever dist you are using) openzwave packages installed. Remove those first. Run
apt list --installed *zwave* to get a list of installed packages, then
apt-get purge <zwavepackages...> to remove them all. Afterwards, HA will find the correct config files path. There is a priority of paths python openzwave searches, and /etc is one of the first.
HA already has the most recent version of the config paths, so you should have no reason to download them yourself, but you can use the
config_path setting as mentioned to set your own path. If you don’t uninstall openzwave or set your own config_path, you will just keep using very old device config files.
Lastly, don’t bother using
zwave.update_config, it has never worked. Config files are no longer being maintained in the version of OZW uses anyways.