Extended Diagnostics

Some hardware cannot be supported until somebody sees how it behaves on a real system. Nobody working on Device Sentinel owns one of everything, and reading a manufacturer's documentation is not the same as watching a device on a live network.

This screen is how you help, if you want to.

What It Does

Turning something on adds raw readings about that hardware to the diagnostics download you can take from the device page. That is all it does. It changes nothing about how Device Sentinel behaves, raises no alerts, and alters no detection.

Nothing is transmitted. The readings go into a file on your own system. They reach anyone else only if you download that file and attach it to an issue yourself.

What You Can Help With

The list shows only what's on your system, from Z-Wave, Matter, Philips Hue, SmartThings, Tuya, Lutron Caséta and these routers: UniFi, FRITZ!Box, AsusWRT, NETGEAR and MikroTik.

How to Submit Your Data

1. Turn it on. Tick the hardware you'd like supported.
2. Live with it for a few days. Use your house as you normally do, so the readings show your devices on an ordinary day.
3. Run a few simple tests. Note the time and what you did, for example "unplugged the office plug at 2:10 PM for ten minutes". That note is what turns the readings into an answer. Leave Maintenance Mode off, so Device Sentinel reacts as it would to a real fault.
   • Take the battery out of a battery-powered device and leave it out until Device Sentinel shows it frozen or unavailable, then put it back.
   • Unplug a plug-in device for 10 minutes, then plug it back in.
   • Unplug your hub for 10 minutes: the Z-Wave stick, the Thread border router, or the router.
   • For a router with more than one access point, switch one off for 10 minutes.
4. Collect your files.
   • The diagnostics download: Settings > Devices and Services > Device Sentinel, the three dots, Download diagnostics.
   • For Z-Wave, Matter, Philips Hue, SmartThings, Tuya or Lutron Caséta, stack_probe.md from the config/device_sentinel folder.
   • From the same folder, classification.md, device_telemetry.md and silence_episodes.md.
5. Open an issue on the repository, titled with the hardware (for example "Extended Diagnostics: Z-Wave"). Say what you tested and when, and attach the files.

Rather not post your files publicly? They carry device names and readings, and never passwords, tokens or addresses: each MAC address keeps only its maker's half, and your home network's addresses become stand-ins such as IP-01, the same one throughout the file. If you'd still rather not attach them to a public issue, open the issue without them, and you'll be given an email address to send them to.

Asking for a Hub or Integration That Isn't Listed

If you have a hub or integration that isn't on the list and you'd like Device Sentinel to support it, open an issue on the repository titled "Extend support for name integration" or "Extend support for name hub". Say what it is, what Device Sentinel does with its devices today, and what you'd like it to do.

What Appears In The List

Only hardware found on your system, and only where support is still being built. A house with no Z-Wave is never offered Z-Wave, and a house with an unsupported router is. When support for something is finished, it is removed from the list, so the screen never asks for data nobody needs anymore.

What Is Collected

Two things, and neither is the contents of what your devices report.

• A snapshot, refreshed as Device Sentinel runs: what each of your devices publishes right now, and what Home Assistant holds about how to identify it.
• The shapes of what changes. A snapshot alone is not enough. The faults that have taken longest to find were only visible in what a device published at the moment something went wrong, which is a thing no single reading shows. So each distinct kind of change is kept once, with an example, and every later one of the same kind is counted rather than stored again. A hundred outages add nothing to the file; one device behaving oddly is kept.
• For Z-Wave, Matter, Philips Hue, SmartThings, Tuya and Lutron Caséta, a second file, stack_probe.md in the config/device_sentinel folder. Each time the network says something about one of your devices (alive, dead, away), it's written down beside what Device Sentinel says about the same device, with the device's name. That side-by-side record is what support for these hubs is built from.

Device names are included, because the rest of your diagnostics file already carries them and because a name is often what lets somebody match a reading to the problem you described.

Credentials, passwords, and tokens are never included, in this or any other part of the file.

Stopping

Untick the toggle and collection stops at once. What was already collected is removed at midnight. stack_probe.md rolls over at 1 MB and keeps three older copies.

Why This Exists

Device Sentinel supports what it has been able to test. Support for a router, a radio stack, or an integration usually stalls on the same thing: nobody involved has the hardware, and guessing from documentation produces support that looks right and fails on contact with a real system.

One person turning on a toggle for 48 hours has repeatedly been worth more than a week of reading.