Announcement

Collapse
No announcement yet.

Device (Node 38) woke up, but queued command failed to be sent. Command=Poll Device

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

    Device (Node 38) woke up, but queued command failed to be sent. Command=Poll Device

    I've started getting this error every day, on a door open sensor. It works fine (it triggers when the door opens) but I see

    Device (Node 38) woke up, but queued command failed to be sent. Command=Poll Device

    The only thing that's changed in my system is that I've installed the SDJ Health plugin. Any idea what this error means?

    #2
    Originally posted by mlevin77 View Post
    I've started getting this error every day, on a door open sensor. It works fine (it triggers when the door opens) but I see

    Device (Node 38) woke up, but queued command failed to be sent. Command=Poll Device

    The only thing that's changed in my system is that I've installed the SDJ Health plugin. Any idea what this error means?
    You went silent in the thread you posted in the SDJ-Health sub-forum so I don't know how you got on.

    The error above means that HS has queued a poll request for the device and then when the device has woken up it has gone back to sleep again before responding to the request. HS retries at the next wake-up, and on and on. Sometimes it can just be an intermittent communication issue (network busy) and will be resolved at the next wake-up but it can indicate other issues.

    First thing to determine is 'why is the device being polled'. Check the details for that node in 'PLUG-INS>Z-Wave>Node Information' to see if you have automatic polling set for the root or any of the child devices for that node. They should all say 'Polling Disabled'. It might be set for the Battery Child, although most modern battery devices don't need to be polled, they send a reading when the battery level changes. So, depending on the actual device you may want to disable polling of the battery device.

    You can poll from an Event action but it is unlikely that you have configured an event to do that accidentally.

    The other possibility is that a Plug-in is polling the device. SDJ-Health won't poll non listening devices but it is possible that HS has the device configured incorrectly. If it is a device that can be run on power or battery and you 'include' it on power and then change to battery HS might think it is a listening devices (supports status) when it doesn't. Again in the node information, viewed as above, after 'Manufacturer:', 'Type:' and 'ID:' it has 'Listens:'. Does it say Yes or No against this? Also if you go to the Advanced Tab of the Root device against 'Supports Status' does it say True or False?

    You will need to restart the Z-Wave plug-in to clear the poll queue or else any queued polls will continue.

    Steve

    Comment


      #3
      > You went silent in the thread you posted in the SDJ-Health sub-forum so I don't know how you got on.

      apologies, I got snowed under with work. I will be getting back to this over the weekend, going carefully over the manual and reporting back to the thread.

      > First thing to determine is 'why is the device being polled'. Check the details for that node in 'PLUG-INS>Z-Wave>Node Information' to see if you have automatic polling set for the root or any of the child devices for that node. They should all say 'Polling Disabled'.

      aha! It was set with polling according to the below, so I set it to 0:00:00.Click image for larger version  Name:	Screen Shot 2020-08-19 at 9.09.47 PM.jpg Views:	0 Size:	50.5 KB ID:	1412631
      What is the polling for? Should I not have battery devices (this is a water sensor) being polled?
      I'm still getting the error - will the queued polls run out at some point?

      Comment


        #4
        Originally posted by mlevin77 View Post
        > You went silent in the thread you posted in the SDJ-Health sub-forum so I don't know how you got on.

        apologies, I got snowed under with work. I will be getting back to this over the weekend, going carefully over the manual and reporting back to the thread.
        No problem.

        Originally posted by mlevin77 View Post
        > First thing to determine is 'why is the device being polled'. Check the details for that node in 'PLUG-INS>Z-Wave>Node Information' to see if you have automatic polling set for the root or any of the child devices for that node. They should all say 'Polling Disabled'.

        aha! It was set with polling according to the below, so I set it to 0:00:00.Click image for larger version Name:	Screen Shot 2020-08-19 at 9.09.47 PM.jpg Views:	0 Size:	50.5 KB ID:	1412631
        What is the polling for? Should I not have battery devices (this is a water sensor) being polled?
        I have an Everspring Leak Detector but it is an older version than yours. Mine does require the battery device child to be polled so I have that set at 12 hours. The batteries last for ever (4 and a half years and counting with mine) so it would be a long time before you discovered whether the device sends out battery levels without polling or not. If you can't find anything definitive in the manual you are best off leaving the polling set at 12 hours on the battery child but turn off polling on the other child devices. One poll on the battery every 12 hours shouldn't cause any problems whether it is needed or not.

        For a non listening battery device polling is queued until the device wakes-up, which might only be every 12 hours. If the device detects a leak it sends a warning immediately it doesn't need to be polled. Test it by dipping the probes in water.

        Originally posted by mlevin77 View Post
        I'm still getting the error - will the queued polls run out at some point?
        Originally posted by SteveMSJ View Post
        You will need to restart the Z-Wave plug-in to clear the poll queue or else any queued polls will continue.
        I hope that helps.
        Steve

        Comment


          #5
          ok, I clicked on the checkmark for the interface, it deactivated (turned into a red circle with a line through it), but when I clicked it again to restart it, I now see this - something is wrong, the interface is listed twice??

          Click image for larger version

