Why Does a Home Assistant Automation Fail When Triggered by a Device State Restored After Reboot?

Introduction: The Frustrating Midnight Discovery

Picture this: You’ve spent an entire weekend perfecting your Home Assistant setup. Your motion sensors trigger the hallway lights flawlessly. Your thermostat adjusts based on occupancy like clockwork. Everything works beautifully — until you reboot your Home Assistant server.

Suddenly, your automations fire all at once. Lights turn on at 3 AM. The garage door opens unexpectedly. Your smart alarm triggers a false alert. Or worse — some automations simply stop working altogether.

If you’ve been there, you’re not alone. I’ve personally dealt with this exact nightmare, and after hours of digging through logs, reading GitHub issues, and testing solutions, I finally understood the root cause: state restoration after reboot.

This is one of the most misunderstood behaviors in Home Assistant, and it can break even well-designed automations. In this guide, I’ll explain exactly why this happens, show you real scenarios, and walk you through proven fixes that actually work.

[📌 Image Placeholder 1]
Suggested image: A screenshot of Home Assistant’s Developer Tools showing entity states with “restored: true” attribute visible after a reboot.
Alt text: “Home Assistant Developer Tools showing restored entity states after system reboot with restored true attribute highlighted”

What Happens to Device States When Home Assistant Reboots?

Understanding the State Restoration Process

When Home Assistant shuts down or reboots, it doesn’t simply forget everything. Instead, it saves the last known state of every entity to a database (the home-assistant_v2.db file). When it starts back up, it restores those saved states before the actual integrations reconnect to your physical devices.

Here’s the critical timeline:

  1. Home Assistant starts booting → States are loaded from the database
  2. Entities appear with their last known state → But they carry a hidden restored: true attribute
  3. Integrations connect to actual devices → Real states replace the restored ones
  4. The restored attribute disappears → The entity now reflects reality

The problem? Step 2 and Step 3 don’t happen simultaneously. There’s a gap — sometimes just milliseconds, sometimes several seconds — where entities exist with “fake” restored states that don’t match reality.

Why This Matters for Automations

Your automations don’t know the difference between a genuine state change and a restored state replacing “unavailable.” When Home Assistant boots:

  • An entity might go from unavailable → on (restored state)
  • Your automation sees a state change to on
  • It triggers — even though the device was already on before the reboot

This is the core of the problem. The automation interprets the state restoration as a real event.

[📌 Image Placeholder 2]
Suggested image: A timeline diagram showing the sequence of events during Home Assistant reboot — from shutdown, to state restoration, to integration reconnection.
Alt text: “Timeline diagram illustrating Home Assistant reboot sequence showing state restoration gap between startup and integration reconnection”

Real-World Scenarios: How This Bug Bites You

Scenario 1: Lights Turning On After Every Reboot

What happens: You have an automation that turns on lights when a motion sensor’s state changes to on. After a reboot, the motion sensor’s last state was on, so it gets restored as on. The automation fires, and your bedroom lights blast on at 4 AM.

YAMLautomation:
  - alias: "Motion Light"
    trigger:
      - platform: state
        entity_id: binary_sensor.hallway_motion
        to: "on"
    action:
      - service: light.turn_on
        target:
          entity_id: light.hallway

The flaw: No protection against restored states.

Scenario 2: Notification Spam After Reboot

What happens: You have an automation that sends a push notification whenever your door sensor opens. After reboot, the door sensor state is restored from unavailable to off, and in some configurations, any state change triggers the notification logic.

Scenario 3: Climate Control Going Haywire

What happens: Your thermostat automation triggers when temperature sensor readings change. After reboot, the restored temperature value causes a state change event, and your HVAC system kicks into action based on stale data.

My personal experience: I once had an automation that controlled my water heater based on a schedule and a temperature sensor. After a routine update that required a reboot, the automation fired with a restored temperature of 45°C (from before the reboot), even though the actual water temperature had dropped to 30°C. The heater didn’t turn on when it should have because the system “thought” the water was already hot enough.

The Technical Deep Dive: Why Automations Can’t Tell the Difference

