When I create a rule, using the Rule Machine, under the action I have it set to send a message.
That message is "%device% is at %value% for battery life". The notification get's sent out but neither the %device% nor the %value% are being populated, they are blank.
This can be done, but takes some doing. See this post.
The reason I posted this is because this used to work. Also, when setting up the rule, this description is actually in there on how to get device information as part of the notification, so is this incorrect and should then be removed??
It would be helpful to see your rule. The %device% and %value% variables are populated based on the device and attribute (value of that attribute) that triggered the rule. If your rule was triggered based on something else (e.g., a "specific time" trigger or invoked from another rule), these variables will not work. A common mistake is to assume that they will "read" some device used in a conditional in which they are contained. Could this explain any if your issues?
In any case, it sounds like the Notifications app could also do what you're doing here, probably with a lot less work to set up. (It's hard to make RM send a specific notification only for a specific device if you have lots of triggers all in one rule--that's what I was going for in the post linked to above, but it's not what I would recommend generally.) If you haven't checked that out yet, it might be worth looking into!
2 Likes
This is my rule - I used to have many devices (thought same thing that too many devices was tripping it up) but get same results even with 1 device in rule.
I will test out the notification app see if it will accomplish what i'm trying to do.
Do you know if this group of variables has a name?
System variables? Global variables seems sort of accurate but probably wrong, since these arenāt part of RMās GV menu and GVs are created by individual users.
That wouldn't really be the problem. The problem is more that if you have a trigger like Device A Battery, Device B Battery any <= 20% and, say, Device A is at 19% and Device B is at 90%, this trigger will still match even if device A's battery didn't change but device B's changed from 90% to 80%. This particular issue can be remedied by splitting it into two triggers, Device A battery < 20% OR Device B battery < 20% (these triggers look similar but behave differently from the previous one). However, then you run into the issues mentioned in the other post of how to determine in your actions which device it really was. In your case, you probably don't care, though it will notify you exactly one each time the battery level changes, which could be at unpredictable times or intervals. With the Notifications app, you could set up a repeating notification, only get notified once until the level goes back up (e.g., you change batteries), etc.--more options with less effort (still no way to only get the notification at a specific time, e.g., if you want to see this when you're probably awake and not at, say, 3 AM when the device finally checks in; a third-party app like Device Watchdog might be better at that).
That being said, your rule as written looks fine. You won't get any notifications now from the rule running based on the device itself because your battery is at 42% and your trigger only matches if it's at or below 20%. If you're trying to simulate things by clicking "Run Actions," it will indeed run your actions section, but the %device% and %value% variables won't be populated because there was no triggering device, so your notification would look something like "is at for battery life." Could that explain what you see?
Thank you for the great explanation - so it may be working but not populating because technically my devices are healthy.
I'm not sure if they have a "standard" name, but they are documented here: https://community.hubitat.com/t/rule-machine-global-variables/9880:
When setting a String value, %device%, %value%, %time%, and %date% are available for most recent event for that rule
(This is in the context of setting the value of a global variable, which at the time that post was written was a new feature to Rule Machine. These variables themselves aren't global, as they are specific to the particular rule.) I think I normally call them "built-in variables" or something to that effect, but I'm pretty sure I made that up, and I'm open to better terminology if it exists. 
EDIT for 2023: I see this is post is often still linked to. Global variables are now a "Rule Machine Legacy" feature, and the replacement is Hub Variables, which are available to theoretically any app, including newer versions of Rule Machine. Local rule variables are still similar. The ones like %device% and %value% are documented here:
1 Like
One question - is it going to notify based on state as it shows up in "Devices" or is this based on the device reporting it's battery level.
Similar variables exist in the notifications (and HSM I think?) app, so I agree it would be nice if the nomenclature were standardized.
Built-in seems like as good a term as any, to me at least. But Iām pretty bad at this stuff so may not be the best judge. 
@bravenel any thoughts?
Yep! You could change your percentage in your trigger and wait for your device to report back (a refresh() on the device might force it to but still might not trigger anything unless the value actually changed), but the rule looks correctly written, so when it's time, it should work.
That being said, you can find lots of posts here (and elsewhere, including the ST Community forum) about the unreliability of battery reporting. I prefer to monitor device activity instead in most cases, something the Device Watchdog app I mentioned above can also help with. But if you know your sensors and their typical behavior, I don't want to steer you away from battery monitoring if does indeed work best for you.
Good luck!
I'm not sure I understand this question, so let me try a couple things and see if any of these are what you're asking:
- the battery percentage Rule Machine sees will be the same one as reported on the page for your device (under "Current States")
- your rule will not trigger unless the battery level changes to a level that matches your trigger (so nothing will happen until the level reaches 20% or below for the first time; it will also trigger every time afterwards if it checks in with a value at or below 20% as well) -- in other words, you need some event (a battery report from the device) to happen for the rule, as-written, to trigger (and the battery level needs to be in the range you specified)
I think my confusion was in that, when testing the rule, i would have expected for it to populate the %device% / %value% based on the rule. I had many devices and pruned it down to one with this expectation but now understand why it was not trigerring.
Thank you very much for the response and the clarification> i will look into the Watchdog app - my goal is to get in front of changing batteries before they die which has been a challenge for me.
No problem! If you haven't taken a look at your device's battery level history, you might want to do that before getting too into battery notifications. I gave up on about all of mine and started using activity monitoring instead. The tradeoff is that you need to know how often your device normally "checks in" (most of my Zigbee motion sensors do at least once every hour or two, so if they haven't checked in for a few hours, it might be a problem; some of my sensors only check in once every day or two, so I have a few different instances of Device Watchdog to accommodate these different intervals) and it at least sounds less proactive than monitoring battery (I'm basically waiting until they're already dead, then checking things out myself if their lack of activity suggests so). That being said, I found it more reliable--sometimes devices would die before their battery levels looked low enough for me to worry about, and in most cases I don't mind waiting until they really die. Your preferences may vary.
Good luck!
For the record I just tested with a device I can test in realtime (a door) and the %device% does get populated as expected. Thank you for the clarification on this and apologize for having raised an issue that is not an issue 
Can you share how you did this? I'm having an issue getting my device names to populate when the batteries are low.
It's been two years since any of the above was posted, but it all looks like it should work more or less the same in today's app versions, too. Can you share a screenshot or description of what you have so far, then maybe someone can help with a specific problem?
The above is still true, too: the %device% variable won't have any contents if you're just testing the rule by running it manually. There needs to be a "real" trigger to populate this value. Perhaps that is your issue.
