Updated to this version. Names still not showing in History, just locked and unlocked.
Schlage BE469
P.S. Though names showing in Messages and Notifications
Updated to this version. Names still not showing in History, just locked and unlocked.
Schlage BE469
P.S. Though names showing in Messages and Notifications
The details missing on the History page a known bug with the new ST app. We’ve reported it to SmartThings and they’re working on a fix for it.
I’m having issues with the BE469NX, it’s detected as a ZWave device, I set the Handler to " Universal Z-Wave Lock With Alarms" and setup the smartapp.
I cannot control the lock remotely and pin doesn’t seem to come accross.
As recommended, I set the number of user to 0, but that doesn’t delete my code I used to have before the migration.
I cannot control it though, and logs say “Device with MSR null, AutoLock feature not supported”
I also have a Z-Wave plug (for buffer), like 5 ft away.
Any idea what could be the issue?
SmartApp Lock logs seems normal, but there is nothing else:
12:30:25 PM: trace The date/time on the hub now is Mon Sep 07 2020 12:30 EDT
12:30:25 PM: warn READ THIS BEFORE PROCCEDING: IT IS NORMAL TO SEE DEBUG MESSAGES EVERY MINUTE, IT CONFIRMS THAT THE APP IS HEALTHY AND RUNNING IN THE CLOUD. IT DOES NOT COMMUNICATE WITH THE LOCK UNLESS YOU SEE A MESSAGE BOX SAYING 'REQUESTED LOCK TO XXXXX
DTH Logs:
12:50:43 PM: warn Unknown device with MSR null, keypad state not available
12:50:43 PM: warn Device with MSR null, Alarm feature not supported
12:50:43 PM: debug Getting configured user pin code length
12:50:43 PM: debug Getting Alarm Level
12:50:43 PM: debug Getting Device MSR
12:50:43 PM: trace Current user pin code length 0
12:50:43 PM: warn Unrecognized device. Contact developer with MSR null
12:50:43 PM: debug Refresh called, Device MSR is null, FW is null
[zw:F, type:0000, mfr:0000, prod:0000, model:0000, ver:0.00, zwv:0.00, lib:00, endpointInfo:[]]
12:31:07 PM: debug Getting configured user pin code length
12:31:07 PM: debug Getting keypad state
12:31:07 PM: trace Current user pin code length 0
12:31:07 PM: trace [DTH] Executing ‘doConfigure()’ for device Z-Wave Device
12:31:07 PM: warn Unsupported device with MSR null, cannot query pin length
12:31:07 PM: debug Getting configured user pin code length
12:31:07 PM: warn Unsupported device with MSR null
12:31:07 PM: trace Z-Wave Device: Configuring lock settings
12:31:07 PM: trace [DTH] Executing ‘doConfigure()’ for device Z-Wave Device
12:31:07 PM: trace [DTH] Executing ‘configure()’ for device Z-Wave Device
12:31:07 PM: info Z-Wave Device: Resetting door tampering activity sensor
12:31:07 PM: info Z-Wave Device: Resetting smoke alarm sensor
type:0000, mfr:0000, prod:0000, model:0000, ver:0.00, zwv:0.00, lib:00
That means the lock didn’t pair properly with the hub due to packet loss (interference, lack of buffering, weak signal) or latency causing the hub to timeout. Try these steps (don’t skip any):
Scan nearby
button (don’t use the brand name option as that disabled remote programming for some locks)After pairing adding a buffering repeater between the lock and the hub for optimal performance: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub? - #2 by RBoy
Thanks @RBoy, I tried that without much success.
I found the manual and performed a factory reset (unplug battery / Press outside Schlage button / plug the battery) and this helped to repair correctly.
I thought everything was pairing just fine because I had a new “Zwave” device when pairing, but this time it was detected as a Schlage immediately.
I am trying to update the Device Handler for my locks from 4.00.02 to the newest 4.08.02 as I believe there are some bug fixes that are relevant fo me. I recently switched from the Classic SmartThings app to the new App and do not like how the default for the locks in the app is to display the “Contact Sensor” vs “Lock” which I understand is fixed in the newer handler.
I created a new Device Handler in the IDE and named it. I edited the device in the IDE and changed it to this new device handler with the updated code. When I go back to the SmartThings app, I cannot open the device… it just says it cannot communicate with the device and to contact support. I manually unlock the lock and looked in the IDE And see that it is picking up the state change so I decided to use the Classic App and sure enough I can see the status and control the lock. For some reason, the new App does not like the device handler. I reverted the change and went back to the old device handler version and I am able to see the status and control the lock in the new app.
what am I doing wrong here?
Thanks
EDIT
Maddie @ rboys support responded to my email -
There’s no issue with the device handler. The new app breaks devices when migrating from the Classic app. You’ll need to exclude the lock, delete the device handler and then reinstall it and pair it again to clear the platform cache.
I will was hoping to avoid having to do this, but i will try it and hopefully this works.
when doors are unlocked with code, can we disarm ST home monitor and run a scene.
I have option to disarm honeywell alarm only.
forgot to mention i migrated to new ST app…
Hey all, switched to the new ST app a while back and all was good. The Smart Lock Guest Access was automatically added to my smartapps when I completed the switch. It seemed to be controlling the lock/unlock function but all my codes were still working so I left it alone. Today my daughter reported her code not working so I deleted the guess access app. I also have 2 versions of the @RBoy app for some reason. One has my 4 codes one doesn’t. I tried updating the app code in IDE and I have no control over the lock, none of the codes work, etc. What should I do? This is a Schlage BE469 and the device has never been removed from ST.
If both the apps are programming the same lock at the same time, then one is erasing users while the other is adding users (remember one app can’t see what the other app is doing) and that’s what’s messing it up. You should only have one app program a lock at one time as explained in the LUM FAQ document. Clear all your codes and start over with a clean slate. Remember that schalge does not allow you to reprogram existing codes so make sure you clear all codes before reinstalling the app or follow the Clear Codes Procedure in the FAQ document.
I started the clear code procedure per the FAQ and this has been going on for 40 minutes now in the device events page:
Nope, it’s not. lockCodes should be all clear. You’ve still got some app that’s programming the codes in the background. Uninstall all your lock/user management apps and then clear all codes or reset your lock.
Thanks for the help @RBoy, I think this issue was partially caused by low batteries as well. I finally got some time to work on it today and deleted the smartapp from both the mobile app and IDE, I updated the DH in IDE, replaced batteries in the lock, then reinstalled the app in IDE and then mobile app. I waited a few minutes and then did the clear code procedure. This time it seems to be clearing the codes I had set actually stopped sending the deleteCode commands this time.
Please make sure that your lock is within 20ft of a buffering device/repeater for best performance and reliability.
Thanks @rboy I’ve been using this new updated DTH since it went up. It is working great after the cache issue caught up in a day or so (Smartthings really needs to fix that). The lock is responding quicker, and I love that it can control the lock with the button right on the dashboard now. I’ve been monitoring the developer threads and know it wasn’t easy, but you guys were able to navigate all the changes, help other developers move their projects along, and be an advocate to stay on Samsung to make sure everything gets fixed. Thanks again for all the hard work.
Seems there is something wrong with the new device handler, getting Sensitive on history once an hour, any comments?
If I change the device handler back to a “Z-Wave Lock,” is there any possibility it would over-write my LUM stored entry codes?
If you’re just switching device handlers from this to Z-Wave Lock (or vice versa), it should be fine.
I switched device handlers and then switched back just so I could get the updated custom UI features in the new app. Nothing happened to my lock codes.
I updated the DH, ver 5.0, and everything is working fine. So, thank you for the changes that work with the new App.
I have an unrelated question, which may have been answered before and sorry if it has. Although I have my Google account in the Linked Services of the new St app, along with several other accounts, I don’t have my Yale lock showing up using either the RBoy smartapp or this handler. Having my August account linked, the lock shows up as a device on my Google home app no problem. Any suggestion?
Just thought I’d share, I had to switch to generic Zwave lock DTH, delete this DTH. Then reinstall this updated DTH and switch back to it. Now I see the new UI.
I didn’t lose and codes or setting during the whole process. YMMV but for me it worked.