Warning - Z-Wave device #68 poll failed.

[Sireone]

For some reason, I keep getting the following error in my log and not for the life of me can I find out what device it is to remove it.
I don't have 68 zwave devices, so which one is it referring to?

Warning - Z-Wave device #68 poll failed.

-Devon

[SteveMSJ]

For some reason, I keep getting the following error in my log and not for the life of me can I find out what device it is to remove it.
I don't have 68 zwave devices, so which one is it referring to?

Warning - Z-Wave device #68 poll failed.

Hi Devon
#68 is the reference number of the device. Every device in HS has a unique reference number. Node numbers and names can have duplicates so don't necessarily point to an individual device.

If you go to 'TOOLS>Setup>Custom' and check 'Show Device Reference Number on Device Management Page' the reference numbers of devices will be shown in the left hand column of Device Manager.

However, the log message is just for information/troubleshooting. SDJ-Health should be alerting you that the device has a problem and it will identify the device.
You haven't provided any information so I'm guessing here but, I presume you have a listening Z-Wave device (perhaps a lock) that your are monitoring by polling. Look at your SDJ-Health monitoring child devices and see what they are reporting. If it is just missing the odd poll every once in a while and you have the pi configured to ignore one or more missed wake-ups, then you might not be getting an alert. Z-Wave battery devices will often miss the odd poll if the network is busy.

Let me know what you find.
Steve

P.S. In the log message the #Ref is for the battery child of the monitored device.

[Sireone]

Got it! Found the offending device which hasn't updated it's status in a few months. What would be the procedure to re-poll this device?
Also, when going to Battery Device Monitoring, I notice that Devices Requiring Polling only has 2 of my battery devices. How do I add the rest?

[SteveMSJ]

Got it! Found the offending device which hasn't updated it's status in a few months. What would be the procedure to re-poll this device?
Also, when going to Battery Device Monitoring, I notice that Devices Requiring Polling only has 2 of my battery devices. How do I add the rest?

You would have to give me a bit more information about the device for me to answer your first question.

I don't know anything about your system but if your battery devices are mostly Z-Wave non-listening devices then they are picked up automatically by SDJ-Health and monitoring child devices set up. They are monitored by wake-up notifications they don't require, and can't be polled. You need to have the Z-Wave pi configured to log wake-up messages. This is all in the guide.

Monitoring battery devices by polling is for Z-Wave listening devices like locks and sirens. Non-listening devices won't appear in the list. The manual describes all this but if it isn't clear then please ask further. Best thing is to give me a list of the actual device details for any you are having trouble with.

Some Z-Wave battery devices, such as Z-Smokes, transmit a regular Heartbeat. If you have any of these types of devices check the option to monitor Heartbeats and they will be picked up automatically.

Finally, non Z-Wave battery devices can usually be monitored by Activity but need to be selected from the 'Select Devices that require Activity Checking' if you wish them to be monitored.

I hope that helps,
Steve

[Sireone]

Sorry for the lack of details. First off, I'm running HS4. Second, the device in question with the 'poll fail' issue, is indeed Z-Wave Smoke Detector. I'll enable MonitorHeartbeats. For my other ZWave battery devices (Motion, flood etc.) what is the process of getting those discovered?

[SteveMSJ]

Sorry for the lack of details. First off, I'm running HS4. Second, the device in question with the 'poll fail' issue, is indeed Z-Wave Smoke Detector. I'll enable MonitorHeartbeats. For my other ZWave battery devices (Motion, flood etc.) what is the process of getting those discovered?

It depends on what type of smoke detector, only some transmit heartbeats. As I said without details I can't advise.
The guide explains the methods so I suggest you start there.

Basically make sure you have the Z-Wave pi set to log wake-up messages then wait 24 hours in which time any of your Z-Wave non-listening battery devices should have woken up and SDJ-Health will have automatically detected them and configured monitoring child devices.

Then if you have any listening Z-Wave battery devices, such as locks and sirens, select them from the 'Select devices that require polling' list. The pi will then set up monitoring children for them and poll them at regular intervals to check they are alive.

For other technologies that don't log wake-ups you can monitor by selecting them from the 'Select devices that require Activity Checking'.

The different types of monitoring methods, advantages and disadvantages, and the reasons for them are explained in the guide. You can configure the various parameters globally as well as overriding them for individual devices if necessary.

Also, consider turning on LogToDatabase which saves all the battery levels to a database so you can view the battery history for your devices.

Steve

[windracer]

