wdhille

This post will be longer and more detailed than most... I am finally 100% satisfied that my four Schlage Z-Wave Locks and my ISY 944 running V5.3.2 are reliable and work all the time. I have been testing the current configuration now for 72 hours and there have been no/no communication errors or failure to communicate issues. So here is what I have learned in this long and expensive process. 1) The Schlage locks work best when they are a direct link to the ISY. Range Extenders or Repeaters, regardless of who's you have, can be problematic when used with older Schlage locks that do not have the latest firmware. (I tried Domes, Aeotec Gen6, Gen7 and Inovelli) 2) The newest Schlage Locks using Z-Wave Plus (Model BE469ZP Firmware Version 0.11.0) seem to work when a repeater is required. Thank you to Schlage for stepping up to the plate and sending me two of your latest locks. I guess the squeaky wheel does get oiled.... 3) The newest Schlage locks that are Z-Wave plus have greater range than the older Z-Wave BE469 locks, so using them can (it did in my case) eliminate the need for a repeater. 4) While in theory we should be able to have several repeaters inline (three hops max), if you have a lock that is several hops away from the ISY it might be more cost effective and less time consuming to just put another ISY next to the lock. That is the only way I was able to get the lock in my external shop to work. 5) The Z-Wave products tool kit provides usable information in troubleshooting connections. The software/firmware is not professional grade, there are lots of anomalies, but for me at least it provided detailed technical data to troubleshoot and improve the system. It is kind of cool to play with, and it was on sale last month. So with that said, below is some data I have from the Z-Wave Products Tool kit. The first picture is the map of my Z-Wave network. I have simplified the network as much as possible. The number in parenthesis is the number of nodes each device sees. So at the top is my ISY, and it sees six nodes. The "old garage door" is in yellow because it only sees two nodes, but one of them is the direct link to the ISY.... And that link works... Pic 2 shows the "basement door" that sees three repeaters. In the ISY, "Z-Wave>show information in event viewer>all" you can see the basement door lock connects to the ISY via one Aetoec Gen7 repeater. The third pic shows how I got the lock in my detached shop to work. I ran a new Cat6 cable to within a few feet of the door and installed a second ISY. (Suggestion to Universal Devices: Can you make the ISY's POE powered...!) Now, for the first time in history.... when I use the Z-Wave tool box and do a "network health test" on all devices, I have have 100% success in almost every node all the time. That didn't happen before. The basement lock in the picture achieved 58/60, but in reality the ISY will resend that command several times if that happens. Thank you to Michel at UD for a lot of help and advice on this! Wayne

Well... higher gain is probably not what you want for a mesh network. I'm my case, I want point to point to the darn lock.... And as you said... gain is not free... increased gain in one direction costs you... Now maybe we need an antenna that has electronic beam steering and the antenna is electronically pointed to the node the hub wants to talk to..... I'm saying that jokingly, but we have the technology.... and it would work.... might cost more than the current hubs though.....

Hart2Hart: My initial thought was an external antenna. I don't believe the ISY's with the newest boards support an external antenna. I still believe though that would have solved my problem since I need a direct connection to the ISY. In my youth (20's and 30's...) I did a lot of RF work, and I am sure these antennas are about as good as a wet noodle, as the saying goes. And put the wet noodle in a metal door, I suspect we're down 20-30 dB from an isotropic source... But since I can't find any pattern testing on this stuff, I'm making that up. stre: When I first got the locks I asked about updated firmware. Apparently that's not possible... The four locks I have are two years old. Two years of pain and torture trying to get them all to work reliably. I am 100% convinced the issue is with their firmware. Guaranteed. I spent the last 30 years doing stuff like this... Failure to admit there is an issue is not a recipe for increased sales and profits.... I think Schlage will be sending me two updated locks with the latest firmware. While I'm not thrilled with their product, I don't think we have many options, and I'll give them a lot of kudos if they send me two new locks. In the mean time... I ordered my third ISY this afternoon. Three ISY's will cover the four locks. BTW, my second ISY that is less than five feet from the door lock is 100% reliable all the time. Wayne

