My hub shows a recent update is available. I looked at the change log and nothing appears to apply to my equipment.
This concept has me very gun-shy about allowing it to update until absolutely necessary.
Oh nice, that is good to know. I'll keep that in mind - thanks! 
1 Like
+1, thanks for the link...
My lock situation is further complicate by all of them having Medeco tumbler assemblies. So I would also need to confirm if these Yale locks use a compatible tumbler so I can swap it from the Sh@!lage. Otherwise there is an additional "not insignificant" cost to get the Yale re-keyed to match. Assuming Medeco offers a tumbler assembly that will fit in the Yale.
Very nice!
When I switched locks, I decided to go entirely keyless .....
Don't be afraid. I'm always on the latest version and yes I run into issues... but nothing is major. I eventually put my hub into the same room as the locks and they have not given any issues since. So for some reason they don't like going through the repeaters.
If you want to give the update a shot, make sure you perform a pre update backup, do the update, run all your tests, and if you are not happy you can roll back to the previous version and restore the backup.
1 Like
Same here, but sadly I never bought any equipment and didn't get any real world experience to cement the code into my noggin. I'd probably have to start over with the morse code training software at this point...
My little brother got his no-code tech back when they were still issuing the N#xxx call signs. Unfortunately, by the time I took the test those were all used up and they were issuing the KB#xxx calls. Then as an extra slap in the face, by the time I tested for General class the FCC had changed their SOP for license upgrades to no longer automatically assign a new call. Surprise, surprise when the new license arrived with the same old call sign. (I guess I should pay better attention.) So I'm still stuck with the KB#xxx call. Would be nice to have one of the older General class call format, but at least I have the consistency of the same call. Although, I have considered testing for the Extra class just to get a shot at a new call sign.
Or possibly something in your mesh doesn't pass secure messages properly or at all.
1 Like
Looked into that. The only things was the aeotec repeater which I could see was routing its data based on its light and inovelli switches which should all support them fine.
At one point I took the aeotec device out of the loop just to see how it worked with all the inovelli switches (and I have a lot) and it still gave problems where it would drop off for hours at a time and come back on eventually and repeat.
All devices are zwave plus and support beaming.
I can't rule out 1 specific device that might be bad but to figure that out would be pretty difficult based on the number of devices. But if it was bad I would probably see more issues. I only had issues with the locks. Every other zwave device was fine. But the locks are the only ones that were joined securely.
2 Likes
That’s exactly how it works on the kwikset ones.
Hi, I'm going to update that I used to have terrible issues with this lock and Hubitat. Added the recommended repeaters, etc. Installed the Reliable Lock app. Still terrible. Basically gave up on reliability.
Fast forward to a couple days ago and I went to check my logs and noticed something. One thing led to another and I've discovered that sometime between October and now, everything works great, quickly, and no more battery drain. The last few updates to the Hubitat firmware have been awesome and the development on the platform is amazing.
I'm using a lock code alert and also set up an alert if the door is left unlocked combined with an alert once it's locked again after being left unlocked.
3 Likes
Doesn't seem like much has changed. I started moving from ST to HE over the last week or so, and everything has gone fairly smoothly. There was an issue with some Iris V1 devices but that is a tale for another thread. I have 5 locks 3 of the BE469s, an FE599, and a Kwickset 910. One of the BE469s and the FE599 work well. Both of those locks are basically in the same room as a hub. The other three, two BE469s and the Kwickset 910 will not stay connected. I have many Z-wave repeaters from right next to hub to right next to the device.
I did have to bring the hub next to two of the three to get them to pair. The one that I got to pair without moving the hub, would not load all my codes at first. I moved an Iris 3210-L repeater I had close to the device and I was then able to get it to load the codes. I ordered a Aeotec repeater to put out by the lock but it hasn't arrived yet. I moved the repeater I used to get the codes loaded back to it's original location.
The other two locks, a BE469 and the Kwikset have GE Z-wave plus smart switches right next to them. I guess I am going to have to put them back on ST and just use Hubconnect to control them. They all worked great with ST. I don't really use many automations with locks. I mainly just want them to lock if we forget to lock them and leave. Right now I am not confident that will happen as I can't manually lock and unlock them reliably from the HE portal or app.
I just updated to the latest firmware today. I read through the release notes and there were mentions of Z-wave updates. I had hoped that might help but it did not.
Unfortunately, the z-wave spec for battery-powered locks, combined with the firmware implementations that most of the manufacturers have gone with, results in fairly poor performance, as far as reliability goes. Locks often don't respond, or don't respond fully, even with a robust z-wave mesh. It has leaked out and become widely known that ST hacked around this by (if I'm remembering the exact detail correct), rebooting the z-wave transmitter in their hub if they don't get a reply back from a lock. That did result in better performance of the locks on ST, but with the unfortunate side-effect that other commands, such as lighting commands, could be ignored while the locks were being commanded.
As far as I know, HE does not do this hack, and so many users report worse lock performance on HE than on ST. Personally, I had poor z-wave lock performance on both. That's why I wrote the Reliable Locks app for HE. It helps significantly. However, it can't fix all issues. The real solution was to convert my locks to Zigbee. The Zigbee spec and implementations for battery-powered locks are just far more robust than the z-wave versions.
However, I think your idea of keeping your locks on ST and moving everything else to HE could be a good workaround, if you don't want to change out the z-wave chips to zigbee.
1 Like
I had read seen some threads where your app was brought up and I figured when I had a minute I would check it out. I just had a minute and have it installed, so we will see how it works.
Thanks for the input.
It helps with some issues when sending commands from the hub to the lock. Where I have found it doesn't help is if the lock is not reporting back on manual changes.
The other issue is that z-wave lock issues get exponentially worse if you try to command more than one lock at the same time. I think it just floods the network. I ran into this when I wanted to lock down the house (5 z-wave plus Kwikset locks) at the end of the day.
I have a second app, Lockdown, that helps with this. It spaces out the lock commands and makes sure to only lock one lock at a time, as well as force-refreshing their status. It makes a huge difference when controlling multiple locks at the same time.
3 Likes
Which repeaters did you add
In the process of moving from ST to HE. Formerly on Wink prior to ST.
Planning to migrate my Schlage BE496NX to HE. My question is what device choice to I use when adding it, since this particular device/model doesn't show in list? Generic zwave lock?
