Announcement

Collapse
No announcement yet.

hs3 command timers; issues of .280 vs .96

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

    hs3 command timers; issues of .280 vs .96

    Hello,

    I upgraded from 3.0.0.96 to 3.0.0.280 version last night and immediately noticed issues with command frequency. In summary, it appears that the same device is on a "timeout" period once a command is sent. It seems to be somewhere around 7-8 seconds for sequential commands to the same device .

    1. a command is sent
    2. a second command is sent almost immediately
    3. the log shows "failed to send z-wave command to device xx"
    4. the second command gets executed 7-10 seconds later or not at all.

    is there a way to reduce the delay ? ideally to 0. This is causing issues with devices such as thermostats where a command sequence of set temp to x, set mode to auto is buffered and fails in 50% of the time...

    if there is no artificial delay, does anyone have similar issues with .80 version of the z-wave plugin?

    #2
    I tried optimizing but what I get back during optimize or an individual node scan is this

    "the optimization was not executed as the node cannot be reached "


    this message is repeated for every node in the database, yet , when I'm sending a command to a node it executes, with a 10 second delay... I'm lost here ...

    Comment


      #3
      The solution appeared to be ol' and tried reboot of the controller.
      Unplug the batteries from the controller, re-plug and all now seems to work well.

      Messed up routing would result in some nodes being reachable sometimes, or never, while others would succeed... inconsistent data delivery is also possible. In this specific case, the delivery was very consistent, just 10 seconds delayed on a command level.

      I did a bit of tracing, and when I saw that the first discovery frames would result in responses succeed and the second one would fail due to 10 second delay (i.e. controller got the message, but no RF transmission). It looked like hardware... unplugging the controller didn't do the trick, I had to pull the batteries out and make sure the thing really went down.

      All (seems) to work properly now. Full optimization is running without issues.

      Could someone on the development side send a reset command to the controller on plugin update?
      Last edited by arthurmnev; May 22, 2016, 11:12 PM.

      Comment


        #4
        It sounds like you might have the Z-troller. It has been recommended in the past that you only put batteries in them when you are performing a remote Z-wave exclusion/inclusion. I certainly had a few lock-ups with mine back in the day and they seemed to be less frequent without batteries.
        cheeryfool

        Comment


          #5
          spot on, z-troller it is

          Comment

          Working...
          X