Help with devices not reporting status

[simonmason]

Hi, I have been using the plugin for a while now - extremely helpful to warn me about low batteries. I recently started to enable some of the other capabilities such as missed wakeup calls and unusual battery discharge. It seems that no matter what I do the missed wake up calls is permanently on so I thought I would explore this one in more detail first.

I set missed wakeup calls to 5 - assuming that I would provide a little bit of a buffer and only start alerting when something really is not reporting.

Here is an example - the plugin shows no wakeup since March yet the device shows an up to date report.

What is the best way to go about diagnosing this? Thanks.

[SteveMSJ]

Hi, I have been using the plugin for a while now - extremely helpful to warn me about low batteries. I recently started to enable some of the other capabilities such as missed wakeup calls and unusual battery discharge. It seems that no matter what I do the missed wake up calls is permanently on so I thought I would explore this one in more detail first.

I set missed wakeup calls to 5 - assuming that I would provide a little bit of a buffer and only start alerting when something really is not reporting.

Here is an example - the plugin shows no wakeup since March yet the device shows an up to date report.

What is the best way to go about diagnosing this? Thanks.

I'll need a few more clues to advise properly.

The device in your example is a lock so it doesn't wake-up as such, it will always be awake. This is a 'listening' devices in Z-Wave parlance. Battery devices that have to receive and react immediately to commands, e.g. locks and sirens, can't sleep otherwise they would miss the commands.
The pi won't detect and set up 'listening' devices automatically you have to select them to be monitored by choosing them with one of the monitoring methods, i.e. polling or activity checking. On the one hand you must have selected the device for it to have created a monitoring child and if so which method, on the other hand the fact that the monitoring status is 'Last Wake' rather then 'Last Good Poll' or 'Last Good Check' has me somewhat confused. Was this possibly set up with a very old version of the plug-in?

Please can you click on the name of the monitoring child, Garage Door Lock Battery (Health), then select the SDJ-Health tab and post a screenshot so I can see all the details of how that particular device is setup in the plug-in. Hopefully I can then figure out what is going on.

Thanks,
Steve

[simonmason]

I have been using this for a long time. Here is the screen shot:

[SteveMSJ]

I have been using this for a long time. Here is the screen shot:

Thanks for the information.

I am at a bit of a loss as to how the monitoring device has got into this state. It shows that the Monitoring Method is by Wake-Up which is normally only set when the plug-in detects a wake-up call in the log for that node. Perhaps it occurred in some early version of the plug-in or a bug in updating between versions. I haven't seen it happen before. Anyway, its not worth dwelling too much on the whys as it is pretty easy to sort out.

What I suggest is that you delete the monitoring child for this lock. If you then go into the 'SDJ-Health>Battery Devices' page you should find the device is available to be selected in both the Polling drop down list and the Activity Checking drop down list. I would recommend selecting it in the Polling drop down list. It will then be polled every 6 hours (360 minutes by default unless you change the poll interval) to check whether it is still alive. A new monitoring child will be created the first time it is polled.

As far as the plug-in and reporting are concerned, the polls are considered similar to wake-ups so I suggest you set the MissedWakeFactor to say 1. This will allow one missed Wake-Up/Heartbeat/Poll/Activity Check to occur before alerting. You can set it to zero but you will probably find, with polls, that the odd one may fail due to network activity.

If you have other 'listening' Z-Wave devices that are somehow set to Wake-Up monitoring like this one, then delete those and add them to be polled.

The only issue with deleting a monitoring child would be if you had for some reason referenced it in events. However, the whole point of the plug-in is that alerting and reporting is all through the Root device so no events should reference the child devices or need editing as you add and remove devices from your system.

I hope this helps and let me know how you get on.

Steve

[simonmason]

Great - Thanks. I went through these steps and a new child device shows that is displaying correctly. I have another device that doesn't seem to align. A water sensor in the laundry. Same issue?

[SteveMSJ]

Great - Thanks. I went through these steps and a new child device shows that is displaying correctly. I have another device that doesn't seem to align. A water sensor in the laundry. Same issue?

Hi,

This isn't the same issue. I would imagine this device is a non-listening device which will have been detected automatically by the pi and the monitoring child created.

The monitoring child is showing it last detected a wake-up 6/18/20 7:40 PM but that it was only 5 minutes after the previous wake-up was received. Now I suspect that your wake-up period for the device will be much longer than 5 minutes either the devices default or something you have configured. I don't have any of these devices so I don't know what their default wake-up period is but I would expect it to be several hours.

Did you manually force a wake-up of the device, perhaps to set some parameters or optimize? If so this would account for the last short period and the pi then indicating missed wake-ups shortly after. If that is the case the monitoring of this device will return to normal the next time it wakes-up automatically.

I suspect that by now the monitoring child is reporting healthy for this device but if not we can investigate further.

By the way, I notice you have your global MissedWakeFactor parameter at 5. I would recommend reducing this. If you have non-listening devices that only wake-up say every 12 hours it will take a long time for the pi to notify you that the device has died with such a large factor.

Let me know how you get on.

Steve

[simonmason]

Thanks. I did wake-up the device to see what it's reporting period was. There was something going on in the setup as Homerseer was reporting it as -1 seconds. Based on posts online I set it at 6 hours as apparently this device has issues reporting.

