Announcement

Collapse
No announcement yet.

Failed Sending Z-Wave Command to Device

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

    #31
    Originally posted by sparkman View Post

    While it’s a great utility, it does not show “exactly” what traffic is on the network, only what may be generated through events.
    I agree - just used it, and it's nice but not for what the problem is here.

    I went ahead and turned debug on & studied again. 2 separate 1.5 hour logs that I put into spreadsheets as a before / after. I had done this before & trimmed down a lot of traffic. Trimmed a little more today,

    Comment


      #32
      As a final note on this thread (at least for me), because of the efforts to control polling that tends to create a logjam, I no longer have communication issues via Modbus to my SolarEdge inverter. Life is good.

      Comment


        #33
        Originally posted by racerfern View Post
        As a final note on this thread (at least for me), because of the efforts to control polling that tends to create a logjam, I no longer have communication issues via Modbus to my SolarEdge inverter. Life is good.
        It is amazing how busy Z-Wave can make the system. It is also amazing how much better EVERYTHING is when you tame it.

        It also pays a small dividend to turn off logging on particularly chatty devices.

        HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

        Comment


          #34
          Originally posted by Michel View Post
          ...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...
          I haven't got a failed command since December 28th (touch wood). Again my Z-wave population is minimal so that was taking some potential problems off the list. I had already turn-off polling and reduced my HEM reporting with no luck.

          My Z-Net is in the basement, 25 Ft. from the lock in a garage with a concrete wall in between. Then, between the wall and the lock sits our car, a Chevrolet Volt with batteries, charger, high voltage...if my micro-wave can kill my 2.4Mhz Wi-fi, what can that car do? When I started having Failed commands I quickly moved a non-mechanically installed HS valve (Z-Wave Plus) between the Z-Net and the lock, hoping to improve the network reliability but no improvement.

          I stumbled on an old post from Rick Tinker, explaining Z-wave. The "Beacon" feature used by locks draw my attention as I was anyway wondering how this battery device could be listening for commands (Lock/Unlock) without always being ON. My understanding is now that the controller issues a command. That command is held in buffer until the locks sends a beacon (1000ms) and wakes-up to receive the command if there is one. That minimal beacon wake-up being more energy efficient then staying ON. It is also my understating that the "Command" can also be held in buffer by a nearby device, as long as it is a secured device.

          That valve was plugged-in when I received it and just did not get a chance to install it yet (aka over a year) so it could be plug into any outlet. That got me thinking that when I added the valve to the network, that was my first or maybe second Z-Wave device and I was far from convinced that I had selected the regular "Include" or the "Non secure" one. So to be on the safe side, I excluded the valve and re-included it in the regular secure mode and it now seems to work as expected.

          Time will tell but so far so good.

          Comment


            #35
            I thought I'd share my current frustrations in the event it could shine a bit of light on the situation. My setup is extremely minimal as I only have the ZWave controller and a single Schlage lock (Insteon for the rest of my automation). The lock becomes non-communicative about once per week with the usual message about being unable to send messages to the ZWave device.

            For me, a simple disable and re-enable of the plugin fixes the problem. Until the next time...

            I'm inclined to find a way to automatically restart the plugin every day.

            Comment


              #36
              Just want to share that I still have not seen that communication fail message even once since I wrote the previous post.

              What I would try, if I were in your position, would be to install at least (1) ZWave+ powered device, between your ZWave controller and your Lock. Possibly a ZWave+ wall switch. I would try to find a location kind of half way but tending to be closer to the lock then to the ZWave controller. The PLUS is important as regular ZWave does not qualify for secure message buffering.

              Again, the theory is that the powered ZWave+ device will :
              1. More reliably receive the command from the Controller, being powered thus always listening.
              2. Hold that secured command in buffer (ZWave+) until the lock sends its next 1000ms listening beacon.
              Good luck.

              Comment


                #37
                I have 4 devices that constantly do this (of the 80 or so in total). Of course, one of the four is the lock (Yale) but the other three are Z-Wave Plus (Qubino and Ecolink). I did all kinds of network fiddling, including segregation of the Qubinos to a separate, Z-Wave Plus - only network but they did not seem to care.

                For the lock, my solution is to monitor the command execution and send retries if the command fails. The retries are 30 seconds apart. I limited the retry count to 5 but HS is not very persistent, by the third retry, it gets convinced.

                Comment


                  #38
                  and myself both had this issue that also involved locks. In our case it was excessive activity on the z-wave network that was mostly caused by polling. In HS3 I checked every parent/child and eliminated all polling. The problem went away. It's amazing how much polling goes on that never shows up in the log.


                  Comment


                    #39
                    Originally posted by Michel View Post
                    Just want to share that I still have not seen that communication fail message even once since I wrote the previous post..
                    Guess I need to retract on this one. I had kind of forget that I also had implemented a (3) minutes auto-lock on the Yale thus patching the problem if a Failed command was encountered. Just looked at my log and I do still get Failed commands from time to time.

                    Comment


                      #40
                      Originally posted by Michel View Post
                      Guess I need to retract on this one. I had kind of forget that I also had implemented a (3) minutes auto-lock on the Yale thus patching the problem if a Failed command was encountered. Just looked at my log and I do still get Failed commands from time to time.
                      As bad as polling is, I solved the dreaded Z-Wave lock failed phenomenon with exactly that.

                      I have auto-locking OFF and an event that will engage the lock only when the door is detected as closed - PLUS a 10 second delay that then forced a POLL. What this means is that if a Z-Wave failure occurs and the lock is incorrectly considered "locked", it suddenly changes to be "unlocked".

                      I have a second event that detects a spontaneously lock > unlock change WHILE the door is still shut for a short length of time - it will then re-run the above event plus send me an email that it occurred. This therefore means the sequence starts all over - the lock engaged, 10 second delay, and a poll.

                      80% of the time the door simply locks on its own - great. 15% of the time I get an email advising the above fix kicked in - great. 5% of the time I get 2 or even 3 notifications of fix attempts - so lucky I have the above in place as this therefore mean for a minute or so the front door was still unlocked and my system auto-corrected it.

                      Hope this maybe helps?

                      Comment


                        #41
                        Very frustrating, 2 locks and 8 other devices just dropped off my networks (3 on one controller, 3 on another and 4 on a 3rd controller)for no reason yesterday evening. The system has been flawless for 6 months and I have not touched anything. I managed to get 1 device to communicate again with a power cycle, but the remaining 7 (not locks) were fixed by exclude/include. The two locks would exclude, but will not include. I am running the 3.0.2.0 Z-Wave plug-in, IIRC I was using 3.0.1.252 before, but it has been removed from availability.

                        It is very frustrating to have to go through this so often, without any clue as to why they are dropping off.

                        When I was testing in December, I tried including the locks with a Samsung Hub and they included reliably. I no longer have that controller.
                        HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                        Comment


                          #42
                          I have never experienced, what I would consider, reliable Z-Wave service.

                          I dread whenever I have to include or exclude device as it always screws other devices up.

                          Sent from my LM-G820 using Tapatalk

                          RJ_Make On YouTube

                          Comment


                            #43
                            Main inclusion issues I have:
                            1. I sometimes need to include devices multiple times, because the first time or two there are missing child objects
                            2. My front door lock is S2 but even rubbing the Z-Wave stick directly against the actual lock itself it gets included S1
                            3. On rare occasion the Z-Wave plugin stick and/or plugin crashes during inclusion and I have to do a restart

                            Comment


                              #44
                              I am not as concerned with inclusion/exclusion as I am for 13 devices going MIA (across 3 different controllers) all at once. This same thing happened last December. The nodes still exist in the controllers, but the devices stop communicating. Two of the devices, both Aeon labs smart strips, began working with a power cycle, 2 of the the 3 thermostats required exclusion/inclusion one began working with a power cycle. The Aeotec Smart Dimmer 6 need exclusion/inclusion. I still have 2 Enerwave outlets (out of 5), 2 Jasco outlets (out of 6) and a HomeSeer HS-WS200 to try power cycling.

                              I strongly suspect that something is putting out Z-Wave noise, garbage or traffic, since some of the devices are in a bad state corrected by a power cycle. I don’t have any way to determine why other devices require exclusion/inclusion, I can only guess that they have somehow reset or lost their link to the HomeID. The 2 thermostats do indicate they are still included, but required exclusion/inclusion to begin communicating again.

                              WRT the locks, I am convinced that traffic, primarily energy reporting, is causing the inclusion to fail.

                              While repairing the failures is time consuming, the collateral damage is worse. Having to repair Events, graphing and other things dependent on a reference ID of a replaced device. is far worse. Unfortunately there is not a viable replacement for a Z-Wave lock. I still wonder why the Samsung hub worked so quickly with the locks, but it could be simply that they were the only devices communicating with the controller.

                              I also have to wonder how Z-Wave deals with traffic across multiple controllers in a single dwelling. I would think that the collision detection and avoidance would only work within a single HomeID, not across several networks sharing the same RF spectrum. The problem is that I have been able to prove that locks and some Z-Wave remotes will not work on busy controllers. I had to add 2 just to get a pair of locks to work reliably. Maybe the new 700 series devices will address some of these problems, though I don’t have high confidence.
                              HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                              Comment


                                #45
                                Is Z-wave becoming the new X10? Is the application of the technology exceeding its design limits? These kinds of semi-mysterious issues sound suspiciously familiar.
                                Mike____________________________________________________________ __________________
                                HS3 Pro Edition 3.0.0.548, NUC i3

                                HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

                                Comment

                                Working...
                                X