Main

What Each Smart Plug Does When the Power Comes Back: Configuring Restore States So an Outage Doesn’t Switch Everything On

October 8, 2026

After an outage, the question everyone asks is “what does my smart plug do when power returns?” The honest answer is that you cannot answer it from Home Assistant’s side. Home Assistant only observes the resulting state. The restore behavior — on, off, or last state — is a firmware property of the plug, and it varies by model, by firmware revision, and sometimes by how the plug was configured before it lost power.

So the practical move is to stop trying to enumerate per-plug behavior and instead make Home Assistant enforce the state you want after it comes back. That is a reconciliation routine, and it works the same way regardless of which plugs restore to on, off, or last state.

What Home Assistant actually knows

A switch entity in Home Assistant can be in one of four states: on, off, unavailable, or unknown. The first two are real states. The last two mean Home Assistant does not currently know what the device is doing — typically because the integration has not connected yet, or the device has not reported in. The switch integration documentation lists these states explicitly.

The switch building block also provides the actions you will use in a reconciliation routine: switch.turn_on, switch.turn_off, and switch.toggle. It provides triggers too — switch.turned_on and switch.turned_off — which fire when a switch changes state.

What the switch integration does not define is what the physical device does when it loses and regains power. That is not a Home Assistant concept. It is a device concept. Home Assistant sees the result, not the policy.

Why a trigger alone is not enough

A trigger reacts at a specific moment, not while something is true. The trigger documentation is explicit about this: a state trigger fires on the transition, not on the steady state. If a plug comes back on and stays on, the trigger fires once. If it comes back on, then your automation turns it off, then something turns it back on, the trigger fires again.

That matters for reconciliation because you are not trying to react to every state change. You are trying to run a one-time check after Home Assistant has started and the integrations have had a chance to report real states. A trigger on “Home Assistant starts” fires at the moment of start — before most integrations have finished loading. The delay is what gives devices time to report their actual state.

Home Assistant starts is listed among the things that can trigger an automation in the trigger documentation. That is the trigger you want, followed by a delay long enough for your integrations to settle. How long depends on your stack. I have not seen a reliable number that works for every setup, so treat the delay as something you tune by observation, not something you copy from a blog post.

The diagnostic path

Before you write the routine, find out what actually happens. The procedure is simple and repeatable:

  1. Pick one smart plug. Note its entity ID and its current state.
  2. Cut power to that plug only — unplug it, or flip the breaker that feeds it.
  3. Wait for Home Assistant to mark the entity unavailable or unknown. This confirms Home Assistant noticed the loss.
  4. Restore power to the plug.
  5. Watch the entity state in Developer Tools → States. Does it come back on, off, or does it stay unknown until you interact with it?

What you learn from this is the plug’s actual restore behavior. It is not documented in the switch integration because it is not a Home Assistant property. It is a property of the device and its firmware.

Repeat for each plug you care about. The results will not be uniform. Some plugs restore to off. Some restore to on. Some restore to their last state. Some do not report a state at all until they are toggled. You cannot assume, and you cannot infer from the brand name.

Build the reconciliation routine

The routine has three parts: a trigger, a delay, and a Choose block that applies your intended state to each plug.

The trigger is Home Assistant starts. The delay is long enough for your integrations to report real states. The Choose block runs the actions of the first option whose conditions are all met, and can have default actions if no option matches — that is how the scripts documentation describes it.

Here is the shape of it in YAML. This is a pattern, not a finished automation — you will need to substitute your own entity IDs and your own intended states.

alias: "Reconcile smart plugs after restart"
triggers:
  - trigger: homeassistant
    event: start
actions:
  - delay:
      seconds: 60
  - choose:
      - conditions:
          - condition: state
            entity_id: switch.office_plug
            state: "on"
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.office_plug
      - conditions:
          - condition: state
            entity_id: switch.living_room_lamp
            state: "off"
        sequence:
          - action: switch.turn_on
            target:
              entity_id: switch.living_room_lamp
    default:
      - action: notify.persistent_notification
        data:
          message: "Reconciliation: one or more plugs were unavailable or unknown. Check manually."

The first option turns off a plug that should be off but came back on. The second turns on a plug that should be on but came back off. The default runs if neither condition matched — which, in this pattern, means the plug was unavailable or unknown, and you want to know about it rather than blindly toggling.