Sorry for the thread bump but I'm having a similar problem with my HS-FS100+ temperature/light sensor. SDJ-Health seems to be getting info from it (battery level and temp), but I'm seeing the "poll failed" issue in the log every 12 hours (which is my polling interval). The other two battery devices (#13/14 and #30/31) are Z-Wave door locks, #198 is the sensor. Any idea what would be causing this?

Settings:


SDJ Device:


Warnings in log:

[SteveMSJ]

Sorry for the thread bump but I'm having a similar problem with my HS-FS100+ temperature/light sensor. SDJ-Health seems to be getting info from it (battery level and temp), but I'm seeing the "poll failed" issue in the log every 12 hours (which is my polling interval). The other two battery devices (#13/14 and #30/31) are Z-Wave door locks, #198 is the sensor. Any idea what would be causing this?

Hi,
I don't have details of the HS-FS100+ but I suspect it is a non-listening Z-Wave device and therefore you shouldn't be trying to monitor it by polling. As long as you have 'Log poll and wake-up messages' selected, as per the guide, the pi will detect these automatically the first time they wake-up and set up monitoring devices. Locks are listening devices so do need polling.

I suggest you deselect the sensor from the list. It shouldn't even be in the list but sometimes HS reports the properties incorrectly

Looking at your 2nd screenshot you seem to have deselected displaying some of the information so I can't really see what is happening. Can you post a screenshot of the SDJ-Health tab for the monitoring child (201) and I will try and advise further.

Steve

[windracer]

Sorry for the late delay, I was out of town for the holiday weekend.

I've removed the HS-FS100+ from the polling list in the PI. I'll check tomorrow morning to see if I have a warning overnight (in the next 12 hours). In the meantime, here's that screenshot you requested, taken after I turned off polling (not sure if that's why the title bar shows "ERROR Method unrecognized" or not).

[SteveMSJ]

Sorry for the late delay, I was out of town for the holiday weekend.

I've removed the HS-FS100+ from the polling list in the PI. I'll check tomorrow morning to see if I have a warning overnight (in the next 12 hours). In the meantime, here's that screenshot you requested, taken after I turned off polling (not sure if that's why the title bar shows "ERROR Method unrecognized" or not).

Hi

Thanks for the additional information, I now understand better how you have things set up so can comment in more detail.

The "ERROR Method unrecognized" is as you guessed because you have removed it from the polling list.

The main thing I see is that you have turned off everything except Battery Level monitoring and alerting. You may have your reasons for doing this, and that’s fine, but despite the risk of boring you or anybody else reading this, I’ll just drone on a bit about this in case there are things you haven’t considered.

In my opinion you are missing out on the main purpose of the plug-in and the reason I wrote it in the first place. Battery level reporting from home automation devices, with some exceptions, across most technologies is notoriously inconsistent. Even identical devices will report differently and the reported level at which the device dies, is hugely variable. Whilst you can work round this to some extent, by setting different alert levels for different devices, you still run the risk of devices dying whilst still showing a healthy battery level even if they were still working below that level on the previous set of batteries.

There are also many other reasons why a device may no longer be working other than dead batteries. For example, the plug-in that owns the device may have failed, communication between the device and its controller may have been disrupted, broken device, etc.

When I originally wrote the plug-in the only battery devices I had were non-listening Z-Wave devices. These devices wake-up at specific intervals and announce themselves to the Z-Wave pi, effectively saying ‘I’m alive do you have anything for me’. Whilst the Z-Wave pi does not inform HS directly of these wake-ups it does write some log entries, as long as you have ‘Log Poll and Wake-up messages’ selected. By monitoring the log, and with a little deciphering of the message and the Z-Wave database, the plug-in can detect which device the message came from.

The plug-in adjusts to the frequency of these wake-up messages for the particular device and therefore knows when to expect the next one. If the next message is not received then this is recorded as a missed wake-up, and the plug-in will alert you.

Subsequently I extended the plug-in to work with listening Z-Wave devices and devices owned by other technologies. This required additional ways of monitoring whether devices are still ‘alive’ hence the three other methods Polling, Heartbeat and Activity, which between them can cope with just about any battery device and plug-in technology. When adding the alternative methods I kept to the original philosophy of the plug-in so each monitoring method generates a sudo wake-up. Perhaps rather confusingly, I refer to these as Wake-ups even though they may be a poll, a heartbeat, or a check on activity.

The upshot of this is that if you want the plug-in to monitor whether battery devices are still alive and notify you when they die, you have to leave the default setting of Alert ‘checked’ for the ‘Monitor Wake-Ups’. It doesn’t matter which method is being used to monitor a particular device, it is still considered a Wake-Up. This is a global setting on ‘Plug-ins>SDJ-Health>Battery Devices’ or can be overridden for individual devices if required.

Of, course it is entirely up to you whether you use the above, but I don’t see any reason not to, which is why it is set by default.

The other optional monitoring and alerting for Battery Level, Battery Discharge Rate and Battery Life are variously useful or just for interest.

Battery Level and Battery Life are useful, particularly for critical devices that you want to be alerted to change the batteries before any risk of them failing. However, you still want the catch all Wake-Up monitoring in case something other than battery level causes the device to fail.

