Help with devices not reporting

[pcgirl65]

I set this up as per the instructions but it isn't notifying me when the batteries are low on devices. What am I doing wrong?

[SteveMSJ]

I set this up as per the instructions but it isn't notifying me when the batteries are low on devices. What am I doing wrong?

I can see from your screenshot that you have a problem with HS in that there haven't been any wake-ups noted since the 20th April. Hence all your devices are showing missed wake-up. There are two probable causes for this:

1. There is a well documented bug in the Z-Wave plug-in, which unfortunately HS still haven't addressed. This occurs sometimes after including a new device, usually, but not exclusively, using Z-Tools. The Z-Wave pi gets itself in a state which normally shows up as high, sometimes 100%, cpu activity. Whilst things generally carry on operating relatively normally one symptom is that it stops logging wake-up messages. This causes various problems but can be cured by restarting the Z-Wave lug-in or HS3. If you have SDJ-Health running it is fairly obvious when this bug occurs because you see your battery devices missing their wake-ups one after the other.

2. Unchecking the option to 'Log Poll and Wake-up Messages' on the Z-Wave>Controller Management page.

It is unlikely that you have done item 2 but best to just check that option is still checked. Then disable the Z-Wave plug-in, wait a few secs, and re-enable. You should then find that over the course of the next day your devices will wake-up and their status will change to Healthy.

Their is a hierarchy of warnings, of which Missed Wake-up, is the most critical so they are masking the low battery warnings. Once your Z-Wave pi is operating normally that should be corrected.

Let me know what you find.

Steve

[pcgirl65]

Thanks! I checked the "Log Poll" setting and it is checked. I have disabled z-wave and re-enabled it. I will report back in a day or two. I wonder if this is also why sometimes devices just don't fire for some reason and then they do?

[pcgirl65]

Also, noticed that you have an update 3.0.8.5 but when I try to install this is says it fails.

[SteveMSJ]

Also, noticed that you have an update 3.0.8.5 but when I try to install this is says it fails.

Did you disable the pi before updating?

[pcgirl65]

Oh no I didn’t. That worked! Thanks!

[SteveMSJ]

Thanks! I checked the "Log Poll" setting and it is checked. I have disabled z-wave and re-enabled it. I will report back in a day or two. I wonder if this is also why sometimes devices just don't fire for some reason and then they do?

It could be. When the Z-Wave pi is in its messed up state it consumes lots of cpu so presumably all sorts of delays and missed actions could potentially occur. Failing to acknowledge wake-ups is just one symptom. I use to have StellaZ radiator valves which required lots of events with polling to operate. The polling used to stop working when the Z-Wave plug-in was in this state. It took me a long time to figure out why they usually stopped working just after I had included other unrelated devices. As a matter of course now I restart the Z-Wave pi after including any devices, not that I do that much anymore.

Out of interest, the event you posted is just for low battery, do you also have an event for SDJ-Health triggered by Missed Wake-ups? That is the most important notification as it usually means the batteries are dead, whatever their apparent level might be. Personally I just use the one event for sending a pushover message triggered by any of the alerts, see example in the SDJ-Health guide. The message tells you what type of alert it is so it isn't really necessary to have separate messages. I have another event to email full reports.

Steve

[pcgirl65]

Ok I will look at the instructions again and see what the event is that I need to implement. I did add a lot of new devices at once as I had to redo everything when I decided to go back to HS3

[pcgirl65]

I can't seem to find "had its value set to a value in the range of" in the Events. I think this is why I just did batteries. Can you tell me how you got that Condition?

[SteveMSJ]

I can't seem to find "had its value set to a value in the range of" in the Events. I think this is why I just did batteries. Can you tell me how you got that Condition?

You select:
> A Device's Value is..
then select:
> This device has its value set to...
then select the SDJ-Health Battery Health Root device
then in the 'is set to dropdown' select:
> (Enter a custom value or value range)
then you have two boxes where you can enter the start and finish of the range.



By the way, to be pedantic, it's a Trigger not a Condition

Steve

[pcgirl65]

Yes, that is true, it is a Trigger! Thanks, how often does this event tell you if batteries are low? Once a day?

[SteveMSJ]

Yes, that is true, it is a Trigger! Thanks, how often does this event tell you if batteries are low? Once a day?

The event, with the Trigger as discussed, will send you a message every time an alert is triggered by the plug-in. So, for example, if any of the monitored battery levels drops below its set threshold it will trigger the event. Don't forget as well as setting a global threshold you can override this for individual devices as necessary.

You can of course use the HS event engine to do pretty much whatever you want. For example, if you want the previous event to also send you an alert every day then you would add a second Trigger (Or If) to the event.
> Or If 'The Time is this:' (set the time of day you want the message sending)
> And If 'The device has its value set and it is less than' (choose the SDJ-Health Root) 'Waiting'

Then, in addition to any time an alert is raised this event will also trigger every day at a certain time but only if there is an alert condition. If you wanted a report every day even if there isn't an alert condition then don't add the last condition (And If).

You will probably want to control the type of report which you can do in the Actions of the event by changing the Root device between 'Status', 'Short' and 'Full'. Refer to the example email event in the guide for how to do this.

The permutations are endless due to the power of the HS event engine.

Please feel free to post any questions.

Steve

[pcgirl65]

Thanks for the explanation. I will have to look at this closer. I am wondering, what does it mean if a device misses its wake up? And is there something that can be done to correct this problem. All of my devices except for one are now OK. 1 missed its wake up but the battery is at 80%.

[SteveMSJ]

Thanks for the explanation. I will have to look at this closer. I am wondering, what does it mean if a device misses its wake up? And is there something that can be done to correct this problem. All of my devices except for one are now OK. 1 missed its wake up but the battery is at 80%.

Z-Wave non-listening devices are normally asleep to conserve battery power but wake-up at a regular interval to check whether the controller needs to control them or request some information. If a device misses its wake-up then the batteries are probably dead. There can be other reasons for the odd missed wake-up such as, HS3 being off-line, short term communication issues, unresponsive Z-Wave pi, etc, so the pi can be set to ignore one or more missed wake-ups. It is all configurable on the Config page and can be overridden if necessary for individual devices. Z-Wave devices can be fairly erratic at reporting battery levels, and most stop working before the reported battery level gets down to zero. It varies from device to device and can also influenced by battery types and manufacturers. This was originally the main reason for writing the plug-in as I wanted to be alerted if any of my devices died, as battery level alone was not a reliable indicator.

I have some devices that consistently report nicely descending battery levels down to 0% before dying, but I also have devices that fail at random levels which can be as high as 90%. The pi can build up a history of reported battery levels for your devices which you can view and observe what kind of pattern different devices exhibit.

How you set alerts and how you use the information the pi provides is up to you and probably depends on how critical individual devices are. I have some devices that I don't replace the batteries until they die, some that I replace when they drop below a certain level, and some that I replace after a set number of days. You can configure the pi to alert you when any of these conditions occurs.

The guide does provide some information on this but is not comprehensive and everybody will develop their own methodology.

The pi can also use other monitoring methods for devices that are always awake, but that's another discussion.

I hope this helps.

Steve

[pcgirl65]

Fantastic! Thanks for your help!