Lock status bug in Smarthings mobile app?

Hi, SmartThinge newbie here. Just finishing up my migration from Vera. Went as well as could be expected, but I’m seeing something weird with my Schlage BE369 lock. In the new SmartThings app (Android) the lock status always seems to show the unlocked state. However, if I go to the IDE and check the lock there it has the correct state and correctly changes it as I lock/unlock the door. Automation notifications also work. The lock responds to unlock commands. SmartThings Classic (Android) also shows the correct status. Is this a known bug? I tried a few different device handlers for the lock, but that didn’t fix it (and seems to me that the device handlers were working if the status in IDE shows correctly).

The new app does not support customer DTH yet. Stick to classic.

1 Like

If you’re using a custom handler for the lock, it needs to be renamed to the exact same as the default handler “Z-wave lock” in order to work with Smart Locks.

1 Like

I was mostly trying standard handlers. I was using the default handler that it picked for the lock, which was Danalock. I tried changing that to “Z-wave lock”, and then “Z-wave lock with codes”, and then tried one of the custom ones. I always left the name as Danalock. Should I try changing that?

You’re saying the DTH needs to be renamed or the device? You’re not completely clear on that and I think that’s what’s causing some confusion.

What I’m saying is that I left the field called “Name” with the default it chose when I added the lock (this was Danalock). The field “Type” was also Danalock originally, but I then changed this to the other ones I mentioned (but never changed the “Name” field to match … always left it as Danalock).

Depends on the DTH, the DTH needs to be designed to work with SmartLocks.

If it’s designed to work with SmartLocks, then the next step to get Real Time updates is that you need to change the name.

I think you’re referring to this post right?

1 Like

If you’re seeing the correct state in the IDE then it’s a ST App display issue. As @Ryan780 mentioned, you can’t use custom DTH’s with the new SmartThings apps.
If you’re using the new SmartThings app you need to use the stock “Z-Wave Lock” Device Handler (not the z-wave lock with codes).

If it still doesn’t display the correct state, basically the push connection to the ST server is broken. Try to reboot your phone or reinstall the SmartThings app. If it still doesn’t work report it to ST support.

Meanwhile the Classic app is still your best friend and you can use custom DTH’s with it.

1 Like

sorry, device handler itself needs to be re-named as Rboy linked to.

1 Like

Thanks everyone, it’s now working :slight_smile:
I’m not sure exactly what did it, but I did the following things and it now works properly:

  1. set name and type fields to Z-wave lock
  2. reboot phone
1 Like

Does anyone know if this solution would work for my Schlag BE468 CAM605 lock? The symptom is different, but I am desperate for a solution. The lock had for over a year (& almost flawlessly) auto unlocked via the ST presence sensor & through smartthings classic “I’m back” routine. I also have it set up to auto lock after shutting the door. A few months ago (and out of the blue) the lock just stopped auto unlocking and has not auto unlocked since. Everything else seems to work fine on the lock and I can unlock it manually through the ST classic App but the “I’m back” auto unlock will not work at all! I have tried taking the lock out of the routine and then added it back and still nothing (even though the app says it is supposed to open). Any feedback that anyone may have on this matter would be greatly appreciated… Help!

is the presence sensor updating correctly?

When you run the routine manually does it unlock?

Thanks for asking. Yes… the lock unlocks when I run the I’m back routine manually.

In that case the routine is timing out. It’s a platform load issue. Do you have anything else configured in the routine?

Set SHMonitor to disarm and change mode to home is all. See attached screenshot

I suspect one of these action is timing out and causing the rest to stop executing. This is actually a fairly common issue with ST routines. We’ve published this app to counter this issue on popular demand - [RELEASE] Routines Backup - Verify/double check your routine execution, notify and take actions

One way to test it to remove the other actions till you figure out which action is timing out.

When a presence sensors arrives it triggers a lot of event internally and sometimes it has an effect of timing out of if there’s a bug in the ST platform if one action fails the other also fail. You can verify this by opening your IDE Live logging and then “arrive” and see if the actions execute of it’s throwing an error in the logs.

If I install the routines backup, do I have to still " remove the other actions till you figure out which action is timing out"? Is this actually a back up program or does it just “double check” that the routine was performed (or both)?

You don’t need to remove the other items. It double checks all configured actions.