I have a few hundred devices (Zwave, Zigbee, other stuff... some wired, most battery, etc). I'd love to figure out how to build a dashboard for only the battery powered devices, showing their charge level. I then want to customize the dashboard to remove a few devices that incorrectly pretend they have a battery or whatever.
I'm still a n00b and I find the dashboard building experience is the primary reason I also use Home Assistant (yes, that's a horrible dig at HE... the dashboard building workflow is absolute garbage). Anyway, is there a better way than me clicking through hundreds of objects and manually assigning each one to a "tile" etc etc? The crappy UX means I keep making mistakes, accidentally clicking the same device twice, etc etc. I need a batch / automated operation.
I would gladly accept workarounds like Apps that do this already, but I haven't found any.
I’m already doing that and, unfortunately, I’m getting an large amount of what I’d call false positives. I also don’t like the UX - I want to poll the system myself rather than wait for a daily message about my battery level. Maybe I’m doing something wrong?
oh yeah... I was definitely doing something wrong. I see now I should HSM > custom monitoring rule > etc etc (there are lots of obvious options at that point). Trying that now... that's still only for pushing an alert to me on some cadence, but maybe it's what I should really do!
What do you mean??? Once installed, simply pick what devices to monitor and set it for around 15 hours (this should encompass everything checking in within that period). Send a notification at specific time to specific device so you can see whats up.
Not sure exactly how you're using DAC, but note that there are (at least) two different configurations that could help you: checking the actual battery level or checking for time since last activity. I've really given up on the former since reporting from most devices is so unreliable -- and you're likely to face the same problem since you're dealing with the same data if you build a Dashboard to show this information. I don't want to discourage anyone from trying, just from getting their hopes up too high, but most people have found battery reporting to not work as nice as it sounds like it might.
For last activity, you'll need to have a feel for how often your devices check in. Some devices can be tricky, especially ones that don't report in on their own; others might at least send a battery report once a day or something. When choosing the interval, my tip is to go longer if you aren't sure: if the alternative is not knowing at all, this would still be faster. (And it eliminates "noise," so you're more likely to pay attention when things actually need attention.)
Am I doing this right? I've hat this rule configured for a few hours now, I have a handful of devices that are clearly reporting below 33% battery, but HSM hasn't given me a single notification. WTF?
Have your devices actually sent an event since configuring the rule? You'll need an event to actually get the notification. Nothing will happen right away (at the time of rule creation) as a result of any current state, even if it meets your criteria.
You can check the "Events" button on the device detail page and look for "battery" events to answer this question.
Since Hubitat hasn't registered a change since you implemented the rule you won't get a notification until the offending devices check in and report a lower change. That said I set mine for 20%. Devices check in once about every 12 hours.
hmm... so this rule is event driven based on a device checking in?
If that's true, then I guess an obvious "best practice" is to pair battery level along with device-check-in rules... anything that's truly gone to zero/dead will never check in... and thus never alert. More carefully stated: if a device goes from consistently reporting 100% directly down to "actually dead" in less time than my device-check-in max, then I'll never get a low battery alert.
They will likely never report zero either... I e. They can't, the battery is dead. Like @bertabcd1234 mentioned, battery readings can really only be used as a guide, but many don't report accurately.
The trick, like others have described, is to work out the pattern of events for each device. Sensors in rooms like a master bedroom or bathroom are likely to have events each day, but others may differ based on use of areas in the home, so, depending if they report things like temperature or lux, you may need to spend a little more time to understand how best to configure their criteria.
And is "check-in" some very specific and narrowly defined event (maybe just events that already naturally include battery level?) or is it more like, "kinda any event, which will cause HSM to check the battery level"? Basically, the mechanics here still vex me because they aren't working as I'd naturally expect.
For example: I have a device in question called "Front Door" that's reporting 1% and it's been active all day, even since after creating this HSM rule. In the logs I can clearly see dozens of events over the last few hours (since my HSM rule has existed) and the logs even show "batter is at 1%" so I'm left wondering why HSM didn't notify me?
Some drivers do not generate an event unless the value changed (since this is normally what makes events useful for automation). Many make an exception for battery events, given other usefulness they may have; yours may not. That's probably what's going on.
Logs can be helpful, but to see actual events, you'll need to do as I mentioned above and go to "Events" on the device detail page. That's the authoritative source.
Is there a global events menu so I don’t have to check through each of my devices to figure things out? Remember part of my original premise here is finding scalable solutions for my plethora of devices
Why is this so f****ing dumb? Seriously HE, I’ve got a device that’s clearly logging enough structured info to tell me something useful but because it’s not “an event” I can’t HSM it usefully. COME ON. This is the kind of stuff that prevents systems like HE from perfect mass appeal- it doesn’t “just work” in a way that’s super obvious.
I can't think of anything that sounds exactly like what you're describing, but "Logs" with the level filtered to "info" will normally get you pretty close, especially if you also select only devices (or even only ones you're interested in). The caveat, as you saw above, is that some drivers log things they send for event processing, even if the hub discards them by default if the value didn't change since the last time. (If this sounds odd to you, there is a reason, as it's normally not useful for automation, and drivers have the option to force an event in cases where one might want it, button events being the classic example--you want to see "button 1 pushed" even if button 1 was the last button pushed--but battery events sometimes being one just so the device generates "activity.")
An unofficial alternative is the event websocket, but you won't find that anywhere in the UI, and it's not documented (though I've heard it might be since it's unlikely to change at this point).
From your previous posts, it sounds like there are two different concerns here:
The one I mentioned above about default event filtering. If you share what driver this device is using and what specific driver you're using (assuming it's built-in), staff might be able to make a change as I recall they have done with some others for battery events. (This would only help when you see something in "Logs" that suggests the device sent such information.)
Why HSM doesn't send notifications if a device is currently at or below your specified level after setup without an event. This is because this is an automation, and something needs to trigger it. As-is, that would be a battery event. From the above, this may not be working as you expect, which is one issue; but some people have an expectation that something will happen immediately after setup (e.g., a notification right then or some undetermined time after). It's important to keep in mind that this will be true no matter how battery events are generated until one is actually generated. If you want a different approach, you'd need an app like DAC that will query the device on demand (the difference here being that you can wake the app in response to something else--a button you press in the UI, a scheduled job you can set up in the app, etc.--and it's querying last reported device data instead of relying on the device itself sending anything).
Take look at Tile Builder Activity Monitor, you can generate a table of devices that have not updated in a least x hours\days and many other configurations. Good for catching devices that have a failed battery. I have some contact sensors where the last report was 100% battery life, couple of hours later it’s dead. The free version does everything you need but no alerts.
(And it eliminates "noise," so you're more likely to pay attention when things actually need attention.)
