You definitely chose the Cusotm Attribute option in Rule Machine as a Trigger Event?
Yes. The custom attribute for the generic leak sensor gives two choices: battery and water.
The above snip was for the motion sensor.
1 Like
The I can't think of another way to access the attribute in a rule, unless the right capability is defined in the driver, something you will need to request to be changed in the driver code.
1 Like
Thanks much.
If @bcopeland is out there, perhaps he could respond.
Is a driver change possible to capture the battery low alarm attribute?
1 Like
An event won't get generated unless the driver does so, so "alarm1" would have to be coming from that. But if it's not available in RM, it's likely not formally defined as a custom attribute in the driver but is rather just being generated as an event (that then mostly disappears aside from remaining in this history until that is purged). This is unusual, though some drivers use this for one reason or another in rare cases.
Related to the actual issue: what model of device is this? I see it's Z-Wave, at least. FWIW, all Z-Wave devices I've seen that have a "low battery alert" option don't really implement anything special for this. It's basically a "do it when the battery level reports less than x%" thing. Some even have a configuration parameter you can set to specify what x is. On Hubitat, you could do the same (or really quite a bit more) by just looking at the battery attribute. The alternative seems to be geared towards simple hubs/controllers that don't offer this kind of functionality — not a problem here.
This is ignoring how unreliable battery reporting can be on this kind of thing in the first place...another story. 
If you do want to use this attribute directly for some reason, you'd need a custom driver that uses a custom attribute. But I haven't seen a Z-Wave device where this is actually useful given the above (not saying there aren't any where it might actually be different--your device manual will probably have more information on what it does, which is why I'm curious what it really is).
1 Like
It is a Utilitech water sensor, MODEL #ST812-2, originally for Iris.
I found a driver in the thread below, that was ported from a 2014 ST driver in 2018.
I'm poking around with it, but have no idea what I'm doing.
Try adding the following:
metadata {
definition (name: "Utilitech Water Sensor", namespace: "Hubitat", author: "tosa68") {
capability "Water Sensor"
capability "Battery"
capability "Configuration"
capability "actuator"
capability "refresh"
fingerprint deviceId: "0xA102", inClusters: "0x86,0x72,0x85,0x84,0x80,0x70,0x9C,0x20,0x71"
}
}
The two capability lines for actuator and refresh capabilities. You may only need one....
But what do you get in the rule trigger options?
Looking at the manual, it appears the device sends either 20-100% as the battery level, or 255 if the battery level is "low," the threshold for which does not seem to be configurable. This information appears to come in on the standard battery report (just with a level of 255, the max--not sure if this is standard, but it's common on devices I've seen that do this).
Many Hubitat drivers will take that information and parse it into a level of 0 or 1 -- so the information is already usable, even if not easily distinguished from a regular battery report. (This is based on observations of similar devices, not this exact one.) But for this device, something less than 20 doesn't appear to be something the device reports, so anything less than that is probably something the driver is doing in response to this state. If you've observed the states when it's actually reporting "low battery," I would expect it to do something like this. If not, a driver certainly could be written or modified to do so.
Ultimately, this is still dependent on the infamously unreliable battery reporting from these devices, BTW, so in case you're expecting it to be better than regular reports, no matter how the information gets parsed into events, I wouldn't.
Hang on, if you select Custom Attribute? Do you see Alarm 1 then?
No, I'm not. I only saw that the battery was low, supposedly, by the blinking red light on the device and the alarm 1 message in Device Events. It was 100% right before. It's not like I've replaced the batteries, yet, and measured the voltage. I have 12 of them to do.
It's possible this driver just reports anything >= 100 as a 100% level, including the "special" value of 255 (contrary to my description of "many" drivers above that treat this as a special value based on information from the device manual). The real test would be seeing what debug logging says came through on the BatteryReport that was ultimately parsed into this event. Might be a bit harder unless maybe your device has a Refresh command and you wake it at the right time to make it send one back in response to this (with debug logging enabled, of course).
Perhaps try setting up a new device with updated driver?
May be completely unrelated to this discussion, but it would seem to me that having an attribute with a space in the name would cause issues...
1 Like
There is also no definition of that attribute in the driver, so I am expecting any attribute not identified in the existing capabilities would be picked up by RM... Perhaps with my addition of the refresh / actuator capabilities plus an attribute definition of alarm 1 it might work?
