Keep waking it up, it is battery powered, it may take a lot of tries. If you are trying to include it using security, (which since it is a lock, I’m assuming you are) that takes even longer then a normal battery device. How close is it to the controller?
There is one other possibility. Does the UI page show 5 lines at the bottom
If yes, check the MFG & TYPE:ID pair with the Zwave DB for the device. It will be under the Thing properties tab. Yours could be different and need to be added. Some of the properties are in Hex and some in decimal, so make sure to watch that.
Should I enter 90 for the manufacturer and how do I transform 0811:23A8 into a number in digital format?
The thing properties are grayed out in the UI, I assume there is an XML file somewhere that can be modified, do you know where that is?, or is there another way to change the properties values?
Hi I tried that, played with the lock, opening and closing it and adding lock codes for about 1 hr and then leaving it overnight and nothing
I think it is a database issue
This device has not been fully discovered by the binding. There are a few possible reasons for this -:
The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like “Z-Wave node 1 (0082:6015:020D::2.0)”). Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed.
My lock device shows in the same format as that shown in the explanation Z-Wave node xx (0082:6015:020D::2.0)
Since the device properties have been discovered, communications with the device looks fine and this device is in the database so there ought to be channels showing…
Continually “waking up” a lock won’t help since it is basically always awake. Locks are what’s called FLiRS devices - these wake up themselves periodically - it can be 1 or 10 times per second - to allow communications to occur without waking the device up.
This is fine, but do you perform a hard reset on the lock before doing this? Locks can only be included into the network if they are hard reset since the key exchange protocol can only take place within 15 seconds of them joining the network.
Also, when you join the device, don’t do it too soon after starting the system as the network may be busy and this can slow things down if it needs to talk to other devices, and it can push the key exchange out past the 15 seconds. Once this happens, you need to reset the device and start again.
Also in the properties, does it show that the device is securely included?
Properties can’t be changed - they are set by the binding.
No - you can’t change them. They are just properties that give the user information from the binding and changing them will do nothing.
Based on the above, and the fact that your device IDs seem to have been discovered and are consistent with the database, I don’t think so.
My guess is it’s related to the secure join and the restrictions on the timing I mention above. You can also get a debug log to see what’s happening - this should show if the key exchange works ok or not.
Well, he said above that his properties were the same -:
These values come from reading the information from the device (and can’t easily be manipulated by the user), and are correct for this device. Admittedly this doesn’t include the device id which is the third component, but 2 out of 3 values are being correctly read from the device and are consistent with the values in the database.
Sorry - I missed this point. I prefer not to change things here as it potentially then changes everyone UID on their devices and will break peoples systems. We could just change the name that people see and leave the UID and Black and Decker, but that is then inconsistent and will likely cause further confusion. IMHO it’s best just left alone - at least it’s consistent in OH and doesn’t break peoples systems - even if it’s changed and now not consistent with the ZWave definition.
And that might be the problem here:
I cannot find any indication that a 0090:0811:23A8 even exists. The Z-Wave Alliance tells us that there are 0090:0811:03A8 and 0090:0811:13A8, but I cannot find a 0090:0811:23A8 in their database.
We either have a thing type UID that doesn’t match the name, or a name that doesn’t match what the ZWave Alliance now calls the company. Ideally, the UID used for the company would be aligned with the name of the company - that’s not always the case, but something we try and do to avoid people getting confused.
Anyway, for now I don’t propose to change the UID or the name in the database.
I don’t really understand what you’re trying to show here though with this image? The thing type UID is made up of two parts - the part that is listed at the bottom of the device entry, and then another part that comes from the manufacturer entry in the database.
If we take your example of the NAS-PD07Z, then in that devices entry, we see -:
I agree - this doesn’t change.
However we also have another part that comes from the manufacturer, so the full thing type UID is shenzhen_naspd07z_00_000. This is made up of the manufacturer name, the device UID, and the version.