Battery discharge rate is rarely useful, which is whey alerting for this is turned off by default. This was introduced at the request of several users and whilst it does provide interesting information, particularly if you have the logging feature turned on, it doesn’t have much practical use.

Getting back to your specific issue, I’m not sure how this device ever got into the list of devices available for monitoring by Polling. When building the list the plug-in does check with the ZWave-pi whether a device supports polling but I think I have seen other occasional instances when the Z-Wave pi randomly returns an erroneous true response. I might have to investigate that further, because it isn’t the first time it has happened and it might be a bug in my code. I did have to introduce a workaround because devices that supported polling were very occasionally dropping out of the list due to an erroneous response from the Z-Wave pi and perhaps this code introduced a bug.

Can you check the Z-Wave info for whatever Node No this device is? A screenshot of the node from the ‘Plug-ins>Z-Wave>Node Information’ page will show all the details and capabilities.

Judging by your screenshot of the SDJ-Health page for this device I can see it has been monitored for some time so I suspect that it has actually been monitoring the wake-up messages, even though somehow polling was selected as well. The "ERROR Method unrecognized" at the top of that page should change to show it is being monitored by ‘Wake-up calls in the log’ the next time it wakes-up. If it doesn’t then:

• Check your log by searching for ‘Wake-Up Notification Received’ messages.
• If there aren’t any check that you have ‘Log Poll and Wake-up messages’ checked for the interface in the Z-Wave pi.
• Check that you have ‘Monitor Log for wake-ups’ selected at the top of the ‘Plug-ins>SDJ-Health>Battery Devices’ page.

If all the above are true and the device still shows "ERROR Method unrecognized" then you will need to delete the monitoring child 201 (NOT the actual device). A monitoring child will be recreated the next time the device wakes-up. You shouldn’t lose the battery history already recorded because this is stored using the Battery Root device reference ID as the key.

One last thing to help me identify the bug that causes your device to appear in the list of devices available for Polling could you do the following:

• Go to ‘Plug-ins>SDJ-Health>Plug-in Config’ and change the LogLevel to 2, which is debugging.
• Go back to the devices page and then go to ‘Plug-ins>SDJ-Health>Battery Devices’.
• Go back to the ‘Plug-ins>SDJ-Health>Plug-in Config’ page and set the LogLevel back to what you want, 0 or 1.
• Filter your log for type ‘SDJ-Health’
• Copy the log messages from ‘LogLevel changed to 2’ to ‘Loglevel changed to 1’ and post them.

Sorry for the rather long post but I hope it helps.

Steve

[windracer]

Hi Steve, thanks for the detailed reply!

I probably turned off the "Monitor log for wake-ups" setting in the PI when I first installed it because I only had the two door locks at the time. When I added the temp sensor later, I most likely just went into the PI and turned on the polling checkbox for the new device. I can confirm that since I turned off polling, that warning every 12 hours that prompted my original post has gone away.

Here's some of the info you requested. First, the node information:



And, when I turned on debug logging for the PI, I got this. It is detecting the temp sensor as not pollable, so again I was the one who probably turned on that checkbox and then just never really noticed the warning in the log every 12 hours until recently.


Continuing your recommendations, I found that "Log Poll and Wake-Up Messages" was NOT turned on at the Z-Wave controller level on my PiTroller, so I turned that on and then re-enabled "Monitor log for wake-ups" in the PI global settings and "Monitor Wake-Ups" on the Battery Devices page.

The device still shows "ERROR Method unrecognized" and also looks like this on the Devices page:



In the log it looks like now that I've turned on those options the PI thinks it missed a wake-up so maybe that's why. I'll let it soak for a bit and see if anything changes.

[windracer]

Looks better this morning. I see the wake-up request in the log and the device now shows "This device monitors the 'Freezer Sensor' by Wake Up calls in the log" in the PI page.



Thanks again for your help! Glad to know I'm using the PI more efficiently now. :-)

[SteveMSJ]

Looks better this morning. I see the wake-up request in the log and the device now shows "This device monitors the 'Freezer Sensor' by Wake Up calls in the log" in the PI page.



Thanks again for your help! Glad to know I'm using the PI more efficiently now. :-)

No problem, thanks for the feedback.

I will take a look at the bug that caused the device to show as available for polling i due course.

Steve

[SteveMSJ]

I will take a look at the bug that caused the device to show as available for polling in due course.

windracer
I've tracked down the bug that was causing the non-pollable device to appear in the list of devices available for polling. It was a stupid coding error that crept in when I put in a workaround for an HS issue. I will release an update soon.

Thanks for raising this.

Steve

[windracer]

I've tracked down the bug that was causing the non-pollable device to appear in the list of devices available for polling.

Cool, glad I was able to help out!