Plugin to monitor Z-Wave battery device Health - CLOSED

[SteveMSJ]

I have sent you a pm.

I notice you're location is NL, Netherlands? I wonder if it has to do with commas as decimal separators. If it is it will be good for me to get that sorted.

Steve

There was indeed a bug with writing discharge rates to the SQLite database if the system is set to use commas as the decimal separator. Current version updated to 3.0.5.2. in message #241 at the top of page 13 of this thread.

Thanks to Bart for testing this.

Steve

[racerfern]

I just want to say "THANK YOU" for an invaluable plug-in which fills a void that should have been part of the HS core.

Being subject to higher and higher tides, I feel comfortable that my water sensors will not fail because of battery issues. Interestingly, the Aeotec water sensor went through a set of batteries fairly quickly. The Aeotec door sensors have fared much better.

Life goes on.

[SteveMSJ]

I just want to say "THANK YOU" for an invaluable plug-in which fills a void that should have been part of the HS core.

Being subject to higher and higher tides, I feel comfortable that my water sensors will not fail because of battery issues. Interestingly, the Aeotec water sensor went through a set of batteries fairly quickly. The Aeotec door sensors have fared much better.

Thanks. It's always good to here when things are working, not just problems


At some point I should probably move this plug-in to a better named thread in a more appropriate part of the forum.

Steve

[akurz]

Suggestion...

Hi Steve,

First of all - this is a really useful plugin and I really enjoy using it. It's extremely helpful the way it is and it does it's job (alerting me about dead devices) just brilliantly. Over time the plugin has become a bit more than that by including battery statistics and stuff, but as we all know Z-Wave battery monitoring is flaky at it's best and most manufacturers have their own "creative" ways of reporting battery levels.

I believe that the one big problem the plugin suffers from is battery levels that go up and down because of "creative reporting", ambient temperature and god knows what else, ending up with stats like this one:

22.06.2017 04:44: 100% 0,0% per day
21.06.2017 17:14: 84% 14,6% per day
20.06.2017 14:53: 100% 0,0% per day
20.06.2017 02:53: 84% 32,0% per day
19.06.2017 14:53: 100% 0,0% per day
19.06.2017 02:53: 84% 11,5% per day
17.06.2017 17:25: 100% 0,0% per day
15.06.2017 21:40: 100% 0,0% per day
15.06.2017 10:12: 84% 719,9% per day
15.06.2017 09:40: 100% 0,0% per day
14.06.2017 22:12: 84% 11,2% per day
13.06.2017 11:52: 100% 0,0% per day
13.06.2017 08:40: 81% 854,9% per day
13.06.2017 08:08: 100% 0,0% per day
12.06.2017 20:40: 84% 767,9% per day

This device for example occasionally jumps back to 100%, but 84% is it's real value. So what I suggest is to only ever allow battery devices to set a new value if it's actually lower than the value on record. If a battery goes from say 84% to 80% there's a reason for it, even if it jumps up to 82% or more after that. The interesting fact for me is that under worst circumstances the real value of the device is 80%. So just leave it there. This should make sure the reported discharge curves are smoother and much more plausible.

Exceptions must be made for devices that sometimes report 0% values (yeah, I have some doing that as well) and of course any upward change that goes over the "Battery New Increase" threshold, but other than that the only way is down for batteries

What do you think?

Cheers,
Alex

[SteveMSJ]

Hi Steve,

First of all - this is a really useful plugin and I really enjoy using it. It's extremely helpful the way it is and it does it's job (alerting me about dead devices) just brilliantly. Over time the plugin has become a bit more than that by including battery statistics and stuff, but as we all know Z-Wave battery monitoring is flaky at it's best and most manufacturers have their own "creative" ways of reporting battery levels.

I believe that the one big problem the plugin suffers from is battery levels that go up and down because of "creative reporting", ambient temperature and god knows what else, ending up with stats like this one:

