The Problem List

The Problem List

The problem list is where Device Sentinel's detections become something you act on. It is a standard Home Assistant to-do entity, todo.device_sentinel_problem_list, visible in the sidebar's To-do panel, in the companion app, and on any dashboard through the ordinary to-do list card.

It holds every problem the integration currently sees, and nothing else. This list is the single source of record: the phone pushes fire on changes to this list, so an item and its notification can never disagree. What is on the list is what you were told about; what leaves the list is what has recovered.

What Fills It

The list is maintained by the detections alone, live. The moment a device is judged frozen, unavailable, unknown, or never reported, the moment a battery crosses the low threshold or begins running down, or the moment a signal problem is confirmed, an item appears. The moment the last of a device's problems clears, its item is deleted.

You cannot add to this list. The entity deliberately declines the create feature, so there is no add box. This is by design: if you could type an item, it would vanish on the next sync because it did not come from a real detection. The only controls you use on this list are the checkbox and deletion.

One Line per Device

A device appears once, no matter how many problems it carries. The line leads with the device's name and then lists its problems in a fixed order: the freeze verdict first, because it says whether the device is alive at all, then the battery, as a percentage where it is under the threshold and as a forecast where it is running down, then signal.

A frozen device whose battery then dies does not become a second entry; its one line grows a second problem. Tap the item open, and the description gives each problem its readable start time. For a freeze verdict on a Zigbee2MQTT device the description also carries what Zigbee2MQTT says about that device, with the timeout it judges by: a second opinion rather than the verdict, which is why it sits in the description rather than the summary line. See The Bridge and Broker Sensors. The item's due date is when the earliest problem began, so the list shows you the outage's age at a glance.

The Checkbox Is the Acknowledgment

Checking an item means one thing: you have seen this problem and decided it can wait.

The item stays on the list, marked as done, and it goes quiet on every human-facing channel. An acknowledged device leaves the daily brief entirely, including the emailed version, and it goes silent on the persistent dashboard card and in your phone pushes, for every problem kind it carries. Acknowledging a problem is the statement that you already know about it and do not want reminding. The fault is still fully recorded in the background reports and diagnostics, where an audit trail belongs.

The worked example: you have a vibration sensor in a vehicle that is away at the shop. Unchecked, every daily brief would mention it. Checked once, it stays silent for as long as the car is gone, and its line keeps itself current in the background.

Acknowledgment ends when the problem does:

• If the problem worsens while acknowledged, for example a low-battery device finally freezing, nothing is sent, because you already said you know it needs attention.
• If the device recovers on its own, the daily brief will say so, and any later fault on that same device is treated as a fresh incident that speaks up normally.

Checking never means recovered. Recovery is detected, not declared. When the device comes back, its item is removed automatically whether you checked it or not. That removal is the automatic re-arm. If the same device fails again next month, that is a new incident, a fresh unchecked item, and a new notification.

Unchecking and Deleting

Unchecking an item returns it to the open block, making it an active alert again.

Deleting an item by hand while its device is still down is the hard un-acknowledge: on the next sync, the integration will see the device is still down, re-add it as a new incident, and announce it again.

The Order

Open items sort alphabetically by device name, so the active list reads like a roster rather than a timeline.

Acknowledged items follow in the order you checked them, oldest first. This makes the checked section a stable history that does not reshuffle as active problems come and go around it. The integration owns this order; dragging items to rearrange them will not stick.

Restarts

A reboot changes nothing here. Both the problems and your acknowledgments live in the integration's storage, and detections are re-derived from stored clocks at startup. A device that was twenty hours into a freeze is still listed as twenty hours frozen after a restart, and the box you checked last week is still checked.

Excluding Instead of Acknowledging

An acknowledgment silences a current incident. An exclusion is the standing statement that a device should never be judged for that problem at all. If you find yourself re-acknowledging the same device every time it fails, the exclusion pages, like Low Battery or Global Exclusions, are the better tool. Once excluded, the device drops off the list at once and stays off.

On a Dashboard

The standard Home Assistant to-do list card, pointed at todo.device_sentinel_problem_list, gives you the live report and the acknowledgment checkbox in one place.

Two settings on that card are worth knowing:

• Keep the completed section visible: This is where your acknowledged items live.
• Avoid the "Remove completed items" action in the card's menu: This hand-deletes all your acknowledgments. Because the devices are still broken, the next sync will re-add them all and fire fresh notifications for every one.