The 14h comes from a 1.5x safety margin on top of the longest gap actually observed (9.2h) - deliberately conservative so a single quiet night doesn’t trigger a false “not reporting” alert on a motion-driven sensor like this one.
Honestly though - for this device, whether it’s set to 7h or 14h probably doesn’t matter much in practice . It’s the kind of sensor where an occasional quiet stretch (nobody in the laundry room overnight) is completely normal, not a real problem either way. The recommendation is meant as a starting point, not a rule - if your current value works fine for you, there’s no need to change it.
That said, fair point that 2x your current setting feels like a big jump. I’ll make that 1.5x safety margin itself a configurable setting (default stays 1.5x, so nothing changes unless you touch it) so you can dial it down to e.g. 1.3x if you’d rather get tighter suggestions.
Hello Richard, what a great app. It replaces a lot of flows checking all devices. Nice!
I have two questions:
Would it be possible to build 3 new “When” cards for when devices are responding, reporting and battery level is ok again. With the same (format of) parameters “Device 1, Device 2, etc.”?
The reason is that I colour “wrong” devices on my dashboard (HDashboards) and I want to reset the colour if the device is “repaired”.
Is there another way than PayPal to contribute to this project? Maybe have contact by PM?
Hi Victor
Please try out V1.9.45 (available in test, under review for live)
“Devices become available again” - realtime, mirrors “Devices newly become unavailable”
“Devices are reporting again” - fires per scan, mirrors “Devices are newly found not reporting”
“Devices’ battery is OK again” - fires per scan, mirrors “Devices with low battery are newly found”
Same format as the ones you’re already using: count + a devices token with the comma-separated names (“Device 1, Device 2, …”), bundled if several recover close together instead of firing once per device. Should drop straight into your color-reset flow the same way the “newly found” ones feed the color-set side.
Thanks for the report - they led to a small change.
Quick clarification on the “decimal dot” one first: that wasn’t actually a bug - the suggested threshold is deliberately always a whole number of hours (no decimal to lose). 109h checked out exactly: longest observed gap × your configured safety margin.
But your original point about 14h feeling too conservative was worth digging into properly. Turns out the underlying issue was real: the suggestion was always based on the single longest gap ever observed, which can massively overweight one quiet stretch - especially for an event-driven device like yours (only reports on state change, not periodically). One rare 3.5-day quiet spell shouldn’t necessarily set the bar for the whole suggestion.
So now, in the Recommendations tab:
(The safety margin (was a fixed 1.5x) is adjustable, and can even be overridden per device) → already implemented before
- You can switch the suggestion to be based on the average interval instead of the longest gap - better fit for devices like door/window contacts
New test build: v1.9.48 - now in Swedish, Dutch and Norwegian
Hi all,
Device Watchdog just passed 770 installs - thank you all!
I’d love to crack 1000, so if you know someone with battery sensors or flaky devices, point them this way.
Looking at the install stats, about 58% of installs come from Sweden, the Netherlands and Norway - and until now the app only spoke English and German. So v1.9.48 adds Swedish, Dutch and Norwegian: settings page, Flow cards, widget, virtual device and the App Store description. The language follows your Homey’s language setting.
What I’d love feedback on
Wording that sounds off, stiff or just wrong in your language - I’m not a native speaker in any of the three, so some phrasing will certainly need polishing. Telling me what you’d rather see is perfect.
Anything that’s still English, or text that gets cut off (long words in buttons or the widget)
Regular installs are unaffected, this only applies if you opt into testing.
Optional → Support the Developments (just thought about a guiness I’m missing now)
Developing, testing, and maintaining it takes a lot of time and effort. If the app helps you keep your smart home running smoothly and you’d like to support my work, buying me a coffee (or a beer ) is always appreciated!
i’ve only just installed this app and this is what ive been looking for. i have some ikea tradfri motion sensors which homey has a hard time checking the battery status. this makes it so much easier just to see if my devices are low on battery, unavailable or not reporting.
i’ve only just updated a bunch of devices to not monitor. can already see a bunch of devices either low on battery or not reporting/unavailable. those are my tradfri motion sensors which i cant see the battery percentage.
will do a bit of reading and set up some flows and configure this app. thanks for your efforts in building this app
The culprit wasn’t the timer this time, it was the dashboard widget: every time it’s opened it runs a real scan (to re-sync availability), and that bypassed the “Wait after app start” setting. So opening your dashboard 5 minutes after the firmware update scanned everything right away - hence the 16 “not reporting” flags at 10:21 instead of after your 65 minutes.
Fixed in v1.9.49 - available as a test version now, and in review for the live release:
While the startup wait is still running, the widget just shows the last known result instead of scanning. The “Scan now” button still scans immediately (that’s a deliberate click), and once the wait is over, opening the widget scans again like before.
Let me know if it behaves after your next restart!
Is it possible to create a setting for timeline reporting to differentiate between reports? For instance I would only like to see a timeline report when a device is not available and am less interested in not reporting devices. Thanks
Sure, added in v1.9.50, which is live now: under Settings → Notifications there are three extra switches below the timeline switch - include unavailable, not reporting and low battery.
Switch off the last two and you only get timeline entries when a device becomes unavailable. The matching “available again” / “reporting again” / “battery OK again” entries follow the same choice. Everything is on by default, so nothing changes for existing setups.
Also, whenever I tap the Pause entry field on my iPhone it immediately defaults to today then disappears, and I have to scroll back up to the filter boxes shown at the top of the page and select Paused, then expand the “1 devices not monitored” scroll back down to the bottom of the device settings and re-edit the Pause date to the one desired.
Is there any way to keep it “staying visible” similar to when you edit any of the other monitoring settings and the device changes state from unresponsive/unreachable to OK?
Thank you kindly good sir you work on this wonderful app is greatly appreciated
both are in the latest test version (v1.9.51) - a time for the pause (pick date + time, then tap Apply Pause) , and the iPhone fix (tapping the date field no longer pauses the device right away; the device also stays in view when it moves to “not monitored”). Could you give it a try and let me know if it works for you?
. It’s the kind of sensor where an occasional quiet stretch (nobody in the laundry room overnight) is completely normal, not a real problem either way. The recommendation is meant as a starting point, not a rule - if your current value works fine for you, there’s no need to change it.
)
) is always appreciated!
Buy me a coffee via 