I just wanted to give a quick update on my issues with the four Schlage BE469 locks. I posted a lot of data in previous posts, but the bottom line is the Schlage locks do not work properly when using a range extender. Two of my locks are a "direct path" to the ISY and they work 100% of the time. Never a problem. Two of them using range extenders (name your brand, I've got Aeotec, Dome, Gen7, Gen6, Inovelli) are totally unreliable. They work some of the time if I reset them by taking the battery out. But not for 24 hours in a row. I've created what I believe is a robust mesh by adding up to 12 range extenders, and the lock still doesn't work all the time all the time. The Z-Wave toolkit I purchased show 100% rock solid links to every device in my mesh all the time, except the locks.... I then tried one RE inline to make a point to point path. That doesn't work either. So I still want to use the locks, and at this time I have not found a suitable replacement that will work on my network and not need connectivity to the cloud. My solution is to put an ISY close to each lock I want to control. While this is not ideal, it solves the problem and gets me out of the mode of fixing something beyond my control. Yesterday I spent four hours running an ethernet cable next to one of the problem locks. It works now as it should. I'm going to buy one more ISY for my other "problem" doors to solve that problem. While this seems like a band aid, it is. But... for $200 each it will work. And, if I look at the time I've spent on this, I could have bought many many ISY's for the hours I've spent on something that should have been a plug and play. I have been in contact with Schlage, but I've only reached low level customer service and tech support. Somewhere in that company must be an engineer who probably makes $75k per year that fully knows they have issues, but is not addressing it. That's too bad, because I suspect the fix is a few lines of code... And... when you call them up, the first thing you hear is "your time is important to us". But it takes ten additional minutes to get a human online who then reads some boiler plate document about what you are doing wrong... Maybe the CEO ought to try calling tech support.... Anyway, that's it for my Sunday rant. The one in this pic works great.... Three feet away..... Wayne

I'm be interested in hearing about your results. I have six Gen6 and six Gen7 Aeotec ZWave Plus repeaters. I believe the repeaters work great... My Schlage locks certainly don't like them. OR the Dome repeaters.... Wayne

1) We have four Schlage BE469 ZWave locks. 2) I don't have the ISY's "talking" to each other. I will look into that. The newest ISY though controls one door and one door alone... I left the Insteon stuff on the first ISY. So I have one simple program.... Lock the darn door at night! 3) I don't believe I have any issues with the two different Z-Wave networks conflicting. There is about 75 feet of separation between them which includes two brick walls and three framed/drywall walls. I am absolutely certain that installing the Z-Wave locks in a metal door is not ideal for RF link margin... What I would like to see is a RF pattern analysis of the ISY, the repeaters and the locks so we know where the dead spots are and we know which direction the antennas work best in. I'm old school... and years ago I did RF work... and I would never install a system that had an RF link without knowing how to point the antenna.... Sadly, the antennas on the Z-Wave (and other home automation stuff) while might be designed as omnidirectional antennas, they are not..... So on an amusing note... I called Schlage yesterday to discuss after Timothy in tech support stopped answering my emails.... The first thing the recording says is "Your time is important to us". Well after ten minutes of pushing buttons I had the opportunity to speak to a customer service representative. They're of course nice and polite, but they are not technically qualified to help. The more I learn about these the more I believe they have issues because they try to use strong encryption and there may be timing issues when using the locks with a repeater. If I was to start over, I might buy WiFi Locks or Bluetooth locks that require a nearby device to connect to my network. Last year I bought a WiFi lock, but sent it back because it would only work if I allowed it to connect to the "Cloud", which after many years working in the cyber industry I still can't find where that cloud might be located and who controls it.... The reason I like the UD/ISY is I can run it on a closed network and I can keep all of my IOT things on an isolated VLAN that can't phone home.... Sorry for the long post... but in retrospect, after many many hours on this, and many many dollars... it would have been cheaper, faster and easier if I had just bought four ISY's and ran CAT6 to each door... I'll bet Michel might even cut me a brake if I bought four at once... Wayne

