Lost Polling on a Device

[Kaje]

I have been running the plug-in for over a year, operating great (I love it!!). A couple of weeks ago one of the devices was flagged for missing a poll. Upon further investigation it is no longer available in the SDJ-Health config "Devices Requiring Activity Monitoring" pull down. The SDJ device itself shows "Monitoring Method - Unknown" (the other polling devices show 'Polling')

The missed poll issue occurred 1 day after I replaced the batteries in the device.

Any ideas on how I can fix this?

Ken J.
HS Pro 3.0.0.435 (Windows); SDJ-Health 3.0.6.2

[SteveMSJ]

I have been running the plug-in for over a year, operating great (I love it!!). A couple of weeks ago one of the devices was flagged for missing a poll. Upon further investigation it is no longer available in the SDJ-Health config "Devices Requiring Activity Monitoring" pull down. The SDJ device itself shows "Monitoring Method - Unknown" (the other polling devices show 'Polling')

The missed poll issue occurred 1 day after I replaced the batteries in the device.

Any ideas on how I can fix this?

Ken J.
HS Pro 3.0.0.435 (Windows); SDJ-Health 3.0.6.2

Hi Ken,
A few questions to try and narrow down the issue:
What is the particular device?
Do at least the root and battery child of the device still show properly grouped together in HS3 Device Management?
Does it still show in the dropdown for 'Select devices that require polling'?
If you filter your log to show only SDJ-Health entries are there any error messages?
Are you using the LogToDatabase feature?
Presumably the device itself is still working ok?

Thanks,
Steve

[Kaje]

