I truly hope that this is not the case. Aren’t z-wave devices’ firmware able to be updated over z-wave in any case, or is this more of a device-specific feature/capability? I’ve seen references over the years to z-wave light switches that got firmware updates, the ADC-T2000 t-stat (I don’t think this one ever materialized, though the capability was supposedly there…?).
If Qolsys does tell us that this is a device-specific issue and that they can do no more on their end, then I would ask if you could please send me as much case detail as possible (case number, names of folks involved in the Qolsys/Schlage technical discussions, technical description of the underlying issue, etc). In this eventuality, I’d absolutely want to go back to Schlage to pursue further. I haven’t even had these a full year yet and I would have difficulty accepting dead-ended z-wave support as an appropriate response.
Aren’t z-wave devices’ firmware able to be updated over z-wave in any case, or is this more of a device-specific feature/capability?
This is not a universal option, no. Device manufacturers must support it, and while sometimes possible, it is not always practical. The T2000 updates for example I believe were halted due to extreme difficulty in applying them safely.
Keep in mind I was just commenting on the possibility that the date specification is related to the issue we are seeing. I don’t know 100% that is the case.
I’ll see if I can get as detailed of an explanation as possible for this based on what Qolsys knows and go from there. I’m happy to provide as much as we can.
Here’s a quick update. I contacted Schlage about this, and they happily sent me a replacement Schlage BE469ZP. The replacement lock was manufactured just recently on Mar 2020. The firmware is different than my older one. Adding the new lock the to the IQ2 panel went well, no issues, no hiccups, just smooth addition. However, its unfortunate because there are still issues with my Schlage. The status of the lock, (ie. locked or unlocked) huge lag in the panel (if at all), and alarm.com doesn’t even report its activity. So for example, panel or alarm.com could say its locked, but it could actually be unlocked! And, when I manually lock/unlock nor the panel or alarm.com notices it (i.e. no annunciation or app notification). I remade all the rules after adding the lock. My other 2 locks are Weiser, work flawlessly. They are S0, while the Schlage is S2 encryption.
Do other people have issues with Schlage locks and Iq2 panels? I think this thread now should be a different thread.
Glad you were able to get a replacement with a newer firmware so easily. As for similar issues as to what you are reporting regarding the S2 Schlage lock, I dont believe its something we have come across before.
Does the lock function via remote command quickly or is that negatively impacted as well? Was the lock learned within 6 feet of the panel and there are extra repeating nodes installed as necessary.?
Hi Tyler, via remote command, its somewhat negatively impacted, but better than my first lock (which rarely responded on the first command, but always on the second command and lock status was not issue as well).
I wonder if this is the problem as I did NOT learn it in within 6ft of the panel. If you think this will solve the problem, I will try this. I did do rediscovery of all my devices after I added the lock, however.
With locks, proximity to the controller when learning it in is extremely important.
Definitely try relearning within 6 feet, leave the panel there until learning is complete. Then run a rediscovery with everything back in its final location.
Strangest things ever. After following your advice and learning with 6 ft of the panel (after excluding/deleting successfully), and then installing and rediscovering, the lock continued to behave erratically. I then installed my old lock again (because the newer one was worse than my older one). This time I learned it within 6ft but, I did not run a rediscovery after installation. Would you believe if I told you that my old lock is now behaving flawlessly? (at least in the last few hours). Immediately, it starts announcing its status with no lag, and after I set up the alarm.com rule, I get the alarm.com notifications. It locks and unlocks upon command, consecutively. I never learned the lock at the panel before, and this was the difference.
I didn’t realize that a z-wave network can be so flaky. I guess I’ll use my second lock for parts.
One thing that is odd I had the automation rule where upon a smoke/fire alarm, it would unlock my front door (the Schlage), but now, I cannot set it up (with any of my locks). Why would I lose this functionality?
Automation > event-triggered rule > locks > …
I used to be able to click on “alarm” and choose “smoke/fire/CO event” to unlock my lock at this point but now I only have two options “arm/disarm” and “lock” and cannot re-create this rule. The feature was there a few hours ago, but now its disappeared
I get the alarm.com notifications. It locks and unlocks upon command, consecutively. I never learned the lock at the panel before, and this was the difference. I didn’t realize that a z-wave network can be so flaky.
This is why we stress the proximity when learning in devices, especially locks. The effective pairing range is significantly shorter than general use.
Once in a while you might get away with making it work from a little farther away, but it is only inviting problems. It must be close for reliability.
Unless it is an NWI compatible device, be sure to learn in close to the controller. This is most important for locks, but affects thermostats a lot too.
One thing that is odd I had the automation rule where upon a smoke/fire alarm, it would unlock my front door (the Schlage), but now, I cannot set it up (with any of my locks). Why would I lose this functionality?
I cannot view your account to confirm what you are seeing, but you can only have one smoke triggered opening rule I believe. If you already have one set up you would need to edit that rule.
Thanks, Jason that was indeed the case. I was able to make the automation again after deleting the old one.
With regards to the lock, the lock is now behaving like it used to, i.e. rarely works on the first command, and needs a second command to work. Despite the paring at within 6 ft (with no rediscovery at first). Regardless, my older lock works much better than the new lock (both were paired at 6ft).
I’m back to square one with this issue. At this point, I see no option other than to replace my Schlage lock with another Weiser/Kwikset unless software can fix this.
I would advise trying a different model, yes. Unfortunately there is precedent for this. A few Schlage models in the past broke their compatibility with other controllers like 2GIG.
I’ll see if I can get some more info from Qolsys and I’ll let them know the newest Schlage’s are still having trouble.
This is mostly a guess, but I believe the issue that keeps popping up with Schlage locks is that Schlage builds their locks for Nexia, rather than general use with multiple controllers.
Thanks, Jason - yes, I am also still very interested in Qolsys’ analysis from our earlier debug sessions and your log submissions from data gathered from the panel. Still having the same issue with both of my Schlage locks and would definitely like to know how we can move forward to address it.
For my part, I can state that one of the two locks that I have affected by this was learned in within 10 feet of the panel with clear line of sight. Not quite the recommended 6 feet, I know - but somewhat close…
FWIW, I had 3 Schlage locks work flawlessly on my old Concord 4 system at my old home.
LOL, tell me about it Jason. I switched from Schlage to Kwikset and finally to Yale Assure Lock SL and (so far) all my locks are finally playing nicely with my GC2. It wasn’t cheap but sooooo worth it!
I basically solved the problem. I removed the Schlage and replaced it with another Weiser of the same model as my other 2. After a few days, I can report now, officially I’m back to pre HEM days.
I’m glad that you’re past this problem, xeon. Unfortunately for me, this approach isn’t going to be an option (and it’s not just a matter of cost, but also one of aesthetics and what my wife and I are both willing to accept in the realm of form and function).
I really feel stuck between a rock and a hard spot. If this problem doesn’t get resolved in software-space, the more realistic options for include:
Accepting marginal functionality of current smart locks (basically just use them for manual indication; they cannot be relied upon for any kind of automation capabilities), OR
Rolling back the Z-wave SDK update from the IQPanel 2 Plus (if even possible), removing the HEM from service permanently, destroying/rebuilding my Z-wave network
Either of these options for the long haul would be very disappointing. Hopefully, Jason can share what Qolsys learned from our earlier debugging and there remains some hope…
Either of these options for the long haul would be very disappointing. Hopefully, Jason can share what Qolsys learned from our earlier debugging and there remains some hope…
Yeah, neither of those options would be ideal, I understand the frustration. I pushed for some more info on this. There is always hope when it is a software issue, especially when we have a definitive timeline of when the issue occurred and the instigating factor (the 6.81 update).
As long as you are ok with it I’ll send additional data logs from your panel as needed.
The rep I’m speaking with was under the assumption that the Schlage date of manufacture would have an effect here. But it apparently does not. I’m trying to find other examples of this issue to give the report more urgency and hopefully get a software fix quickly. I don’t have an update or ETA yet, but hopefully soon.
Rolling back the Z-wave SDK update from the IQPanel 2 Plus (if even possible), removing the HEM from service permanently, destroying/rebuilding my Z-wave network
I’m not sure rolling back is supported, but I have asked Qolsys to verify for you just in case.
Yes, please feel free to share any additional log data with Qolsys. While I’m not locking/unlocking via the app too much these days because of the issue, I have at least one scene that I use commonly (and will soon be adding more) that at least attempt lock/unlock commands, which may generate additional data representative of this issue.
Of course, I’d be more than happy to attempt any specific testing to generate additional data of interest, test preliminary patches/firmware - basically, whatever is required from my end to help drive this forward towards resolution (short of replacing the locks ).
LOL, tell me about it Jason. I switched from Schlage to Kwikset and finally to Yale Assure Lock SL and (so far) all my locks are finally playing nicely with my GC2. It wasn’t cheap but sooooo worth it!