Automation Events

Automation Events

Device Sentinel fires events on the Home Assistant bus when a device lands on the problem list, when its worst problem clears, and when you acknowledge it. An automation can trigger on those directly, without polling a sensor to find out whether something has gone wrong.

Until this was added the integration only listened to the bus. It watched every device in your house and never said a word, so the only way to react to a frozen sensor was to poll an entity and work it out yourself.

Where the Events Come From

The events ride the problem list, not the raw verdict.

That matters more than it sounds. The list already waits out a device's own debounce before a line appears, so a sensor that blips for thirty seconds and comes back never reaches it. You never see that on the card or in the daily brief, and your automations do not see it either. What reaches the bus is what reached you.

It also means a device with two problems fires one event carrying both, exactly as it takes one line on the list rather than two.

The Three Events

device_sentinel_fault

Fires when a device lands on the problem list, and again if a further problem is added to a device already on it. The second fault is news, so it earns its own event carrying the fuller list.

Field	What it is
device_id	The device's registry id. Survives a rename.
name	The device's name, as you see it on the list.
area	The device's area, or Unassigned.
kinds	Every problem on the line, worst first.
since	When the worst problem began, timezone aware.
renewed	true when this is a re-announcement after unticking.
battery_level	Present only when a battery problem is in kinds.
signal_value	Present only when a signal problem is in kinds.

kinds is ordered so the first entry is the headline:

unavailable → frozen → unknown → never_reported → low_battery → falling_battery → railed_signal

Unavailable leads because a device that has gone quiet is honestly absent, where a frozen one is holding a plausible value and lying to you. Both are worse than a low cell.

device_sentinel_recovered

Fires when the worst problem on a device's line clears.

Field	What it is
device_id, name, area	As above.
kind	The problem that cleared.
down_for	Seconds the problem stood.
resolved_by	self, intervention, or unknown.

This does not mean the device is well. It means the worst thing is no longer wrong. A sensor that comes back online while its battery is still low fires a recovery for unavailable and stays on the list carrying low_battery, which fires its own recovery later when the cell is replaced.

That is the right reading for an automation that resumes trusting a sensor: a device reporting again is trustworthy whether or not its battery is low.

resolved_by says unknown when it is unknown rather than guessing. An intervention is a reboot or a bridge reconnect that Device Sentinel saw. self means it recorded that nothing intervened. unknown means there was no lever to name, which is the ordinary case for a battery or a signal.

device_sentinel_acknowledged

Fires when you tick an item on the problem list.

Carries device_id, name, area and kinds.

Unticking has no event of its own. Unticking is the soft un-acknowledge, so the fault fires again with renewed: true. Your automations therefore need no knowledge of acknowledgment at all: they react to faults, ticking silences the re-announcement, and unticking brings it back.

What Does Not Fire

Nothing during the startup grace. Everything in your house reports at once after a restart and none of it is news. A problem still true when the grace ends is announced then, once.

Nothing for a coordinator outage. When a bridge or broker goes down, the devices behind it never reach the problem list at all: one row names the cause instead. So a dead coordinator does not fire forty device faults at your automations. If you want to react to the coordinator itself, trigger on its own availability entity, which is more direct than anything Device Sentinel could offer.

Quiet hours do not apply. They silence phone notifications and nothing else. An automation does not sleep, and an event withheld overnight means a heater that never restarted and a gap you find in the morning with nothing to explain it.

Writing an Automation

Notify on a fault

alias: Tell me when a device stops reporting
trigger:
  - platform: event
    event_type: device_sentinel_fault
action:
  - service: notify.mobile_app_your_phone
    data:
      title: "{{ trigger.event.data.name }}"
      message: >
        {{ trigger.event.data.kinds | join(', ') }}
        in {{ trigger.event.data.area }}

Stop trusting a sensor until it recovers

The one worth building. A frozen sensor is worse than a missing one, because it holds a plausible value and everything downstream keeps believing it.

alias: Do not trust the outdoor temperature while it is faulted
trigger:
  - platform: event
    event_type: device_sentinel_fault
    event_data:
      name: Temperature Outdoors
action:
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.outdoor_temp_untrusted

---

alias: Trust the outdoor temperature again
trigger:
  - platform: event
    event_type: device_sentinel_recovered
    event_data:
      name: Temperature Outdoors
action:
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.outdoor_temp_untrusted

Every automation that reads that sensor then checks the boolean first.

Two Things That Catch People Out

Filter by device in the trigger, by kind in a condition.

Matching on event_data is exact equality. device_id, name and area are single values, so they match there and your automation never wakes for another device:

    event_data:
      name: Switch Master Entryway

kinds is a list. Matching kinds: [unavailable] would only fire for a device whose only problem is unavailable, and would silently miss the same device when it is also low on battery, which is the case you most want to catch. Filter on kind in a condition instead:

condition:
  - condition: template
    value_template: "{{ 'unavailable' in trigger.event.data.kinds }}"

Name is readable, device_id survives a rename. Matching on name is easier to read and easier to write. If you rename the device in Home Assistant, that automation stops firing and nothing tells you. Matching on device_id keeps working and is unreadable six months later. Both are in the payload; pick per automation, and use device_id where silence would be expensive.

Repairs Are a Separate Thing

Events tell your automations that a device has a problem. Repairs tells you that Device Sentinel itself has one, in Home Assistant's Repairs panel under Settings.

The two never overlap. A device fault is an event and a to-do line, and is never a Repair. A problem with Device Sentinel's own ability to do its job is a Repair, and never an event.