%device% and %value% not working for me

I have a rule that is basically
if battery device A
or device B,
or device C
< 40%
then
log message: 'battery low %device% at %value%'

never seem to get the device or value listed.

None of your devices are below 35%.

Wouldn't HSM do what you want, maybe simpler?

Bad example - one was below and the device and value didn't report. I mainly want to know which battery is low.

1 Like

It will do it as well, but I don't seem to get the %device% reported. So I would need a separate HSM alarm configured for every battery.

Even if the rule fires it won't give the numbers you want (I treid the same thing and Ryan was right)

see post here

HSM won't bug you (or your wife) enough. It is too passive and only updates on a change, not when a battery sits at 1-15% for months.

In the end I used a custom rule for the main devices, and then a custom app called "device monitor" that send daily reports. Still not what I wanted but it will do for now.

According to HSM:

"Use %device% to include alert device name, %value% to include alert value, %time% to include alert time, and %date% to include alert date." for text alerts, OR "Use %device% to include alert event device name, %value% to include event value in message" for audio alerts.

....telling me my door lock is 75% is a priority.

The app has major flaws with reporting/resetting alarms, that make no good as a battery monitor IMHO.

Did you set the percentage? I missed that setting in HSM for a while too.I found it in HSM rule > click Configure Custom Rule > Alert when battery level is below. It is sort of hard to see, below "Monitor All Battery Levels?".

Now if you set 30% and it is alerting you at 75%, then that is a bug that needs to be reported. :grin:

@neonturbo It has to do with they way it triggers/ is evaluated, and to be honest it is over my head.

Basically something along the lines that if 1 sensor in below the threshold (mine is set for 20%, and 2 sensor are below it) it will trigger the "alarm" which stays active until reset. While "active" it will alert you to all battery changes even if they are above the threshold. To make things more fun, if the alarm is reset and the offending sensor does not move from the current value (below threshold) you will get no alarm until it does. :man_shrugging:

For "well maintained" HE/HSM setups that might work, I'll just go with... mine is not. I have also seen others post ways to "reset" the alarms, again too much work for what I am trying to do. With and the important ones on rules like above, I just made a decent "batteries dash" I just check fairly often and call it a day.

Weird.

I have never got my batteries low enough to have this action run.

That does sound (somewhat ) like a bug though. It might be tough if the battery stops reporting (I.E. changing) to make things work right code-wise, but it shouldn't falsely report one being low when it isn't.

You should report this bug, and link your posting above for reference. support@hubitat.com

You could try out @bptworld's device watchdog app.
I have mine set to 40% and then display them on on a dashboard.
This may work for you. Certainly worth checking out.

image
image
image

1 Like

bravenelStaff

The "issue" is well documented. Device monitor or the Device Watchdog @bobbles posted are better solutions as of now.

I don't think I saw this mentioned above, but the Notifications app can do this. As of hub firmware 2.1.9, it can also repeat the nofications at a specified interval, too (a request I did see mentioned above). That being said, I'd probably use Device Watchdog (mentioned above) for this because I like some control over when I get the notifications since I'm unlikely to act on it if it happens at 3 AM. :slight_smile: I know that's something you might try in a rule, too, but as mentioned, %device% and %value% refer to the triggering device (not anything from a conditional), which you won't get with a "specific time" trigger.

To do more or less what any of this is intended to do, I do use Device Watchdog. However, I only use it to monitor activity as opposed to battery. It's less proactive--or at least sounds like it would be--but I've found it to work better (battery reporting can be unreliable) and meet my needs most of the time (definitely tells me if something is presumed to be offline, but you do need to have a feel for how long your devices can go without reporting anything before you think it's a problem; I have several child apps for different intervals, depending on the device). Just another thing you might consider instead or in addition!

1 Like

You seem to have a good grasp of the subject...

Help me out here.

3 Devices
(Dev1, Dev2, Dev3)
3 variables
(Dev1(Dev1), Dev2(Dev2), Dev3(Dev3))
if Dev1(Dev1)=%device%
if Dev2(Dev2)=%device%
If Dev3(Dev3)=%device%
one of those devices just caused a RM trigger...
none of them will be true?
Hoping for clarification.
Thanks.

My initial thought--which I'm leaving here because I guarantee someone is going to come along later and say this is impossible--was: I'm not sure how you'd actually set that up. Variables in Rule Machine cannot point to devices, only one of the pre-defined data types (String, number, boolean, etc.). I have seen a request for something along these lines--the ability to set a variable to a device or check if the triggering device is a specific one. At the moment, you'd have a hard time doing that.

Then it occurred to me: %device% is, it appears, a string variable that contains the name of a device. If you don't have collisions in the device display name space (this is the device label if one is set, otherwise it's the device name), trust yourself not to make any typos, want to make things really hard by needing to type names in the first place instead of just picking devices, and don't mind a bit of awkwardness, I tested something like this and it does, indeed, work:

(This logs "Hey, it was switch 1!" any time the "TEST Switch 1" device gets turned on or off; it logs the other string for switch 2. Proof:
image )

As you can imagine, this is likely to become unwieldy (and a maintenance nightmare) for large numbers of devices. I also had to use a "proxy" variable, strNameTemp, for %device% because RM does not allow you to create conditionals with arbitrary/predefined variable names, just ones you've defined. I would strongly recommend an app dedicated to this purpose instead. However, if you want to try, I guess this at least serves as a proof of concept that you could. :slight_smile:

3 Likes

OOOH,OHHH that was it!

and thenkfully I only am looking at input from HubConnect Hubs, so there are not to many devices to be handled with this. (5)

Any one here remember the OS9/Basic09 manual?
Now there would be a target for documentation.
(by others!)

Thanks again for the pointers, the direction sure was correct...

1 Like

I didn't realize this, but it sure solves my problem. This is great...thanks.