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.
