How to Turn a UPS Into a Smart Home Power-Outage Sensor

A UPS can keep your hub alive and still leave your smart home blind. If the hub cannot read the UPS, it only knows that it is still powered. If the router dies first, the cloud notification you were counting on may never leave the house. The useful version of this setup is narrower and more practical: wire the UPS into the hub, expose its state locally, and make the house report power loss before the battery is gone.

That is the smart home power outage backup tip that matters after you have already bought the battery: the UPS becomes infrastructure only when it becomes a sensor. In Home Assistant, the cleanest path is usually NUT, short for Network UPS Tools. Once Home Assistant can talk to a NUT server, it can poll the UPS locally and expose entities such as UPS status, battery charge, battery runtime, load, input voltage, and output voltage. The Home Assistant NUT integration uses port 3493 by default, recommends a static IP address or DHCP reservation for the NUT server, requires credentials with instcmds permission for command support, and polls locally every 60 seconds by default.[1]

This article assumes the boring electrical choices are already handled: what gear is actually on the UPS, which switches or access points stay up, and how much runtime you are willing to buy. If that part is not settled, start with which smart home gear needs to run during a power outage. Here, the job is detection and alerting: power dropped, power returned, battery is low, and something local should react.

The Home Assistant NUT path

There are two common physical layouts. In the simplest one, the UPS connects by USB to the machine running Home Assistant or to another always-on device that runs the NUT server. In the networked version, a NAS, small server, or UPS network card runs NUT and Home Assistant connects to that server over the LAN. Either way, Home Assistant is not guessing that utility power failed; it is reading the UPS state.

Before writing any automation, add the NUT integration and identify the actual entity names Home Assistant created. A typical install gives you a status entity, a battery charge entity, and often runtime, load, and voltage entities. The exact names depend on your UPS, NUT server, and Home Assistant’s entity naming, so do not paste sensor.ups_status from an article and assume it exists.

What to confirm before automation

• The UPS is connected by USB, network card, or another NUT-supported path to a device that remains powered during an outage.
• The NUT server has a stable address, preferably a static IP address or DHCP reservation, so Home Assistant does not lose it after a reboot.[1]
• Home Assistant can reach the NUT server on port 3493 unless you intentionally changed the port.[1]
• The Home Assistant NUT credentials have the permissions you need. If you plan to send UPS commands, the docs call out credentials with instcmds permission.[1]
• The UPS status entity shows a real state change when utility power is removed. Home Assistant’s published example triggers on the state “On Battery, Battery Discharging.”[1]
• Battery charge is exposed as a numeric entity if you want a low-battery trigger. Home Assistant’s published low-battery example uses a below-25% battery-charge pattern.[1]

Do not assume your phone alert survives the same outage

This is where many otherwise good UPS recipes fall apart. Home Assistant can detect the outage locally, but a mobile push notification may still depend on a router, modem, ISP path, Apple or Google push services, and the recipient phone’s network connection. Battery-backed hubs help only if the communication path is backed too; cloud-dependent systems can lose remote visibility when internet service drops during the outage.[2][3]

For an outage sensor, the alert route is part of the build. A useful local route might be a speaker or siren that is on the UPS-backed LAN, a dashboard tablet that stays powered, a locally reachable notification bridge, or an automation that tells a NAS or server to begin its own shutdown sequence. A cloud push can still be nice when broadband remains online, but it should be treated as a bonus path unless you have tested it with the UPS unplugged from the wall.

Automation 1: report that power is out

Start with the status transition. Home Assistant’s NUT documentation publishes an automation pattern that fires when UPS status changes to “On Battery, Battery Discharging.”[1] The example below keeps that state as the trigger and adds a message with charge and runtime. Replace the entity IDs and the notification service with your own.

alias: UPS - Power is out
mode: single
trigger:
  - platform: state
    entity_id: sensor.ups_status
    to: "On Battery, Battery Discharging"
action:
  - service: notify.local_house
    data:
      title: "Power outage detected"
      message: >-
        UPS is on battery.
        Charge: {{ states('sensor.ups_battery_charge') }}%.
        Runtime estimate: {{ states('sensor.ups_battery_runtime') }}.
        Load: {{ states('sensor.ups_load') }}%.

The service name notify.local_house is intentionally generic. If your only notification service is a phone push that leaves through the internet, keep it, but add a second local action. For example, call a script that flashes a Zigbee bulb powered by the UPS-backed hub, plays a local TTS announcement on a powered speaker, or writes a persistent notification that will be visible on the Home Assistant dashboard.

alias: UPS - Power is out with local fallback
mode: single
trigger:
  - platform: state
    entity_id: sensor.ups_status
    to: "On Battery, Battery Discharging"
action:
  - service: notify.mobile_app_your_phone
    data:
      title: "Power outage detected"
      message: "UPS is on battery at {{ states('sensor.ups_battery_charge') }}%."
  - service: persistent_notification.create
    data:
      title: "Power outage detected"
      message: >-
        UPS switched to battery.
        Check router, modem, NAS, and remaining runtime.
  - service: script.local_power_outage_announcement

That second example is not a guarantee that every listed action works during a blackout. It is a reminder to separate “Home Assistant noticed” from “a human was actually alerted.” If the speaker, Zigbee coordinator, switch, or Wi-Fi access point is not on backup power, the automation can run perfectly and still say nothing useful.

Automation 2: report that power is back

Restoration matters because it closes the incident. It also prevents a later low-battery or shutdown automation from being mistaken for an active outage. Rather than assuming your restored state is named a particular way, this version watches for the status entity to leave “On Battery, Battery Discharging” after it was previously there.