22.06.2017 04:44: 100% 0,0% per day
21.06.2017 17:14: 84% 14,6% per day
20.06.2017 14:53: 100% 0,0% per day
20.06.2017 02:53: 84% 32,0% per day
19.06.2017 14:53: 100% 0,0% per day
19.06.2017 02:53: 84% 11,5% per day
17.06.2017 17:25: 100% 0,0% per day
15.06.2017 21:40: 100% 0,0% per day
15.06.2017 10:12: 84% 719,9% per day
15.06.2017 09:40: 100% 0,0% per day
14.06.2017 22:12: 84% 11,2% per day
13.06.2017 11:52: 100% 0,0% per day
13.06.2017 08:40: 81% 854,9% per day
13.06.2017 08:08: 100% 0,0% per day
12.06.2017 20:40: 84% 767,9% per day

This device for example occasionally jumps back to 100%, but 84% is it's real value. So what I suggest is to only ever allow battery devices to set a new value if it's actually lower than the value on record. If a battery goes from say 84% to 80% there's a reason for it, even if it jumps up to 82% or more after that. The interesting fact for me is that under worst circumstances the real value of the device is 80%. So just leave it there. This should make sure the reported discharge curves are smoother and much more plausible.

Exceptions must be made for devices that sometimes report 0% values (yeah, I have some doing that as well) and of course any upward change that goes over the "Battery New Increase" threshold, but other than that the only way is down for batteries

What do you think?

Cheers,
Alex

It's an interesting idea and I will give it some thought.
I also have one or two devices where the reported battery level bounces around or hovers between two values. The trouble is 'what is the true value' and how useful is the reported value anyway?
I have discharge rate alerts turned off for most of my devices and don't pay too much attention to the reported battery levels, although find it interesting to view the history for a device.

It might be confusing to have the plug-in showing a different level to that shown for the actual device but I could possible display two values, the reported value and the baseline value with discharge rates and alerts based on the baseline value. I would probably need to make it configurable for individual devices and also have a reset button.

When I have some time to play around I will see what I can come up with.

Steve

[akurz]

Hi Steve,

Yes, I've thought about the contradicting values on "original" battery and your plugin, but let's face it: most Homeseer users have already given up on the "original" battery value a long time ago as it's simply not giving any reliable info. The stats in your plugin already help, but wouldn't it be nice to "fix" this issue and give people a value that's actually worth looking at?

Cheers,
Alex

It's an interesting idea and I will give it some thought.
I also have one or two devices where the reported battery level bounces around or hovers between two values. The trouble is 'what is the true value' and how useful is the reported value anyway?
I have discharge rate alerts turned off for most of my devices and don't pay too much attention to the reported battery levels, although find it interesting to view the history for a device.

It might be confusing to have the plug-in showing a different level to that shown for the actual device but I could possible display two values, the reported value and the baseline value with discharge rates and alerts based on the baseline value. I would probably need to make it configurable for individual devices and also have a reset button.

When I have some time to play around I will see what I can come up with.

Steve

[ZeroGravitas]

Access to Hometroller

Hi all:

I am new to Homeseer and am just building out and learning the system, one of the first things I ran into was no battery readings, so took an instant like to this plugin. Having said that, I have what I'm sure is a really simple issue but I can't seem to resolve it.

I have a Hometroller Zee S2.

I cannot login, using WinSCP, to the Hometroller to load the plugin files. It finds the unit no problem but I get an 'access denied' message when validating the password. I am inputting the login and password I changed to when I first installed the unit (and which works fine when accessing via Chrome).

Apologies & thanks in advance for what I'm sure is a small issue I am missing.


Rod

[Ltek]

Hi Steve,

Yes, I've thought about the contradicting values on "original" battery and your plugin, but let's face it: most Homeseer users have already given up on the "original" battery value a long time ago as it's simply not giving any reliable info. The stats in your plugin already help, but wouldn't it be nice to "fix" this issue and give people a value that's actually worth looking at?

Cheers,
Alex

Agreed

Seems Rich doesnt care to fix this problem - it IS a problem. Pretty important to have an accurate read when 95% of my zwave devices are battery powered.

Sux to go from a $150 Vera hardware/app & free plugin system to a $150 app alone (which needs expensive plugins that HS makes money from) only to see the basics ignored and bugs not fixed

[SteveMSJ]

I have a Hometroller Zee S2.

I cannot login, using WinSCP, to the Hometroller to load the plugin files. It finds the unit no problem but I get an 'access denied' message when validating the password. I am inputting the login and password I changed to when I first installed the unit (and which works fine when accessing via Chrome).

