Yale Smart living Keyless lock

I own one of these locks

http://www.vesternet.com/yale-smart-living-keyless-connected-smart-lock

it is included in the indigo with these device info.

Code: Select all

   Z-Wave                          Indigo Device "015 - Skur Lås" Z-Wave Properties:
Indigo Z-Wave Version: 2.0.91
Node ID: 15
Model: Keyfree Connected Lock
Model ID: 00060000
Manufacturer: Yale
Manufacturer ID: 0129
Protocol Version: 3.34
Application Version: 17.32
Model Definition Version: 0
Library Type: 3
Class Name: Keypad Door Lock
Class Hierarchy: 04 : 40 : 03
Command Class Base: 62
Command Versions: 80v1 85v1 86v1 8Av1 8Bv1 4Cv1 4Ev1 98v1 20v1 62v1 63v1 70v1 71v1 72v1 75v1
Encryption Status: Enabled for Commands 80 85 86 8A 8B 4C 4E 98 62 63 70 71 72 75
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, security, frequentWaking
Neighbors: 4, 7, 13
Associations: 1:[1]
Config Values: - none -


The battery status always shows 10 % . is there anything to do about this ? (new batteries is installed)

I use the z-wave lock manager plugin which give me chance to send pin codes to the lock etc.

-Allan

[matt (support)]

Sending a status request doesn't update it? Sounds like it is a marginal unit or has a firmware bug. You could turn on Indigo's Z-Wave Debugging checkbox via the Interfaces->Z-Wave->Configure... menu item so we can see exactly what the module is sending. First choose the Interfaces->Z-Wave->Reload menu item, then turn on debugging, then send the module a status request. That should force Indigo to query the battery level from the module. Copy/Paste the Event Log window results into a reply for me.

Code: Select all

  Z-Wave Debug                    RCVD requestMeterLevel: 01 10 00 04 00 04 0A 32 02 21 34 00 00 00 00 00 00 C0
   Z-Wave Debug                    . .  requestMeterLevel: node 004, endpoint None, meterType 01, raw value 3400...
   Z-Wave Debug                    . .  requestMeterLevel: 0.0 W (float: 0.000000)
   Z-Wave Debug                    RCVD requestMeterLevel: 01 10 00 04 00 19 0A 32 02 21 34 00 00 00 09 00 00 D4
   Z-Wave Debug                    . .  requestMeterLevel: node 025, endpoint None, meterType 01, raw value 3400...
   Z-Wave Debug                    . .  requestMeterLevel: 0.9 W (float: 0.900000)
   Z-Wave Debug                    SENT nonceRequest: 01 09 00 13 0F 02 98 40 25 FA EF
   Z-Wave Debug                    RCVD nonceReport: node 015, nonce BB 82 64 38 8D 19 22 D6
   Z-Wave Debug                    SENT requestLockStatus1: 62 02 (encrypted)
   Z-Wave                          sent "015 - Skur Lås" status request
   Z-Wave Debug                    SENT nonceRequest: 01 09 00 13 0F 02 98 40 25 FC E9
   Z-Wave Debug                    . .  nonceRequest: requeuing 1 unsolicited packets
   Z-Wave Debug                    RCVD nonceFetch: node 015
   Z-Wave Debug                    SENT nonceReport: 01 11 00 13 0F 0A 98 80 D2 1B 58 B8 EE 15 40 C1 25 FD 6B
   Z-Wave Debug                    . .  nonceReport: requeuing 1 unsolicited packets
   Z-Wave Debug                    RCVD nonceFetch: node 015
   Z-Wave Debug                    SENT nonceReport: 01 11 00 13 0F 0A 98 80 D2 1B 58 B8 EE 15 40 C1 25 FE 68
   Z-Wave Debug                    . .  nonceReport: requeuing 1 unsolicited packets
   Z-Wave Debug                    RCVD encryptedPacket: 00 62 03 FF 00 00 FE C2 (decrypted)
   Z-Wave Debug                    RCVD requestLockStatus1: 01 0D 00 04 00 0F 07 62 03 FF 00 00 FE C2 FF
   Z-Wave Debug                    . .  requestLockStatus1: node 015, endpoint None, value 255
   Z-Wave Lock Manager             Status: Door is locked [Node: 15]
   Z-Wave Lock Manager             Latch open, Bolt locked, Door open [Node: 15]
   Z-Wave Debug                    reusing outgoing nonce D2 1B 58 B8 EE 15 40 C1
   Z-Wave Debug                    RCVD encryptedPacket: 00 62 03 FF 00 00 FE C2 (decrypted)
   Z-Wave Debug                    RCVD requestLockStatus1: 01 0D 00 04 00 0F 07 62 03 FF 00 00 FE C2 FF
   Z-Wave Debug                    . .  requestLockStatus1: node 015, endpoint None, value 255
   Z-Wave Lock Manager             Status: Door is locked [Node: 15]
   Z-Wave Lock Manager             Latch open, Bolt locked, Door open [Node: 15]
   Z-Wave Error                    no nonce reply (015) for requestBatteryLevel (re-sending)
   Z-Wave Debug                    SENT nonceRequest: 01 09 00 13 0F 02 98 40 25 FF EA
   Z-Wave Debug                    RCVD nonceReport: node 015, nonce 87 17 E4 9C 03 38 80 3E
   Z-Wave Debug                    SENT requestBatteryLevel: 80 02 (encrypted)
   Z-Wave Debug                    RCVD nonceFetch: node 015
   Z-Wave Debug                    SENT nonceReport: 01 11 00 13 0F 0A 98 80 E0 7D 34 CA 41 13 45 80 25 02 33
   Z-Wave Debug                    . .  nonceReport: requeuing 1 unsolicited packets
   Z-Wave Debug                    RCVD encryptedPacket: 00 80 03 0A (decrypted)
   Z-Wave Debug                    RCVD requestBatteryLevel: 01 09 00 04 00 0F 03 80 03 0A FF
   Z-Wave Debug                    . .  requestBatteryLevel: node 015, level 10
   Z-Wave                          received "015 - Skur Lås" status update battery level 10%

Here it is

[matt (support)]

That is showing the module is indeed sending back to Indigo that the battery level is 10%. I'm not sure why it is sending the wrong thing, but I can say that several modules have poor implementations of determining how much battery level is left. I don't know if this is just a bad implementation on Yale's part or if you have a malfunctioning module.

That is showing the module is indeed sending back to Indigo that the battery level is 10%. I'm not sure why it is sending the wrong thing, but I can say that several modules have poor implementations of determining how much battery level is left. I don't know if this is just a bad implementation on Yale's part or if you have a malfunctioning module.

dont think it is the module because I have another yale lock not same model/type but have switched module before between the two locks still same so think it must be yale that have some issues.

and the other lock appears to be more accurate.

That is showing the module is indeed sending back to Indigo that the battery level is 10%. I'm not sure why it is sending the wrong thing, but I can say that several modules have poor implementations of determining how much battery level is left. I don't know if this is just a bad implementation on Yale's part or if you have a malfunctioning module.

dont think it is the module because I have another yale lock not same model/type but have switched module before between the two locks still same so think it must be yale that have some issues.

and the other lock appears to be more accurate.

I am investigating purchasing this lock myself. I came across the thread below on the SmartThings forum:

https://community.smartthings.com/t/yal ... ries/52107

It appears to be a problem with a batch of locks, as one user found that the device was constantly sending out its battery level as 10%, and someone else reported that after pestering Yale for a while, they dispatched a new lock that did not have the same issue.

Sounds Great I will try with vesternet where I bought it when it first came out.