So weirdness. All of my iblinds v3 (z-wave) are categorized as stale. Some only a couple of days, some months. Yet the report every 24 hours. 2 of them are reading as normal. I have 16 of them. The majority are like below. Thoughts?
Weird. I will have to look into this.
Looking at the data — Last Battery shows 1h ago for all three, meaning the app received a battery reading recently. But Last Activity shows 1w ago, 3d ago, and 2d ago with the stale warning.
This is expected and correct behavior — Stale is based on Last Activity, not Last Battery. These are blind devices (motorized blinds) that report battery level on a schedule but don't generate other activity events like motion or contact changes.
- Last Battery updates when the battery level is reported
- Last Activity only updates when the device generates any event — and blinds may only do that when physically operated.
MAY need driver to reach out occasionally to get an update.
I only have five (the most my wife would allow). 
All are reporting normally and none are showing as stale. 
Did you try "Force Scan Now" at the top of the battery report...maybe see if that gets them back to normal and they stay that way?
Loving this app. I have two locations, and if I am at location 1, there is no need to have the report for location 2 automatically sent, as I can't replace batteries where I am not. Would it be possible to have an option for a switch that would suppress the report if it is off (or on, either works for me) ?
VERY important improvement for this app, @JdThomas24.
This really needs to say: "He's dead, Jim."
Puhleeze!?!? 
(But I'm serious). 
This would be an edge case and i would need to think on it.....
NO- see the commands. Let me look at it and see if there is anything i can see. It COULD be driver issue but you never can tell.
Turn on debugging and test.
This is a driver behavior issue — the blind driver may not be generating response events back to Hubitat when commands are executed. Some drivers do, some don't.
So the stale flag is still technically correct from Hubitat's perspective — the device hasn't reported anything back, it's just been told what to do. Whether that's a real problem depends on the driver.
Keep and eye on it and see if the stale event has a cap of 7 days or if it continues further out.
That's a one line fix in the driver, something like sendEvent(name: "position", value: 50)
Debug the device as well. See if its reporting back to the hub AFTER a command.
@bertabcd1234 any thoughts? (he made the driver)
For app additions: users will need to create a poll of requested features, and I’ll review the results.
I’m not guaranteeing anything will be added, but I will give the top-voted option a second—or even third—look 
I have several other apps and drivers I am quietly working on and testing, when time permits.
The driver should parse in any data that comes back. What you're showing above is only showing commands, no events, suggesting that this data is in fact not coming back. If you enable debug logging, you'll see for sure. If nothing there, look at Z-Wave JS logs for reports back from the node (assuming you are on JS) -- and if there's nothing there, consider Bryan.
Do make sure you see things with a "Refresh" too, which I suspect you will. Some people have had problems with the above on iBlinds V3 for some reason. I don't think I have, although I saw it once and an upgrade or reboot (I was doing a platform update) "fixed" it, so I assume it was a beta platform fix but don't really know what was happening in the first place.
Device Health Monitor — Beta Testers Wanted!
NOT Ready for its own thread just yet, 
I've been working on a new companion app to Battery Monitor 2.0 called Device Health Monitor. Instead of tracking battery levels, this app monitors how frequently your devices check in with the hub and flags anything that goes quiet, checks in late, or drops offline.
What it does:
- Automatically detects Zigbee, Z-Wave, Matter, Hub Mesh and LAN devices
- Learns each device's normal check-in pattern using EWMA baseline learning
- Health ratings: Excellent, Good, Fair, Poor, Offline
- Scheduled scans — no event subscriptions, very low hub overhead
- Notifications via Pushover or hub push
- Already found a real faulty motion sensor in my own home during testing
Looking for beta testers — especially users with a mix of Zigbee, Z-Wave, Matter and LAN devices. The more device variety the better.
That sounds like a good idea. I volunteer.
Have some of all the above types of devices.
If your app takes this to a different level, count me in -
Included in that project's list of "device check" apps are two that I currently use and like...maybe targets for borrowing UI or functionality/reporting structure ideas from.
Device Health Status app included in the Device Health Status topic.
By no means am into a competition with another developer. I am just creating what i think will be useful for many.
It was originally going to be part of the BM 2.0 but bloated the app and so decided to separate it.
Differences:
- Does not rely on
healthStatusattribute which requires devices to implementcapability.healthCheck- many devices don't report this reliably- Does not use Table-based display using DataTables library - Better UI display
- Does not use baseline learning with raw last activity timestamps with fixed color thresholds (green < 9hrs, red > 25hrs)
- Uses health scoring - Excellent/Good/Fair/Poor ratings
- Does not Subscribe to
healthStatusevents. Less overhead- EWMA baseline learning — adapts to each device's normal behavior rather than fixed thresholds
- Health scoring relative to each device's own baseline — a motion sensor and a lock are judged differently
- No event subscriptions - lower overhead
- Protocol detection and color coding
- Notifications built in
- Much cleaner UX
I'm in!
We are in early BETA so i will use those to references. 
Yeah, I don't think anyone was thinking that, there are lots of apps from different devs (and HE built-in) available here that provide similar functionality. As we like to say, choice is good!