Checking it now, it appears it has not reported battery level since that time so the issue - it would seem - is in the device itself. What is also curious is that it continues to report 100% battery. It has been installed for several years. I am guessing that I have other issues with this unit. The only good thing about it is that I tested the water detection and it does wake-up and alert just fine.

So I think I need to work with HS to see why this unit is not waking up to report it's battery level and whether the battery level is even accurate. Unless you have any other advice I will disable monitoring from the PI at this point.

I will reduce the MissedWakeupFactor.

[SteveMSJ]

Thanks. I did wake-up the device to see what it's reporting period was. There was something going on in the setup as Homerseer was reporting it as -1 seconds. Based on posts online I set it at 6 hours as apparently this device has issues reporting.

Checking it now, it appears it has not reported battery level since that time so the issue - it would seem - is in the device itself. What is also curious is that it continues to report 100% battery. It has been installed for several years. I am guessing that I have other issues with this unit. The only good thing about it is that I tested the water detection and it does wake-up and alert just fine.

So I think I need to work with HS to see why this unit is not waking up to report it's battery level and whether the battery level is even accurate. Unless you have any other advice I will disable monitoring from the PI at this point.

I will reduce the MissedWakeupFactor.

So are you saying that it isn't waking up every 6 hours, after you have set it to do that? As long as it does its regular wake-up and announces that to HS then SDJ-Health should monitor it ok. The SDJ-Health monitoring child should display the last wake-up time it detected. You can also search the log for wake-up notifications for the node number of the device.

Also beware of a longstanding bug in the Z-Wave plug-in that occurs quite often after including devices. The Z-Wave pi can get itself in a state of which the symptoms can include, high CPU and slow network response but also polling and wake-up detection issues. It is cured by restarting the Z-Wave pi.

As far as battery level reporting in HS is concerned, do you have a polling interval of 6 hours set in HS for the actual battery device so that HS has a poll queued ready for the wake-up? Most modern battery devices will report their battery level when it changes without being polled but lots of older ones only report if polled at their regular wake-up.

The water detection alert is independent of the wake-up period. A device will transmit that the instant it happens but doesn't announce it is awake ready to receive commands so doesn't interfere with the SDJ-Health wake-up monitoring.

Steve

[simonmason]

The water sensor is not reporting unless I wake it up. If I check it's device settings in homeseer it shows wake-up at -1 seconds. If I scan the device it shows 12 hours in the log. And every time I try to change the polling settings it fails. So something is not right in the device or the homeseer driver for it. I have posted separately about this but it appears that others have had issues with this so I am not confident. I will have to consider replacing this sensor with something that is proven to work with homeseer. Don't want to take chances with a water leak sensor.

[SteveMSJ]

The water sensor is not reporting unless I wake it up. If I check it's device settings in homeseer it shows wake-up at -1 seconds. If I scan the device it shows 12 hours in the log. And every time I try to change the polling settings it fails. So something is not right in the device or the homeseer driver for it. I have posted separately about this but it appears that others have had issues with this so I am not confident. I will have to consider replacing this sensor with something that is proven to work with homeseer. Don't want to take chances with a water leak sensor.

Noted.

Steve

[simonmason]

So after a lot of back and forth I have everything cleaned up and reporting. Mostly everything was issue with the individual battery powered units and how they interact with Homeseer. Getting close to monitoring nirvana again! A couple of questions:

One of the devices, the water sensor, clearly does not report battery correctly except on manual wake-up. Issue with the driver or something. I have it disabled right now but can I use the Alert on battery life exceeded to warn me to check? I looked in the docs on this option but didn't see anything specific?

Thanks

[SteveMSJ]

So after a lot of back and forth I have everything cleaned up and reporting. Mostly everything was issue with the individual battery powered units and how they interact with Homeseer. Getting close to monitoring nirvana again! A couple of questions:

One of the devices, the water sensor, clearly does not report battery correctly except on manual wake-up. Issue with the driver or something. I have it disabled right now but can I use the Alert on battery life exceeded to warn me to check? I looked in the docs on this option but didn't see anything specific?

Thanks

Yes, you can alert on battery life exceeded, that is set by default. You can turn Battery Life monitoring on and off globally on the 'SDJ-Health>Battery Devices' page but you can also override that setting for individual devices on the SDJ-Health tab of each monitoring child.

The only thing to bear in mind is that if the device isn't reporting the level, e.g. it stays at 100%, the pi won't detect automatically when you put new batteries in. You just need to go to the SDJ-Health tab of the monitoring child for that device, click on the 'Batteries Last Replaced' date and set it when you change the batteries. Remember to click the 'Save' button.

You set a global battery life number of days on the 'SDJ-Health>Battery Devices' page but you can also override that for individual devices on the SDJ-Health tab of each monitoring child.

The pi will alert through the Battery Health Root device when any of the monitored devices raise an alert, such as exceeding battery life.

Is the water sensor not waking up at all or is it just not reporting it's battery level? If it is waking up then you can still monitor that to be alerted when it dies, it doesn't need an actual battery level.

Steve

[simonmason]

It appears to not be waking up and reporting at all. Not sure if it is not waking up, or it is waking up and not reporting. Have to check into that. But there is clearly something wrong as in Homeseer Z-wave settings for this device I cannot successfully set the wake-up interval. No matter what I set it to, when checking again, it shows -1 seconds. Someone else posted issues with the Zooz sensor integration into Homeseer in the past so I am chasing that to see if I can get this thing configured correctly or look for something with a more reliable interface. Can't have my water sensor being the one device that runs out of battery.