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?
I always do the inclusions the same way. I go to Things, click on the + sign, choose the Z-wave binding, click on SCAN and then press the button or the paddle or whatever the manufacturer says
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.
First
Should I enter 90 for the manufacturer and how do I transform 0811:23A8 into a number in digital format?
Second:
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.
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.