alias: UPS - Power is back
mode: single
trigger:
  - platform: state
    entity_id: sensor.ups_status
condition:
  - condition: template
    value_template: >-
      {{ trigger.from_state is not none
         and trigger.to_state is not none
         and trigger.from_state.state == 'On Battery, Battery Discharging'
         and trigger.to_state.state != 'On Battery, Battery Discharging' }}
action:
  - service: notify.local_house
    data:
      title: "Power restored"
      message: >-
        UPS is no longer reporting battery discharge.
        Current UPS status: {{ states('sensor.ups_status') }}.
        Battery charge: {{ states('sensor.ups_battery_charge') }}%.

During your test, write down the exact restored state your UPS reports. If it is stable on your system, you can simplify the trigger later by targeting that state directly. The template version is less pretty, but it avoids baking in a state label that may not match your hardware.

Automation 3: warn at low battery before shutdown

The low-battery automation is where the UPS stops being a dashboard novelty and starts protecting equipment. Home Assistant’s NUT documentation includes a published automation pattern that triggers when battery charge drops below 25%.[1] Use that threshold as a starting point, not as a moral law. A rack with a NAS and PoE switch may need action earlier than a hub-and-router-only shelf.

alias: UPS - Battery low
mode: single
trigger:
  - platform: numeric_state
    entity_id: sensor.ups_battery_charge
    below: 25
condition:
  - condition: state
    entity_id: sensor.ups_status
    state: "On Battery, Battery Discharging"
action:
  - service: notify.local_house
    data:
      title: "UPS battery low"
      message: >-
        UPS battery is below 25% while utility power is out.
        Runtime estimate: {{ states('sensor.ups_battery_runtime') }}.
        Starting local shutdown sequence if configured.
  - service: script.ups_low_battery_shutdown_sequence

Keep the shutdown action as a script while you are building. That gives you one place to stage the sequence: stop nonessential services, tell the NAS to shut down, pause automations that would flap devices, and leave the Home Assistant host for last if you shut it down at all. The script name above is a placeholder. A safe NAS shutdown depends on the NAS, its integration, its credentials, and whether the network path between Home Assistant and the NAS is still alive.

alias: UPS - Low battery shutdown sequence example
sequence:
  - service: persistent_notification.create
    data:
      title: "UPS shutdown sequence started"
      message: "Low battery threshold reached. Running local shutdown steps."
  - service: script.shutdown_nonessential_services
  - delay: "00:00:30"
  - service: script.shutdown_nas
  - delay: "00:02:00"
  - service: script.final_ups_warning
mode: single

Do not let the word “runtime” lull you into precision. Runtime estimates are useful for decisions, but they move when loads change. Adding PoE cameras, access points, NAS devices, or other gear changes how long the UPS can carry the system, and outage-backup guidance recommends simulating the outage by unplugging the UPS from the wall rather than unplugging individual devices.[4]

The unplug-from-the-wall test

A real test is short and slightly annoying, which is why it catches mistakes. Do it while you are home, while nothing critical is writing data, and while you can see both Home Assistant and the physical UPS. Pull the UPS input plug from the wall. Do not unplug the router, NAS, hub, or UPS output devices one by one; that tests a different failure.

1. Confirm the UPS itself switches to battery.
2. Watch the Home Assistant NUT status entity change to the battery-discharge state you used in the automation.
3. Confirm the “power is out” automation fires.
4. Confirm the local alert reaches the place you expect: speaker, dashboard, siren, local notification bridge, or other local target.
5. Check whether the phone push arrives. If it does, note whether it arrived through Wi-Fi, cellular, or a still-working internet path.
6. Let the test run long enough to see battery charge and runtime estimates move, then restore utility power.
7. Confirm the “power is back” automation fires and records the restored status.

If the power-out alert fires only after internet returns, it is not an outage alert. It is an after-action report. That may still be useful, but it is not the same as giving the house a surviving way to say “utility power is gone” while the UPS is still carrying the load.

If you are not running Home Assistant

NUT is the best fit when you want UPS telemetry inside Home Assistant. Outside that world, the alternatives are more fragmented. They can still be useful, but most of them detect “something about power changed” rather than exposing the UPS as a full local sensor with charge, runtime, load, and voltage.

The battery-backed-hub idea is still worth doing. SmartThings community discussions and vendor guidance both point to the same practical split: a powered hub may keep local control alive, but remote alerts and cloud functions depend on the network and cloud route remaining available.[2][3] Treat any quoted runtime for a hub or mini-UPS as a planning lead until you have tested it with your own router, radios, and automations attached.

UPS buying guides and smart-home UPS explainers are useful for narrowing hardware and setting expectations, especially around load and runtime, but they do not replace an unplug test on the actual shelf you expect to survive an outage.[5][6]

Where this fits with the rest of the outage plan

Once the sensor and alerts work, the remaining questions split cleanly. Use the power-backup gear guide to decide what deserves battery power. Use the outage-tracking guide when you need to separate a real grid outage from a local breaker, modem, or ISP failure. After restoration, use the post-outage recovery guide for devices that stay offline even after utility power returns.

The finished recipe is not a bigger UPS promise. It is a tested chain: UPS reports state locally, Home Assistant sees the state, the automation fires, the alert path survives long enough to matter, and the low-battery action happens before the rack goes dark.

References

1. Network UPS Tools (NUT), Home Assistant
2. Battery backup necessity, SmartThings Community
3. What Happens to Your Smart Devices During a Power Outage, EVVR
4. Home Network, Internet, Camera & VoIP Outage Backup, Data Wire Solutions
5. How To Choose The Right UPS For A Smart Home, HomeTechHacker
6. The Best Uninterruptible Power Supply (UPS), Wirecutter