I just got my zwave setup on HASS and added just one light switch into for now, and will likely add the rest of my home this weekend as I transfer things over.
But I also have 1 lock that I will need to pair. And according to the docs I need to set a network key in your options.xml file.
But I seem to somehow have 2 of them? One of them is located in the config directory of OZCP and the other in the my /usr/local…/libopenzwave-0.3.1-py3.5-linux-x86_64.egg/config directory.
So do need to set the same network key in both files? First with OZCP to pair the device correctly, and then also set the same key in /usr/ location so that HASS can control it?
Of can you tell OZCP to look in the /usr/local… config location for the pairing?
Thanks, I’ll likely set up a symbolic link tonight.
In doing so, and making sure I do correctly,. If I want to keep the options file located in my OZCP location, and then remove the one located in /usr/local…
After I delete the usr/local one, the correct command would be…
Hmm, I have the exact same situation right now and I don’t think either solution is correct. I have /srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config and /srv/hass/src/python-openzwave/openzwave/config (after executing the home-assistant raspberry pi all-in-one installer).
The /srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg is a pip-managed installation directory, which will likely be removed with the next version update (and while I don’t know either way, I don’t think pip has special configuration file handling similar to what dpkg has).
The /srv/hass/src/python-openzwave is a source code directory and similarly likely to not be guaranteed to be stable (though, not having a version number in it’s name, it probably is slightly more stable than the egg).
Neither of these directories seems like the correct place to put static per-site configuration. For now I have moved config to a new directory in /etc/openzwave and created symlinks in both old places. At least this makes me relatively certain that it won’t get lost on updates. Which is the other problem: The directory seems to contain device/model data which probably is subject to updates when the software is updated.
So, ehh, what is the correct way to handle the situation?
Has anyone here gotten there NetworkKey line to work in the options file? I’ve tried docker, Hass virtual environment, different machines. The only time I was able to get my aeontec gen 5 to securely include my scalage lock was by taking my stick over to a docker of domoticz and putting my key into the web interface. When I bring the gen5 stick back to any other box running openzwave or home assistant I get errors about missing the NetworkKey. I’ve included it in every options.xml file that exists on each system.
If anyone here has a working file, would you mind sharing it with maybe some modified numbers just so I can see what it’s supposed to look like?
Mine is:
<?xml version="1.0" encoding="utf-8"?>
<!-- To be effective, this file should be placed in the user data folder specified in the Options::Create method -->
<Options xmlns='http://code.google.com/p/open-zwave/'>
<Option name="logging" value="true" />
<Option name="Associate" value="true" />
<Option name="NotifyTransactions" value="false" />
<Option name="DriverMaxAttempts" value="5" />
<Option name="SaveConfiguration" value="true" />
<!-- <Option name="RetryTimeout" value="40000" /> -->
<!-- If you are using any Security Devices, you MUST set a network Key -->
<!-- <Option name="NetworkKey" value="0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10" /> -->
<Option name="NetworkKey" value="0x62, 0x6c, 0x46, 0x70, 0x52, 0x55, 0x53, 0x6d, 0x44, 0x6c, 0x57, 0x38, 0x30, 0x56, 0x70, 0x48” />
<!-- Some Devices have a big UserCode Table, that can mean startup times
when refreshing Session Variables is very long (Especialy on Security
Devices) This option will make the UserCode CC stop on the first
"available" usercode slot rather than retrieve every one -->
<Option name="RefreshAllUserCodes" value="false" />
<Option name="ThreadTerminateTimeout" value="5000" />
</Options>
Yes, getting it to see the network key has not been a problem for me. When home-assistant (or ozwcp) starts up, look into the OZW_Log.txt file, where you’ll find a Info, Setting Up Provided Network Key for Secure Communications line. If right after that there’s a Warning, Failed - Network Key Not Set it didn’t work, otherwise it did.
Attention: The file you posted is syntactically incorrect:
Seems there is still no clear cut answer to how to handle z-wave config folders and all the symlinks… I just did full re-install from (unknown crash after upgrade)… and for the first time I tried HASSbian out, only to see it has symlinks in a couple locations that all link to the z-wave config folder that doesn’t even exist… So I updated the links in all locations to now point to a folder I created in the homeassistant configuration folder:
/home/homeassistant/.homeassistant/zwave-config
So that all of my configuration is managed in that one place now. This seemes like a good practice for me anyhow!
For reference between the AIO installer and HASSbian image, these are all of the locations I’ve found symlinks for z-wave configurations that I synced up to point to 1 place now:
AIO Installer via apt-get: /srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config/options.xml /srv/homeassistant/homeassistant_venv/src/python-openzwave/openzwave/config/options.xml /srv/homeassistant/homeassistant_venv/src/open-zwave-control-panel/config
If you used the AIO installer prior to December 2016 (as described here) then you will need to change /srv/homeassisant/homeassistant_venv/* to /srv/hass/hass_venv/* in the above paths.
Hope this helps someone else trying to track these paths down and sync them up…
Ok, so I wanted to add some additional information to my above post for my ‘best practice’ for managing Z-Wave configuration files because, HomeAssistant needs to find more than just the options.xml file for z-wave to work fully.
It has several other dependencies, that I’ve learned of by trial and error.
This link describes what I’ve developed as my ‘best practice’ for managing all of the Z-wave configuration elements, file dependencies, etc. so that I can manage them in one place and eliminate copy/paste issues – hopefully making my setup more stable and making it easier to setup new HomeAssistant instances for others…