Rod,

I don't have a zee so I can't give you definitive guidance on this. When I have played with HS3 on a Pi I have installed the operating system myself so username and passwords were configured by me. There have been a number of threads on the board about accessing the Zee using putty and WinSCP and I think the latest information I read was that the Username is either 'Homeseer' or 'homeseer'. The password is what you set it to when you configured the Zee. So I think the confusion is probably that the password is what you set but the username stays as 'Homeseer' possibly lowercase. Give both a try.

Steve

[SteveMSJ]

Seems Rich doesnt care to fix this problem - it IS a problem. Pretty important to have an accurate read when 95% of my zwave devices are battery powered.

I don't think think the issues (features ) with battery reporting can be laid solely at Homeseer's door, although I'm sure there is more they could do about it. A lot has to do with the individual devices and how they report. For example the attached screen shots show the battery history for a StellaZ over a reasonable period of time. The level hovered around 70%, dropped, to 42% for 12 hours, rose back to 71%, dropped to 69% a couple of weeks later and then died about a week later still reporting 69%. The batteries were replaced on 30/04/17 and the level reported 89%. It has worked its way down to 71% over the last couple of months with some fluctuations up or down. Now, I suspect that the fluctuating values and fact that it was reporting 69% when it died are down to the device itself not Homeseer. However, my other identical StellaZ always reports 0% no matter how many times I re-scan it. That is more likely to be a Homeseer issue.

I don't have in depth first hand knowledge of systems other than Homeseer but I know that when I have searched for problems with battery reporting on the StellaZ, for example, users of other systems also have problems.

For most of my battery devices I don't rely on levels, I need to be alerted when devices die, which is the reason I wrote this plug-in. The plug-in can do a lot with levels but it's primary purpose is to alert you when the batteries die, irrespective of the reported level

Steve

[Ltek]

All of my devices reported consistently and accurately using Vera, for years. In HS3 most don't report at all.
I had several connect to both systems at the same time, for 2 weeks and they reported correctly in vera, not Homeseer.

Based on years of the same devices working 100% properly in Vera, the only possible conclusion is Homeseers is the problem... Or vera is magical.


Sent from my SAMSUNG-SM-G935A using Tapatalk

[SteveMSJ]

All of my devices reported consistently and accurately using Vera, for years. In HS3 most don't report at all.
I had several connect to both systems at the same time, for 2 weeks and they reported correctly in vera, not Homeseer.

Based on years of the same devices working 100% properly in Vera, the only possible conclusion is Homeseers is the problem... Or vera is magical.


Sent from my SAMSUNG-SM-G935A using Tapatalk

Why on earth are you using Homeseer then?

[Ltek]

Why on earth are you using Homeseer then?

vera has 1 fatal flaw... when it gets to the level of automation and integration I do, it has stability issues under heavy load . The hardware cannot handle it. Overall it has been really good.
Homeseer is OK, but it could be amazing if there were better attention to detail in the system and the user experience was better. I've been writing up a review that I'll post once I've got my entire system running. I'm also a beta tester for an unreleased commercial system, so I may be able to compare it to that one too, not sure yet.

Sent from my SAMSUNG-SM-G935A using Tapatalk

[mwolter]

Hello SteveMSJ,
In my quest to resolve incorrect battery reporting (always 100%) for my Aeotec Multisensor 6 sensors on my SEL (Linux) I have updated to the latest zwave beta 3.0.1.131 and it appears all devices (except smoke detectors) created by your plugin are reporting offline, when in fact they are working properly. I verified that "log poll and wakeup messages is on" but the devices still report offline. Have you noticed an issue with this zwave version?

[SteveMSJ]

Hello SteveMSJ,
In my quest to resolve incorrect battery reporting (always 100%) for my Aeotec Multisensor 6 sensors on my SEL (Linux) I have updated to the latest zwave beta 3.0.1.131 and it appears all devices (except smoke detectors) created by your plugin are reporting offline, when in fact they are working properly. I verified that "log poll and wakeup messages is on" but the devices still report offline. Have you noticed an issue with this zwave version?

I'm on 3.0.1.130. I'll give 131 a try and report back.

Steve