Aeotec Range Extender 6 didn’t seem to have any effect on the problem. So I guess its back to the drawing board… I don’t understand why don’t any other company make a lock like Schlage’s instant click unlock lever lock. just add wifi to this lock and i will gladly pay another $300
We have a bunch of the FE599’s in our lab (original and new firmwares) - all of the lined up in a row, most of them work just fine (with a beaming repeater between the locks and the hub). However, one of them just won’t report a user code, all else works fine.
Because of the recent posts I tried again to get my lock to send notifications when it is unlocked. Nothing, nada, rien. It is so frustrating because my other FE599 is perfect. I can get the non functioning lock to send me notifications when a code is changed, but that is not a function that is initiated by the lock itself. I contacted Schlage and they were less than helpful. They emphasized that nothing is wrong with their lock and it must be a Smartthings firmware issue. I do receive notifications from the door sensor (same distance and also with a monoprice repeater) I just don’t know who actually opened the door. I think at this point I’m going shopping for a Yale lock…unless RBoy wants to exchange a functioning lock…
Update for me: I tried 2 different new FE599s and neither work for the push notifications. I tried both the Monoprice and Aeotec Range extenders between the hub and lock and neither helped. No notifications at all… sigh.
So I gave up on the FE599 and just installed a Yale Assure YRL216-ZW2-619 (push button lever lock with key). Paired up to ST, programmed with LUM using the Enhanced DTH and it started pushing code notifications immediately!! Awesome.
Thanks @RBoy for all your feedback, but “draw of luck” is expensive at $200/pop for the FE599. LUM is of course great to use - no complaints there - my suggestion is to go for a Yale lock!
You need to remove the lock from hub and then re-pair it, and you can see it stops pushing code notification. " the lock would works fine if it paired with hub about 6 months ago"
We’ve been investigating this deeper. There appears to be a bug with the hub firmware which causes it to drop certain incoming messages from some locks after a new pairing. If your hub isn’t receiving unlock/lock notifications from the FE599 despite adding a buffering repeater and following all the steps mentioned in this post, you may be hitting the bug. ST has been made aware of the bug and they’re working on a potential fix.
Feel free to send an email to ST support (email@example.com) explaining the issue and you can also reference ticket no 899130 in your email so they can tag them together to expedite the fix.
Thanks for following up on this issue. I have contacted Schlage a couple of times and they really weren’t interested since they claim I’m the only one having a problem. They blame the hub for not relaying the notifications. I did contact ST and referenced the ticket no you mentioned. I’m really hoping that it can get resolved. If not resolved before the busy summer season I will be purchasing a Yale.
I appreciate you reaching back out and trying to get this issue resolved.
This is interesting. So when you say a bug impacting a new pairing, I assume that means excluding and repairing the lock will have no impact?
@Rubin_Chen sorry for the delay, but confirming that, like others, neither of my Schlage FE599 locks work with per-user notifications in RLA.
To confirm earlier suggestions, I did end up purchasing the applicable Monoprice plug-in repeater between the hub and lock, moved the hub as far away from the lock as a I could with the repeater in between, repaired the Z-wave network more times than I can remember, tested in multiple 1500-2000 sqft apartments across two floors and no dice. In sum, per user notifications on both of my FE599 locks would never work.
For what it is worth, I also recently picked up a Schlage BE469Z (V Cam 619) deadbolt lock for a whopping $3 at a local Habitat Humanity REStore, dropped in batteries, paired it to the hub, and per user notifications were working just minutes later.
So while Schlage decides if they are ever going to fix that bug @RBoy is indicating above, I’ll skip purchasing any further FE599s and take a closer look at the Yale and other models mentioned in the forums to see what better models are out there.
Just to clarify, while Schlage can improve the firmware for the FE599 (in many ways), this is a recent issue specifically caused by a combination of the new hub firmware architecture along with a quirk in the FE599/BE369 firmware while pairing. It can be resolved by ST with a hub firmware patch. ST is aware of the bug and they have a potential fix.
Do send in an email to ST support (firstname.lastname@example.org) explaining the issue and you can also reference ticket no 899130 in your email so they can tag them together to expedite the fix.
ST was kind enough to have a lengthy detailed conversation with me about this issue. Without going into technical details, ST is aware that there is a problem with some locks and the auto encapsulation feature. Thankfully now there is a temporary “workaround” and a potential permanent “fix” that we discussed in detail. Unfortunately since not a lot of people have brought up the issue the permanent “fix” is not a priority.
The best way at this time to get notifications working again on the BE369/FE599 locks is:
- Send an email to email@example.com; tell them you have a FE599 or BE369, that you aren’t receiving notifications/updates from the lock and request the “association workaround”. They will send the “association workaround” command to that specific lock on your account. You will need to request this for each affected lock (and each time you re-pair the lock). This will get your notifications working again.
If enough people affected this issue ask for the “workaround”, they may consider investing in the permanent “fix”. Hope this helps.
UPDATE: The permanent fix is going to be deployed in the upcoming 0.31.x hub firmware. Note that this would required you to exclude and re-pair your lock with the changes to take effect.
Will do. Interesting timing as well since I just walked through this week confirming that no notifications were received after removing RLA from the hub, removing and re-adding the lock, and confirming I was on the latest versions of the ST app and hub firmware via my open support ticket with ST.
Just emailed them if this works… I will e-kiss you! I was going to say support you by buying your products but I already did… so e-kiss for now.
Thank you for the follow up and taking the time to explore this with ST. I just sent an email to their support and hope that they will be able to apply the workaround for my lock/hub. Let’s hope!!
Thanks so much for still working on this for us. I did as you recommended and used the term ‘workaround’, but the response from ST indicates that they still don’t have a clue. Is there a particular representative that might be more helpful?
This is the response, "In regards to your query, where you are unable to get notifications of the Schage lock. So, I request you to once remove the Sclage lock from the Smart Things and re-add it and also once clear the cache and check it out. Also, do share the screenshot of the error if any occurs and please get back to us if the issue still persists.
As I understand, this “issue” is acknowledged in the 0.30.x firmware, so keep an eye out for it. You could point support back to that link as well. It’s possible they may not be aware of it just yet.
Any way to get notification of when this issue is fixed? I have the same issue, and have asked for the work-around a bit ago via SmartThings email support.
Let me clarify as to what is going on here.
In Z-Wave, The hub/controllers need to set association between the device and itself so that the device sends “lifetime”/primary events to the hub(Similar to Bluetooth Low Energy, where the clients can enable notifications on GATT characteristics). This Association step is automatically attempted and completed when a device is added, you can also associate with other groups of events as well in the DTH, but regardless this is a step the hub automatically performs.
So what is going on with this Lock? Well sometime ago in 0.25.X we added “Auto Encapsulation” method for all outgoing Z-Wave messages. This was done so once Z-Wave S2 is enabled in our platform, the DTHs can remain the same. So when we go to send “Association Set” command to this particular lock, we encapsulate the command with the highest level of security available with the Lock and in this case, we use S0 encapsulation. This particular lock does not “act”/“process” Association Set if sent with the S0 encapsulation. This Lock is essentially not following Z-Wave Spec.
Of course, the easy solution is “Well dummy, do not encapsulate it with S0 then”. So in 31.X, We are going to make the change to not encapsulate the “Association Set” for the affected devices, first we needed to identify the affected devices, so we are not applying a fix that could potentially break integration with other devices. Also, I am full aware of the option of delegating this change to DTHs, I wish I could explain the technical reasons why this change would have been more exhaustive to be accomplished in time.
I am sorry if this has been an issue for you guys!
Thanks for staying on top of this Kianoosh. Currently I believe there are two devices affected, the Schlage BE369, FE599 which use a different group for controller associations.
The Yale T1L and YRD120 are the same device. There’s also a Yale B1L (YRD110). That device should process Association Set with S0 encapsulation.
The Schlage FE369 is affected as well.