OpenZwave config files - how do they work?

Configuration Z-Wave
1

Hi,

I’m trying to get a basic understanding how the configuration files for openzwave work together.
I’m running the docker version of HA, so openzwave is located in /usr/local/share/python-openzwave/config.

I got a Fibaro FGK-10x ZW5 window sensor yesterday. It shows up in HA and it’s working, but it’s not recognized with name.
Instead all the sub-sensors are named sensor.unknown_id010f_unknown_type0701_id1001_*.

So, I looked into the openzwave config directory and found this manufacturer_specific.xml file.
The file contains a line:

<Product type="0701" id="1001" name="FGK10x Door Opening Sensor" config="fibaro/fgk10x.xml" />

The id and type seem to match my sensor, so why does it not show up with its name?

Also, am I correct that the referenced file (fibaro/fgk10x.xml) describes the sensor’s “attributes” and it’s only(?) used by ozwcp to allow configuration of those attributes?

This is all still a black box to me…

Sebastian

2 Likes
2

I’ve found that after a few HA restarts, ZWave names start settling out and unknowns are replaced by the valid sensor type and name. Pretty much every time I have added a ZWave device, I’ve had to do a few restarts before I got the correct device.

3

I restarted like 20 times since yesterday for configuration mods.
Nothing changed - they’re still are all named with unknown_id and unknown_type.

Sebastian

4

Sorry that’s the best I can offer - like you it’s a black box to me somewhat as well. The only other thing I can think of is do you have it set for binary report?

5

Hi guys,

I had the same situation with Monoprice sensors. Here is the best practice i came up with after a suggestion by a fellow forum member,

