Device missing from polling list

[mkaplan1]

One of my locks has had a missed wakeup and I realized it's no longer on the list of devices to poll in the config page.

If I look at the device history it shows the battery level but still has a missed wakeup error. I lock is configured to poll every 2 hrs.

[SteveMSJ]

One of my locks has had a missed wakeup and I realized it's no longer on the list of devices to poll in the config page.

If I look at the device history it shows the battery level but still has a missed wakeup error. I lock is configured to poll every 2 hrs.

If the lock is in the list of devices available for polling (on the config page) then just re-select it and it will start monitoring it again. The status will change back to healthy the next time the plug-in polls it successfully. If you deselect a device to be polled it doesn't automatically delete the monitoring child so it will change to Missed Wake-up over a period of time unless you manually delete the monitoring child. However, this allows you reinstate monitoring by re-selecting it.

If it is no longer in the list of available devices then there is something wrong and I will need to investigate further.

I don't see any reason why a device should de-select itself from the list so, if this was the case, can you recall any sequence of actions that might have caused this?

Let me know the situation.

Steve

[mkaplan1]

It's not on the list. It used to be on the list but about 2 months ago it must have become corrupted. What do you need to investigate further?

Mark

[SteveMSJ]

It's not on the list. It used to be on the list but about 2 months ago it must have become corrupted. What do you need to investigate further?

Mark

Hi Mark

Go to the SDJ-Health Config page and change the LogLevel to 2.
Then exit the Config page, i.e. go back to Device Management.
Then open the SDJ-Health Config page again.

This will generate a lot of log entries. Post the log here from when you set LogLevel to 2, you can filter to only show SDJ-Health messages if you like.

After this set the LogLevel back to 0 or 1.

Can you also:
Post a screenshot of the Advanced tab for the locks battery child device
Post a screenshot of the node information for the locks node from the Plug-ins>Z-Wave>Node Information page.

Thanks,

Steve

[mkaplan1]

[SteveMSJ]

Hi Mark,

Thanks for the information. I think I can see the problem.

The plug-in has changed the monitoring method for this particular device from polling to wake-up, which is why it has dropped off the list of devices available for polling. The device is a 'Listening Device' so doesn't issue wake-up notifications hence the 'Missed Wake-up' status.
I think I have seen this happen once before a long time ago and it is caused by some corruption in Z-Wave communications which causes HS to erroneously think it has received a Wake-Up notification from a device. The plug-in has a hierarchy of monitoring methods with wake-up notifications being the highest level as they are the best way of detecting device health. When it detects the wake-up notification it changes the monitoring method for that device because it is higher up the hierarchy. Unfortunately as this was an erroneous notification it doesn't receive any more and goes to 'Missed Wake-up' status.

The quickest way to correct the situation with this device is to delete the monitoring child device. That is just the specific SDJ-Health monitoring child device for this lock NOT the actual battery device NOR any other of the devices associated with node 71.

You should then find if you go to the SDJ-Heath config page the lock will be back in the list of devices available for monitoring by polling. You can select it again and in due course a new monitoring device will be created.

The downside of deleting the current monitoring child is that you will loose the battery history for that device. If that matters to you then let me know and, as an alternative, I will add a quick change to the plug-in to let you re-assign the monitoring method for the existing device.

I will also modify the plug-in so that, if for some reason any more spurious Z-Wave notification messages are received, it shouldn't happen again. I probably won't release the update for a week or two as I will like to give the change some thought and test it. As I say I think this is a very rare occurrence.

Let me know how you get on.

Steve

[SteveMSJ]

Hi Mark,

Thanks for the information. I think I can see the problem.

The plug-in has changed the monitoring method for this particular device from polling to wake-up, which is why it has dropped off the list of devices available for polling. The device is a 'Listening Device' so doesn't issue wake-up notifications hence the 'Missed Wake-up' status.
I think I have seen this happen once before a long time ago and it is caused by some corruption in Z-Wave communications which causes HS to erroneously think it has received a Wake-Up notification from a device. The plug-in has a hierarchy of monitoring methods with wake-up notifications being the highest level as they are the best way of detecting device health. When it detects the wake-up notification it changes the monitoring method for that device because it is higher up the hierarchy. Unfortunately as this was an erroneous notification it doesn't receive any more and goes to 'Missed Wake-up' status.

The quickest way to correct the situation with this device is to delete the monitoring child device. That is just the specific SDJ-Health monitoring child device for this lock NOT the actual battery device NOR any other of the devices associated with node 71.

You should then find if you go to the SDJ-Heath config page the lock will be back in the list of devices available for monitoring by polling. You can select it again and in due course a new monitoring device will be created.

The downside of deleting the current monitoring child is that you will loose the battery history for that device. If that matters to you then let me know and, as an alternative, I will add a quick change to the plug-in to let you re-assign the monitoring method for the existing device.

I will also modify the plug-in so that, if for some reason any more spurious Z-Wave notification messages are received, it shouldn't happen again. I probably won't release the update for a week or two as I will like to give the change some thought and test it. As I say I think this is a very rare occurrence.

Let me know how you get on.

Steve

Having looked a bit harder at your log I think that, whilst it doesn't change the solution, I might be wrong about the cause of the issue in your case. I can see that you have a number of pollable battery devices that are being excluded from the list because they are Type 0, which means being monitored by wake-ups. This may have been caused by some corruption that I haven't seen before. Have you updated the plug-in recently and if so was it from a very early version?

Have you got a problem with any other devices that are being monitored by SDJ-Health?

Steve