Steve,
Answer to your questions:
- What is the particular device? Schlage Lock
- Do at least the root and battery child of the device still show properly grouped together in HS3 Device Management? Yes
- Does it still show in the dropdown for 'Select devices that require polling'? No
- If you filter your log to show only SDJ-Health entries are there any error messages? No Error messages. And for this particular device (#1947) it is showing "PEData read sucessfully from child device #1947" and no other info for it
- Are you using the LogToDatabase feature? Yes (100 per device)
- Presumably the device itself is still working ok? Yes it is working fine

And some additional information. I have 4 other of these same devices (Schlage Locks) that were introduced at the same time as this 'missing' device. No issues with them.

Ken J.

[SteveMSJ]

Steve,
Answer to your questions:
- What is the particular device? Schlage Lock
- Do at least the root and battery child of the device still show properly grouped together in HS3 Device Management? Yes
- Does it still show in the dropdown for 'Select devices that require polling'? No
- If you filter your log to show only SDJ-Health entries are there any error messages? No Error messages. And for this particular device (#1947) it is showing "PEData read sucessfully from child device #1947" and no other info for it
- Are you using the LogToDatabase feature? Yes (100 per device)
- Presumably the device itself is still working ok? Yes it is working fine

And some additional information. I have 4 other of these same devices (Schlage Locks) that were introduced at the same time as this 'missing' device. No issues with them.

Ken J.

Hi Ken,
Thanks for the comprehensive response.
Can you try going to the SDJ-Health/Config page and set the LogLevel to 2. Then go to the Device Mangement page and finally return to the SDJ-Health/Config page. You can then turn LogLevel back to 0 or 1 as desired.
Have a look in the log and see what SDJ-Health messages show. When you go to the Config page the plug-in builds the list of battery devices that have a parent and report as pollable. There maybe a messages to show an issue with the particular device. Let me know if anything shows.

Can you also post a screenshot of the advanced tab of this particular locks battery child device.

Steve

[Kaje]

Changed LogLevel to 2 and got 3 of the following: "Warning - Duplicate device name add sufix."


Ken J.

[SteveMSJ]

Changed LogLevel to 2 and got 3 of the following: "Warning - Duplicate device name add sufix."

Hi Ken,
The warning messages, with the slightly embarrassing spelling mistake, arise because there are devices with the same locations and name.
When the plug-in builds the lists for selecting devices it uses the location1, location2 and name of the root device (or battery device depending on the NameDeviceBy option on the Config page). If location1, location2 and name are all identical it adds a suffix (-0, -1, etc) to the name to make it unique in the list. The warning message only shows with LogLevel 1 or more as it isn't an error and shouldn't cause any issues. Do you have some devices in the 'Select devices that require...' dropdown lists that have -0, -1 -2 suffixes to the names? NOTE the suffixes only show in the dropdown lists, the plug-in doesn't change anything to do with the actual device.

This shouldn't be related to the issue of the missing device but if these are your other locks and the names are the same it might indicate where to look further.

The plug-in builds a list of battery devices, excluding those that it is already monitoring by WakeUps or Heartbeats, The Pollable dropdown only shows Z-Wave devices that report as pollable whereas the Activity dropdown will show all the devices. If, as I suspect, the duplicate naming isn't the issue I will add some more debug logging to see if we can identify why this particular lock is no longer showing in the list.

Steve .

[Kaje]

Steve,
In the "Select devices that require Activity Checking" pull down there are 3 that match the naming issue. My Netatmo devices. I renamed them all something unique and that cleared the suffix warning issue.

But in looking through Activity Checking pull down I do see the missing device listed there. It still does not show up in the Polling pull down.

Ken J.

[SteveMSJ]

Steve,
In the "Select devices that require Activity Checking" pull down there are 3 that match the naming issue. My Netatmo devices. I renamed them all something unique and that cleared the suffix warning issue.

But in looking through Activity Checking pull down I do see the missing device listed there. It still does not show up in the Polling pull down.

You don't need to rename the Netatmo devices, the warnings are only debug messages, but it doesn't hurt.

Your first post had said that the problem device didn't appear in the Activity checking dropdown but perhaps you meant the Polling dropdown. The fact that it appears in that list and not the Polling dropdown indicates that HS3 reports that the device doesn't support polling.
I should have spotted in your screenshot of the Advanced Tab it shows Supports Status as false. That indicates that the device doesn't support polling which is obviously wrong.

Public Property Status_Support(ByVal hs As IHSApplication) As Boolean

This property indicates (when True) that the device supports the retrieval of its status on-demand through the "Poll" feature on the device utility page. The plug-in which owns the device is responsible for returning the status when the poll command is issues.

The Z-Wave plug-in is the owner of the device and controls polling. If you look at the advanced tabs for your other locks you should see that they show Supports Status True. Let me know if that isn't the case.

This device must have originally reported True as it was being monitored. I don't know why this should have changed. Did you re-scan the device at any time, perhaps after you had changed the batteries?

If the advanced information is showing differently for this lock than your other identical ones, the only way to correct it would be to try a re-scan. However, this is unlikely to work successfully with a lock unless the lock and the Z-Wave controller are brought very close together.

Steve

[Kaje]

Yep...I meant "Polling Drop down", my bad.

I got the Z-Wave controller close the lock, did a re-scan and 'ta-da' it is back to being pollable. It shows back in SDJ-Health "Polling Drop down" and all is well.

Like I said it happened 2 days after a battery change. I did not perform a re scan at that time. SDJ-Health just started reporting "Missed a Poll" and of course my first reaction was 'sucky batteries' but I checked and they were good, and the lock performed fine. Kind of odd that HS polled the device fine if the Public Property Status-Support was false...one of the many mysteries of HS and Z-Wave.

Thanks for the support!

Ken J.

[SteveMSJ]

Yep...I meant "Polling Drop down", my bad.

I got the Z-Wave controller close the lock, did a re-scan and 'ta-da' it is back to being pollable. It shows back in SDJ-Health "Polling Drop down" and all is well.

Like I said it happened 2 days after a battery change. I did not perform a re scan at that time. SDJ-Health just started reporting "Missed a Poll" and of course my first reaction was 'sucky batteries' but I checked and they were good, and the lock performed fine. Kind of odd that HS polled the device fine if the Public Property Status-Support was false...one of the many mysteries of HS and Z-Wave.

Good news that it is sorted.
This may be a one off but I think I might change the pi so that even if HS erroneously changes the Status Support on a device from true to false the pi will continue to monitor the device with perhaps just a warning.

I have noticed other instances where HS changes properties when it shouldn't. For example I change the suffix of all my temperature sensors status to the degree symbol, rather than the default scale which shows as C. However, every now and again I will notice that one or more of these have changed back to the default and I have to set them again. I haven't seen any other reports of this and it's only a cosmetic issue that I resolve with a script.

Steve

[SteveMSJ]

Good news that it is sorted.
This may be a one off but I think I might change the pi so that even if HS erroneously changes the Status Support on a device from true to false the pi will continue to monitor the device with perhaps just a warning.

I have submitted an updated version (3.0.6.3) to the portal which will keep devices that have already been set to be monitored by polling in the list even if HS erroneously changes the Status_Support flag from true to false. This might have been a unique event but at least it is covered if it should ever happen again.

Steve