I have 3 Bali z-wave blinds all using the generic z-wave shade driver.
I'm trying to get notifications when battery level drops below a certain point using rule machine or other ways.
Within the device itself in HE, it does not immediately report battery status. But if you click refresh, or every time a command is sent, battery state is reported back.
How do I expose this battery state/status to rule machine, or as a battery device in any way? Again, it shows up every time I click refresh, but it is not one of the predefined custom attributes I can report on. Any suggestions would be appreciated. I've tinkered trying many different things.
Sounds like you need to run a rule periodically to refresh the device and then check the battery status. If you are comfortable with setting this up yourself, here's a screenshot that can hopefully get you started, but let me know and I can provide some more detailed steps. It's been a while since I set something like this up, there is likely still an option to do a device refresh as well, rathe than a custom command, but it probably doesn't add any benefit.
I cannot figure out how to get my Rule Machine to look at all like yours. Ultimately, even if I pick actuator (in a different way then your screen shows) the best I can do is a Refresh. If I manually did a Refresh in the device, at that point it will show the Battery. However, I see no way to capture this value and do something with it. Battery does not show up as an attribute in a drop down list. There is also no "setStringAttribute" option that I see.
Here are a few screen shots for context:
go into device and see current states (battery is not there):
Click refresh, battery will always appear.
Device always shows battery status after every command:
Rule machine allows me to do only as much as this:
I see no way to capture the battery state/attribute.
Ultimately goal: when battery is down to say 10% or 15% I want to get notified so I can plan to recharge. I can manually observe battery but I have a number of devices with this goal in mind.
Thanks in advance. I'm happy to work around the shortcoming of the driver, though I wish the driver would capture and store this value it seems to understand when it's reported.
Apologies, I was a little lazy in my description.... You got very close...
With the refresh command you don't need to pass in the 'battery' parameter, you just need to call the command with no parameters. Also, with the trigger in the RM rule, set that to be a periodic schedule trigger, like this one:
You could then use the monitoring options in the notifications built-in app if you wanted to monitor the battery reading and notify you when is drops below a certain threshold.
Otherwise, if you want to keep this in the same RM rule, you could include a delay / wait action after the refresh is called, say for 10 seconds, then a third action as a conditional action with an IF condition on the battery being below a certain value, then send a notification if that is true.
Just a side note on commands, in case you ever want to run a different one via RM again..... If you look at one of your earlier screenshots where you showed the commands listed on the device edit page, compare the refresh command to the setPosition, noticing the setPosition has the "Position" parameter shown below the button to run the command, whereas refresh does not.... This is what you can look for to determine whether you need to pass a parameter in when adding the command as an action in a rule.
Tagging @bcopeland from Hubitat as it sure sounds like that "Generic Z-Wave Shade" driver does not explicitly declare the Battery Capability, since it disappears until refreshed again.
1 Like
Well spotted, I didn't pick that up at all, and my suggestions would not work if that is the case.
I think that's exactly my point. The battery capability is not exposed. However every time you refresh you see the value, and it always reports in the Events of the device. Whenever you go back to the device, there is no cached Battery value.
Is there a way to write a rule solely based on Events until the driver is improved (if ever)?
This is what I see:
Battery is never listed as an attribute, even though Battery shows up when I click refresh monetarily and shows up as an Event in the device.
Not that I know of. @bcopeland is usually pretty responsive to items like this. I would hope he could squeeze this into the next Hubitat release. 
1 Like
Given you see the attribute appear, I expect the hard work has been done and hopefully it is just a case of referencing the capability....
1 Like
Still though, is there any way to detect/intercept the event of the battery status in the rule machine?
As you can see it shows up in the events of the device, why can't I do something with that event in a rule?
https://community.hubitat.com/uploads/default/original/3X/2/6/26366582ef7d860477fbda3368356aa7278f3c24.png
I'm not aware of a way, not to say it would be impossible, but in most cases the UI is driven by the capabilities of a device, so it would be looking for devices that implement the battery capability when setting up triggers on a change in the batter level, as you have discovered.
Fixed in next release.. Thanks for pointing it out..
3 Likes
Dumb question: is there a way to see the built-in driver, and then enhance with battery myself for the time being? Or is that proprietary ?
No, the built-in stuff is managed by HE staff, so like just happened, they are the ones to sort these things out.
Gosh that's great! Thanks folks!
1 Like
If this is the only event you get from the device at that time you could try the following.
In an RM rule define a local string variable called battery.
Do an trigger to refresh the device.
Then using set variable, set var battery to %text%.
Does the battery value get copied into the local variable.
You could then use the local variable to report battery %.
Something to ty. It may work.
hmm
dev:4012022-02-16 01:00:10.009 pm infoDining shade battery level is 35%
dev:4012022-02-16 01:00:09.811 pm infoDining shade is open
dev:4012022-02-16 01:00:09.783 pm errorgroovy.lang.MissingMethodException: No signature of method: genericZWaveShade.refresh() is applicable for argument types: (java.lang.String) values: [battery]
Possible solutions: refresh(), parse(java.lang.String), every() on line 5107 (method refresh)
app:5812022-02-16 01:00:09.768 pm infoAction: Set localBattery to '%text%(Dining shade is open)'
app:5812022-02-16 01:00:09.756 pm infoAction: refresh() on Dining shade
app:5812022-02-16 01:00:09.712 pm infobattery event Triggered
app:5812022-02-16 01:00:09.702 pm infobattery event event: Dining shade windowShade open
dev:4012022-02-16 01:00:09.597 pm infoDining shade is open
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
