Originally posted by SteveMSJ
View Post
Announcement
Collapse
No announcement yet.
Plugin to monitor Z-Wave battery device Health - CLOSED
Collapse
X
-
This tool looks perfect for functionality I need, however I installed it yesterday lunchtime but no devices have yet been created, just the root device. Although several devices have connected with battery status updates, anything obvious I might have missed?
Edit: Looks like I missed turning on log wake up calls, so waiting againLast edited by trevor-austin; January 24, 2017, 05:07 AM.
Comment
-
This has all configured nicely, the only thing it will not work with at present is my Fibaro door/window sensors (Homeseer sees them as Zwave Fibaro on/off sensors) they work fine in Homeseer, however they always show zero battery.
But they also don't appear to send wake up calls. Any ideas?
Comment
-
Plugin to monitor Z-Wave battery device Health
I think I found a bug or inconsistency. As you can see on screenshot the root device is not updated properly. You see it is showing last device who has failed, but is currently up (so maybe good to then not show that message anymore) but more interesting is the fact that It triggered (see change time) by the aeon who reported low battery. But that is not showed in the text
Comment
-
Originally posted by trevor-austin View PostThis has all configured nicely, the only thing it will not work with at present is my Fibaro door/window sensors (Homeseer sees them as Zwave Fibaro on/off sensors) they work fine in Homeseer, however they always show zero battery.
But they also don't appear to send wake up calls. Any ideas?
I have 3 fibaro door/window sensors which are working fine. You can configure the wake up period as long as you like with these so maybe yours are set to a very long time. If you want to monitor them you it's best to set a wake up time of say 6 to 12 hours.
Steve
Comment
-
Originally posted by olof View PostI think I found a bug or inconsistency. As you can see on screenshot the root device is not updated properly. You see it is showing last device who has failed, but is currently up (so maybe good to then not show that message anymore) but more interesting is the fact that It triggered (see change time) by the aeon who reported low battery. But that is not showed in the text
I'm away for a few days. I will try to look at this at the weekend.
Steve
Comment
-
Originally posted by TechFan View PostI have also noticed that one of my devices is reporting good (green) even though it has a battery level of 0%? Seems like that should at least be a warning. . .
Maybe it is because it is one of the devices I had to add to the configuration for Devices requiring polling (doorlock)?
The plugin only alerts when the device fails to wake or responds to polls, i.e. dead or alive. The battery level is not monitored.
I will be adding battery monitoring as an option but that wasn't the original goal.
Steve
Comment
-
Originally posted by SteveMSJ View PostThe plugin only alerts when the device fails to wake or responds to polls, i.e. dead or alive. The battery level is not monitored.
I will be adding battery monitoring as an option but that wasn't the original goal.
Steve
Comment
-
Originally posted by TechFan View PostThat makes sense. I was thinking it was monitoring battery, but really it is making sure each battery device is still checking in at all. So, with the devices I configured to need polling, does this mean that the device actually responded even though its battery level is 0%?
That is correct. However, as I don't have any locks I'm relying on your feedback to determine whether the polling method works with them. Can you test whether the lock reporting 0% is actually still operating. I certainly have some devices that still work happily when the battery is reporting 0% and conversely others that die at 70%.
Steve
Comment
-
I went and did some checking. That outside garage door was reporting that it was working in HS, but it wasn't physically locking/unlocking. . .so I had to exclude/include it again. . .seems to be controlling again. Still hasn't updated battery levels. . .and manual test of batteries I just replaced seem to be good still. Will give it a bit of time to try to get to its first poll interval.
So, HS was reporting it was working. . .so it must have reported back to the wakeup request. . .?
Comment
-
Originally posted by TechFan View PostI went and did some checking. That outside garage door was reporting that it was working in HS, but it wasn't physically locking/unlocking. . .so I had to exclude/include it again. . .seems to be controlling again. Still hasn't updated battery levels. . .and manual test of batteries I just replaced seem to be good still. Will give it a bit of time to try to get to its first poll interval.
So, HS was reporting it was working. . .so it must have reported back to the wakeup request. . .?
We could do with running a test on a lock to check that they are being monitored properly. The way to do this would be to set LogLevel 2 and identify the SDJ-Health poll log messages for a particular device, it will report the return result and value in the log. Then remove the batteries and watch what is reported the next time the plug-in polls it.
The only non-wakeup battery device I have is a Everspring Siren which tests correctly. The plug-in polls the battery child because I found with that if I polled the root device HS reported a successful poll even with the batteries removed! It's possible that the locks don't behave as one would expect when polled but the only way to find out is to test.
Steve
Comment
-
Originally posted by SteveMSJ View PostI have 3 fibaro door/window sensors which are working fine. You can configure the wake up period as long as you like with these so maybe yours are set to a very long time. If you want to monitor them you it's best to set a wake up time of say 6 to 12 hours.
Steve
Comment
Comment