Folks, I'd like to jump in here as I'm certainly struggling with my Schlage locks. When they are a direct connection to the ISY they seem to work 100% of the time. When any repeater is introduced in the link, they do not work reliably. Period. I'm in contact with Schlage who's only advice so far is to buy Dome repeaters that they have tested. Well I bought six Dome Repeaters last week, and they work no better/no worse than the Aeotec or Inovelli Z-Wave plus repeaters. Bottom line, after a lot of work, the Schlage locks have issues when using repeaters. They seem to work OK if they are the first hop to the ISY. I also purchased a Hubitat Hub to see if maybe the ISY was at fault. It is not. The Hubitat has the same issues as the ISY. Thanks to Jeff Bezos for refunding my hard earned cash. I purchased a Z-Wave Tool box recently to help understand what is going on. The "problem" node is Schlage lock ID 51. It gets no response from the Network health tester, even when I set it to "never sleep". I have one Dome RE less than a foot away. All of the Dome's have rock solid connections to the ISY. My real goal is to control a lock about 100 feet away from the ISY. It's a tough shot and the lock is in a metal door. The solution that worked for me is to purchase a second ISY with Z-Wave and put that in the same room/building as the Lock. Now that lock works great, and now I have two ISY's.... For anyone interested, I've attached some screen captures of the Z-Wave toolbox that show a little bit of what's going on. The problematic lock is Device ID 51. It has a Dome repeater 12 inches away. The network health tester shows rock solid links to all the repeaters. (Repeater Slave and Power Switch Binary) Device 90 is a lock that while only 25 feet from the ISY needs a repeater to work. Device 12 is a direct connection. I need to give a big thank you to Michel from UD for all the patience, help, support and advice while I figure this out. My Insteon Devices (over 70) are and always have been rock solid. When I step back and look at things, the money I've wasted on Z-Wave repeaters would have been better spent buying additional ISY's... They seem to work fine with the Z-Wave locks. I also want to say it may not be just a Schlage issue. I had a Kwikset ZWP look for 29 days also which worked about as poorly as the Schlage locks. I'll keep you all posted with what Schlage says, but I am finished spending money on repeaters for locks that don't work reliably with them. Wayne

I've been chasing down issues with my Z-Wave locks. It's been horrible. It was suggested I look at the error logs, which I hadn't done previously. For some reason, my ISY error log has the IP address of my Pixel phone popping up. So, I took the phone off DHCP and assigned a static IP address to it. IT still follows it... Mind you the ISY and Wi-Fi are on VLAN isolated subnets, which might be why I see this error. But.... More importantly, I have disabled (force stop) Agave, and this is a new ISY I'm using. Other than Chinese hackers, anyone have any ideas? This is with a static IP address I put in this morning at 7:30 AM. This error does not show up unless my phone is using Wi-Fi. xmlns:u= Sat 2021/01/23 04:18:38 PM System -170001 [HTTP:0-31-5] 192.168.10.137:53027->80 Sat 2021/01/23 04:18:38 PM System -170001 [HTTP:0-31]: POST[1]-->/services Sat 2021/01/23 04:18:38 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus This is yesterday with a DHCP address assigned by the Firewall/Router. xmlns:u= Fri 2021/01/22 06:45:06 PM System -170001 [HTTP:0-27-5] 192.168.10.27:52606->80 Fri 2021/01/22 06:45:06 PM System -170001 [HTTP:0-27]: POST[1]-->/services Fri 2021/01/22 06:45:06 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=

Dennis, That's the first thing I did was to see who 192.168.10.207 is. Nothing showed up. But... upon further investigation.... it is my Pixel phone, which runs Agave to control the ISY. I turn it off at night, so when I initially did a network scan of that subnet nothing showed up. So, my plan is to clear the error logs, "remove" the failed node, reinstall the lock and see what fails. That involves physically removing the lock from the door and reinstalling it. At this rate I'm going to wear out the screw threads taking it in and out. I'll send that log into tech support, but my guess is Agave made a request to query the lock, lock it, or unlock it, and when it failed to do that the error was generated. But that's only a guess. I'm still really thinking the issue is with the lock firmware, which I can't upgrade. When I put the kwikset in this weekend I'll know in a few minutes. Interestingly though, the lock works great when it is the first hop to the ISY. The problems show up when it uses repeaters. The Aeotec devices seem to work fine in a "mesh" scenario, so my instincts tell me the issue is with the locks. Of the four locks I have, the two with direct comms to the ISY are fine. Thanks for you input. Wayne