The restored Attribute — Your Hidden Clue

When Home Assistant restores an entity state, it adds a special attribute:

JSON{
  "state": "on",
  "attributes": {
    "restored": true,
    "supported_features": 0
  }
}

Most automations don’t check for this attribute, which is why they get fooled.

State Change Events During Boot

Home Assistant fires state_changed events during the restoration process. Here’s what the event looks like:

Event PropertyValue
old_stateNone or unavailable
new_stateThe restored state (e.g., on)
contextNormal context (no special boot flag)

Since there’s no universal “this is a boot event” marker in the trigger, your automation treats it as a legitimate state change.

The from Parameter Trap

Many users think adding a from parameter protects them:

YAMLtrigger:
  - platform: state
    entity_id: binary_sensor.door
    from: "off"
    to: "on"

But during reboot, the entity goes from unavailable (or None) → restored state. Since unavailable ≠ off, this trigger might not fire — which sounds good until you realize it also won’t fire for legitimate state changes if the entity briefly becomes unavailable due to a network glitch.

[📌 Image Placeholder 3]
Suggested image: A screenshot of Home Assistant’s Logbook showing automation triggers immediately after a system reboot, with timestamps clustered together.
Alt text: “Home Assistant Logbook displaying multiple automations triggered simultaneously after system reboot due to state restoration”

Step-by-Step Solutions to Fix Automation Failures After Reboot

Solution 1: Use the not_from and not_to Filter (Home Assistant 2023.11+)

Starting with Home Assistant 2023.11, you can use not_from and not_to in state triggers to explicitly exclude transitions from unavailable or unknown:

YAMLautomation:
  - alias: "Motion Light - Reboot Safe"
    trigger:
      - platform: state
        entity_id: binary_sensor.hallway_motion
        to: "on"
        not_from:
          - "unavailable"
          - "unknown"
    action:
      - service: light.turn_on
        target:
          entity_id: light.hallway

Why this works: It prevents the automation from triggering when the state transitions from unavailable (which is what happens during restoration) to any other state.

Solution 2: Add a Boot Delay with homeassistant_started Event

Create a helper that tracks whether Home Assistant has fully started:

YAMLautomation:
  - alias: "Set HA Started Flag"
    trigger:
      - platform: homeassistant
        event: start
    action:
      - delay: "00:02:00"  # Wait 2 minutes for all integrations to connect
      - service: input_boolean.turn_on
        target:
          entity_id: input_boolean.ha_fully_started

Then use this flag as a condition in your automations:

YAMLautomation:
  - alias: "Motion Light - With Boot Check"
    trigger:
      - platform: state
        entity_id: binary_sensor.hallway_motion
        to: "on"
    condition:
      - condition: state
        entity_id: input_boolean.ha_fully_started
        state: "on"
    action:
      - service: light.turn_on
        target:
          entity_id: light.hallway

Don’t forget: You also need an automation to turn off this flag when HA shuts down:

YAMLautomation:
  - alias: "Clear HA Started Flag on Shutdown"
    trigger:
      - platform: homeassistant
        event: shutdown
    action:
      - service: input_boolean.turn_off
        target:
          entity_id: input_boolean.ha_fully_started

Solution 3: Check the restored Attribute in Templates

You can use a condition template to check if the entity has been restored:

YAMLautomation:
  - alias: "Door Alert - Restored Check"
    trigger:
      - platform: state
        entity_id: binary_sensor.front_door
        to: "on"
    condition:
      - condition: template
        value_template: >
          {{ not trigger.from_state or 
             trigger.from_state.state not in ['unavailable', 'unknown'] }}
    action:
      - service: notify.mobile_app
        data:
          message: "Front door opened!"

Solution 4: Use for Duration in Triggers

Adding a for parameter ensures the state must persist for a duration before the automation fires:

YAMLtrigger:
  - platform: state
    entity_id: binary_sensor.hallway_motion
    to: "on"
    for: "00:00:05"  # Must be 'on' for 5 seconds

Why this helps: During reboot, restored states are often quickly replaced by actual states from integrations. The 5-second delay gives integrations time to report real states.

