Quick note on scope, since this comes up now and then: Device Watchdog is built to watch devices that actually report something — battery level, a sensor value, on/off state, temperature, etc. It flags a device when that reporting goes quiet for longer than expected.
It’s not meant for pure action/trigger devices — things like the WhatsApp app’s “send” device, virtual scene-trigger buttons, or anything that only fires an action and never reports a value back. There’s simply nothing for Watchdog to compare against on those, so “not reporting” was never really a meaningful state for them.
Good news: as of v1.9.29, devices like that get auto-excluded from the “not reporting” check anyway (any capability the Homey API itself marks as write-only is now ignored for staleness). So you don’t need to manually exclude them — but if you add a new device and wonder why it never shows up in the “not reporting” list even after being untouched for months, that’s by design, not a bug: it simply has nothing to report in the first place.
When a device shows up as not reporting, not reachable or low battery, its Details panel now gives you a one-line recommendation based on what the device actually looks like. A few examples:
never reported any data → “if it’s only used for Flows or a display, stop monitoring it”
a contact/motion sensor that’s simply quiet → “long gaps are normal here, raise the threshold or count ‘last seen’”
a battery reading that’s months old → “the device may have gone quiet rather than actually being low – check it directly”
several devices from one app dropping at once → “probably the app restarting – raise the ‘unavailable’ delay”
It sits in the Details panel (a tap, not a hover, so it works on mobile) and only appears while a device is actually flagged. If nothing specific fits, you get a sensible generic hint instead.
Just restarted my homey. The watchdog app (1.9.32) doesn’t seem to obey all commands. With a few devices I said do use the last seen timestamp and it ignores it. What info do you need to pinpoint the cause of the disobeyance?
Do you have some screenshots? Watchdog status. / Detail settings and from the developer Tools the capabilities? The “Verlauf” too I’ve they are back again now. You can add a Diagnostic report too than i have more Information and it’s not only guessing
There was a reboot tonight here and the device went unavailable and 10min later available. Just gonna raise the option delay to unavailable to 15min now
Everything back to normal by now.
The restart was around 20:55. I triggered a few times a manual scan. No change yesterday evening. The first scan was delayed by 5 min. Changed it to 15 now.
The last good message though was yesterday at 23:07.
Did a restart just now. Let’s see what happens.
Just realised my „last seen“ script needs some rework. Presently it only shows devices with an existing „last seen timestamp“. My bad.
Had to realise my last seen seems only to shows devices with a valid last seen timestamp. Must dig into it.
So it might be your app works okay
Funny, now everything is at should be. So forget about my „issue“. Maybe should have remembered after an update to reboot a second time before looking at anything,
Sorry.
In this case, the door doesn’t open that often, but is reachable… what setting should I apply (because indeed it can happen that a couple of months later I open the door and then it is inactive)..
Just bump the Not reporting threshold for that door way up — think days, not hours. Long enough to cover the real gap between openings.
To be clear though — you’ll get a Device Watchdog “check this” notification once it crosses that threshold. Which is fine, that’s the whole point of the app: it’s a nudge to go check on a device you otherwise wouldn’t think about. So once in a while — weekly, say — just open the door yourself to confirm it’s still alive and reporting. That’s exactly the manual test the app is there to prompt you into.
Battery warning: leave that one as-is, no need to touch it.
And if you’d rather sidestep this kind of thing entirely for future sensors — pick one that reports more on its own. A Shelly BLE reporting its RSSI regularly, for example (my go-to), stays “fresh” without ever needing to be physically triggered. Device Watchdog can’t fully compensate for a sensor that’s just naturally silent for months — it’s not an eierlegende Wollmilchsau.
I always have alerts for sensors which i dont get regular updates, so I check them manually or Pause them (e.g.my garage Door sensor if I am away). But i still prefer a setting of 48h and a “not reporting” message than a dead sensor
Device Watchdog v1.9.34 — raw Capabilities view in Details
Small one, but a few of you will like it: every device’s “Details” panel now has a collapsible “Capabilities” section at the bottom - shows the exact same raw values Homey’s own Developer Tools does (title, id, value, last-changed timestamp), without leaving the app.
Rows are colour-coded against that device’s own “not reporting” threshold:
green = updated within it
red = older than it
no colour = a capability the staleness check itself ignores anyway (Button, battery-only, write-only)
Loads on demand when you expand it (doesn’t slow down the device list), plus a manual Refresh button so you can watch a value update live.
Handy for the “why is this thing flagged?” moment - one click instead of switching over to Developer Tools.
v1.9.34 just submitted for review, should be live shortly. As always, feedback and
bug reports welcome here!
The only thing it triggers a bit too fast, some devices do apparently disconnect every now end then and get back a bit later… is there a way to either in the settings OR in the flow put something like delay for check again after 5 minutes before this alert is triggered…
For the flapping issue though, don’t build the delay into the flow — there’s already a setting made exactly for this.
Settings → Default thresholds → “Delay before ‘unavailable’ counts”. Default is 0 (instant); set it to a few minutes (5 sounds about right for what you’re describing) and a device only gets flagged once it’s stayed unreachable that whole time. Brief disconnects that recover on their own never trigger anything. It’s global, but overridable per device via “Details” if some devices need a different grace period.
This delay covers the Flow trigger, the summary trigger, timeline, log and the virtual device’s counter/alarm — so your flow’s trigger will just naturally stop firing on the quick blips once it’s set.
There’s actually an FAQ entry on exactly this in post #2 if you want the full rundown: “A device flickered to ‘unavailable’ for a few seconds and I got a notification - can I avoid that?”
Glad it’s useful!
P.S. i have a similar flow for all the devices still alerting
New test build: v1.9.37 - reporting-frequency stats + a smarter threshold suggestion
Hi all,
Just pushed a test build I’d love some real-world feedback on before it goes out as a regular update - it’s the biggest change to the “not reporting” side of things since the app started.
What’s new
Every device’s Details panel (under “Not reporting”) now tracks how often it’s actually been reporting recently - no more guessing a threshold:
Shows a short list of its last few real updates, with which capability triggered each one (sortable by time or capability)
“Reports about every ~X” - how often it’s actually been reporting
A suggested threshold based on the largest gap it’s actually seen between reports (with a safety margin), and a one-click “Apply” to use it
If a device flaps between quiet and chatty (e.g. a power plug monitoring a PC that’s off overnight, on during the day), the suggestion accounts for the longest gap it’s ever seen for that device, not just whatever’s in the last few minutes - so it won’t quietly forget an overnight gap once the device starts reporting frequently again the next morning
It needs 5+ real updates before it shows anything (below that, it just says it’s still collecting data) - for a chatty device that’s minutes, for something that reports rarely it could take a while, and that’s expected: the whole point is to learn that specific device’s real behaviour, not guess at it.
There’s also a manual “reset reporting stats” button in Settings if you ever want a clean slate for everything.
What I’d love feedback on
Does the suggested threshold feel right for your devices, or way off for any particular type?
Any device where the “reports about every X” number looks obviously wrong?
UI clarity - is it clear what’s going on, especially the “still collecting data” state?
Performance on a larger setup (I’m running this against ~300 devices myself, hasn’t shown any issues, but more data points welcome)
Sofar it looks good. It takes a while to collect enough data. You provide an average update time span value. How about showing the longest „silent“ time too?
New in v1.9.39: a “Recommendations” tab (currently in review, available in test)
The per-device stats were useful but meant opening every single device’s Details to find out if its threshold needed adjusting - not great with a couple hundred devices . New tab lists every device whose current threshold doesn’t match what’s actually been observed, sorted by how big the gap is:
Current → suggested threshold, plus the average interval and longest silent period behind that suggestion
A “minimum observation period” field (7 days by default, you can change it) - a device only shows up once it’s actually been watched long enough to trust the suggestion, not just because it happened to produce 5 updates in its first ten minutes
One-click Apply per device, or “Apply all” for the whole list at once
Expandable “show recent reports” per row if you want to see the raw data behind a specific suggestion, without leaving the list
Same as before - needs real data to build up over time, so don’t expect the list to be huge on day one.
Let me know how it looks on your setups - especially whether the suggested thresholds feel right, and whether 7 days is a sensible default for the observation period or too short/long.
green = updated within it
red = older than it
Refresh button so you can watch a value update live.
. New tab lists every device whose current threshold doesn’t match what’s actually been observed, sorted by how big the gap is:
