[OBSOLETE] Lock User Management (LUM)

SmartApps & Automations Community Created SmartApps
, , , ,
1638

@maddie

With the User Unlock/Lock app and assume this one, there is the ability to set a notification if an associated door Sensor is left open “Notify if door has been left open”. This works fine however the notification itself states the name of the Lock as opposed to the name of the associated Door Sensor. Not sure how others feel but would not be more relevant and helpful if it actually gave the name of the associated Door Sensor as opposed to the Lock name in the Notification, after all it is the door that is open even though the lock is unlocked. Probably a very easy fix in the app. The same applies to the any other associations and notifications.

Thanks!

1 Like
1639

I programmed on use as a “Start/end date and time” user. The App didn’t save the date properly (it seemed to only save the year and month “2017-05”), so it expired the user. I have properly set the date now “2017-05-28” and time “12:01 AM” , but the App still shows the user as EXPIRED .

How do I fix that?

Also, how do you delete a user?

1641

You’ve set the end date to 2017-05-28 instead of 2018 so it’s showing as expired. Unfortunately ST doesn’t have a date picker yet so users need to enter the date manually for now.

As for a deleting user, just leave the user code input blank.

If you want to keep the user settings/code and temporarily disable the user, select the type “Temporarily disabled”.E.g. you sibling visits and you want to keep her/his code in the app for the future, set it to temporarily disabled.

1642

why would I want lock after closing unchecked? I want it to do that.

1643

I’m having 2 issues with this device and I’m not sure if they’re related. These things started happening after I recently updated both the DTH and related smart apps (Lock User Management and Schlege Lock Alarm Mode and Sensitivity Change and Monitor). They are all current as of about 5/20/18).

The issues are:

1 - I get an error on the DTH just after the Schlege app runs: Contact Developer Is Alarm Sensitivity Not Supported, Mgr 003B-6341-5044. That fingerprint should is for my Camelot deadbolt tied to the DTH and should be supported. After this error the device appears to be unreachable until I perform a refresh, but log messages continue to be generated.

2 - I have 2 time restricted lock code users. Although I am notified that the lock codes were properly removed and re-applied, it doesn’t appear that they are actually registering on the lock (i.e., the physical lock doesn’t have the changes). This is the same lock as the first issue and the timing of the changes are the same - both are mode based. This is why I suspect there may be a cause/effect. One potentially related note: The lock times used to go past midnight (e.g., lock available from 6 am until 1:30 am). I suspected that this may be the problem so I broke those up into two seperate schedules (e.g., 6 - 11:59 and midnight - 1:30). This did not help.

I’ve tried tracing and other debugging techniques to no avail. Please let me know how to proceed.

Thanks…Greg

1644

All your issues seem to stem from the communication issue between your lock and hub. The sensitivity setting warning is being printed because the lock didn’t respond to the alarm setting request. The codes aren’t reaching the lock due the mesh issue, so the engine will try for about 10-15 minutes (you can configure how many times) and then will log an error and stop retrying.

The app supports times past midnight so you don’t need to split your times.

Make sure your lock is within 20ft of a z wave repeater (any mains powered z wave plus device like a switch or a plug). If you don’t have a repeater you should install atleast one repeater between the lock and the hub (requires to create a strong mesh). After adding the repeater do a z-wave repair. You may need to exclude and re pair your lock with the hub if it’s lost it’s connection otherwise a z wave repair with the repeater should fix all your issues.

1645

Interesting - that’s something I didn’t expect. I do have a repeater in the middle (A go control siren) at about 20 feet.

Would the fact that the Schlage notice and the Zwave error are occurring almost instantaneously (based on logs) change this diagnosis?

In the interim I will see if I can identify issues with the mesh.

Thanks…Greg

1646

The opposite, it reinforces it as the Schlage message is a result of the zwave issues. It’s just a log message saying the lock isn’t responding. Someone reported an issue with the siren and the repeater functionality earlier this week somewhere on the forum.

If things are running and suddenly stop, a good rule of thumb is to check the mesh. Reboot the hub, z wave repair, check batteries, repeaters etc. it accounts for 99.9% of issues we see.

1647

Thanks for your help. That fixed it.

1 Like
1648

I just installed a Kwikset Z-wave door lock. With the standard DTH I can lock/unlock from the app with no problems. When I changed it to Rboys DTH I can’t lock/unlock. Changed back to standard DTH and works there. Just won’t work with your DTH.

1649

I ran the mesh repair and I repeatedly get a message that says that the device failed to update the route. I would normally be concerned about that, but since we’re talking a battery powered device, my research shows that they are “sleepy” which can legitimately cause this response even though everything is fine.

Is there any way for me to determine the current mesh routing in my network and the lock’s neighbors? I can test the batteries, but the device shows 97% battery life.

1650

EDIT: Looks like republishing it solved it for you.

You can always use the stock DTH, works just fine with the app.

Probably and an issue with the ST server or a copy/paste issue. Start over and try after a while.

1651

Locks are FLiRS devices, not sleepy. They wake up every few hundred milliseconds to listen for messages. If you’re seeing a route failure, I would recommend rebooting the hub, excluding the lock, pairing it again and then doing a Z-Wave repair.

1 Like
1652

I will do that. Any recommendation for a method to re-pair the lock without taking it off my door to get it within 3 feet of my hub?

1653

Tricky question because it depends on the lock, some can pair through repeaters other needs a direct connection with the hub. I would recommend the following steps:

  1. Try to pair as is from where it is currently
  2. Try to pair after removing your siren device (still need to confirm if that’s causing an issue with the repeating)
  3. Try to add a Monoprice Z-Wave Plus plug or another Z-Wave plus plug near the lock, repair the z-wave mesh and then try to pair it.
  4. Remove the lock and bring it close to the hub or bring the hub close using a portable ethernet to wifi client bridge
1654

Does the Kwikset 912 report the code that was entered? Or just the lock/unlock status.

1655

It reporting just fine here. @lflorack has extensive experience with the 912

1656

Looking at the codeEntered capability. I never get a value here. Is that the wrong one?

1657

No such capability in ST. I think you’re trying to capture the code used when locking/unlocking from the DTH to use in a custom app. That’s a DTH feature, this SmartApp is a consumer of that information.

We’ve published more details on how to capture the usedCode reported by the DTH to ST for use with custom apps here:

1658

Shoot, I’m in the wrong thread again. Moving to the DTH thread.

1 Like