[APP][Pro] Device Watchdog - Battery, connectivity & staleness monitoring for all your devices

Apps
62

Found and fixed the gap. The log now double-checks that a device was actually re-evaluated in a given scan before deciding it “recovered”. Previously, if a device happened to be briefly missing from a single scan’s results (e.g. a transient hiccup), it would silently drop out of tracking without ever getting logged as recovered - which is very likely what happened to your door sensor. Now it stays tracked until a scan genuinely confirms it one way or the other.

v1.9.11 is up, and I ran a live end-to-end test on my own setup to make sure: forced a device into “not reporting”, confirmed it logged, then forced it back to ok and confirmed the recovery entry appeared correctly too.

63

How long do you keep log entries?

64

Log entries in the Verlauf/History tab don’t expire based on age. The app keeps a rolling cap of the last 200 events — once a new entry comes in and the list would exceed 200, the oldest one gets dropped automatically. So it’s count-based, not time-based (only actual events like a device going offline/coming back, or battery warnings, get logged — not every scan).

How many weeks/months that translates to for you depends on how often those events happen on your setup. The 200 limit is currently fixed, but it could be made configurable in the future if there’s demand.

65

200 Entries sounds fine. Can you please tell the full name of the log file. Then one can read it via a get. Makes analysing easier.

Had set waiting time for the first scan after restart to 60 min (max?).
Homey reboot: 12:43:51, first devices not reporting message came in at: 12:48:23. next message at 13:44:15 - the rescan period is 65 min.
Nearly forgot: from 12:44:18 untill 12:44:36 device is reachable messages for all reachable devices even excluded ones.
According the logs timestamps the scan is done every 60 min and not 65 as configured.
Am looking at log entries from before the reboot because of new FW: one good message after 37 min, another (different device :)) one after 5 min. Homey notified you?
Am not comlaining just telling what I noticed.

66

No problem, happy that you are testing. First of all, I dont experience what you are experiencing, even the FW this night only affected 3 of my devices which healed themself again.

image
image310×527 35.2 KB

For the rest / your input :slight_smile:

Log access:

There’s no actual log file — the Verlauf/log tab is stored internally and exposed through the app’s own local API:

GET /api/app/com.rickd.devicewatchdog/log

It returns JSON (array of {ts, type, device, zone, detail}), not plain text. Since it’s Homey’s local API, you’ll need a Bearer token/session like any other /api/app/… call — a bare unauthenticated GET won’t work.

Startup grace “max”:

There isn’t one — you can set it to anything ≥ 0, 60 wasn’t a ceiling.

60 vs 65 min:

Good catch, and there’s a real quirk here. On boot the app starts two independent timers: the recurring scan-interval timer (65 min, ticking from the moment the app starts) and a one-shot timer for the delayed first scan (your 60 min grace). They aren’t synced to each other, so right after a restart you get the grace-delayed first scan at t=60, then the already-running interval timer’s first tick just 5 minutes later at t=65 — before it settles into the proper 65-min cadence from then on. Your 13:44:15 entry lines up almost exactly with the grace timer (60m24s after the 12:43:51 reboot), so that’s most likely what you were seeing, not a genuinely shortened interval. Would be great if you can confirm whether the next one after that landed ~65 min later.

Excluded devices getting “reachable” messages:

This one’s a genuine bug on my end, thanks for flagging it — the recovery (“available again”) log entry wasn’t respecting the same exclusion rule the “not reporting” entry already used, so excluded devices logged recoveries anyway. Fixed with 1.9.14.

37 min vs 5 min recovery gap before reboot:

That’s expected, not a bug — recoveries are reported per device the moment Homey sees it come back (realtime), not on a fixed schedule, so two different devices coming back at different points after a firmware update is normal and unrelated to any of the interval settings.

=> 1.9.14

67

addendum:

why such a high waiting time after restart?

I have the following setting with my devices:

image
image430×340 14.1 KB

image
image428×588 34.9 KB

my (modified homey) needs around 100s to start everything up

68

Some devices are a bit slow in reporting after a boot. 60 min was a test to see how far I can avoid unnecessary messages.

69

makes sense why you tried it, but the 60-min startup grace isn’t actually doing what you’re after here.

The messages you were seeing right after boot (12:48:23, and the “reachable” burst at 12:44) don’t come from the scheduled scan at all — they come from Homey’s realtime device events, which the app listens to independently and which fire regardless of the startup grace setting. That setting only delays the first automatic scan, so bumping it to 60 min doesn’t suppress the early noise from slow-booting devices — it just means no automatic scan runs at all for the first hour after a restart, while realtime detection keeps working the whole time anyway.