After adding the node to your z stick,

  1. Insert the stick to your HASS host machine and restart/start the machine.
  2. Stop HASS and start OpenZwave
  3. Load the stick and you will start seeing the nodes populate to the list (during this part of the process keep your battery operated fibaro sensor in discovery mode. This usually means you keep the cover open. See your particular sensor’s instructions.
  4. You will see that in the list the names of each node will populate(be patient as it might not do it immediately after the first load). Once the new node (sensor) name is listed properly hit the Save button in Open Zwave. This will save all the new info for the nodes to the OpenZwave config file.
  5. Once done, go to the OpenZwave directory and copy the zwcfg file over to the main HASS configuration folder. If you want you can back up the existing zwcfg file that is already in the HASS config folder.
  6. Boot HASS back up or reboot your host machine.

Note that it helps to not install the sensor in the location it is intended to live before you go through the above steps. Meaning, sit at the desk or table where your HASS host machine is and do all the steps above. Once done you can place the sensor where its supposed to go. This helps because you dont have to run back and forth between your HASS machine and the sensor (i learned that the hard way haha)

Hope this helps.

4 Likes
6

Oh one more thing, if you get to step 4 and are waiting 10 minutes for the proper name to load but it doesnt; Select the node from the list and hit “Request Node info” in the actions menu followed by the Execute button that appears. This will make OpenZwave re-request the info from the node.

1 Like
7

Thanks, I’ll try it your way.

I just stopped HA, launched domoticz and opened the zwave device setup.
I removed the sensor and re-added it (securely).
Domoticz recognized that thing with its actual name and listed all the available settings.

I then exported the zwcfg_0xdeafbeef.xml file from domoticz and replaced the one HA uses.
After restarting HA, it took a while and the sensor eventually showed up as unknown again.
This time, the names did not even have the IDs in it: sensor.unknown_temperature_13_1.

I’ll have to play around a little with the inclusion process tomorrow…

Sebastian

8

It looks to me like there’s an issue with openzwave in 0.36.1.
For some reason, while fiddling around with this issue, I lost my Fibaro FGMS multisensor.
It later reappeared as an unknown sensor, just like the FGK sensor.
The FGMS was listed with its actual name before.
It also had its old node id though, so I didn’t accidentally remove/re-include it.

I just went back from HA 0.36.1 to 0.35.3, removed both sensors and readded them one at a time.
Now both are recognized by name and the binary (sub-)sensor instance associated with the FGK now even reflects the state of the (hardware) sensor, i.e. window opened/closed.
Before it stayed permanently on or off without any recognizable pattern.

I’ll try upgrading to 0.36.1 again. Let’s see what happens.

EDIT:
…transition to .36.1 went fine; all sensor names are still showing correctly and the FGK binary_sensor still reflects the actual state.
So to me it looks like the inclusion process in 0.36.1 is not working correctly.

Sebastian

9

I know this is an old thread, but there isn’t much information on this at all and it’s not clearly outlined in the docs either. So I thought I would post and cross link from some other threads to this one to hopefully help explain what I’ve learned from trial & error.

Here is what I’ve gathered that is needed to get a health z-wave network going from a configuration and files perspective.

This post here (from above) is very useful, but I want to add a couple more details I’ve discovered through trial and error.

There are 3 key configuration elements for my z-wave setup to finally work fully:

  1. Openzwave ‘config’ folders
  2. zwcfg_XXXXXX.xml & zwscene.xml file dependencies
  3. options.xml for Secured Devices

Openzwave ‘config’ folders:

Depending on the installation you have (I have only used/researched the following), there are 3 valid places that the z-wave ‘config’ folder must be referenced. So to help manage this in one place, we will Symlink 2 of the sources to point to one that is the most practical as a best-practice (I selected it because it’s part of the /srv/homeassistant/ application directory, doesn’t contain versions, and as far as I can tell, is least likely to change).

For each of the following, we will symlink the two listed to all to point to the one target to manage them here:
HASSbian:
/srv/homeassistant/src/python-openzwave/openzwave/config

AIO Installer (prior to December 2016):
/srv/hass/hass_venv/src/python-openzwave/openzwave/config

AIO Installer:
/srv/homeassistant/homeassistant_venv/src/python-openzwave/openzwave/config

The following are all of the ‘config’ folder locations that I’ve found need to be updated for z-wave to function fully; each of these following paths would be updated by deleting the config folder from all 3 locations (create a backup/rename it to be safe) and then re-create a Symlinked folder pointing to the respective location above (simply used WinSCP to create the symlinks from Windows most easily (:

HASSbian:
/srv/homeassistant/src/open-zwave-control-panel/config
Note, the version numbers in the next path may differ…
/srv/homeassistant/lib/python3.4/site-packages/libopenzwave-0.4.0.31.egg-info/config

AIO Installer via apt-get (installed Prior to December 2016; more info here):
/srv/hass/hass_venv/src/open-zwave-control-panel/config
Note, the version numbers in the next path may differ…
/srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.4.0.31.egg-info/config

AIO Installer via apt-get (recently installed):
/srv/homeassistant/homeassistant_venv/src/open-zwave-control-panel/config
Note, the version numbers in the next path may differ…
/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/libopenzwave-0.4.0.31.egg-info/config

zwcfg_XXXXXX.xml & zwscene.xml:

HomeAssistant is dependent on these files to actually drive the Z-Wave entity configurations within HomeAssistant. I read some details, but can not recall where I found them, but this is a cached configuration file holding all of the data read from Z-Wave nodes/devices. This file is constructed by the Open Z-Wave Control Panel application (OZWCP) and stored when you click “save” in the top right side of OZWCP (fyi, some useful information on managing and “saving” devices and their data with OZWCP can be found here).

These files are expected to exist within the .homeassistant configuration folder, so rather than copy them, as I’ve read in many posts, I also want to manage these in only one place. And since they are generated by the OZWCP application (the more powerful Z-Wave config UI vs HomeAssistant itself), I think the best-practice is to leave them where they are and then symlink to them directly at the file level.

So, regardless of your installation, you will want to symlink the following files in the .homeassistant configuration folder to their respective locations within the open-zwave-control-panel application folder as follows:

/home/homeassistant/.homeassistant/zwcfg_XXXXXXX.xml ==symlinked to==> /home/homeassistant/.homeassistant/open-zwave-control-panel/zwcfg_XXXXXXX.xml

and

/home/homeassistant/.homeassistant/zwscene.xml ==symlinked to==> /home/homeassistant/.homeassistant/open-zwave-control-panel/zwscene.xml

options.xml for Secured Devices:

This file is where you must specify a valid Encryption Key for adding Secure devices to your z-wave network. This is described really well in the docs here under ‘adding secure devices’.

This is stored inside the OZWCP config folder. However, since we’ve already updated all of our ‘config’ folder references (above), now this file is in one place so we can edit it in this location:
HASSbian:
/srv/homeassistant/src/python-openzwave/openzwave/config/options.xml

AIO Installer (prior to December 2016):
/srv/hass/hass_venv/src/python-openzwave/openzwave/config

AIO Installer:
/srv/homeassistant/homeassistant_venv/src/python-openzwave/openzwave/config

BUT, because I wanted to more easily manage my options.xml file while debugging secure devices, I did take it one step further. I created a new folder in my .homeassistant configuration folder so that I could easily update/debug from my samba share via Windows (on HASSBian):
/home/homeassistant/.homeassistant/zwave-config

Then I copied the options.xml into this folder (from the above location), and symlinked to this file directly:
/srv/homeassistant/src/python-openzwave/openzwave/config/options.xml ==symlinked to==> /home/homeassistant/.homeassistant/zwave-config/options.xml

Additional ‘config’ folder and ‘options.xml’ locations that can be ignored (and just added confusion):
I also found that z-wave config folders and options.xml files existed at the following paths . . . but they do not seem to be relevant so I did not touch them. My system is functioning fully, with secure Lock devices, so I think these paths can be ignored:

HASSBian (note: I did’nt confirm if similar folders existed on the AIO installation, but I suspect they do):
/srv/homeassistant/lib/python3.4/site-packages/python_openzwave/ozw_config
/srv/homeassistant/lib/python3.4/site-packages/python_openzwave-0.4.0.31-py3.4-linux-armv7l.egg/python_openzwave/ozw_config

12 Likes
10

Thank you for the detailed information. I was wondering if someone can help me. When I try to follow this instruction and create the Symlink it tells me the target is not a dir. Here is the command I’m using.

ln –s /srv/homeassistant/src/python-openzwave/openzwave/config /srv/homeassistant/src/open-zwave-control-panel/config

Sorry for the Noob question…

11

/srv/homeassistant/src/python-openzwave/openzwave/config likely doesn’t exist or is a symlink itself

Try:
ls -s /srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/libopenzwave-0.4.0.31.egg-info/config /srv/homeassistant/src/open-zwave-control-panel/config

1 Like
12

I got here from a link to a link. @firstof9 I think this needs to be ln rather than ls Could save someone frustration. :slight_smile:

1 Like