[Depricated] Lock Code Manager

SmartApps & Automations Community Created SmartApps
405

Hello @ethayer, thank you for sharing your awesome code! I was trying to find a way to configure a small number of access codes that will be disabled when we are at home or during specific day/times. I would like to do this to keep ‘services’ out of the house at any time other than when they are allowed in, or to keep relatives from entering the house instead of ringing the doorbell and letting us open the door (having the code doesn’t mean you can just walk in whenever you please… family or not). The first goal is for added security, the latter is just to combat bad habits that won’t go away even with kind reminders.

I am using the “Century Style Schlage Connect Touchscreen Deadbolt” on my front door and really like it. The biggest issue was the pin code management which you have resolved!

Would it be possible to have one or two codes that always work (not affected by schedule or other limitations), and a couple codes that are based on a schedule (plus any other applicable limitation)? An example limitation would be to only allow a code to work if the house is in “Away” mode so relatives cannot enter the house (without being let in) unless we are away (ie: to let the dog out).

I get the impression that the current code sets all users to the same schedule. Is that correct? If so, do I have to install multiple instances to set different schedules for different users?

BTW, the device type I am using was written by @garyd9 (Thank you!!) and was recently updated to support your smartapp.

My lock: http://www.schlage.com/en/home/products/BE469NXCENFFF.html?bck=@@sch-us:brand/schlage@@sch-us:product/deadbolts/touchscreen@@sch-us:product/deadbolts/connectedDevice@@sch-us:product/deadbolts@@sch-us:electronics/zwave

406

Create a new instance of the app.

407

Because of limitations on the scheduling calls, and for simplicity sake… any user(s) whom have different scheduling needs from other users should be initiated and handled by a different instance of the app.

This may change as ST evolves.

408

I migrated over to the new hub yesterday and since then my Kwikset 916, which has been working perfectly, no longer reports the battery level. Anyone else with similar problems?

409

I have a Schlage and occasionally it has helped me to do a battery pull/disconnect/connect and get the right status. Thereafter it works fine.

1 Like
410

Give it time. The poll is ridiculously long on all parameters. Can take a day or so for it to show up. Unless the battery level actually changes.

1 Like
411

Thanks to both of you. I’ll give it until tomorrow and then pull the battery if nothing by then.

412

I am glad you mentioned this! I performed the “nightmare” V2 hub migration yesterday in the AM sans SmartThings support :confounded: and have missing battery status.

The Kwikset SmartCode™ 916 Touchscreen Electronic Deadbolt with HomeConnect™ technology has been included in my V2 Hub network for over 24 hours and as of 3:00 EDT, I have no lock battery status. The tile has a field for the value, but is waiting for a value. I have pressed the refresh button several times still no battery status. Battery status was woking perfectly on V1 hub.

I also notice that SmartThings marketing staff and Kwikset must be feuding because SmartThings UI does not recognize the Kwikset 916 as a supported lock. The 916 is in the family of the Kwikset Zwave 914 which SmartThings does support `> (and “Yes”, I have asked SmartThings support about why they do not have the Kwikset 916 lock listed. Smartthings support provided no response to my requested email…which is typical!)

Luckily the Kwikset SmartCode™ 916 Touchscreen Electronic Deadbolt with HomeConnect™ will emit a short alert tone after each open and close when the battery level is less than ~40%. According to Kwikset technical documents, based on 10 operations per day, a single, new set of Alkaline batteries will operate the lock for over a year.

I am using @ethayer 's “Zwave Lock Reporting” device type with capability “Battery” which was working perfectly in V1:

valueTile("battery", "device.battery", inactiveLabel: false, decoration: "flat") {
  state "battery", label:'${currentValue}% battery', unit:""

// Only check lock state if it changed recently or we haven't had an update in an hour
def latest = device.currentState("lock")?.date?.time
if (!latest || !secondsPast(latest, 6 * 60) || secondsPast(state.lastPoll, 55 * 60)) {
  cmds << secure(zwave.doorLockV1.doorLockOperationGet())
  state.lastPoll = (new Date()).time
} else if (!state.MSR) {
  cmds << zwave.manufacturerSpecificV1.manufacturerSpecificGet().format()
} else if (!state.fw) {
  cmds << zwave.versionV1.versionGet().format()
} else if (!state.codes) {
  state.pollCode = 1
  cmds << secure(zwave.userCodeV1.usersNumberGet())
} else if (state.pollCode && state.pollCode <= state.codes) {
  cmds << requestCode(state.pollCode)
} else if (!state.lastbatt || (new Date().time) - state.lastbatt > 53*60*60*1000) {
  cmds << secure(zwave.batteryV1.batteryGet())
} else if (!state.enc) {
  encryptCodes()
  state.enc = 1

IMG_1337.jpg750×1334 92.8 KB

413

I’ve updated the device driver to the latest SmartThings release. Update your device type code accordingly.

You lucky lucky peoples. Still waiting for my hub.

414

Erik,

What changes did you make to the driver? (Just as an FTY)

415

Thanks Erik, just did that!

Is the only difference between your custom “Z-Wave Lock Reporting” device handler and ST’s “Z-Wave Lock” device handler is the call to:

reportAllCodes(state)

Just trying to see why the “Lock Battery Status” would not post in the new V2?

416

I made no changes. The changes were made by SmartThings. I did not analyze their changes, I simply merged them.

A summary of the changes can be found here:

@kurtsanders - Yes, that is the only change in the device driver from the default, coupled with the function itself.

def reportAllCodes(state) {
  def map = [ name: "reportAllCodes", data: [:], displayed: false, isStateChange: false, type: "physical" ]
  state.each { entry ->
    //iterate through all the state entries and add them to the event data to be handled by application event handlers
    if ( entry.key ==~ /^code\d{1,}/ && entry.value.startsWith("~") ) {
      map.data.put(entry.key, decrypt(entry.value))
    } else {
      map.data.put(entry.key, entry.value)
    }
  }
  sendEvent(map)
}

Note, this is not a change from previous versions of Lock Code Manager.

417

Thanks Erik for the confirmation. Your mods look fine.

I’m still scratching my head why the lock’s battery status does not report to the ST Tile from the device’s function calls. I see that the ST Developer only periodically checks and report the lock battery status based on last time checked, perhaps to save battery life with too many poll checks? Who knows?

Any thoughts on the missing battery status before I submit to ST Support?

418

No idea. My first inkling is a bug with the v2 hub? I’m still on v1 and it’s still working fine.

419

Ah, didn’t realize this was an update to bring your driver in sync. Sorry about that!

420

Add this “deficiency” to the growing list of V2 bugs that will hopefully be resolved in the next firmware update…

So much for the “IT Quality Assurance” department catching these before launch…

1 Like
421

Erik,

@ethayer I am on V2 and it is working great- went to V2 on Friday. Battery status 78%

423

Still a no-go for me

424

I wonder if it’s just that the battery only reports on change.

Try removing the battery and putting it back in. If it’s not accessible, see if it populates in a few days.

425

I removed the batteries and when that didn’t work, I put new batteries in. I’ll give it some more time.