Announcement

Collapse
No announcement yet.

Failed Sending Z-Wave Command to Device

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

    #16
    , excellent write up as usual. Thanks.
    Michael

    Comment


      #17
      I dunno, I guess I've become so accustomed to seeing Z-Wave "failed to send command to" errors that I barely notice them anymore.
      I've just had a quick look at the log since I last restarted HS3 back on the 17th. I see 11 such errors on 5 different devices, only one of them being a lock (one instance) that has historically been a huge problem for me. Only one of these devices is Z-Wave+.

      One Intermatic appliance module - five instances. (Polling at 10 minutes was enabled on this and shouldn't have been. Turned off now).
      Two Leviton dimmer switches - three and one instance respectively (the two are on adjacent walls). Neither is polled.
      One Schlage lock - one instance. Not polled.
      One FLS-100 - one instance. Not Polled.

      The oddest thing is that all of these devices are among those physically closest to the Z-Net, and coincidentally, the error frequency is exactly proportional to the distance from the controller, decreasing with increased distance. This may be entirely coincidental however.

      A while back I embarked on a project to re-send commands at 60 second intervals when a failure occurred. This seemed to exacerbate the problem however as, especially with the lock I would be sending a lock command repeatedly until the lock reported success and too frequently the lock would just hang and not respond at all, even from the lock/unlock buttons on the door. The only solution when that happened was to pull the lock off the door, completely reset it and go through the whole exclude, include, scan, optimize routine with fresh batteries (the battery had almost completely drained).
      I quickly abandoned that project.

      More recently, when I see a send failure, which is more likely IMO a failure by HS to receive or recognize a response, I've just re-optimized the individual offending device several times. This more than anything else I've done seems to have reduced the frequency of these failures. Instead of the eleven errors I have in my log now over the past seven days, I would normally have been accustomed to having seen as many, or more, in the course of one day.

      All this said, I'm pretty sure all of these errors will have occurred at times when multiple devices were controlled in quick succession.
      For instance,
      When I leave my office and the motion sensor turns off (x10RF sensor), an event turns off three Z-Wave devices at once.
      When motion is detected or stops in/near the laundry room, the two Leviton switches are activated at the same time. This is controlled by a Z-Wave motion sensor.
      At bed time, all of the lights are checked and turned off, and then three Schlage locks are told to Lock. All of this occurs within about 10 seconds (a lot of traffic).
      Finally, I have an Alexa event to turn off all of the outside lights at once by voice command. (Includes 3 FLS-100s and several other Leviton switches).

      Does all of this point to the Z-Wave plugin? Too much traffic perhaps to handle at once? RF Collisions maybe that the single controller can't process?
      I will say that under HS2 with a Z-Troller, until I finally moved to HS3 in April this year, then later replaced the Z-Troller, first with a Z-Stick and now a Z-Net, I rarely if ever saw any of these errors.

      With HS4 being the focus right now, it's unlikely we'll see any work done on the Z-Wave plugin for some time.
      Real courage is not securing your Wi-Fi network.

      Comment


        #18
        . Very detailed post. Thanks for sharing your investigation results.

        For me the problem occurred very shortly after installing my lock. Since I had made attempts to translate a few expressions I blamed my self for the errors. From there I've excluded the node and since I had played previously with optimization etc... and also a year ago got rid of a few Z-Wave T-Stat, I decided to back-up by Z-Net and then restored, in order to reset routes and free-up unused node numbers. Then I've included the lock without any attempt to modify not event it's name. Since Test Connectivity was good for all nodes I left it like that with no further attempt to optimize. The failure came back.

        As I mentioned in my previous post, I was somewhat ruling out high Z-wave traffic collisions as I have so few devices that if Z-Wave cannot handle that, it can't handle much.

        1 x Z-Net
        2 x HS Door sensor with very few openings
        1 x HS Valve (Not mechanically installed or included in any event yet)
        1 x Yale Lock (one event)
        1 x Aeon Multi 6 (USB Powered) (Reporting on value change)
        1 x Aeon HEM (Reporting on value change)

        Z-Wave polling is off in the plug-in config page (3.0.1.252) and only (3) polling per 12 Hours for the battery operated devices.

        I also tried turning-on Send-Receive logging. Like any other debug log it seems overwhelming to see constant logging, mainly from the Multi 6 and HEM but there are also empty zones of 5-6 seconds. Again my Z-Wave network is minimal. My main network was built around Insteon and my Night routine commands over (20) devices flawlessly each time. One would assume that Z-Wave was built to spool commands, shall a busy peak arises.

        Before enabling the Auto-lock feature, my event was simple. If door is closed (X10RF) and Yale has been unlocked for 10 Sec. (To avoid rapid fire from open-close door quickly) then lock Yale. Do not re-trigger for 5 Sec. What bothers me is that when the lock command was failing, it was failing for many retries and after maybe 5-6 retries (so +/- 35-40 Sec.) it would eventually lock. If is was traffic related, with my basic network, it could have failed once but not five time in a row. And what makes that suddenly the 6th attempts works? I have many X10 motion sensor and do have collision once in a while. I will have 1 but not 2 or more. And I fully understand that there is no acknowledgement process with X-10.

        We also need to keep an open mind about the possibilities of having different problems causing similar Errors. Ex.: Distance for someone, High traffic for another etc...But I'm still not ruling-out the plug-in yet. When I have more time I'll try turning on Send Receive logging enough to maybe catch the pre and post error logs.

        Please keep feeding this thread with your SmarThings testing. Not that I'd like to switch to that but I find it interesting to see if it is reliable.

        Comment


          #19
          I've started seeing these errors occasionally, usually associated with a WD-100 switch. This and other strange behaviors seem to have started since my system auto-updated to version 548. Prior to that I had about a year of nearly problem free operation.

          Comment


            #20
            Power reporting for me has caused lots of problems, and it took me a long time to find out that it was power reporting flooding my network. I have started replacing power reporting on/off modules with ones which do not report power, and others where ther are parameters I scaled back power reporting. I have sold a lot of Greenwave on/off modules, they were great cheap on/off modules with power reporting, but no way to control the reporting. This has made my network more responsive, but there is still work to be done. I still have lots of Everspring on/off modules, and I cannot find any parameter setting to scale back the reporting. I have 5 Fibaro RGB modules to be installed soon, but on purpose did not go for the zwave+ version as they report power... Its a shame as its nice to see (and sometimes useful for logic too) but I am now really selective of where do I really need it.

            Comment


              #21
              Originally posted by Wadenut View Post
              I dunno, I guess I've become so accustomed to seeing Z-Wave "failed to send command to" errors that I barely notice them anymore.
              I've just had a quick look at the log since I last restarted HS3 back on the 17th. I see 11 such errors on 5 different devices, only one of them being a lock (one instance) that has historically been a huge problem for me. Only one of these devices is Z-Wave+.
              I have as well, but this exercise was begun because three of my locks became permanently uncontrollable virtually overnight, yet two of the three would report changes of status. That coupled with the fact that I could not exclude/include them again maid me dig deeper. I also was accustomed to seeing a few random errors daily, but the quantity began ramping up significantly over the last couple of months, culminating in the lock failures.

              I will say that two days in since the rework I did Sunday, there have been none. At least subjectively, this exercise yielded huge improvements. YMMV

              HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

              Comment


                #22
                Is anybody familiar with what that section of the Z-Wave plugin is telling us? Some are self explanatory but I'm confused about "MGD" and "Report Buff"

                Click image for larger version

Name:	Capture.jpg
Views:	545
Size:	11.3 KB
ID:	1349505
                Also. My perception of the "beacon" on a battery operated lock is that every 1000ms the lock will turn-on communication, letting HS know it is ready to receive a command, if there is. If for some reason HS has a command before the next beacon, it is held in Q. Am I way off?

                Comment


                  #23
                  FWIW. I'm finding similar threads both on Vera and SmarThings forums.

                  Comment


                    #24
                    Once in a while my Yale lock doesn't lock - HomeSeer logs a "failed sending Z-Wave Command to Device" and does it's silly move of then assuming and flagging it as the intended result (locked) but putting the "Unknown" status icon on it. Insanely dangerous move by HS3 IMHO as all calls to HomeSeer thereafter insist it is "locked" when in fact it did not and is in an "unknown" state.

                    Although it only happens once in a blue moon, my home is left unlocked as a result so I've therefore invested countless hours into solving this.

                    My solution ended up being really simple:
                    1. When I detect the door is closed I automatically lock the door as usual - BUT then wait 10 seconds and force a poll on the door lock. IF the lock command failed but HS3 flagged it as locked the status now reverts back to its true status of "unlocked".
                    2. I have a second event that is set to lock the door if it is unlocked but not opened within 10 seconds - this automatically triggers because HS3 considers the above to be an "unlock" and of course the door is closed. I modified this event to call the above lock event so the wait and poll commands are repeated.
                    I have already seen this kick in twice - after say 15 successful door lock requests one will fail, 10 seconds later HS3's incorrect lock status reverts to unlocked, and 10 more seconds later the door then successfully locks (had it failed again this process would have repeated until it eventually worked). I have an email trigger set up as well so I am notified of a failed and then repeated door lock event.

                    Simple in the end but took countless variations before coming up with this because of the whole complication with HS3's "unknown" yet "incorrectly known" status phenomenon.

                    Comment


                      #25
                      Everyone's system is different but what worked for me was to check and eliminate excessive polling. Zooz and Aeotec were the biggest offenders followed by Qubino. It's amazing how much bandwidth all these unseen reports gobble up. Since cleaning things up, I haven't had one "Failed Sending..."

                      Comment


                        #26
                        "Z-Wave polling is off in the plug-in config page (3.0.1.252) and only (3) polling per 12 Hours for the battery operated devices."

                        this is still confusing me as I'm getting conflicting answers. If global polling is turned off from the config page, doesn't that overwrite any individual polling settings for a specific node?

                        Comment


                          #27
                          Originally posted by Tomgru View Post
                          "Z-Wave polling is off in the plug-in config page (3.0.1.252) and only (3) polling per 12 Hours for the battery operated devices."

                          this is still confusing me as I'm getting conflicting answers. If global polling is turned off from the config page, doesn't that overwrite any individual polling settings for a specific node?
                          When it is turned off in the Z-Wave config page, mine stops all scheduled polling. I’ve tested it. I can’t speak specifically to battery operated devices, but Jasco switches and outlets as well as my other first gen Z-Wave devices do not generate any polling messages when disabled on the config page. I see no reason for battery operated Devices to ignore the setting. To the best of my knowledge what I wrote above is correct. Automatic polling is generated on the schedule set on the HomeSeer Device’s Z-Wave tab. The setting on the config page stops all of the scheduled (automatic) polling. That setting has no effect on polls generated from an Event or manually through the Device Manager page.
                          HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                          Comment


                            #28
                            Originally posted by rprade View Post
                            When it is turned off in the Z-Wave config page, mine stops all scheduled polling. I’ve tested it. I can’t speak specifically to battery operated devices, but Jasco switches and outlets as well as my other first gen Z-Wave devices do not generate any polling messages when disabled on the config page. I see no reason for battery operated Devices to ignore the setting. To the best of my knowledge what I wrote above is correct. Automatic polling is generated on the schedule set on the HomeSeer Device’s Z-Wave tab. The setting on the config page stops all of the scheduled (automatic) polling. That setting has no effect on polls generated from an Event or manually through the Device Manager page.
                            Ah...that helps. Thanks

                            Sent from my SM-G975U using Tapatalk

                            Comment


                              #29
                              The tenHsEvents is a great utility to see exactly what traffic is on the Z-Wave network.

                              http://tenholder.net/tenWare2/tenHsEvents/default.aspx

                              Comment


                                #30
                                Originally posted by RGMessick View Post
                                The tenHsEvents is a great utility to see exactly what traffic is on the Z-Wave network.
                                While it’s a great utility, it does not show “exactly” what traffic is on the network, only what may be generated through events.
                                HS 4.2.8.0: 2134 Devices 1252 Events
                                Z-Wave 3.0.10.0: 133 Nodes on one Z-Net

                                Comment

                                Working...
                                X