Rule behavior changed after going from 2.3.0.124 to 2.3.1.137

I wrote rule awhile ago to give me an alert when a battery goes under 50%. Simple but effective. Since upgrading I get random reports of batteries that are NOT under 50%. Rule looks like this:

And i'm getting bogus notifications like this:

Any suggestions would be appreciated. Or is this a bug in the Rule Machine in this release?
Thanks,
Jay W

Did you try the native app Notifications? It´s easy to do what you want, I have the same rule running in it without problems!

1 Like

I just created a quick test, similar idea but different attributes:

I found the same thing: the rule triggers when any value changes and any of the values is less than the specified trigger (even if the device that generated an event has a value that is not in this range):

I remember "any" triggers working like this a while back and thought that was considered a bug, since fixed, so perhaps it was inadvertently re-introduced. I downgraded to 2.3.0 and verified that this behavior was different, as I remembered (and as you mentioned).

@bravenel would be the one to ask.

The workaround then was to use separate triggers rather than a single "any" trigger, which would certainly work now but take a lot more clicks.

1 Like

What version of Rules is this rule using?
(You can find it in the last column of the apps screen.)

5.1

Ouch. That would be painful! It does look like a bug was reintroduced. I would have liked to test the beta but I was away for an extended time and unable to test 2.3.1 during the beta.

Oh brother. So elegant. Seems to do what I want with 87.3% less kludginess. I rewrote it as an instance of Notifications. Let's see how it does. Thanks @marcusvrsilva

1 Like

I will look into it.

2 Likes

You might also try Device Activity Check which can simply let you know when a device battery dies and it goes offline. I use this for all my battery devices. I gave up on battery level notifications, because many of my devices hang at 1% or 0% for WEEKS before they completely die, and as a result I was changing batteries much more often than I needed to change them.

The flaw with this approach is that sometimes it's critical when a device dies. For example we recently took a very long road trip. One of the most important types of devices NOT to die while you're gone is water sensors. I would rather replace the battery a little early than have them die a day after we leave for an extended trip. I turn off the water, but still, stuff can happen. Like sump pump failure or water heater leaks.

Jay

Yeah, fair enough. If I’m going to be away for a while, I do replace the low batteries for critical devices. So a mixed approach would probably be best.

You might also check out the Device Watchdog by @bptworld; it has the ability to configure both activity and battery monitor checks.

1 Like

I'm pretty sure they have always worked this way. Call it a 'feature'. The logic is as follows: If any of these devices send an event, see if the condition that any of them are in the target state or not is true. That's different obviously than seeing if the eventing device is in the target state. However, this sort of trigger uses the same logic as a condition of any being below a threshold. This would not be something easy to change.

So, if what you want is to trigger only if the reporting device is less than a threshold, use separate triggers, one for each device -- not a multi-device trigger.

The app linked to above (Device Activity Check) is one I wrote and can monitor either activity or battery or both. I believe this is similar to the other app mentioned, as well.

3 Likes

Well, it did change after this last release. Until I updated, I only got a single alert for my dying water sensor. I watched it for 26 days while I was on a road trip. :slight_smile: Once I updated 2.3.1.x upon my return, I starting getting all of these random notifications. All is well as I have changed to another method to watch batteries.

1 Like

But, maybe the bug was the behavior before this...