The Problem List

The Problem List

The problem list contains the frozen devices and low batteries the integration currently sees and is where its detections become something you can 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.

What Fills It

The moment a device is judged frozen, unavailable, unknown, or never reported, the moment a battery crosses the low threshold or is projected to run down to empty, or the moment a signal problem is confirmed, an item appears.

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, then the battery, as a percentage where it is under the threshold and as a forecast where it is running down.

When a Bridge or Broker Goes Down

A coordinator or broker going down silences every device behind it at once. Rather than one row per casualty, the list carries a single row naming the cause, reading Zigbee2MQTT down: 74 devices unavailable. Its description says when the bridge stopped reporting, and that the devices behind it are counted rather than listed. The count moves as more devices fall; the time the outage began does not.

Those devices are still judged and still recorded. The Device: Frozen sensor counts every one of them and the device telemetry file lists them, because those say what is true rather than what is worth reading. The list, the card, your phone and the daily brief show the one sentence you can act on.

Two devices keep their own rows through an outage:

• One whose problem began before the upstream went down. It was already broken, and it should not vanish into the outage and reappear when the outage clears.
• One still down after the upstream returns. Everything else came back and this did not, which is the most useful line the integration can give you after an outage.

A broker outage outranks a bridge outage, because a broker that is down takes every bridge with it, and two rows for one fault is the same noise in a smaller font.

The row clears when the upstream returns. What you are sent and when is on Notifications and Daily Brief.

The Checkbox Is the Acknowledgment

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

The item remains on the list, marked as done, and becomes silent. It is ignored and does not appear on the daily brief, it will not appear in the persistent dashboard card, and is absent in your phone notifications. The fault is still recorded in the diagnostic reports and audit trails.

The worked example: you have a vibration sensor in a vehicle that is at the mechanic. Unchecked, every daily brief would mention it. Checked, it moves to the background and becomes silent for as long as the car is gone.

Acknowledgment ends when the problem does:

• If the problem worsens while acknowledged, for example a low-battery device 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.

Checking never means recovered. Recovery is detected, not declared. When the device recovers, its item is removed whether you checked it or not.

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.

Muting Instead of Acknowledging

An acknowledgment silences a current incident. A mute is the standing statement that a device should never be judged for that problem again. If you find yourself re-acknowledging the same device every time it fails, the muting lists, like Low Battery or Exclusions and Muting, are the better tool. Once muted, 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.