Solution 5: Use initial_state for Critical Automations

For automations that absolutely should NOT run during boot, set them to start disabled:

YAMLautomation:
  - alias: "Critical Alarm System"
    initial_state: false
    trigger:
      - platform: state
        entity_id: binary_sensor.alarm_trigger
        to: "on"
    action:
      - service: alarm_control_panel.alarm_trigger
        target:
          entity_id: alarm_control_panel.home

Then enable it after boot:

YAMLautomation:
  - alias: "Enable Critical Automations After Boot"
    trigger:
      - platform: homeassistant
        event: start
    action:
      - delay: "00:03:00"
      - service: automation.turn_on
        target:
          entity_id: automation.critical_alarm_system

[📌 Image Placeholder 4]
Suggested image: A side-by-side comparison of YAML code — one showing a vulnerable automation and the other showing the fixed version with reboot protection.
Alt text: “Side-by-side YAML code comparison showing vulnerable Home Assistant automation versus reboot-safe version with not_from filter”

How to Diagnose If Your Automation Was Triggered by a Restored State

Step 1: Check the Logbook

Go to Settings → System → Logs or the Logbook panel. Look for automations that triggered within the first 30-60 seconds after a reboot. If multiple automations fired simultaneously right after startup, they were likely triggered by state restoration.

Step 2: Inspect Entity Attributes in Developer Tools

  1. Go to Developer Tools → States
  2. Search for the entity in question
  3. Look for restored: true in the attributes
  4. If you see it, the entity hasn’t connected to its integration yet

Step 3: Enable Debug Logging for Automations

Add this to your configuration.yaml:

YAMLlogger:
  default: warning
  logs:
    homeassistant.components.automation: debug

After a reboot, check the logs for entries showing automation triggers with old_state: None or old_state: unavailable.

Step 4: Use the Trace Feature

Home Assistant has a built-in automation trace feature:

  1. Go to Settings → Automations
  2. Click on the automation in question
  3. Click Traces (top right)
  4. Look at the trigger data — you’ll see the from_state and to_state

[📌 Image Placeholder 5]
Suggested image: A screenshot of the Home Assistant Automation Trace panel showing trigger details with from_state as “unavailable” indicating a reboot-triggered event.
Alt text: “Home Assistant automation trace panel revealing trigger from_state as unavailable confirming automation was triggered by state restoration after reboot”

Best Practices to Prevent Reboot-Related Automation Failures

1. Always Specify from and to States

Never use a bare state trigger without specifying where the state is coming from:

YAML# ❌ Bad - Will trigger on any state change including restoration
trigger:
  - platform: state
    entity_id: binary_sensor.motion
    to: "on"

# ✅ Good - Only triggers on genuine off → on transitions
trigger:
  - platform: state
    entity_id: binary_sensor.motion
    from: "off"
    to: "on"

2. Use not_from for Modern HA Versions

YAML# ✅ Best - Explicitly excludes restoration transitions
trigger:
  - platform: state
    entity_id: binary_sensor.motion
    to: "on"
    not_from:
      - "unavailable"
      - "unknown"

3. Implement a Global “System Ready” Check

Create a reusable condition that any automation can reference:

YAML# In your input_booleans
input_boolean:
  system_ready:
    name: System Ready
    initial: false

4. Group Critical Automations

Organize your automations by criticality. High-impact automations (alarm systems, door locks, HVAC) should always have reboot protection.

5. Test After Every Update

After updating Home Assistant, always test your critical automations by performing a deliberate reboot and monitoring the logs.

Community Experiences: What Real Users Have Faced

Experience from the Home Assistant Community Forum

“I spent three days trying to figure out why my garage door automation kept opening after every HA restart. Turned out the cover entity was being restored as ‘open’ which triggered my notification automation, which then triggered another automation that toggled the garage door. Chain reaction from a simple state restore.” — Community member on the Home Assistant Forum

Experience from Reddit r/homeassistant