Name:	Screen Shot 2020-08-20 at 8.53.57 PM.jpg
Views:	64
Size:	59.7 KB
ID:	1412909

          Comment


            #6
            Originally posted by mlevin77 View Post
            ok, I clicked on the checkmark for the interface, it deactivated (turned into a red circle with a line through it), but when I clicked it again to restart it, I now see this - something is wrong, the interface is listed twice??

            Click image for larger version

Name:	Screen Shot 2020-08-20 at 8.53.57 PM.jpg
Views:	64
Size:	59.7 KB
ID:	1412909
            Restarting a plug-in means going to ‘PLUG-INS>Manage’ and clicking the green Enable switch corresponding to the plug-in, Z-Wave in this case, to disable it. Wait 10 seconds or so and then click again to restart it.

            Steve

            Comment


              #7
              ah, that's it, I may not have waited 10 seconds. I ended up closing HS3 and starting it again, now it looks normal. However, now I'm getting the same error about a different node. Probably that one has the same setting issue, but I wonder why it wasn't showing up as an error before.

              Comment


                #8
                Originally posted by mlevin77 View Post
                ah, that's it, I may not have waited 10 seconds. I ended up closing HS3 and starting it again, now it looks normal.
                For future information the point I was making is that you were changing the sate of the interface you weren't stopping and starting the plug-in. You were in 'PLUG-INS>Z-Wave>Controller Management'. You should go to 'PLUG-INS>Manage' to restart any plug-ins.

                Originally posted by mlevin77 View Post
                However, now I'm getting the same error about a different node. Probably that one has the same setting issue, but I wonder why it wasn't showing up as an error before.
                Random polling might not throw errors if the device responds. It's all down to timing and what is happening on the network at that moment. Errors like this might come and go but it's best to remove all unnecessary polling to improve the efficiency of the network. HS has a habit of setting 20 minute, plus a random number of seconds, polling on child devices, I guess as a catch up in case a state change is missed. This can play havoc if it is a non-listening device, as is the case here.

                For information - If you are having timing issues or general slowing down of your Z-Wave network it is always a good idea to look at what polling is going on. You can brute force turn off all polling temporarily to test if that is the problem. You go to 'PLUG-INS>Manage' then click on the 'Z-Wave' name, it is a hyperlink. This displays information including the Poll Queue for each interface you have. There is a checkbox 'Enable Polling' that can be unchecked temporarily to test your system running without any polling. Restart the Z-Wave pi and then If this cures all your timing issues then you know where to concentrate your troubleshooting efforts.

                Steve

                Comment


                  #9
                  Thanks! That's very helpful. Is it possible to find which device has the polling set? And is there any general rule to know which devices need to be polled? What is polling used for (in what circumstances is this function useful)?

                  Comment

                  Working...
                  X