@clifster @eyegirl @pirouz @RB03 @Rubin_Chen @TomSBos @Trakkasure
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 firstname.lastname@example.org; 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.
UPDATE: The “workaround” script is now available with ST support. The “fix” will be deployed in the upcoming 0.31.x hub firmware:
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.
Never heard of a FE369. Are you referring to a BE369? PM me the device MSR and I can confirm the model number.
RBoy, thank you. You are correct, my lock is the BE369NXCAM. I had pulled the number from the ST app since I didn’t have my paperwork handy. I noticed that in Post 46 on this thread the app also identified his lock as FE369.
My experience has been identical to what is described above. ST support has been challenging - 8 tickets and counting since July of 2019. Screenshots, logs, details of exact times door was opened with no notification were all submitted numerous times. This was never identified as a “known issue”. Instead I had to keep doing all of the resets, resyncs, reboots that ST said was the problem (even bad internet). I was specifically told by ST to uninstall my Rboy app as the issue (it had always worked fine) or they couldn’t help me troubleshoot.
The end of March I collected all my emails and documentation and submitted it all to Samsung’s “Office of the President” : http://contactus.samsung.com/customer/contactus/formmail/mail/MailQuestionGeneralNew.jsp?PROD_ID=G303850&siteId=591
I got this lock (and hub) for the specific functionality of knowing when and who opens the door and whether it is locked. With no ETA for a fix, I requested a refund (not a product exchange - another delay tactic). Even though I was told by support supervisors that my request was “not possible” after sending that email I did receive a check for the full amount of the hub. In the Covid interim, it’s not a fix but at least I am not doubling up my costs as I look for an alternative. Any suggestions for another system that can get me back to using your App and “seeing” my door again?
You can request support for the workaround (they did respond to my request and after a few modifications to their script I can confirm that it’s working now) or wait until 0.31.x firmware is released. Otherwise try another lock like the YRL216, YRL256 or Kwikset lock. If you need a deadbolt see the BE469, YRD216, YRD256 or Kwikset. There are others also like Samsung, IDLock, KeyWe, Philia etc which are also excellent locks depending on your region. You can see this topic’s first post for a comparison table.
So SmartThings support finally has the script required to fix the notifications until the firmware patch is released. This affects BE369 and FE599 locks.
If you’ve had trouble getting a response from support in the past, you may want to try reaching out to them again (email@example.com) as this workaround was updated today after I made some recommendations. Here is their response:
I did show the whole team here what changes to make to the existing script so that it does what is required for these specific Schlage locks. If you encounter this in the future and send us the Hub ID and the Node ID(s), we can take care of them as soon as possible until the more permanent fix is available in a later Hub Firmware version.
Thanks again for all your time today. Your quick responses and ability to test made a difference, as I was able to send this to other similar cases we have been investigating for awhile with relatively high confidence it will finally resolve their troubles.
Hey RBoy, I contacted them however they gave me this generic response. I did mention reference ticket number 937206. I have just reply to them asking them to refer to these forum post. I include my hub id in my reply. however i don’t know how to find the node id can you enlighten me? is it the network device id?
Sathyendra Nath (SmartThings)
Apr 29, 12:58 PM MST
Thank you for contacting Samsung SmartThings Support.
I apologize for the inconvenience caused to you.
In order to resolve your issue, I request you to please remove and readd the locks to SmartThings application and check the status of the notifications.
After that please make sure that you turn on the notifications option. To do so follow the steps provided below:
- Open Settings
- Select Apps
- Scroll to SmartThings
- Then click on Notifications
- After clicking on Notifications toggle the ON option. below you are able to see SmartThings notifications should be ON and General notifications should be ON and also App icon badges ON
Once you follow the above troubleshooting steps and check the status.
The Notifications feed in the SmartThings app shows the push notifications of your Location for the last 7 days.
To view notifications:
- From the Home screen, select Menu (Menu icon) and touch History
- See the Notifications tab
If you want to know about Activity and Filter Device History Please Click here.
If still, the issue persists please write to us with the below details. So that we will investigate further.
- What is the status of the locks showing in your SmartThings application send the screenshot
- Your SmartThings application version
- Your mobile device OS version and complete model number
To send logs please follow the below steps:
- Go to SmartThings App
- Tap the Menu button (3 bars)
- Tap the (Gear icon)
- Scroll to the bottom and look for the option “Help” Tap on that option
- Tap “Report a problem”(Mention this “945157” number)
Thank you for choosing Samsung.
Samsung SmartThings Support
I contacted them as well with a subject line " FE599 Schlage lock notification fix". I provided the Hub ID and the Node ID. Got a similar reply, with less detail. They are acting clueless or perhaps not acting…
It looks like there is a disconnect between regional support teams. Thanks to @Brad_ST for looking into it. Hopefully it will be sorted out soon.
Mohammad Saad (SmartThings)
Apr 30, 3:00 PM MST
We are writing back in regards to your concern with notifications of Schlage lock.
Upon checking we see that you are still using custom device handler for your locks.
In order to provide further support, you will need to delete these customer handlers and then Exclude and re-join these locks using the standard lock handler.
Once the locks are rejoined, then only we will able to look deeper into the issue on whether the issue is with the lock or the Hub.
Kindly perform the requested steps and get back to us,
Samsung SmartThings Support.
Received this today from engineering, if you get a canned response from support ask them to check for update to recent guidelines for this issue and escalate it to Tier-2:
As an update to what I sent earlier, I’ve now worked with a few people internally to send information to have our Tier 1 representatives get trained to spot and then escalate cases like this more directly. This should greatly reduce time spent troubleshooting, get the cases to our Team quicker, and then fixed in a much shorter order.
This might take some time to disseminate, but hopefully it will continue to get smoother until ultimately a change in Hub Firmware helps resolve this permanently.
Let me know if you have any questions or concerns about this. Thanks again for keeping in touch about this and I hope you have a great weekend.