I have quite a number of zwave devices. They tend to report something every 6 to 7 hours.
Any chance for some global settings?
Good timing - this got easier with the last couple of updates.
Two options, and you can combine them:
-
Settings → “Count Homey’s ‘last seen’ toward ‘not reporting’” (global toggle, off by default). Z-Wave devices usually get confirmed by Homey’s mesh (routing/health checks) far more often than they actually report a new value - enabling this treats that confirmed connectivity as a sign of life too, not just capability changes. For a fleet that reports every 6-7h like yours, this alone should clear up most false positives without touching a single per-device setting.
Trade-off to be aware of: this makes “not reporting” less sensitive to a device that’s technically still connected but whose actual sensor data is stuck (e.g. a battery sensor that’s physically failing but the radio/mesh link stays healthy) - Homey’s “last seen” would keep refreshing from mesh traffic alone, so that specific failure mode would go undetected. If you have devices where catching “connected but genuinely stuck” matters more than avoiding these false positives, leave it off for those and just raise their threshold instead.
-
If you’d rather set an explicit threshold (e.g. 8h) just for your Z-Wave devices without changing the global default for everything else: configure it on one device under “Details”, then use the new “Apply to same-type devices” button that appears - it copies the setting to every other device of that same type (matched by app + driver) in one click, with a preview of which devices before you confirm.
Try option 1 first - it’s the more “global” fix you were originally asking for. Let me know how it goes!
App is live 
I’ve been fiddling for a while now to find a proper way to flag flaky or unavailable devices. This seems to be the way! Thank you for this app!!! Looks to be a great addition for my Homey.
Hi Rick, congrats!
A hint on sharing app store links:
When using the format below, the app store page opens in the user’s preferred language, else in English
https://homey.app/a/com.rickd.devicewatchdog/
thx Peter
the “preview” function added the en-us now → but thats better than german 
just submitted 1.8.2 for live version (with the new widget)
I like the widget. Think you can display the battery type too?
Sofar the app looks good. Have to have it running for a few days/ weeks for a better evaluation
added the information to the widget and device details. i have to wait until the live version is reviewed to publish it to test
EDIT: 1.8.4 is not live with the battery details
@Rick_D I just had an aqara P2 door sensor which was falsely flagged as “not reporting”. Homey showed the device as online, and when I opened the door the sensor value was correctly updated. For this I also had “count last seen toward not reporting” configured to yes. Any idea what might have triggered the “not reporting”?
EDIT:
Just checked my devices (i don’t have aqara but i have some zigbee devices)
Followed up on this properly - checked how lastSeenAt actually behaves on real devices (mine), comparing it against the last real capability update across 64 battery-powered devices.
Result: for about 83% of them, lastSeenAt moves in lockstep with the last actual capability change - it’s not an independent “mesh keep-alive” signal that updates more often, contrary to what I assumed when building this setting. Only a small minority (mostly one-off cases, like a device that got re-paired at some point) showed a meaningful gap.
So: not a bug on your end. Your Aqara P2 almost certainly falls into that majority group, where “count last seen” simply doesn’t have anything extra to go on - both signals were probably equally stale. I built the setting assuming routers/mesh devices confirm connectivity far more often than they report data, and that’s just not reliably true across the board. I’m updating the in-app description so it doesn’t overstate what this actually helps with.
For your P2 specifically, the more reliable fix is raising its “not reporting” threshold to comfortably cover its real reporting gap (rather than relying on “count last seen” to bridge it). Sorry for the confusion, and thanks for pushing on this - good catch.
Quick follow-up on the technical side, for anyone curious: I looked into whether detection could be improved further here, and it looks like this is currently a genuine platform limitation, not something fixable app-side. Homey’s Zigbee coordinator does track a proper node.lastSeen internally (every received frame, not just capability changes), but it’s not exposed through the standard app SDK - only through elevated/manager-level access that a monitoring app like this shouldn’t really be requesting. There’s an open community idea asking for exactly this (expose node.lastSeen in the Zigbee SDK) - no official response from Athom yet. If that ever lands, I’ll revisit this.
Funny, zigbee lastSeenAt can be read by a normal script but not from an app.
Found it, and it’s an actual bug on my end - the widget was only checking the OS-level dark mode setting (prefers-color-scheme), not Homey’s own theme setting. If your phone’s OS theme and the Homey app’s theme setting don’t match, you’d get exactly this: light-mode text colors rendered on Homey’s actual dark background. That’s also why the “high contrast” setting didn’t help - it never had a chance to run, since the widget wasn’t picking up dark mode correctly at all.
Fixed in test version 1.8.6 - now follows Homey’s own .homey-dark-mode state instead of (well, in addition to) the OS setting. Should show proper light text on the dark background regardless of what your phone itself is set to.
Let me know if that clears it up on your end!
So if I understand this correcty my sensor will probably only trigger an “I’m alive” signal when a capability updates. And so I should set the “not reporting” treshold higher then the expected time between triggers? E.g. a doorsensor for a door that might get opened only once a day, set the tresshold from the default 24h to let say 40h?
Edit: or alternatively auto reboot my Homey every night and the 24h tresshold should cover everything? It’s a matter over thread sensor so I don’t think there is a way outside of a full reboot to trigger a sensor update
Yes, your understanding of the first part is correct - raising the threshold above the device’s natural reporting gap is exactly the right approach, and the only one that actually works reliably. For a door that’s opened roughly once a day, I’d actually go a bit higher than 40h, since “once a day” isn’t perfectly regular in practice - weekends, holidays, or just not going through that door for a stretch could easily push the real gap past 40h occasionally. Something like 48-72h gives you margin without making detection meaningless; it’s a tradeoff between false positives and how quickly you’d notice a genuinely dead sensor.
The reboot idea, though - that wouldn’t actually help, and I want to save you the trouble of setting that up. Rebooting Homey doesn’t reset or refresh a capability’s “last updated” timestamp - that timestamp lives in Homey’s own device state, not in this app, and it survives a reboot untouched. If the door hasn’t been opened in 20 hours before a reboot, it’s still “20 hours since last update” right after the reboot too. A reboot only resets this app’s in-memory state for the separate “unavailable” tracking (a different problem) - it does nothing for “not reporting,” since that’s computed fresh from the real capability timestamp every time, with no memory to reset.
So: raising the threshold is genuinely the fix here, not a workaround-of-a-workaround. And yeah, if it’s Thread rather than Zigbee, that’s actually even less standardized in Homey right now - the lastSeenAt situation I described is Zigbee-specific; I haven’t looked into whether Thread devices behave any differently on that front, but I wouldn’t bet on it being better.
Looks gooood. Thanks
New in v1.9.0: pause monitoring for seasonal devices, until a date you pick.
If you have devices that are only in use part of the year (irrigation controllers, outdoor sensors, anything powered down for winter), you no longer have to choose between false alarms all season or permanently turning monitoring off and remembering to flip it back on.
Under a device’s “Details”, set “Paused until” to a date - the device is skipped entirely (like “not monitored”) until then, and automatically resumes on the very next scan once the date passes. No reminder needed, no manual re-enabling.
A few details:
- Applies everywhere a fully-excluded device would be silent - battery, not-reporting, and unavailable alarms all stay quiet for the duration.
- Turning the device’s monitoring toggle back on early also cancels the pause, in case you change your mind.
- There’s a dedicated “Paused” filter/tile in the Devices tab, separate from “Not monitored”, so you can see at a glance what’s currently paused.
- If you have several identical devices, you can optionally include the pause date when using “Apply to same-type devices” - there’s a checkbox for it, so you’re not forced to bulk-apply it if you don’t want to.
Great APP!! Much needed to have full control
Didn‘t you mention you included the battery type in the display of the widget in one of the versions? How to active?
