I tried deleting (without removing from the network) and re-added. Same result.
I tried deleting AND excluding and then re-added. Same result.
I tried deleting, excluding, factory resetting, then re-added. Same result.
I checked the “Range Test” on the device and regardless of whether I am right next to my OpenHAB Z-Stick or anywhere else in the house it shows “Red” which is supposed to mean it cannot reach the Z-Wave hub directly or indirectly (through repeaters).
I’m stumped. Still waiting to hear back from Zooz as well.
More generically, what is the step by step process for updating to the snapshot binding in OH3? The script referenced earlier in this thread does not work with OH3.
So at the moment, is there a way to get updates to the zwave device database in OH3? I just bought a whole bunch of 700 series zooz devices that don’t seem to be in the release version of the database but I believe were added recently
Not only that 3.1.0 binding had a broken database. I recently added Zooz ZEN73 and am working on ZEN74.
I spent the last week helping Chris get OH 2.5 binding snapshots working & tested. I might be able to update a 3.0.x binding jar file with the updated database but it would be unofficial. I tested it with 2.5.x based off a script here in the community.
I have not seen this strange frozen inclusion status in a ZEN34 (I have successfully added these devices to my own network), but this sounds very much like the behavior reported in a few other devices (e.g., here and here). If you check out your z-wave logs debug while you are waking up the device, I expect you’ll see no wake-up signal at all. If that’s the case and then this is a similar situation and somehow during the inclusion process the device gets stuck in a state where it can no longer communicate with the controller so no amount of waking up will finish the inclusion process and a factory reset is the only method to get the device back out of this state.
With the three devices I had that suffered this issue, I could never get them included via the binding with many attempts and dozens of wake-ups. I resorted to open z-wave control panel and they all included on the first try only needing a single wake-up. After they were included using ozwcp they have functioned in OH 100%. I am aware of the discussion currently gong on here, but can only report my own experience. Ozwcp worked immediately, where OH could not after weeks of troubleshooting.
That is the downside of the database but there are upsides also. I know it does not normally take that long to get it in a release. OZW just uses what the device reports. The binding makes the same calls but prefers the database over the reported capability.
Nope, no way it was a database issue. It was 100% a inclusion issue. All three devices were in the database (one was a device that had been working with a previous install of OH2 for nearly a year). As soon as ozwcp handled the inclusion, the binding recognized and properly added the things because they were in the database, the binding just could not do the inclusion.
I filed a github issue and had a brief discussion with Chris that ended with him closing the issue. NOT blaming him; this is on me and not him. He gets enough issue false positives that he is 100% in the right to have high burden of proof standards. This is on me not him, I just don’t know what’s going on under the hood well enough to find the smoking gun evidence I need to convince him.
Yeah, sorry. I can’t help with that other than to say make sure you 1) stop OH first or ozwcp can’t access the device, 2) two have selected the correct device in the dropdown at the top of the page, and 3) make sure the user running it has dialout privileges.
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.
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.
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:
Bad communication.
Bad device.
A device that is just hard to add as it does not take part in the conversation exactly as it should.
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.
