You can find this in the posts above but I’ll explain how isolate the source. You will need to get the raw event data from the IDE (click on My Devices -> Lock name -> List Events -> click on the first column date/time for each event you want to analyze)
- If the event was initiated by the ST Mobile app, under Event Source it will say
- If the event was initiated by a SmartApp the device, under Event Source it will say
- If the event source says
DEVICE that means the lock initiated the event (many reasons for this you can find the posts above like a bad battery, sensitive/faulty sensors, misalignment, auto lock etc)
- It could be a platform ghost event (very rare and usually happens with the platform has an outage)
It says device. Not sure how to proceed…
I have a Schlage BE469. It shows as a smoke alarm. I know it has a configurable intrusion alarm, but why does it show as a smoke alarm as well?
I have been having a very strange issue lately that I’ve partially resolved but unfortunately my solution was not a great one. One of my Schlage BE469’s has been having control and reporting issues. I have a fairly significant z-wave mesh with multiple GE switches within about 3 feet of the lock. When I send a lock/unlock commands to this lock it can take minutes for it to respond and in many cases it never does. Likewise, I have messages being pushed every time the lock is locked or unlocked. Up to a few weeks ago this worked flawlessly. Now it barely reports at all. My other two BE469’s seem to be working better, but not as good as they used to.
I removed the lock from Smartthings and did a full reset of the lock. I verified that none of my codes worked to ensure that the reset worked. I then did the code wipe on the lock before I re-added it to my Smartthings. My problem persisted. Using your diagnostic advise on reviewing the device events I noticed some oddities. In the log I was seeing “Source: Device, Name: lockStatus, Value: Alarm off | Battery 100%…” which was showing up every 5 to 10 seconds for large chunks of time. This would go on for over an hour. I checked my other locks and they were showing from 2 to 4 of these messages each separated by anywhere from 5 seconds to 10 minutes in chunks of two. Then the next set would be an hour later and show similar repeat messages.
To try to diagnose this I changed the Device Handler to the one generic Z-wave Lock with Codes for the one door that was the worst and it is working perfectly again. My control is worked every time within 2 to 15 seconds. Likewise, my reporting for manual operation is doing the same in 2 to 15 seconds. Looking at the events it appears that it is doing a COMMAND poll every 6 minutes and the only DEVICE messages are when I’m locking/unlocking the door. I’d be ok with this but my WebCore piston is reporting “null” for the CodeName in my messages. I’m assuming this is because the built in device handler can not handle the CodeName like the Rboy handler? I have not tried to reprogram any of the codes on this door since changing the handler so I’m not sure if that works or not with the built in handler
Any thoughts on what might be handling. Initially I thought it was a mesh issue but changing the device handler seemed resolve the issue. I also thought it was a bad z-wave module in the lock but again, changing the handler seemed to resolve the issue. I’m not saying it isn’t a mesh issue and that the lock was “talking” too much to be able to communicate well with the app, but I’m not sure why changing the handler would resolve that. I also can not remember if I updated the Rboy handler around the time that my issue started. It is possible I jumped a few versions around the same time it started misbehaving.
I believe what you’re experience are differences related to the cloud vs local handlers. The stock DH runs locally where as the custom DTH runs in the cloud which has dependencies on the internet and platform speeds. If the internet latency is running high/dropping packets or if the platform is experiencing high latency it can interfere with the z-wave commands (they may timeout, get delayed etc). It helps to reboot the hub and the internet modem/router. You can’t do anything about the platform other than report it to ST or see if there’s any outage.
IMPORTANT: REQUIRED UPDATE FOR UPCOMING FIRMWARE 25.x for V2 and V3 hubs
This update is required to continue receiving lock/user usage notifications once ST deploys the 25.x firmware to the hubs (this update is backwards compatible with 24.x and older firmware)
Universal Enhanced Z-Wave Lock for Schlage, Yale, Kwikset, IDLock, DanaLock, August Pro, Samsung, Locstar, Delaney, KeyWe and Popp Z-Wave Keypad Device Handler - Version 04.03.01
- Support for upcoming 25.x firmware z-wave framework user/lock notifications
- Improved compatibility with SmartLocks
Schlage Lock Alarm Mode and Sensitivity Change and Monitor - Version 02.02.00
A SmartApp like Lock User Management (LUM) or SmartLocks is required for programming user codes.
This Device Handler has been tested and verified and optimized on the following lock models:
- Yale Z-Wave locks (Assa Abloy, YRD2xx, YRD4xx, YRL2xx, YRC2xx, B1L, T1L, Keyfree, Assure, Conexis, Touchscreen, Deadbolt, RealLiving, nexTouch)
- Schlage Z-Wave locks (FE469, BE469, BE468, FE599, BE369)
- Kwikset Z-Wave locks (910, 912, 914, 916)
- DanaLock Z-Wave locks (V2/V3)
- August Pro Z-Wave locks
- IDLock Z-Wave locks (101/150)
- Samsung Z-Wave locks (SHP-xxx, SHS-xxx)
- Delaney (ZWxxx)
- Locstar Z-Wave locks
- Monoprice Z-Wave locks
- KeyWe Z-Wave locks
- Popp Z-Wave keypad
Key features include automatic discovery of lock features:
- Privacy/keypad control
- Audio control
- One touch/Lock n leave
- Alarm mode
- Alarm sensitivity
- DPS/Door sense
- Fire/smoke alarm
- Tamper/motion alerts
- Emergency alerts (police/fire)
- Battery life optimization
- Configuration of one time parameters
Yale -> relock timeout, wrong code reporting limit, volume level and dps
Danalock ->turn speed, brake n go, turn n go and relock timeout
IDLock -> volume level, unopened relock
- Enhanced programming communication for a weak mesh
If you’re looking to capture specific events (e.g. invalid codes) and create custom actions/rules refer to this post.
Copyright © RBoy Apps
Not sure what’s happening but I excluded my Schlage lock but when I try to add it again it shows the three green checks but the lock never appears on the SmartThings classic app.
I updated, but my BE469 lost all tiles associated with sound, autolock, etc. The only tiles are Lock, Unlock, and battery (which seems to be wrong).
Sounds like your lock is using/reverted the stock DTH and not the custom DTH.
Nope. Checked and verified that I’m using the new app. Anything else to try?
I was seeing the same thing, I ended up removing completely using exclusion process to try to pair it again. Unfortunately now the lock doesn’t show up on SmartThings classic app even though the lock sometimes shows join event on backend. I also tried to manually add (with universal rboy dth) using the device network id in the join event but I’m back to the screen you’re seeing and can’t control lock.
Any ideas @RBoy
the SmartThings platform has gone to
Blank tiles on the BE469 means your lock is having trouble communicating with the mesh and the hub (the responses aren’t reaching the hub or vice versa)
Tap the refresh tile at the bottom of the page a couple of times. If you don’t see any tiles show up then try to reboot your hub, add a repeater within 20ft of the lock and do a Z-Wave repair. Some folks have been seeing issues with the network/cloud latency in the past few days causing timeouts/delays, usually rebooting the internet modem and hub helps reduce the latency but if the ST server is running slow not much you can do other than report it to ST to investigate.
EDIT: You may also want to open the IDE and check under My Devices -> Click on your lock -> MSR, if that’s blank, incorrect or corrupted it can explain why the tiles disappeared. Your IDE Live Logs will show unknown MSR when you tap refresh. One person had a similar issue recently where this information was corrupted which was causing issues. You will need to exclude the lock and re pair it again to fix the corruption.
Does it make sense that my Monoprice Z-Wave lock is showing up as Yale?
I seem to be having the same issue with ONE of my Schlage locks. (100% positive DH is installed on both - both now show ‘Cloud’ in the IDE)
Front door only shows Lock, Unlock, Battery
Back door shows all - appears to be working as expected.
Front door - Replaced batteries. Rebooted hub. Did a Z-wave repair. No luck
The back door lock is located about 8ft away from the hub.
The front door lock is located about 30ft away. (but not many obstructions/walls)
Looking in the IDE, I noticed something odd. I thought that the two locks were identical, but according to what I see in the lock Data, there’s a difference.
Back door (working):
Front door (not working)
So there appears to be a firmware difference, but also one shows “endpoint” and the other shows “manufactuer”. Why?
Is there a way to update the firmware on these?
I’ve picked out a wall outlet Z-wave extender to put by the front door if there’s nothing else to try.
Yale Z-Wave locks are on sale for $149 to $199 on Amazon and ZWaveProducts if anyone is interested:
I have the August Lock Pro and I’m not using the Door Sense. I have DPS turned off but my lock is reporting has open. How can correct this?
Have now installed a range extender about 10ft from the front door lock.
Still only seeing the lock/unlock/battery tiles.
Try to reset your lock or exclude and re pair it. Blank tiles means that the lock isn’t responding (which should be fixed by the buffered repeater) or the pairing is corrupted and the platform is not returning the correct identification for the lock.
@smwein the August lock should ideally be used with the DPS sensor otherwise it can return a random state.
I did a reset of the lock…no luck. (Hold down Schlage button while reconnecting batteries)
I did a factory reset…still no luck.
When attempting to exclude the lock, after the last step of hitting the ZERO on the keypad, I always end up with the red X. I understand this to mean that it wasn’t successful.
Even held the hub right next to the lock a few times.
[EDIT] Finally got it. I had to completely remove the lock from Smartthings. As soon as I did that, the app went into exclusion mode and then I repeated the process on the lock…and it was excluded. Then rejoined.
Lock now has all the tiles.