Announcement

Collapse
No announcement yet.

Device status lagging

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

  • Device status lagging

    This morning my SDJ root was showing 1 low battery and 1 missed poll. I checked the device with the missed poll and the battery was completely dead. I replaced the battery and told the root to refresh. The device is now showing 100% battery and the root device is still showing 1 low battery - which is correct. However, the root device is still showing a value of 0 "Missed Wakeup Alert". Should this have switched to 1? Is there a lag before this resets? Thanks.

  • #2
    Originally posted by simonmason View Post
    This morning my SDJ root was showing 1 low battery and 1 missed poll. I checked the device with the missed poll and the battery was completely dead. I replaced the battery and told the root to refresh. The device is now showing 100% battery and the root device is still showing 1 low battery - which is correct. However, the root device is still showing a value of 0 "Missed Wakeup Alert". Should this have switched to 1? Is there a lag before this resets? Thanks.
    There isn't a lag as such, other than the refresh interval, typically set at 120 seconds.
    However, for a device monitored by polling, it won't reset the wake-up until the next time the pi successfully polls the device, so I guess in that respect there is a lag. Have a look at what the monitoring child for that device is reporting. It should reset the next time it polls.
    I might add an option to manually force a poll so you can reset a polled device after replacing the batteries

    Steve

    Comment


    • #3
      Originally posted by SteveMSJ View Post
      I might add an option to manually force a poll so you can reset a polled device after replacing the batteries
      Thinking a bit more about this, did your device immediately report a new battery level when you replaced the batteries? Some do. In that situation it might be sensible if I set the plug-in to consider a new battery level like a successful poll so it would reset the missed wake-up immediately without waiting until the end of the polling interval.
      Steve

      Comment


      • #4
        It did report the new battery level at 100% immediately after changing the batteries

        Comment


        • #5
          Originally posted by simonmason View Post
          It did report the new battery level at 100% immediately after changing the batteries
          It should reset at the next poll but in the meantime can you do me a screenshot of the monitoring child for that device.

          Steve

          Comment


          • #6
            Here is the child device, and the root advanced view. The Home Theater device is the one that I replaced the battery in.

            Comment


            • #7
              Originally posted by simonmason View Post
              Here is the child device, and the root advanced view. The Home Theater device is the one that I replaced the battery in.
              Thanks for the information.
              The root status is indeed incorrect having not been reset in this sequence of events. I think I have found the bug and will issue an update soon.

              Steve

              Comment


              • #8
                Originally posted by SteveMSJ View Post

                Thanks for the information.
                The root status is indeed incorrect having not been reset in this sequence of events. I think I have found the bug and will issue an update soon.

                Steve
                Funny how you forget how your own plug-in works when you haven't touched the code for a while

                At first I thought I had found a bug but I couldn't understand why it hadn't shown up before. On further delving this is actually by design. As you noted, the displayed information on the root device is correct, it is only the value which is confusing. However, the value is only shown by looking at the advanced tab of the root device.

                The long explanation is:
                The reason I programmed it is like this is to do with triggering the main event for notifications as monitored devices go in and out of alert status. There is a hierarchy to the various alerts with a dead device, e.g. Missed Wake-Up, as the highest priority and Battery Life as the lowest priority.

                In your situation you have a device which is showing a low battery value. When that first occurred the root device string will have been set to report this information and the value will have set to 1 to trigger any notification events. Then you had another device which died and missed a poll. The root device string will have been set to report this new information and the value will have been set to 0 to again trigger events.

                You then replaced the batteries in the dead device. The monitoring child for that device will have changed back to healthy and the root device string will have been updated to report the up to date information. There is still one device with low battery status but I leave the value of the root device at 0 so this doesn't re-trigger an alert. On the root device the status shows the correct updated information so it's only looking at the advanced tab that you see the value and the hidden status which are still at 0 - Missed Wakeup Alert.

                The child devices are reporting information for a single device so their status value can go up and down and they have a set of graphics corresponding to the states. These aren't normally used to trigger events because the idea is to just use the root device for reporting.

                I think this explains why nobody has raised this before. However, it is possible to change the status value of a device without triggering events so I think I will make a change to the way this works. I will run the new version for a while before releasing it to the updater as it's not urgent and I want to check that there aren't any unforeseen consequences.

                Steve

                Comment


                • #9
                  Originally posted by SteveMSJ View Post

                  Thinking a bit more about this, did your device immediately report a new battery level when you replaced the batteries? Some do. In that situation it might be sensible if I set the plug-in to consider a new battery level like a successful poll so it would reset the missed wake-up immediately without waiting until the end of the polling interval.
                  Steve
                  Actually the plug-in does already does already do this. It considers a new battery level for a previously dead device as a successful poll in these circumstances. I had forgotten how it works

                  Steve

                  Comment


                  • #10
                    The only reason I noticed is this is because I am using the root value to display two different types of warnings on my touchscreens. Low battery warning displays a red low battery icon. Missed poll displays a yellow full battery icon. Normal displays a grey full battery icon. In this specific use case the low battery icon continued to show (0). It wasn't until I changed the batteries in the one device and it showed 100 that the condition cleared. So according to my touchscreens the condition was showing as missed poll, not low battery. So yes, the change you suggest would take care of that.

                    Of note, I wouldn't have known about either of these conditions without the plugin - it really is very helpful.

                    Comment


                    • #11
                      Originally posted by SteveMSJ View Post

                      Actually the plug-in does already does already do this. It considers a new battery level for a previously dead device as a successful poll in these circumstances. I had forgotten how it works

                      Steve
                      I imagine the other issue with the "0" status not being reset created a red herring - the battery replacement did act as a successful poll, but the status still displayed "0"?

                      Comment


                      • #12
                        Originally posted by simonmason View Post
                        The only reason I noticed is this is because I am using the root value to display two different types of warnings on my touchscreens. Low battery warning displays a red low battery icon. Missed poll displays a yellow full battery icon. Normal displays a grey full battery icon. In this specific use case the low battery icon continued to show (0). It wasn't until I changed the batteries in the one device and it showed 100 that the condition cleared. So according to my touchscreens the condition was showing as missed poll, not low battery. So yes, the change you suggest would take care of that.

                        Of note, I wouldn't have known about either of these conditions without the plugin - it really is very helpful.
                        Yes I see it is necessary for the value to be correct using it the way you are. If you want to try the updated version I have added the exe file only to this post. Just close the plug-in, copy the new exe file over the existing and re-enable the plug-in. The root device value won't reset until you get another alert. You could trigger this by temporarily setting the battery alert level to 100% on one device.

                        Let me know how you get on and thanks for pointing this out.

                        Steve
                        SDJ-Health 3-0-7-0 EXE ONLY.zip

                        Comment


                        • #13
                          Originally posted by simonmason View Post

                          I imagine the other issue with the "0" status not being reset created a red herring - the battery replacement did act as a successful poll, but the status still displayed "0"?
                          Correct.

                          Comment

                          Working...
                          X