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. 
1 Like
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.
1 Like
So I did all this and removed the integration and started over… now amazingly door sensors and motion sensors that previously had to be “manually” added with template sensors because they were unknown devices were recognized and automatically had the proper binary_sensors they needed… my garage door opener on the other hand is still being ridiculous… I think I’ve accepted that it’s possibly just dead… I just don’t understand how it paired immediately the first time with the cover entity and everything and now it’s being so difficult… but an embarrassing thing I just noticed in the process of bringing it in the house to pair it again is that the sticker on the back actually says it’s a GD00Z-5 not a 4… it was listed as a 4 in HA and I just assumed that’s actually what it was… so I don’t know if that’s been the source of my problem… is that 5 is the reason it’s not working? Thanks everyone for all the help… I am pretty happy my other devices are properly identified now… should I give up on the opener?
I would never give up 
Tinkering is the adventure.
Sorry if you mentioned before, but what are you using for a Z-wave controller?
One though just occurred to me, check the OZW_Log for the Command Class not being supported.
Yeah that’s in there
Unhandled Command Class 0x66
That tells me the wrong version of openzwave is in your system. Once that’s fixed you’ll have the cover again.
Did you apt-get purge <zwavepackages...> that @freshcoast recommended?
Yes I did… but not in the VENV correct ? Yes I removed libopenzwave1.5 and 1.5-dev (spelling maybe be wrong)
**Just ran list again… comes up blank
I had saw some of the old posts where you had mentioned the dev branch and the script to fix it but after trying to summarize the posts it seemed that was no longer necessary… also I have 2 Schlage locks and read something from @ptdalen saying it changed how it handled the user codes in the dev branch. Is this still the case (I had both working together at one point)
Try reinstalling the homeassistant-pyozw using the --no-cache pip flag
(homeassistant) homeassistant@hassnuc:~$ pip3 install homeassistant-pyozw --no-cache
Requirement already satisfied: homeassistant-pyozw in /srv/homeassistant/lib/python3.7/site-packages (0.1.4)
Requirement already satisfied: six in /srv/homeassistant/lib/python3.7/site-packages (from homeassistant-pyozw) (1.12.0)
Requirement already satisfied: PyDispatcher>=2.0.5 in /srv/homeassistant/lib/python3.7/site-packages (from homeassistant-pyozw) (2.0.5)
You are using pip version 19.0.3, however version 19.2.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.Nah you gotta use this:
pip3 install --upgrade --force-reinstall --no-cache-dir homeassistant-pyozw
Ok that’s installing… (setup.py seems to take a minute…) is there anything I’ll need to do afterwards to “refresh” the device config?
just load HA up and cross your fingers you don’t get the Unhandled Command Class 0x66 
… and there is the missing cover entity!!! You are the best! Thanks guys for all your patience…
… now just gotta move it back outside and hope it works!
Edit: All good! Thanks again!!
1 Like
@Bartem So just to explain what happened, the libopenzwave1.5-dev that was installed stopped the homeassistant-pyozw package from compiling the openzwave library it uses (which has the patches already applied for the GDO and a few various other fixes) because it had already seen the library existing it didn’t compile a new library.
After you removed the zwave packages via apt, a new library needed to be compiled, and that’s what we did via the pip command 
1 Like
Thank you so much again!! It had really been frustrating the heck out of me… I dunno how I messed that up in the first place
1 Like