Announcement

Collapse
No announcement yet.

Failed Sending Z-Wave Command to Device

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Failed Sending Z-Wave Command to Device

    I have a Kwikset lock connected and working just fine until the other day. I now regularly get the following error about 95% of the time. I even put in fresh batteries. What's the best way of drilling down to the root of the problem?
    Dec-22 08:34:54 Z-Wave Error Failed sending Z-Wave command to device: Locks Garage Access Door Lock
    Dec-22 08:34:51 Device Control Device: Locks Garage Access Door Lock to Unlock (0) by/from: CAPI Control Handler
    Dec-22 08:34:39 Device Control Device: Locks Garage Access Door Lock to Lock (255) by/from: CAPI Control Handler
    Dec-22 08:32:49 Z-Wave Error Failed sending Z-Wave command to device: Locks Garage Access Door Lock
    Dec-22 08:32:45 Device Control Device: Locks Garage Access Door Lock to Unlock (0) by/from: CAPI Control Handler
    Dec-22 08:32:22 Z-Wave Error Failed sending Z-Wave command to device: Locks Garage Access Door Lock

    #2
    I don't have an answer yet. I have 5 Schlage BE469ZP locks I installed in October. Since October 24 they were working well, though occasionally I would get an error when controlling them by Z-Wave. Earlier this month 3 of them dropped off the network (on 3 different controllers) within a day or two, two of them continue to work. While their nodes remained on the controllers, they would mostly report status changes, but would no longer respond to control, generating similar errors.

    I plan on posting at length later, but the short answer is that I had to attempt to exclude and include them again. This worked on one of them, the other two will no longer include. I will post in greater detail later, but I have no idea 1) why they dropped off and 2) how to get them working again.

    Comment


      #3
      I see this type of behavior with one of my Kwikset locks too. What I do to get it working again, is to reinitialize it, rather than resetting or excluding/including. On a Kwikset this is done by removing the battery pack, holding one of the buttons down on the control module, and then reinserting the battery pack. Not sure if the Schlage's have a similar mechanism to do so, but if they do, might be worth trying.
      HS 3.0.0.548: 1990 Devices 1172 Events
      Z-Wave 3.0.1.262: 126 Nodes on one Z-Net

      Comment


        #4
        Originally posted by sparkman View Post
        I see this type of behavior with one of my Kwikset locks too. What I do to get it working again, is to reinitialize it, rather than resetting or excluding/including. On a Kwikset this is done by removing the battery pack, holding one of the buttons down on the control module, and then reinserting the battery pack. Not sure if the Schlage's have a similar mechanism to do so, but if they do, might be worth trying.
        I have not found descriptions of reinitializing a Schlage. On a Schlage, if you hold the “Schlage” button on the keypad while connecting the battery it resets everything to factory defaults.

        I tried removing the battery for 30 seconds and pressing a few keys to completely drain any residual power and it made no difference. This whole lock thing is very frustrating for me. I had two BE469 (not Z-Wave plus) locks for a couple of years. They would occasionally error, but generally were reliable for a couple of years. I replaced those two and added 3 more BE469ZP (Z-Wave plus) locks in October. Besides being a complete nightmare to include in the first place, they would not work with the S2 version of the plug-in at all. Then the three just dropped out literally overnight. I had a set of Events that would check and lock all 5 at bedtime or when we left the house. These events ran for more than a month without failure or error, then a couple of weeks ago I started getting errors when the Events ran. Three of the locks ceased being controllable but they still reported manual or keypad control.

        Schlage is of absolute no help, stating that “HomeSeer is not one of our partner companies” suggesting that I move to “ one of their supported hubs”. I have a SmartThings hub on the way, just to see if the locks will work reliably with it. It will be here tomorrow. This might at least establish a baseline. My neighbor had Vivint install a system and 3 Kwikset locks earlier this year and he has not had a moments problem with them.

        The black art that is Z-Wave makes it very difficult to figure out where the problem lies. It reminds me of an old limerick
        There once was a girl with a curl on her forehead
        When she was good, she was very very good
        When she was bad she was horrid

        Comment


          #5
          I continue to see this about 4-5x week and can't figure it out. It's across a range of devices...usually older switches or plugs, but yesterday it happened with an HD100.

          Looks like it's maybe a latency issue, but I have polling off. sparkman has been helping me as well.... But still in dark.
          https://forums.homeseer.com/forum/ho...ftware/1341122
          ​​​​​​​

          Comment


            #6
            I'm also getting these once in a while with a new Yale lock but older model (Non Plus). When it happens I'm always able to Test connectivity without problem.
            • I had second taught about my lock selection but this post confirms that Schlage and Kickset are also affected.
            • I taught my Z-Wave network was to light with only (6) nodes. (3) Powered and (3) Battery. I tried bringing a powered unit closer and set that node as a route but still getting errors. But you guys have full scale Z-Wave networks
            • I'm now wondering if we all have Z-Net?
            Z-Wave polling is Off.

            It makes me nervous about how I can rely on the lock being actually locked. I ended-up engaging the Auto-lock feature that I wanted to leave off initially. I hate when I leave the door open for some reason and have the deadbolt lock itself. Both for now it is adding safety to the operation.

            Comment


              #7
              I have 5 Schlage BE469ZP locks. They are all Z-Wave
              • Lock 1 (Front Door) on Z-Net #2 (29 Nodes)
              • Locks 2 and 3 (workshop) on Z-Net #3 (23 Nodes)
              • Lock 4 (back porch) on HomeSeer SmartStick+ (11 Nodes)
              • Lock 5 on Z-Net #4 (17 Nodes)
              One reason I have that many controllers is because of locks. My primary controller had about 80 nodes and none of the locks would include with it. There was also problems with Remotec remotes. I also found that locks are completely unreliable unless they have direct communication with the controller (less than 25 feet)

              Comment


                #8
                You really went overboard and still you are getting some errors. I suppose we can now rule-out the Z-Net as well.

                I was thinking of upgrading the batteries to Lithium (Even if they are only a few weeks old) but I think Tomgru tried new cells on a different post with no change.

                A week or so ago I repositioned slightly my Z-Net as it was sitting on a metal rod shelf, next to other electronics and in the basement while my lock is in the garage, ground level. some 25 Feet line of sight with a wall in between. I would say it improved a bit. I'll try to improve that positioning somehow, sometime.

                My brother has a Vera+Schlage that I connect often to and never noticed a communication problem with the lock, but did not actively tried to operate it. I'll start trying to.

                Keep us informed of your test when you get your SmartThings hub.

                Comment


                  #9
                  FWIW, my z-net is only about six feet away from the lock and I don't have communication issues with other devices, battery operated or not.

                  I'm going to research some zigbee options since I have a raspbee along with JowiHue.
                  https://forums.homeseer.com/forum/li...91-zigbee-lock

                  Comment


                    #10
                    Just to recap :
                    1. It is not lock brand/model related as we have at least (3) different types.
                    2. It is not controller related as we have a mix of Z-Net, stick and maybe more. (Feel free to confirm)
                    3. It is not distance related since racerfern has his unit 6 Ft. away while Randy has (3) controllers all over.
                    4. It is not battery related as Tomgru tried brand new cells despite already having a reasonable life span left on the old ones.
                    5. It is not the way we script the commands as a single UI Unlock/lock command will also generate the same random error
                    6. It is not High traffic related as I have only a few Z-Wave devices.
                    7. Since we have at least (3) different brands it seems unlikely that they would have the same Z-Wave flaw (Unless using same chip)
                    Unless I'm missing something, for the moment, that leaves the Z-Wave plug-in itself and I'm not to sure how to test further. Without having a great knowledge about Z-Wave, I'm thinking of some-kind of protocol/command structure, time-out, beacon etc... issue. However, I would expect more error repeatability I suppose

                    If Randy is successful using a SmarThings hub that will put even more weight on the plug-in having a glicth.

                    Did not copy the thread's link but not long ago, while searching, I stumbled on a comment that a metal door could be an interference issue. Maybe we can rule this out as well if someone could confirm having a lock on a wooden door.

                    Comment


                      #11
                      Mine is a metal fire resistant door between the laundry room and the garage, however both the guts of the lock and the z-net are on the same side of the wall.

                      FWIW, I use a this doorlock script to track who unlocks the door since somehow HS3 doesn't capture it.
                      https://forums.homeseer.com/forum/de...cussion-thread

                      If I press lock or unlock in HS3 AND the lock doesn't move because of a failure sending the z-wave command then the script doesn't run. If I keep pressing lock or unlock until it does move, then the script records the change. So to me it's something in HS3 that's not happening.

                      Comment


                        #12
                        Originally posted by racerfern View Post
                        If I press lock or unlock in HS3 AND the lock doesn't move because of a failure sending the z-wave command then the script doesn't run. If I keep pressing lock or unlock until it does move, then the script records the change. So to me it's something in HS3 that's not happening.
                        Haven't looked at Sparkman's code but I would guess that it is triggering the script based on information received from the lock. When you press Lock/Unlock you are sending the command to the lock. Since it does not seems to make it to destination, the lock remains silent so no trigger.

                        Comment


                          #13
                          Haven't looked at Sparkman's code but I would guess that it is triggering the script based on information received from the lock. When you press Lock/Unlock you are sending the command to the lock. Since it does not seems to make it to destination, the lock remains silent so no trigger.
                          Yes, obviously. The point I was trying to make that for me, the event fails at the first step and never gets to the script, indicating the problem is in the z-wave plugin.

                          Comment


                            #14
                            I don't have anything definitive, but here is more data.

                            First of all, I decided to work extensively on my Z-Wave network yesterday. The first thing I did was to check for polling. I have it disabled on almost everything. I went to the Node information page and examined the entire network node by node. I found several Aeotec and Zooz smart strips and smart switches had polling intervals set on every device except for the root. This is an ongoing problem with HomeSeer that I knew about, but forgot about. If you rescan a device polling can be scheduled automatically. These were fairly conservative polling rates of 20m, XXs. I don’t recall rescanning them, but I am certain they had polling disabled when I checked a few months ago. I edited these device (a total of 50-60) to remove polling. Be sure to check polling if you rescan a device.

                            Then I enabled "Log send and receive device information to the HomeSeer log" on the plug-in configuration page. This allowed me to look at traffic. It was substantial. The biggest culprit were 4 Zooz smartstrips. I dug into the parameters and found that by default they report energy when it changes by more then 5 watts. I noticed that many of the strips were reporting energy every second. It seems that they will report everything when they report anything. So I was getting watts and KWH on all 5 outlets once a second. On these strips I set Parameter 2 to disable reporting on threshold. I set all of them to report wattage either at 60 or 120 second intervals, they were all at the default of 30 seconds. I changed KWH reporting from 300 seconds to 3600, as this is not a very important report for me. The problem is that the strips do not have any exposed settings in HomeSeer, only by checking and setting parameters can you determine what they are doing. I am normally better at checking these things, I don't know why I neglected to on these strips. Next time I will RTFM. I also have a handful of new Zooz ZEN25, ZEN15 and ZEN07. I also carefully set the relevant settings on all of these. I also went through all of my other energy reporting devices (Quite a few Aeotec strips and modules and a few Enerwave outlets).

                            All of this cut the number of send/receive entries in half. It also seemed to eliminate all issues of slowness in the network. While we never saw substantial delays, we would occasionally see a second or two of delays in response to motion, remotes, etc. My House to Sleep routine ran noticeably quicker, This routine checks all lighting and power and we would always see it take 15-20 seconds before the last step of turning the bedroom lights off. The bedroom lights are on a 10 second delay. After working on the network, last night the house to sleep completed in 10 seconds. We were also seeing 20-30 random Z-Wave errors each day, so far today there have been 0. Yesterday after working on the network there were 0. There were 15 earlier in the day, some during my testing.

                            I received a replacement lock for my back porch (#4) on Friday. Yesterday after working on the network, I was still unable to include the original lock. It would not initiate inclusion, despite being freshly reset. I replaced the lock and was able to include the new one on the first try. This is with a Smartstick+ about 10 feet away. Feeling confident I decided to try the Master Bedroom lock again. This was another that would not initiate inclusion after I successfully excluded it last week. It connects to a Z-Net about 20 feet away, through the door and another wall in my shed. The door is steel. It included instantly and correctly with HomeSeer (Z-Wave 3.0.1.252).

                            Now all 5 of my locks were back in place and working. I edited all of my lock control Events for lock #1 (re-included), #4 (new lock) and #5 (re-included). Testing yesterday afternoon proved all the locks were (mostly) working. I did get one lock to go to "Unknown" but this was during rapid fire testing. One thing I know about these locks is that they will fail if you control them several times in quick succession. The Events I use to lock at night or when we leave home have delays built in so that commands are sent about 2 seconds apart. These Events ran several times in testing without an Error. Last night when we initiated House to Sleep, it checked all 5, locked 2 without an Error.

                            So... It looks like the biggest problem in my Z-Wave network was the ridiculous amount of energy reports being sent. I don't think the polling had much to do with it. Now I need to see how it does for the next week, but for now, the network is more stable, quicker, free of errors and all 5 locks are working again. Unfortunately, I do not know if my locks would have started working again, since I had excluded the three that refused to be controlled. It is entirely possible that I had so much traffic the locks could get a command, but keep in mind two of them were still working. I will continue to keep an eye on them, but I am confident I made substantial improvements in my network. It is still very busy, but about 1/2 of what it was. I think the lesson to be learned is that Z-Wave can succumb to too much traffic.

                            On a side note, I disable all command logging as a matter of practice. I think the logging also uses resources. The downside is that I didn't see all of these commands in the log until I enabled the send/receive logging in the plug-in. I now know to pull that additional arrow out of the quiver when I am seeing problems.

                            Now for the next thing. I received the SmartThings hub today and installed it. The installation was quick and easy. I installed it as a WiFi hub. I really do not like the interface, but that is for another day. I then took the lock that I replaced (due to be returned to big box tomorrow) and successfully included it first try from about 10 feet away. It is the only Z-Wave device on this hub. The lock is not mounted to a door, so I was able to take it all around the house, even outside. The SmartThings hub is able to control the lock anywhere within 30-40 feet of it. Right now the lock is on the back porch and the hub is on my desk in my office. There is more than 40 feet and 3 walls between the lock and it still can be controlled as well as reporting status. If I send commands to the lock rapid fire, it balks, just as they do under HomeSeer.

                            I don't think I have proven anything, since the SmartThings hub only has a single device paired with it. It may have problems when there are 20-60 as there are on my HomeSeer controllers. I have no idea why the lock successfully included with SmartThings where it wouldn't with a SmartStick+ (12 nodes). For the record I will update what I wrote above:
                            • Lock 1 (Front Door) on Z-Net #2 (29 Nodes) Steel door - continued to report, but quit responding to commands about two weeks ago
                            • Locks 2 and 3 (workshop) on Z-Net #3 (23 Nodes) #2 wood door #3 steel door - both continue to report and control since installed in October
                            • Lock 4 (back porch) on HomeSeer SmartStick+ (11 Nodes) Steel door - continued to report, but quit responding to commands about two weeks ago
                            • Lock 5 on Z-Net #4 (17 Nodes) Steel door - died altogether about two weeks ago. Found dead batteries last week, fixing reporting, but still failed commands.
                            I have always felt that Z-Wave (at least with HomeSeer) is fragile, but my system has been really good for a couple of years until of late. All of that seems to have begun when I went for so many Zooz devices. It is clear that my problems were self-imposed by not carefully configuring these new devices. Now that they are properly configured and reporting has been minimized, it seems my network is back to being as reliable as it once was. I haven't been able to prove anything other than traffic matters on a Z-Wave network.

                            I will continue to play and If I see anything else I will post back here. The first thing I would recommend to any of you chasing problems is to to look very carefully at your Z-Wave network node by node and check polling, reporting and routing.

                            Comment


                              #15
                              rprade - Well, you certainly opened a can of worms didn't you?!?!?

                              I'll get back to this thread in a couple of days after I drill into a bunch of Aeotec outlets and Zooz switches and who knows what else.


                              Comment

                              Working...
                              X