Hi @bravenel,
Ok, great, thanks for confirming my suspicions and that I'm not going nuts. 
Have a great night.
@bravenel, I have seen eerily similar if not the same behavior with Safety Monitor. I wonder if this affects both?
I had this happen, and at the time I forgot to capture a log and send it to you guys. I think the thread below also captures this or a similar issue, in particular look at
1 Like
That's an embarrassing bug -- it's been there forever. Easy to fix... will be in next release
Totally different code for RM vs HSM. Please post a fresh example when you have one to show.
Sure. Just wasn't sure it was related in the code or not. When I get some time and can duplicate it, I will start a new thread.
Sorry for derailing the thread. 
No worries, I'm glad I was able to help improve the product.
Wait, this is a bug? I thought it was a feature. 
(For real: I've explained the difference between a single "any" trigger--as here--vs. multiple individual triggers to many people in this exact way. Definitely would have reported this a while back if I didn't know this wasn't the desired behavior.)
The rule would work as intended with triggers like Battery level of 150 reports <= 15 OR Battery level of B40 reports <= 15 OR ...., though, of course, that's a bit more clicking (but in this particular case might actually be better since you can customize the level for each quite-likely-wildly-different device).
Whether anyone has a use for the current behavior, I don't know, but I would make sure to feature this prominently in the release notes if you make this change since by this point there's probably someone out there... 
I had a similar experience long ago (in tech years) with RM and Safety Monitor as well. I was glad you brought it up because I had just moved on and forgotten about it.
Hi @bertabcd1234
I agree with your statement and understand. The trigger works just fine and as expected, that is not the issue. The problem is that the %device% used in the notification is always the device that called the routine not the device that actually satisfied the trigger. For example, when device 150 called the routine and the value was ok, device 161 was the value that satisfied the trigger, but the notification indicated 150 as the device and not 161.
It's just a reporting thing not a functional thing.
@Ken_Fraleigh - Yea, it's certainly no big deal, I just brought it up cuz I was pulling my hair out trying to figure out why a device that was NOT below the threshold was causing the trigger. That's what I thought until I dug in a little deeper, ran a few tests, and found it was just the reporting issue and not a rule/trigger issue.
1 Like
Yes, this is a bug. Consider the statement in English: If any of these sensors reports its value to be less than 10, do something. If a sensor reports 20, should the rule do something? No, because that sensor reported a value greater than 10. The state of any other sensor should be irrelevant.
Consider the condition "if any of these sensors is less than 10"... This is different, and it should be true if any one or more than one of the sensors is less than 10, not caring as to which sensor made a report.
This is the essential difference between a trigger and a condition.
1 Like
I have been successful using this since I found this post until the latest Hubitat update. Ever since latest update (2.3.6.144) I have had hundreds of devices which have 100% battery fire on this notification. This rule had been working flawlessly for about 2 years and was accurate for me.
Not sure what happened in last update. I even tried adding a “stays that way for 1 hour” and it’s still falsely firing due to one device being below the threshold.
I used to only get the single device which fell under the threshold (you can see in screenshot I have one device at 25% but I am not getting it’s notification only all the other devices)
That's strange, it looks like that whenever any of the battery devices sends an event the rule fires regardless because one of them is below the threshold. Tagging @bravenel as he is the RM guru, he'd have to comment further. I haven't upped to ver 2.3.6 yet so I haven't seen this issue.
When there is any device below the designated threshold this rule will trigger, since it says Any < 30.
%device% refers to the device that caused the trigger to be evaluated. Combined, the result is what you are seeing. The device below 30 needs to be dealt with.
I would not use a rule like this for reporting low battery levels, as I've explained elsewhere.
2 Likes
I do understand how the rule reads, as a software engineer I also understand by the means of how the rule reads it is working as intended. However, I am merely pointing out that I have been using this rule since late 2020 and it has been only firing the notification for the device which falls below 30% and that something has changed in rule machine causing this to no longer function.
I am open to another way to monitor battery notification however I even attempted to create a HSM profile for it and that never functions however this has been fine for years.
To further prove my point I am NOT getting notifications for ALL of these devices in my multiselect but just a few of them randomly as you can see in my screenshot. I have yet to receive a single notification for the truly low one which I am purposely leaving low on power until I can get this resolved.
My next option if this is not resolved is to just expose all of my Zigbee and Zwave devices to homekit since I strictly use habitat for automations but not a UI and use homekit for all interaction with all devices. Homekit shows battery status for devices in the header so that would likely be sufficient for me as last resort.
I just never bothered exposing doors and windows since I only cared about battery notification and this has been rock solid for many years till latest update.
I have a similar rule, probably the explanation subject, that I just tested.
I use %text% but I'm getting similar results.
I originally went with the Notifications app, but it didn't support the Ecolink chime/siren, so I went with RM.
What is the best way to go for low battery notifications?
I just tried the Notifications app.
It seems to work...no bogus reports.
Perhaps I will just use Notifications with Pushover, and not use the Chime/Siren.
edIt: I also found that %text% didn't work with Notification-used %device% instead.
Don't use event driven battery notifications. Just look at the device reports every day. See this app:
The problems with event driven battery notification include (a) dead batteries don't report at all, (b) batteries can go from seemingly OK to dead without any notification, (c) you don't really need this in real-time, etc.
4 Likes
Ok I’ll start using the reporting tool linked.
However can you explain why only 2-3 notifications fire and not one for every device’s battery level?
I NEVER receive the notification for the device below 30.
If you look through the forums this last update has tons of RM triggers not firing as expected for various people with similar (not battery related) rules as these.
I understand we should not monitor batteries this way but can we get an acknowledgment of a regression in RM?
I am away from my home right now but plan to downgrade to previous software as many others have and resolved their issues.
I will just stop updating my device if that’s what’s required for stability but until this update I was always on latest update and I bought the C7 hub in middle of 2020 and have had 0 issues until this.
I admit, I haven't tried this app yet.
However, I did select 'battery' in the status column of the device page.
It would be nice if that column was sort-able so there'd be less scrolling.
Even if there was a mix of status types, like off/on, %, etc, the chances are, for this case, that all the battery % would be grouped together, and likewise for the other types.
edit: On a side note, I got that Intellitech water sensor to report battery status after doing an exclude and include. It'll probably now be at 100% until it fails, lol.
What would you recommend for, as an example, locks where they work pretty decently at a reported 50%, but not so well at a reported 40%?
I would ordinarily say the answer is to ‘use your ears,’ which works pretty well so long as you’re there to hear it, but that’s not always the case.
I setup an HSM rule to tell me when a lock dips below 60%, and obviously an activity-based notification won’t work, since the radio will have power long past the time when there’s not enough juice to make the lock function properly.
If you're not there to hear, you can't very well replace the batteries either.
I've just become familiar with my lock, and know from experience that it's going to need new batteries twice a year. When I notice it not responding I replace them. But I don't rely on the lock (nor would I rely on any battery powered device). It's a convenience only, one I can live without (hidden key works).
I use Lutron motion sensors inside my house, and they have a theoretic 10 year battery life. They also don't report the battery level. I know one needs replacing when the corresponding automation fails. Don't overthink batteries, they aren't worth it.
3 Likes
