You’re right that the “unavailable delay” setting doesn’t help here - that one’s only for reachability, not the battery %. What’s actually happening: battery is only sampled once per scan (there’s no realtime push for it like there is for connectivity), so if a scan happens to land right on that transient 1% dip, it gets flagged on the spot.
Just shipped exactly what you’re after in v1.9.22 (live now): a new “Delay before low battery counts” setting - Settings tab (global) plus a per-device override under “Details”, same pattern as the existing unavailable-delay. Default is 0 (instant, nothing changes unless you opt in). Set it to a few minutes and a device only counts as a confirmed problem once it’s been low continuously since first spotted - a one-off 1% blip that recovers before the delay elapses never fires anything.
On your exact wording - I kept the raw battery %/status you see in the Settings UI and the widget fully live/instant either way, exactly like you asked (“in your app/widget one will see the detection time”) - only the alerting side (Flow trigger, timeline entry, log, virtual device counter) waits for the delay.
Thanks, glad you’re finding it useful! Both are sorted now:
Good catch - you’re right that pausing via a Flow didn’t force an immediate re-check, so a device’s counts/alarm could stay stale until the next scan. Shipped exactly what you asked for in v1.9.23: both “Pause device until date” Flow actions now have a “Rescan immediately” checkbox - turn it on and the pause takes full effect right away (counts, virtual device alarm, everything), instead of waiting for the next scheduled scan. Off by default, so nothing changes unless you opt in.
(Side note if you’re curious: pausing by hand in the Settings UI already force-rescans automatically after every save - it was specifically the Flow-card path that skipped it, which is exactly what you flagged.)
The SwitchBot Bot thing - confirmed, that’s the SwitchBot driver, not this app: the Bot’s “onoff” isn’t a persisted state but a one-shot “press” command, so any write to it (even resending the same value) triggers the button again. My reachability test resends a device’s current value, which is a safe no-op for basically everything else with onoff/dim/etc., just not for a “momentary action” device like this one. Best to avoid the Test button (and skip “Auto-test before flagging”) for it specifically. Added both of these to the FAQ in post #2 in case anyone else runs into them.
I noticed that in the VirtualDevice (App)—even though I’ve pressed the switch button—it’s still showing as “not reporting.” Do you have any idea why? I’ve defined the switch more than 100 times, and now the overview is a bit confusing.
Thanks for the screenshots — they show exactly what’s happening.
Those are virtual buttons from the Virtual Devices app (class button, driver …virtual:virtual_switch). A button-class device has a single button capability with no stored state — you can see it in your Developer Tools screenshot: type boolean, value null, “Last Changed” empty. Pressing it fires a Flow trigger, but Homey never writes any “last updated” timestamp for it.
Device Watchdog’s “not reporting” check works purely off the newest capability-update timestamp Homey reports for a device. For a pure button device there is no such timestamp — ever — so it lands in “not reporting” and stays there no matter how often you press it. The “Updated: no data” in the list is exactly that: no timestamp on any capability. “Count last seen” won’t rescue it either, virtual devices don’t move that field.
(The one exception in your screenshot, “Wohnen 11 FrontLED”, is a real on/off virtual switch — its timestamp is real, just genuinely ~2 months old. Re-sending a virtual switch the value it already holds doesn’t refresh the timestamp; you’d have to actually flip it.)
Two things:
For now: take those virtual devices out of monitoring — the toggle next to each device, or “Ignore zone” on the whole zone, which is the quicker route for 100+ of them.
Next version: I’ll make Watchdog recognise devices that structurally can’t ever report capability data (only a button capability) and stop counting them as “not reporting” at all, so they don’t clutter the overview. I’m also looking at a bulk “ignore all devices from app X” action, since flipping 100 toggles by hand isn’t reasonable.
Great—after restarting a few times and giving it a gentle nudge (using the test button), most of the devices are now working properly.
I’ll take a look at the rest later, because right now I have to focus on my second job (Food & Beverage Manager)—otherwise, things will go wrong at home..
Fixed the Tap Dial in v1.9.27, just published: button+battery-only remotes no longer get flagged “not reporting” just for an old battery reading (they only report on a press).
The virtual switches (Test Fenster, Gang Szenen, Geschirrspühler) are correct as-is — they’re real on/off switches that were simply never toggled, so “no data” is accurate. If you don’t want them monitored, use Details → bulk action to stop monitoring by app/class.
Edit: if you have further issues please add the screenshots from the developer portal with the capabilities too (https://tools.developer.homey.app/)
e.g.
yeah no “last changed”. But i don’t know what you are doing with those devices. the values are NULL.. i also have virtual devices and i’m using the same app. but there are always values
most of my VD are not watched in my setup because in my opinion watching most of them makes no sense. they are special modes (e.g. guest mode that some lights don’t go on outside when there is motion, …).
Edit
My setup - most of the not monitored are VDs or others where there are no values to track or im using them too rarely
Found it — your WhatsApp device only has one capability (send_data), which is write-only and never gets a “last changed” timestamp, so Device Watchdog kept flagging it as stale forever with nothing you could’ve done about it. Same root cause as the Tap Dial fix, just for a capability name that couldn’t be predicted in advance.
Fixed in v1.9.29, just published: any capability the Homey API itself marks as write-only (getable: false) is now excluded from the staleness check, whatever app it comes from. Update and it should stop flagging that device.
.