That last point matters. Toggling an unavailable entity does nothing useful and can mask a device that has not rejoined the network. Treat unavailable and unknown as “skip and log,” not “toggle anyway.”

Use a toggle helper as a policy switch

You will want to disable reconciliation sometimes — during maintenance, during a planned outage, or when you are testing. A toggle helper is a good place to store that policy.

By default, a toggle helper restores the state it had before Home Assistant stopped. If there is no state to restore, it starts as off. That is documented in the input boolean integration. The practical consequence is that if you turn the helper off before a restart, it stays off after the restart, and your reconciliation routine can check it as a condition.

Add a condition at the top of the routine: only proceed if input_boolean.reconcile_plugs is on. Then you can flip the helper from a dashboard without editing YAML.

Graceful degradation

The routine should not assume every plug will be reachable when it runs. If a plug is unavailable or unknown at reconciliation time, the routine should log it and move on. The default branch in the Choose block above does that.

This is the same principle that applies to the rest of a local-first stack: when a component is not reachable, the system should fail in a way you can see, not in a way that silently does the wrong thing. A plug that did not rejoin the network is a plug you need to know about. A plug that rejoined but came back in the wrong state is a plug the routine can fix.

Testing the routine

Testing is part of the procedure, not an afterthought. The only way to know whether the routine works is to run it against a real outage.

  1. Set the plug to the state you do not want it to be in after restore. For example, if you want it off, turn it on.
  2. Cut power to the plug.
  3. Restart Home Assistant.
  4. Wait for the routine to run.
  5. Check the plug’s state. It should be in the intended state.

If it is not, check the automation trace. The trace shows which trigger started the run and which branch of the Choose block executed. That tells you whether the routine ran at all, whether the delay was long enough, and whether the plug reported a real state by the time the routine checked.

If the plug was still unknown when the routine ran, the delay was too short. Increase it and test again. If the plug reported a real state but the routine did not correct it, the condition in the Choose block is wrong — check the entity ID and the state you are comparing against.

When a mechanical timer is the better answer

There is a category of problem this routine does not solve well: a plug that must be in a specific state immediately on power restore, before Home Assistant has started. A mechanical timer or a plain switch does that without any software in the loop. If the consequence of the plug being in the wrong state for the first minute after an outage is unacceptable — and you cannot tolerate the delay — the smart plug is the wrong tool for that job.

For everything else, the reconciliation routine is more robust than per-plug configuration because it works the same way regardless of which plugs restore to on, off, or last state. It only needs to know your intended state and the entity IDs.

What the recorder gives you

If you want to see what happened after an outage, the Recorder integration is what makes that possible. It is enabled by default as a dependency of the History integration, and it writes each entity state change to a database that History and Activity read from. That is how you can look back and see whether a plug came back on at 14:03 and was turned off at 14:04 by the routine, or whether it never reported a state at all.

If you have excluded switch entities from the recorder to keep the database small, you will not have that history. That is a tradeoff worth making deliberately rather than by default.

FAQ

Can Home Assistant configure what the plug does on power restore?

No. The restore behavior is a firmware property of the plug. Home Assistant observes the resulting state; it does not set the policy. Some integrations expose device-level configuration parameters that may include power-on behavior, but that is integration-specific and not part of the switch building block. Check the documentation for your specific integration and device.

Why does my plug show unknown after a restart?

unknown means Home Assistant does not yet know the device’s state. This is common immediately after a restart, before the integration has connected and the device has reported in. The reconciliation routine’s delay is what gives the device time to report a real state.

What if the plug never reports a real state?

Then the routine cannot correct it, and the default branch should log it. A plug that stays unknown or unavailable after a restart has a connectivity problem that reconciliation cannot fix. That is a separate diagnostic path.

Should I use a toggle helper or a separate automation for the policy?

A toggle helper is simpler because it survives restarts by default and can be flipped from a dashboard. A separate automation is more flexible if you need the policy to change based on time of day or presence. For most small installations, the helper is enough.

Does this work for lights too?

The same pattern applies to light entities, using light.turn_on and light.turn_off. The light integration provides its own triggers and actions, and the state model is similar. The reconciliation logic is the same: check the actual state after restart, then apply the intended state.

For a broader look at how the small systems in a home interact and where they fail, see How to Audit the Small Systems That Quietly Run Your Week.