wdhille Posted January 19, 2021 Posted January 19, 2021 I'll apologize in advance for the long post... To start, my network has four Schlage z-wave locks and 60 or so Insteon devices. The Insteon devices are rock solid. The Schlage locks are not. After losing some sleep on this, I believe I must be missing something and it's staring me right in the face. But... I don't see it.... You know how that goes. The Schlage locks work great when they are the first hop to the ISY. Our house/property is spread out though. The walls are brick and the doors are metal, making it harder for the RF to go the distance. I'm currently on my third iteration of Z-Wave repeaters. I currently have six Aeotec Gen 6 and four Aeotec Gen 7. The ISY seems to be able to communicate with the repeaters all day long, although the green icon which indicates it needs to write data to a device never goes off. As a test, I can take my "included" lock that I had two feet from my ISY and put it next to a Aeotec repeater and the flipping (use your own curse word) does not work. I hit the "update neighbor" button, the "Synchronize" button, the "repair link" button and it just doesn't do squat. See pic. I see all sorts of device comms that say [ZWAVE-RX-ST } Send queue full Does anyone know what this means and how to resolve it? Does anyone know why the green icon is always on saying I need to write updates to the Z-Wave devices? I'm running firmware and UI 5.3.0 Thanks in advance for any suggestions. Wayne
Bumbershoot Posted January 19, 2021 Posted January 19, 2021 I don't know how to resolve the "Send queue full" issue, but you may consider installing the test firmware 5.3.1, specifically for this fix: 0000770 - Support old lock notification values I've only got one Schlage lock (an older lock, not Z-Wave +), and it's functionality is much improved over how it functioned on 5.3.0. Additionally, I've got quite a few Z-Wave devices, and none of them show the need to write updates anymore, specifically since I installed 5.3.1.
wrj0 Posted January 19, 2021 Posted January 19, 2021 5.3.1 along with two new Aoetec gen 7 repeaters (added to a gen 5 repeater and siren previously in place) resolved my communications problems with an old BE469.
wdhille Posted January 19, 2021 Author Posted January 19, 2021 Thanks for the input/advice. I upgraded to 5.3.1, and my first thought is no difference. I have more stubbornness than brains, so I'll keep trying. One thing for sure, if the lock connects directly to the ISY it works great. The issue is with the repeaters, or the way the lock or ISY interacts with them. It is just not ready for prime time. I have one repeater now (instead of making a mesh with 10) that has a robust connection to the ISY. It's 25 feet away.... When I move the lock away from the ISY so that it's only neighbor is the Aeotec Gen 7, it fails and seems to be nonrecoverable. Additionally, the repeaters still have the green icon showing that wants me to writer something to it. I'd like to write to it how badly this Z-wave stuff if, but that doesn't appear to be an option. Thanks Wayne
lilyoyo1 Posted January 20, 2021 Posted January 20, 2021 6 hours ago, wdhille said: Thanks for the input/advice. I upgraded to 5.3.1, and my first thought is no difference. I have more stubbornness than brains, so I'll keep trying. One thing for sure, if the lock connects directly to the ISY it works great. The issue is with the repeaters, or the way the lock or ISY interacts with them. It is just not ready for prime time. I have one repeater now (instead of making a mesh with 10) that has a robust connection to the ISY. It's 25 feet away.... When I move the lock away from the ISY so that it's only neighbor is the Aeotec Gen 7, it fails and seems to be nonrecoverable. Additionally, the repeaters still have the green icon showing that wants me to writer something to it. I'd like to write to it how badly this Z-wave stuff if, but that doesn't appear to be an option. Thanks Wayne Ive had nothing but problems with 5.3.1 and yale locks. I don't know what's changed but communication sucks. It was bad with 5.3 and only got worse. Hopefully @Michel Kohanimand Udi can get it back to where it used to be
wdhille Posted January 20, 2021 Author Posted January 20, 2021 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.
lilyoyo1 Posted January 20, 2021 Posted January 20, 2021 (edited) 1 hour ago, wdhille said: 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. Its not a mesh issue. I have about 30 zwave devices in my home. Different sensors and outlets that are in the same area work perfectly everytime. It's an issue that started with 5.3 and got worse with 5.3.1. Go back to 5.0.16 it works great again. It's also an issue in other homes that I use for testing as well. 5.0 16 works fine, 5.3.1 doesn't at all. All other devices are great otherwise... Just locks Edited January 20, 2021 by lilyoyo1
wdhille Posted January 20, 2021 Author Posted January 20, 2021 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.
DaveF Posted January 20, 2021 Posted January 20, 2021 Did you include the repeater in secure mode (Two presses on include)?
wdhille Posted January 20, 2021 Author Posted January 20, 2021 Dave, Do I need to do that with the Gen 7 Aeotec? I don't think it says anything about that??
wdhille Posted January 22, 2021 Author Posted January 22, 2021 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
DennisC Posted January 22, 2021 Posted January 22, 2021 9 minutes ago, wdhille said: 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 Have you checked your error log to see what else maybe going on? I have a Schlage zwave door lock and utilize an Aeotec repeater without an issue.
wdhille Posted January 22, 2021 Author Posted January 22, 2021 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
DennisC Posted January 22, 2021 Posted January 22, 2021 7 minutes ago, wdhille said: 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 No my lock is not.
wdhille Posted January 22, 2021 Author Posted January 22, 2021 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
wdhille Posted January 22, 2021 Author Posted January 22, 2021 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
Recommended Posts