Z-Wave database updates - errors need to be removed

I’ve added some additional checks into the database - some of these result in “errors” which need to be removed before the database entries can be exported. If you are a Z-Wave binding user, please read on and spend a few minutes to check that your devices are properly defined…

There are two main new checks - firstly, there’s a check to ensure that device IDs are not duplicated which would result in an ambiguous selection of the device - I thought that this was in the database checker already, but it seems not…

The second check is to ensure that configuration parameters max/min settings are set consistently - or more specifically, that the default value is consistent with the min max. Sometimes people aren’t putting in the min/max and this is causing problems in the UI which ultimately results in not being able to save the configuration. This is especially notable in PaperUI as it checks, and sends, all parameters to the server - the error display in PaperUI is not very clear so it’s often confusing to people why PaperUI doesn’t allow updates. Since HABmin only updates parameters that have been changed it’s less of an issue there, but it does still apply.

Below is an example error output from the Aeon ZW116 -:

I will likely try and resolve some of the Type:Id duplication errors by removing the offending duplication on one device - this might be wrong, but if the duplication remains, then there is no way to know how the device is detected anyway. In many cases it is obvious which is correct as there’s often some sort of pattern used by manufacturers (and this is the case with the Aeon device above).

I’ve found that there are simply some duplicated devices, and in this case I’ll likely remove the one that looks to be the least complete.

If you spot issues with these checks, and you think they are wrongly detecting issues, then please let me know. If you are unsure what do do, then please discuss…

There are now around 660 devices in the database, so it would be great if people could take a quick search of the database for their devices to make sure there are no errors showing up, and if there are, correct them. Alternatively, you can also check the summary page, but note this takes a while to process the data…

On other news, I’ve also written an import function to read the configuration parameters from the ZWave Alliance XML files, so if these are available, we can now use them as a starting point for the database. There are often errors in these files (strangely!) so they normally need editing, but it should reduce the amount of work significantly for new devices.

1 Like

Done for


There is a duplicate version for this one here:
but don’t understand the comments on that one, they are talking about difference in versions for zwave and zwave plus so I left it untouched.

I could edit some more of the “value is greater” errors for devices I don’t own by comparing them to the manual if you want me to.

1 Like

This device
is actually a FGR222 (newer version) of the (older) FGRM222 (http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/413)
so it just needs to be renamed (devices are working fine with the database parameters).

Is it safe to just rename the newer one from FGRM222 to FGR222 or will it break the config?

Great stuff - thanks.

Up to you - it would of course be very appreciated if you did though :slight_smile: .

It’s safe. The config uses the unique reference field - if you change that, then it might mean that people need to delete/re-add the device to get the config running again. If you wanted to do it, then after 2.2 might be a good time as this will be required once the dev branch gets merged anyway…

I fixed a couple of the devices I use. Overall, most of them were in good shape.

I also fixed the names of some Leviton devices to make them consistent with the others (removed the .XXX extension).

@chris I’m happy to fix more devices even if I don’t use them. Is it possible to produce a report out of the database showing all devices that have the error. If you post that report here, those of us with too much time on their hands can work on the fixes… :wink:

Just follow the link to the “summary page:grinning:

1 Like

Nice! Thanks.

Thanks Mark (and @sihui).

No errors:


Warnings and errors:
Parameters 3 and 4 descriptions are too long and contain HTML. I made the edits to clear the warnings.

Parameters 5, 6, 7, 8, 9, 10, 11 are too long.
Parameter 255 is all upper case
Endpoint 0, 1, 2, and 3 have no command class.

The descriptions look good. I could move the ranges to the Overview to clear the alert but that seems excessive.

Parameter 255 was edited to clear the all upper case.

I don’t know where to look for the Endpoint errors. I looked for the node.xml and discovered that the XML doesn’t exist. Perhaps that is why this device isn’t working for me right now. This will take some looking on my part. Weirdly it is showing as online but hasn’t reported any data in quite some time (I don’t have anything that depends on this device except for a single chart.

Says there are no channels assigned even though there are user configurable channels. This is a range extender so I’m not sure what sort of channels it would use.

There is one association group not linked to the controller. Is it safe to just edit that for someone who does not know Zwave that well? I don’t know the implication of doint that.

Endpoint 0 has no command class.

Thanks Rich,

Probably it’s safe to ignore these - I guess the main one is “no basic class selected for endpoint X” (or similar). I probably should hide this for some devices as it’s not always applicable.

Yes - quite possibly. If there’s no XML, then it means the device hasn’t initialised fully, and likely means there’s a quirk in the device that we need to work around. The thing to do is to get a debug log of the initialisation to see what’s up.

Agreed - ignore this :wink: .

Yes - it’s highly likely it’s ok - it almost certainly can’t do any harm.

As above, there’s not always a need to link this. Notification sensors for example normally aren’t linked (ie door sensors, smoke, pir etc…). Switches and dimmers it’s important - it means that the “Basic” box in the endpoint isn’t ticked for the BINARY_SWITCH, or MULTILEVEL_SWITCH class.

I’ve found a whole bunch of devices where the thing-id contains the manufacturer name.
I could fix that after 2.2 if you want me to :rofl:

Hi Sihui
It’s probably not worth worrying about unless the thing ids are really long. I’ve seen the database reporting this warning for some GE devices and it’s not such an issue really.

I added that more to remind me to check the thing id when adding new devices as sometimes people write fubaro…

Thanks for the work on this :slight_smile:


That’s fine with me.
I think I catched all the other “value is greater” errors, but I did not touch the “duplicated thing id” because I don’t have all those devices :kissing_heart: and it is not alway obvious which thing id could be deleted or moved to another device.

Ol, thanks for putting the time into this. I hope to do an update tonight if I get some time.


Steinel IS140-2 Motion detector

@nork and @Hoagie are describing errors with this device in the comments of the zwave-device-database.
Perhaps it is better to delete the device from the database.

It would probably be best if someone fixed the channels. I’ve not seen anything that says what’s wrong, just that it doesn’t work…


1 Like

Hi @chris,

I guess, there is an error in the z-wave-database.
2 devices of my z-wave-network from Popp are battery-powered:

  • co-detector 004407 and the
  • smoke-detector 0044001.

Popp 0044007 and Popp 0044001.

I’m using this devices in my z-wave-net. Other devices are using this Popp-devices as a relay.
The new batteries (9V) were empty within one night!
In habmin- things- characteristics the routing is activated. (green hook). Is this correct?

The z-wave-network-viewer (habmin) confirms this guess.
For all I know, battery devices cannot be a z-wave-relay.
Thank you for your support.


Sorry, but I’m not sure what is the error you are reporting? :confused:

If the device is a battery device, then it won’t be used as a relay. Only mains devices are used for routing.

This shows neighbors - not routes. It’s not the same thing and the existence of a link doesn’t mean something is being used for routing.

Yes, this is correct.


I just bought a Nexa AN179 (which seems to be a rebrand of the Everspring AN179), but noticed that there’s an error in the database. Is there anything I can do to correct this?

And will this update be included in the stable version of the binding, or do I need to switch to the development version?


Thanks in advance!