What actually gates the realtime “just went unavailable” detection is a separate setting: “Delay before ‘unavailable’ counts” (unavailableDelaySeconds, in seconds, General tab — also overridable per-device under “Details”). That one applies every time a device drops out, not just after a restart, and it’s what determines how long a device is allowed to be briefly unreachable before it’s confirmed as a real problem (Flow trigger / log / timeline / count). If some of your devices routinely take a few minutes to reconnect after a reboot, setting that to e.g. 300–600 seconds is the more direct fix — I’d try that instead of (or alongside) a large startup grace, and probably bring the startup grace back down closer to the default (2 min) since it’s not buying you what you wanted at 60.

70

My devolo sirene doesn‘t report on its own. It needs a test command to update the last seen timestamp. Instead of using a script to send regularly the test command can the app handle this for me?

71

There is a Flow card “test device’s reachability” to do that. But I like the auto heal idea, gonna check how to implement that in a next Version

72

Great app however I will appreciate small improvement: when using Light mode (gray on white) in Mobile App widget, it is hard to read Device Name. Any possibility to improve readibility, for example by changing font color to black or very dark grey? The dark mode is working fine but improvement in Light mode will be great to see…

73

New: Auto-test before flagging “not reporting”
If you have a device that never reports on its own (some sirens, for example) and you’ve been using an external script or a Flow to periodically “ping” it just to keep it from being flagged — there’s now a built-in option for that.
In a device’s Details, if it’s a device the “Test” button already works on (a testable capability like on/off, dim, volume, etc.), you’ll now see an “Auto-test before flagging” checkbox. Turn it on, and before that device is ever marked “not reporting”, the app first re-sends its current value as a live reachability check — same mechanism as the manual Test button. If the device responds, it counts as OK for that cycle and nothing gets flagged or alarmed.
It’s always recorded in the log (so you can still see how often a device needed a nudge), and there’s a second option if you’d rather still get the normal “not reporting” Flow trigger even when the auto-test saves the day.
Opt-in, off by default, and only shows up for devices where it’s actually possible.

V1.9.16

74

Thanks for the feedback! I looked at the widget’s CSS and the device name text should already be near-black (#1a1a1a) on a white background in Light mode, so I want to make sure I fix the right thing before changing anything.

Could you post a screenshot of the widget in Light mode? That’ll help me see exactly which text looks gray to you (the device name itself, or maybe the zone/detail line next to it, which uses a lighter gray by design) — then I can target the fix precisely.

75

Hi,

Thanks for prompt reply, and look at the enclosed screenshot.

As you can see Zone (e.q. Lazienka) and other detail are visible, however Device Name is unfortunately not. Part of the screenshot in email body while the whole screenshot attached.

image.png

Obviously 1a1a1a should be OK and it looks normally as nearly black, but definitely in this case. Perhaps other font attributes cause the issue?

Cheers,

Adam

(attachments)

Screenshot_20260819_145850_Homey.jpg
Screenshot_20260819_145850_Homey.jpg1080×2400 210 KB

76

Hi Adam,

Thx - your screenshot actually confirms exactly what I suspected: it’s not really #1a1a1a you’re seeing — the widget is (correctly) detecting that your Homey app / phone is in Dark mode, so it switches to its dark-mode text color (#f2f2f2, near-white), which is meant for a dark background. The zone text uses a slightly different gray for that mode, which is why it’s still just barely readable while the name (bold, brighter) basically disappears.

The bug was that the widget didn’t fill its own background to match — it just trusted the surrounding card to already be dark, which apparently isn’t always the case in every view (e.g. on a device’s own detail page). So you ended up with “dark mode” text sitting on a card that stayed light.

Fixed in the next update (v1.9.17): the widget now always fills its own background to match whichever text color it’s using, so the two can’t mismatch anymore, regardless of where the widget is shown. Should be live shortly — let me know how it looks once you’ve got it!

Cheers,
Richard

77

Thanks a lot, Richard. It will be great enhancement from visibility point of view and I am looking forward to examine the change as soon as ready (no rush for me).

Adam

78

Hi Adam
The fix is already in the live version (currently live is 1.9.19 with more improvements). wasn’t so happy with the behavior in the settings so a 1.9.20 ist now in the test version and waiting for approval by homey for the live app

so i hope the visibility fix worked :slight_smile:

79

Oh yes, it did. And i am looking forward to 1.9.20. Thans a lot

80

Version 1.9.21 is now live, featuring several minor fixes discovered while resetting my setup to defaults and reconfiguring it :slight_smile:

81

Was having a look at the battery warning. As some devices report 1% for a short while only to go up to 10 or more % again is it possible to delay the timeline message? As the device is still rechable the „defer the non reachable“ info setting doesn‘t seem to apply. So something like „device has x% battery for xx min“ in the timeline. In your app/ widget one will see the detection time.