Maintenance Mode

Maintenance Mode

This page explains the Maintenance Mode button and its one setting. The button lives on the Device Sentinel device page; the window length lives under Advanced.

Press the Maintenance Mode button right before you change a battery, re-pair a sensor, or touch broken hardware. It tells the integration that you are actively fixing things, preventing your manual repairs from polluting the system's learned statistics.

Why It Exists

Device Sentinel learns each device's reporting rhythm from its real gaps of silence. A manual fix, like a battery swap, a re-pair, or a sensor reseated after weeks of silence, looks identical to a device recovering on its own. If that silence were learned, the device would teach the integration that being broken for hours is its normal state, making every future freeze verdict for that hardware slower.

The integration already recognizes two kinds of intervention by itself. It catches a recovery during a Zigbee2MQTT pairing window because the coordinator announces it, and it sets aside anything spanning a Home Assistant restart. Everything else has no signal a coordinator publishes. ZHA does not expose out-of-band joins at all, and Z-Wave and Matter publish nothing usable today.

Maintenance Mode is the person supplying the signal themselves. It is the only intervention signal that works identically on every stack, which is why it exists.

Using It

Press the Maintenance Mode button before touching hardware. The window opens for ten minutes by default, which you can adjust from 5 to 60 minutes under Advanced. Press the button again to end the window early; otherwise, it closes itself automatically when the time expires.

The discard is fleet-wide. The button does not ask which device you are fixing, because you may be about to touch several at once.

For your dashboards, the sensor Maintenance: Ends holds a timestamp while the window is open and reads unknown while closed. A dashboard renders a countdown from the timestamp natively. A conditional card keyed on the sensor not being unknown works well to show maintenance controls only while the mode is on.

What It Changes and What It Does Not

While the window is open, any watched device that recovers, meaning it goes from frozen, unavailable, or unknown back to reporting, has that silence set aside rather than learned.

Detection is untouched. A device that goes down during your window is still detected, still reaches the problem list, and still notifies. The window only changes what happens to a recovery, never to a failure. It also does not suppress notifications. A recovery push is already silent by design.

On a fleet where the coordinator already announces pairing, and where the resurrection cap already bounds what any single hand-fix can teach, this button changes little. Its value grows on every stack the coordinator cannot speak for, which is most of them.

The Fine Print

Opening and closing are both written to the system events log, so the daily brief can explain any discarded recoveries between them. The closing row says exactly how the window ended: it expired, you pressed the button again, or Home Assistant restarted while it was open. The window itself does not survive a restart, deliberately, and the log's closing row for that case is written at the next start.

If a Zigbee2MQTT pairing window and a maintenance window are both open, the pairing window wins the explanation. It names the exact stack, where maintenance names only the person.

A genuine self-recovery that happens to land inside your ten minutes costs one discarded learning sample. This is the same conservative trade the pairing window already makes.

The window end is exact. A device that recovers a minute after expiry is learned normally. If you are still working, press the button again to open a new window.

For more details on alerts and learning rules, see FAQ and Troubleshooting.