So this is interesting. Here are some error logs. My ISY is on a VLAN, and it's not dot 10, so I wonder where the 192.168.10.207 comes from?? The dot 10 subnet, also a VLAN, is my managment network, where as the ISY is in my IOT network. But... that should not matter to the Z-Wave portion. ZW021_1 is the lock that has issues, using the Aeotec repeater. Maybe it's trying to call home to China or Mosow. Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:0-21]: GET-->/rest/query/ZW021_1 Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55254->80 Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:07 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55255->80 Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:07 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:07 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55256->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55257->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55258->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55259->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55260->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55261->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55262->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55263->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55264->80 Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20]: POST[1]-->/services Wed 2021/01/20 08:40:08 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Wed 2021/01/20 08:40:08 PM System -170001 [HTTP:1-20-5] 192.168.10.27:55265->80 Wed 2021/01/20 10:27:15 PM System -170001 [HTTP:0-22] Closing socket normally Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-22-5] 192.168.10.207:39700->80 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-22]: POST[1]-->/services Wed 2021/01/20 10:27:18 PM System -170001 <s:Envelope><s:Body><u:Unsubscribe xmlns:u='urn Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-23-5] 192.168.10.207:39704->80 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-23]: POST[1]-->/services Wed 2021/01/20 10:27:18 PM System -170001 <s:Envelope><s:Body><u:Unsubscribe xmlns:u='urn Wed 2021/01/20 10:27:18 PM System -5006 uuid:66 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-23-6] Socket not active#2 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:0-23] Closing socket w/failure Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:1-20-6] 192.168.10.207:39702->80 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:1-20-6] Socket not active#1 Wed 2021/01/20 10:27:18 PM System -170001 [HTTP:1-20] Closing socket w/failure Wed 2021/01/20 10:27:21 PM System -170001 [HTTP:0-20-5] 192.168.10.207:39708->80

I've never done that, but I will take a look to see if it means anything to me. Are your locks Z-wave plus? My BE964 are not, and it looks like I can't update the firmware. I just clicked now to buy a Kwikset Z-Wave plus lock. Thanks Wayne

So just an update here. It's hard for me to imagine I'm the only one having so many issues with these locks. To reiterate, they work fine when they have a direct link to the ISY hub. As soon as I put Gen6 or Gen7 Aeotec repeaters in the path, things start falling apart. I sort of think it's a Schlage issue, since I always see this error [ZWAVE-RX-ST } Send queue full which in my uninformed opinion looks like the lock is having trouble transmitting data to the ISY when a repeater is inline. I don't believe this is an issue with the Aeotec's, I've tried other repeaters before with the same results. My options for narrowing this down would be to purchase another brand Z-Wave hub, or another brand Z-wave lock. My bet is that the lock is where the problem is, and Schlage has no means to update the firmware. Anyone else have any suggestions on this? Thank you. Wayne

Dave, Do I need to do that with the Gen 7 Aeotec? I don't think it says anything about that??

I'm glad I'm not installing these and trying to make money. I'd be out of business. In retrospect, especially after reading it may not be just Schlage locks, I suspect the real issue is what happens when the Z-wave locks have a repeater in between the hub and lock, the encryption that the locks use have problems. As soon as I put a repeater inline, I get see this [ZWAVE-RX-ST } Send queue full which tells me the lock is having problems sending updates/info to the hub. Take the repeater out it goes away. Frankly, I don't need/want encryption on my locks.... My network is locked down and we have physical isolation, so anyone nearby sniffing packets would have to deal with the Heckler and Koch's.

Are you using any repeaters? I emailed Michel K a few weeks ago. The suggestion was to build a robust Z-wave mesh network, which prompted me to buy 10 Aeotec repeaters. But..... other than costing me $300 was not effective.... I'm looking at some of the WiFi locks now.