“My Zigbee devices were the worst offenders. After reboot, it took about 90 seconds for the Zigbee coordinator to fully initialize. During that window, all my Zigbee sensors showed restored states, and any automation watching those sensors would fire incorrectly.”

My Own Experience

I run Home Assistant on a Raspberry Pi 4, and I noticed that after system updates (which require a restart), my smart plug automations would turn on devices that should have been off. The root cause was that my energy monitoring automation used a state trigger on the smart plug’s power consumption sensor. After reboot, the restored power value (e.g., 150W) triggered the “high consumption alert” automation — even though the actual consumption at that moment was 0W because the plug was still reconnecting.

The fix? I added both a not_from: unavailable filter AND a 30-second for duration to the trigger. Problem solved permanently.

[📌 Image Placeholder 6]
Suggested image: A flowchart showing the decision tree for choosing the right reboot protection method based on automation type and criticality level.
Alt text: “Decision flowchart for selecting appropriate reboot protection strategy for Home Assistant automations based on automation type and risk level”

Advanced: Handling State Restoration in Node-RED and AppDaemon

Node-RED Users

If you use Node-RED for your automations, you can add a function node to filter out restored states:

JavaScriptif (msg.data && msg.data.old_state === null) {
    // This is a state restoration - ignore it
    return null;
}
return msg;

AppDaemon Users

In AppDaemon, you can check for restored states:

Pythondef state_callback(self, entity, attribute, old, new, kwargs):
    if old is None or old == "unavailable":
        self.log(f"Ignoring restored state for {entity}")
        return
    # Your automation logic here

External Resources and References

For deeper understanding, check these official and community resources:

Frequently Asked Questions (FAQ)

Q1: Does every automation get affected by state restoration after reboot?

No. Only automations using state triggers are affected. Automations triggered by time, events, webhooks, or manual triggers are not impacted by state restoration.

Q2: How long does the state restoration phase last?

It depends on your system and the number of integrations. On most systems, it takes 10 seconds to 2 minutes. Zigbee and Z-Wave devices may take longer because their coordinators need to reinitialize.

Q3: Will using from: "off" completely prevent false triggers after reboot?

In most cases, yes. If the entity goes from unavailable → on during restoration, the from: "off" condition won’t match, so the automation won’t fire. However, this may also prevent legitimate triggers if the entity briefly becomes unavailable due to network issues.

Q4: Is this a bug in Home Assistant?

It’s by design, not a bug. State restoration ensures that your dashboard shows the last known state immediately after boot, rather than showing everything as “unavailable.” The side effect on automations is a known trade-off that the developers expect users to handle in their automation logic.

Q5: Can I disable state restoration entirely?

No, there’s no global toggle to disable state restoration. However, you can work around it using the solutions described in this article — particularly the not_from filter and the boot delay approach.

Q6: Does this affect scenes and scripts too?

Scripts can be affected if they are triggered by automations that were falsely triggered by state restoration. Scenes are not directly affected since they are activated manually or by automations.

Q7: What’s the safest single solution if I can only implement one fix?

Use the not_from filter (Solution 1). It’s the most elegant, doesn’t require additional helpers, and directly addresses the root cause. It requires Home Assistant 2023.11 or newer.

Conclusion: Build Resilient Automations That Survive Reboots

State restoration after reboot is one of those “gotchas” that catches almost every Home Assistant user at some point. The good news is that once you understand why it happens, the fixes are straightforward.

Here’s your action plan:

  1. Audit your existing automations for bare state triggers without from specifications
  2. Add not_from: ["unavailable", "unknown"] to all state-based triggers
  3. Implement a system ready flag for critical automations
  4. Test by rebooting and checking your Logbook for false triggers
  5. Monitor after updates since new integrations might introduce new restoration behaviors

Remember: a smart home should work for you, not against you — even after a reboot at 3 AM.

[📌 Image Placeholder 7]
Suggested image: A clean infographic summarizing the 5 solutions with icons — not_from filter, boot delay, restored attribute check, for duration, and initial_state.
Alt text: “Infographic summarizing five solutions to fix Home Assistant automation failures after reboot including not_from filter boot delay and restored attribute check”