The binding doesn’t do the inclusion - this is done by the stick (ie the controller). The binding only does the interrogation, which happens after a device is included into the network.
If a device isn’t being included, I’m not sure why that would be as the binding doesn’t do much except send a simple command to the stick to put it into inclusion mode. This has been a standard command, using the standard Z-Wave Serial API, for a long long time so I’d be surprised if it’s now broken.
That’s not really the issue - I don’t “prefer” to use the database - it was the only option. The issue is that when the binding was written, the only way to generate channels was through the XML files. This mean that there was no option other than to use the database. Since then, OH has the ability to create channels programmatically - this is what I do in the ZigBee binding, but to rewrite the Z-Wave binding to do this is an awful lot of work.
Me too. Wish I had any sort of sensible explanation.
Well, some more interesting results… The OZWCP crash was my own stupidity in not running it as a user who you manipulate the z-stick (duh!), but adding the device via OZWCP didn’t work either.
Zooz support got back to me with a firmware update, but since I do not have a Windows computer I cannot apply it. Instead, they are going to cross-ship me some replacements with the firmware already updated.
Thanks Bruce. This works.
FYI, I received this error at startup:
---- Debugging information ----
message : The URI 'thing-type:zwave:thermofloor_z smoke_00_000' in node 'config-description' is invalid!
cause-exception : java.net.URISyntaxException
cause-message : Illegal character in opaque part at index 30: thing-type:zwave:thermofloor_z smoke_00_000
class : org.openhab.core.config.core.ConfigDescription
required-type : org.openhab.core.config.core.ConfigDescription
converter-type : org.openhab.core.config.xml.ConfigDescriptionConverter
path : /thing-descriptions/thing-type/config-description
line number : 71
class[1] : java.util.ArrayList
required-type[1] : java.util.ArrayList
converter-type[1] : com.thoughtworks.xstream.converters.collections.CollectionConverter
class[2] : org.openhab.core.thing.xml.internal.ThingTypeXmlResult
required-type[2] : org.openhab.core.thing.xml.internal.ThingTypeXmlResult
converter-type[2] : org.openhab.core.thing.xml.internal.ThingTypeConverter
class[3] : org.openhab.core.thing.xml.internal.ThingDescriptionList
required-type[3] : org.openhab.core.thing.xml.internal.ThingDescriptionList
converter-type[3] : org.openhab.core.thing.xml.internal.ThingDescriptionConverter
version : 1.4.13
I saw that error once too before making the changes. That does bear more investigation.
It appears there may be an error in one of the database xml files.
Chris never a criticism and I do not see the way the binding works as an issue. The database has a huge advantages beyond the fact it was not easy when the binding was first built. I love the level of annotation on the properties screens that is well beyond what you get without the database.
Most of the issue reported on this site are people adding devices that are not yet in the database or where there is an issue with communication with the module. The majority of the issues I see are the latter and nothing to do with the binding.
You can spot the ones with communication issues as they have XML with corrupt data for example a bad company id or even no xml. This must be the coms between the controller and the device and nothing to do with the binding as the file is only showing what the controller delivered or did not deliver.
If a module that is in the database does not add it is very rare it is an issue with the entry unless it is a new type of device.
The cause will most likely be:
The easiest way to troubleshoot these is a zniffer but if you do not have one you can get a lot from the logs.
Start by checking for a current device that is spamming your network or any current device that is having to retry when sent messages. Fix these issues before trying to add a device to the network. It is not easy to add devices to a busy or poor network.
The next thing to do is just make sure the device is in range which is hard to do without a zniffer but common sense sometimes works but RF and particularly z-wave RF can be strange.
Sadly, beyond that you need a zniffer. I have identified modules with bad RF circuits and devices from some manufacturers that are just not compliant to the standards.
In summary I have never found the binding to be an issue adding devices. I rebuilt my network earlier this year taking advantage of the remote openHAB capability to split it into several parts for better performance. I added over 180 devices in a day and only had one issue. A module with a bad RF circuit that was transmitting at 25% power. Not exactly a binding issue.
Don’t get me wrong - I didn’t take it as a criticism. I was just pointing out the issue. I fully agree with your point that it’s a better approach - or in fact that a combination of XML files and auto detection is the best. This is what the ZigBee binding does - it means everything works nicely with most new devices without a binding change, but it allows for the inevitable workaround 
.
If OH had have had that feature at the beginning, I would have used it in the ZWave binding - sadly it didn’t so there was limited option.
Just read this again,. Is there any chance you are generating a lot of traffic with OH so the reason OZWCP worked is the network was not busy as OH was not running? Polling interval or rules firing on the basis of sensor changes causing traffic?
Amount of traffic is also relative. A few many hop message is sometimes more than many direct in terms of impact.
They both need exclusive use of the USB stick. When I was using HA with their OZW addon there was the same issue.HA has to be stopped before using OZWCP.
Not what I was getting at. OZWCP would have no code to react to any reports and possibly was not polling anything. OH might have lots of polling configured and lots of code sending messages to devices in response to reports.
The interface will go quiet while stick is in add mode but messages build up and then when the device tries to initialise lots and lots of traffic as the configuration is read by get version, get association, set association etc. alongside any queued messages.
That’s an interesting theory and may have some merit. This was during a period when I was doing a massive upgrade and added 25+ devices (both battery and mains powered) over a period of a few short weeks. I don’t have any way of testing this now.
I will say two things make me lean towards this not being the case. First. I was able to add several other battery operated devices during this time. Each time I successfully added another battery device, I’d go back and try one of the ones the kept failing in the hopes that 1) something had cleared up or 2) I would stop being an idiot and add the troublesome device correctly, but never any luck. Second, I’ve never seen significant or consistent lag in my z-wave network. Before my upgrade I’d see a delay very occasionally from one or two nodes behind the most walls, but after all the additional nodes, my network’s been rock solid.
On the other hand the few devices I’ve added since have gone flawlessly through the OH interface, but then again, I’ve not tried adding additional devices of the same type as the two models that were giving me difficulty.
Sometimes after adding a Thing to OH I have found deleting the Thing and Scanning / Adding it back sometimes helps with discovery.
It is truly strange because the binding does the same as OZW. Tell the controller to go into inclusion mode and then interrogate the devices by calling the same API calls. It is all very standard.
The only difference might be timeout settings but you would spot timeouts in the log.
@chris is there a plan on the roadmap to allow for updating the database via an xml upload into OH, or a file drop? Or could there be a button in OH to allow the addon to pull the latest database from a remote server? Is it even technically feasible?
I already asked about the binding updating the database. In the short term it is not possible but I am sure he would consider a PR if somebody submitted one.
The database was written at a time when OH required all Thing Channel definitions in the binding. It was also based largely on reverse engineering device behaviour.
The binding does need to be rewritten based on the specification but, along with his busyness, the developer is waiting for the official 700 Series serial standard to be publicly released. It was due last year but still has not happened. @chris is in contact with the zwave alliance about that release.