Announcement

Collapse
No announcement yet.

Plugin to monitor Z-Wave battery device Health - CLOSED

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by trevor-austin View Post
    Now I can see that from the manuals, but nowhere can I find which parameter it is I need to set, I don't suppose you know which one it is do you? The manuals seem to cover everything but that, assuming you are using the Fibaro homecentre to set the wake up interval.
    It's a long time since I set one of these up but from memory, if you wake it up and go into settings the wakeup interval can be set from a drop down. Other parameters, like temperature reporting you have to set by specific parameters.

    Steve

    Comment


      Originally posted by SteveMSJ View Post
      It's a long time since I set one of these up but from memory, if you wake it up and go into settings the wakeup interval can be set from a drop down. Other parameters, like temperature reporting you have to set by specific parameters.

      Steve
      Great,

      I'll try that thanks.

      Comment


        Originally posted by SteveMSJ View Post
        If you have excluded/included the device then presumably it is now a new device as far as HS is concerned, with new node number and reference. If it was a wakeup device then the plug-in would automatically create a new child to monitor it the first time it wakes. As it is a listening device then you will need to add it to the poll list if you want to monitor it.

        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
        I'll try to remember to test this tonight. The battery level did get updated overnight. I also renamed the device and now both are shown in the list separately. I assume it is safe to delete the old one?

        Comment


          Originally posted by TechFan View Post
          I'll try to remember to test this tonight. The battery level did get updated overnight. I also renamed the device and now both are shown in the list separately. I assume it is safe to delete the old one?


          Yes it's safe to delete the old one.
          Steve

          Comment


            Although I also have an event based battery 'heatbeat' scheme in place I was interested in your plugin so have been trying it out.....20 devices all the same type, and has been working for some days but it has just stopped for some reason. Basically all wakeup's are occuring according to my event scheme but the Root device is showing as seen below. Tried stopping and starting plugin but does not work. Any ideas to try ?
            Attached Files

            Comment


              Originally posted by naellis View Post
              Although I also have an event based battery 'heatbeat' scheme in place I was interested in your plugin so have been trying it out.....20 devices all the same type, and has been working for some days but it has just stopped for some reason. Basically all wakeup's are occuring according to my event scheme but the Root device is showing as seen below. Tried stopping and starting plugin but does not work. Any ideas to try ?
              Try starting the plug-in with LogLevel set to 2 and let's see what you get in the log. You can set the LogLevel before starting the plug-in by editing the SDJ-Health.ini file in the /config folder.

              Steve

              Comment


                Originally posted by SteveMSJ View Post
                Try starting the plug-in with LogLevel set to 2 and let's see what you get in the log. You can set the LogLevel before starting the plug-in by editing the SDJ-Health.ini file in the /config folder.

                Steve
                Did that but no change. I thought I would just try disabling/enabling another plugin and the same "Interface missing......." came up. I've seen this happen in the past on other plugins and usually another disable/enable does the trick but not this time. So something wider must be going on - not with your plugin though. I restarted HS and now everything is back. Have you seen that yourself ? Will keep watching and see how it goes. Thanks

                Comment


                  Originally posted by naellis View Post
                  Did that but no change. I thought I would just try disabling/enabling another plugin and the same "Interface missing......." came up. I've seen this happen in the past on other plugins and usually another disable/enable does the trick but not this time. So something wider must be going on - not with your plugin though. I restarted HS and now everything is back. Have you seen that yourself ? Will keep watching and see how it goes. Thanks
                  I'm glad you have it sorted. I have sometimes had the "Interface missing..." message with plug-ins, most commonly when updating them. I don't think I have ever had the situation where a disable/enable hasn't sorted the issue though.

                  Steve

                  Comment


                    Originally posted by TechFan View Post
                    Here you go. Attached.
                    Originally posted by SteveMSJ View Post
                    Ok, thanks.
                    I have all the information I need now so I hope to build in the ability to monitor this type of heartbeat device soon. Probably next weekend.
                    Steve
                    Techfan
                    Please could you test the version attached here to see if it deals with your ZSmokes. I'm kind of working in the dark here because I have no device to test it on. I created a virtual group of devices with properties as close to the ZSmokes as possible and it works but it needs to be tested on the real thing.
                    You will find a new parameter at the bottom of the 'Config' page called 'MonitorHeartbeats'. This is off by default so you need to check it.
                    The plug-in then monitors device value changes and if it sees one with a corresponding status of "Alarm Heartbeat" then it treats it equivalent to a wake-up and adds a monitoring child device. This might also work with other Z-Wave devices that send "Alarm Heartbeat" notifications if that is a Z-Wave standard. We will see.

                    Can you also look in the list of 'Available Devices' that appears when you click on 'Select Devices' in 'Devices Requiring Polling'. This list now filters out devices that report that they aren't pollable. Your ZSmokes should no longer appear in this list if I have this working correctly.

                    There are quite a number of other changes/enhancements included in this version of the plug-in. Once I'm confident it is working ok I will update the version and all the details in message #7 of this thread.

                    One thing that is different is that when wake-ups are detected, whether from log messages, polling or heartbeats they are now put in a queue and processed at the 'Refresh Interval' rather than at the instant they happen. This is due to a potential collision issue in my database which I haven't seen happen but is theoretically possible. By queuing them I can deal with them in a more organised fashion.

                    Devices that are monitored by polling no longer generate a simulated wakeup message but are popped straight into the queue for processing.

                    Some of the other changes, which I will describe in more detail when I update the main description and instructions, are as follows:

                    Location and/or Location2 can optionally be included in the displayed name of monitored devices to make them easier to identify, depending on your naming convention.

                    The Location and/or Location2 defaults can be set to blank in which case when a monitoring child is created it will adopt the locations of the device it is monitoring rather than a defined value. There are also buttons to rebuild the child devices so that ones that have already been created can be relocated.

                    The displayed information in the Health Root device can be configured by control buttons to Status Only, Short Report or Full Report. Anything other than Status Only may be extremely cluttered in the web display but work well when included in an email, notification message or HSTouch textbox.

                    What I haven't included at present is battery level and discharge rate monitoring. The battery levels are shown but I don't trigger anything from them. Whilst I have this built into a version I am testing I'm not happy with the way they are working at the moment so won't include them for now.

                    Steve
                    Attached Files

                    Comment


                      Originally posted by olof View Post
                      Hi Steve, I'm using your plugin and it is really helpful. I only have one problem. I have an device (HeatIt Thermostat) for floor heating that is an non battery device but sends wake up messages so it is detected. It would be nice to add in config the possibility to exclude certain devices.
                      Version 3.0.2.2 onward ignore wakeup messages if the device does not have a battery child. I haven't updated the main message yet as I'm waiting for some feedback on testing other aspects of the update, but you can find it in the thread if you want to test.

                      I hadn't expected this to be an issue but the other day I got a random wakeup message from a fibaro switch! Z-Wave has many peculiarities.

                      You can delete the monitoring child for your HeatIt and it shouldn't appear again.

                      Steve

                      Comment


                        Originally posted by olof View Post
                        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
                        I think what you reported here is corrected in version 3.0.2.2.

                        The LastDeviceToFail is there so that when an event is triggered any action can show the device that triggered the notification. In some circumstances there could be several devices fail in close succession in which case the plug-in pauses for a couple of seconds between each so that multiple events can be triggered each with an updated LastDeviceToFail.

                        Also version 3.0.2.2 has options to display in the root much more information about the status of all the child devices which is useful in notifications. You can for example configure an event to send an email or pushover message that lists the details of all the failed devices or indeed all the monitored devices with their current status.

                        Steve

                        Comment


                          Originally posted by SteveMSJ View Post
                          Techfan
                          Please could you test the version attached here to see if it deals with your ZSmokes. I'm kind of working in the dark here because I have no device to test it on. I created a virtual group of devices with properties as close to the ZSmokes as possible and it works but it needs to be tested on the real thing.
                          You will find a new parameter at the bottom of the 'Config' page called 'MonitorHeartbeats'. This is off by default so you need to check it.
                          The plug-in then monitors device value changes and if it sees one with a corresponding status of "Alarm Heartbeat" then it treats it equivalent to a wake-up and adds a monitoring child device. This might also work with other Z-Wave devices that send "Alarm Heartbeat" notifications if that is a Z-Wave standard. We will see.

                          Can you also look in the list of 'Available Devices' that appears when you click on 'Select Devices' in 'Devices Requiring Polling'. This list now filters out devices that report that they aren't pollable. Your ZSmokes should no longer appear in this list if I have this working correctly.
                          Updated plugin in place. I enabled the MonitorHeartbeats option. I also see that the Available Devices list doesn't have anything available to add anymore (ZSmokes are gone). . .since my locks are all selected and on the right side now. It seems there were a few other devices in the list previously other than my ZSmokes, but I don't remember what they were.

                          We'll see how it all looks in the morning. . .

                          Comment


                            Originally posted by TechFan View Post
                            Updated plugin in place. I enabled the MonitorHeartbeats option. I also see that the Available Devices list doesn't have anything available to add anymore (ZSmokes are gone). . .since my locks are all selected and on the right side now. It seems there were a few other devices in the list previously other than my ZSmokes, but I don't remember what they were.

                            We'll see how it all looks in the morning. . .
                            Decided to try removing one of my doors from the selected Polling devices, as a test. . .and now I can't add it back. . .it doesn't show up on the left side. . .so it appears that the filtering isn't working as expected?

                            Comment


                              Originally posted by TechFan View Post
                              Decided to try removing one of my doors from the selected Polling devices, as a test. . .and now I can't add it back. . .it doesn't show up on the left side. . .so it appears that the filtering isn't working as expected?
                              hmm. The list is now filtered so that devices aren't included unless they report that they are pollable. If the locks have gone as well as the ZSmokes then I suspect that, despite the ZWave pi returning a result of 1 = oK, when I poll the battery of those locks, the Z-Wave pi is not really polling them. If you can test one of the ones that is still being polled with and without batteries we will be able to resolve this. If possible capture the SDJ-Health logged messages at a poll with and without batteries.

                              Are all your locks the same type? I'm sure we will find a way of determining whether they are dead or alive with a bit more detective work. Hopefully we will then have a method that works with similar devices.

                              Thanks,
                              Steve

                              Comment


                                Originally posted by SteveMSJ View Post
                                hmm. The list is now filtered so that devices aren't included unless they report that they are pollable. If the locks have gone as well as the ZSmokes then I suspect that, despite the ZWave pi returning a result of 1 = oK, when I poll the battery of those locks, the Z-Wave pi is not really polling them. If you can test one of the ones that is still being polled with and without batteries we will be able to resolve this. If possible capture the SDJ-Health logged messages at a poll with and without batteries.

                                Are all your locks the same type? I'm sure we will find a way of determining whether they are dead or alive with a bit more detective work. Hopefully we will then have a method that works with similar devices.

                                Thanks,
                                Steve

                                Here are some related entries. I didn't find any SDJ-Health entries in the log during the night when it failed to find the battery device (batteries removed). It didn't show the device getting queued during the night when the batteries were out? I did see the Z-Wave Warning messages like the ones below at different intervals during the night.

                                Code:
                                Jan-29 9:48:17 AM	 	SDJ-Health	Device 016A24FE-017 recovered from missed wakeup state.
                                Jan-29 9:43:27 AM	 	SDJ-Health	016A24FE-017 added to message queue for processing.
                                Jan-29 8:43:34 AM	 	Z-Wave Warning	No response from device when getting level: Entry Floor Entry Area Front Door - Node 17 Battery, Node: 17
                                Jan-29 8:43:34 AM	 	Z-Wave Warning	No response before timeout to Get Battery Level for Entry Floor Entry Area Front Door - Node 17 Battery (17)
                                Jan-29 2:43:34 AM	 	Z-Wave Warning	No response from device when getting level: Entry Floor Entry Area Front Door - Node 17 Battery, Node: 17
                                Jan-29 2:43:34 AM	 	Z-Wave Warning	No response before timeout to Get Battery Level for Entry Floor Entry Area Front Door - Node 17 Battery (17)
                                The device I tested by removing from the polling list last night. . .went into alert status (as I would expect). The rest of the doors have a good status.

                                One of my ZSmokes has a good status and the other one is in alert status. I am sure the Heartbeat has been sent, otherwise I would be getting emails about the smoke alarm not checking in. But, it hasn't been seen by the Health plugin. The one that is reporting in had an alarm this morning (just the malfunction alarm that gets sent after someone takes a shower and then opens the door and lets the steam out), so maybe that was enough to get it found.

                                Comment

                                Working...
                                X