Links on the site may earn us an affiliate commission. Learn more.

Home Assistant Home Automations

5 Practical Home Assistant Automations That Just Work

10 min read

5 Practical Home Assistant Automations That Just Work

These are not flashy automations. They are practical ones that actually make a difference once you have them running. We’ll cover update notifications, low battery alerts, a phone charging indicator, a doorbell motion fix, and adaptive lighting.

Table of Contents

1. Available Updates Notification

If you want to stay on top of updates for Home Assistant, apps, and integrations, this automation is a must-have.

It runs every morning at 9:30 AM. A template condition checks all entities under the update domain, and if any updates are available, it sends you a notification. The message body lists every entity with a pending update. The title shows the total count. At a glance, you know exactly what needs attention.

Tapping the notification opens the Home Assistant app directly on the updates page, so you can review and run updates right from your phone. That’s handled by adding the URL to the /config/updates page under the data section.

I also added a group name to keep related notifications organized. It’s not strictly necessary here since the automation only runs once a day, but if you ever change it to run more often, having that group action in place keeps things clean.

alias: Available updates notification
description: ""
triggers:
  - trigger: time
    at: "09:30:00"
conditions:
  - condition: template
    value_template: "{{ states.update | selectattr('state', 'eq', 'on') | list | count > 0 }}"
actions:
  - action: notify.mobile_app_juans_iphone
    metadata: {}
    data:
      data:
        url: /config/updates
        group: updates_available
      message: |-
        {{ states.update 
          | selectattr('state', 'eq', 'on') 
          | map(attribute='attributes.friendly_name') 
          | join('\n') }}
      title: |-
        {{ states.update 
          | selectattr('state', 'eq', 'on') 
          | list 
          | count }} updates available
    enabled: true
mode: single

2. Low Battery Alert

When you have a lot of battery-powered devices in Home Assistant, it is easy to lose track of them. Sensors especially. You set them up, they do their job, and you forget about them. Then one day you check and the battery has been dead for who knows how long. That happened to me several times before I set this up.

Now, when any device drops below 20%, I get a notification that tells me exactly which device needs attention.

alias: Low Batteries Notification
description: ""
triggers:
  - trigger: time
    at: "10:00:00"
conditions: []
actions:
  - variables:
      low_batteries: >
        {% set ns = namespace(list=[]) %} {% for s in states.sensor
            | selectattr('attributes.device_class', 'eq', 'battery')
            | rejectattr('entity_id', 'eq', 'sensor.living_room_air_purifier_filter_life')
            | selectattr('state', 'is_number') %}
          {% if s.state | float < 20 %}
            {% set ns.list = ns.list + [s.attributes.friendly_name | replace(' Battery', '') ~ ' is at ' ~ s.state ~ '%'] %}
          {% endif %}
        {% endfor %} {% set msg = ns.list | join('\n') %} {{ msg[:252] ~ '...'
        if msg | length > 255 else msg }}
    enabled: true
  - condition: template
    value_template: "{{ low_batteries | length > 0 }}"
    enabled: true
  - action: notify.mobile_app_juans_iphone
    data:
      title: Low Batteries
      message: "{{ low_batteries }}"
      data:
        url: /lovelace/battery-maintenance
mode: single

How It Works

The automation runs every day at 10 AM. In the action section, a variable called low_batteries loops through all battery devices, filters out anything not reporting a real number (like unavailable or unknown), and builds a list of every device sitting below 20%.

There is also a line that excludes one of my air purifiers because it reports filter life as a battery attribute. Without that exclusion, it would show up in every notification.

The final output is a single formatted string, one device per line. If the list is long, it truncates at 252 characters and adds an ellipsis so you know there is more.

Before sending the notification, a condition checks whether low_batteries contains at least one item. This is important. Without it, the automation would send you an empty notification on days when everything is fine. With the condition in place, if there is nothing below 20%, it simply stops.

The last action sends the notification. Tapping it takes you straight to a battery maintenance dashboard in Home Assistant.

3. Phone Charging Light Indicator

My iPhone charger is on my desk right next to the Home Assistant Voice PE. When I connect my phone to the charger, the LED ring on the Voice PE turns yellow. When I unplug it, the light turns off. When the battery hits 90%, the light turns green as a visual cue that it’s at a good level and ready to unplug. And if I leave it connected all the way to 100%, the light turns off automatically.

Why iOS Shortcuts Instead of the Companion App

You could use the battery sensors in the Home Assistant companion app for this, but I find them unreliable. The workaround I use instead is the Shortcuts app on iOS. It is rock solid.

Setting Up the Shortcuts

Charging shortcut: This shortcut checks whether the phone is connected to the home Wi-Fi network. That check is important because you don’t want the automation triggering when you’re charging in the car or somewhere else. If the phone is on the home network and charging, the shortcut fires a charging event in Home Assistant. If the phone is disconnected from the charger or the battery is at 100%, it fires a not_charging event instead.

Under Automations in the Shortcuts app, a charger automation runs immediately without confirmation when the phone connects or disconnects from the charger. The action is set to run that shortcut.

Battery state shortcut: This shortcut checks the current battery level. If the battery is between 90 and 99%, it sends a battery_90 event to Home Assistant. Otherwise it sends battery_100. Two separate automations in Shortcuts handle this: one triggers when the battery goes above 90%, and the other when it reaches 100%.

The Home Assistant Automation

alias: iPhone charging Voice PE light
description: ""
triggers:
  - trigger: event
    event_type: iphone_charging
    id: iphone_charging
  - trigger: event
    event_type: iphone_not_charging
    id: iphone_not_charging
  - trigger: event
    event_type: iphone_battery_90
    id: iphone_battery_90
  - trigger: event
    event_type: iphone_battery_100
    id: iphone_battery_100
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - iphone_charging
        sequence:
          - action: light.turn_on
            metadata: {}
            target:
              entity_id: light.voice_pe_led_ring
            data:
              rgb_color:
                - 255
                - 229
                - 0
      - conditions:
          - condition: trigger
            id:
              - iphone_not_charging
              - iphone_battery_100
        sequence:
          - action: light.turn_on
            metadata: {}
            target:
              entity_id: light.voice_pe_led_ring
            data:
              rgb_color:
                - 255
                - 255
                - 255
          - action: light.turn_off
            metadata: {}
            target:
              entity_id: light.voice_pe_led_ring
            data: {}
      - conditions:
          - condition: trigger
            id:
              - iphone_battery_90
        sequence:
          - action: light.turn_on
            metadata: {}
            target:
              entity_id: light.voice_pe_led_ring
            data:
              rgb_color:
                - 0
                - 255
                - 0
mode: single

The automation listens for four events fired from iOS Shortcuts and uses a Choose action to respond to each one. Once it’s set up, it just runs. You connect your phone and the light does its thing.

4. No Doorbell Motion Alert When the Front Door Opens

If you have a doorbell camera, you have probably had this happen. You walk out your front door, your phone buzzes with a motion alert, and it’s just you. That notification is not useful.

This automation handles that by disabling doorbell motion detection when you are walking out, but only when walking out, not when walking in.

alias: Disable doorbell notification when entrance door is opened
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.ent_door_sensor_opening
    to:
      - "on"
conditions: []
actions:
  - if:
      - condition: template
        value_template: >-
          {{ (as_timestamp(now()) -
          as_timestamp(states.binary_sensor.ent_doorbell_motion.last_changed)) <
          30 }}
    then: []
    else:
      - action: switch.turn_off
        metadata: {}
        target:
          entity_id:
            - switch.ent_doorbell_detections_person
        data: {}
      - delay:
          hours: 0
          minutes: 3
          seconds: 0
          milliseconds: 0
      - action: switch.turn_on
        metadata: {}
        target:
          entity_id:
            - switch.ent_doorbell_detections_person
        data: {}
mode: single

How It Distinguishes Walking In from Walking Out

The automation triggers when the front door is opened. Before it does anything, it runs an if statement with a template condition that checks when motion was last detected on the doorbell.

If motion was detected in the last 30 seconds, the automation does nothing. That covers the walking-in scenario: the doorbell sees you approaching, motion is detected, you open the door, and detection stays active.

If no motion was detected in the last 30 seconds and the door opens, that means someone is walking out. The automation disables motion detection on the doorbell, waits 3 minutes, then turns it back on.

Once you set this up, you pretty much forget it’s there.

5. Adaptive Lighting Based on Time of Day

Most people set up a lighting automation early on when building a smart home. This version adjusts brightness and color temperature based on the time of day.

Here’s how mine works. During the day, lights turn on at 100% brightness with a daylight color temperature. In the early evening after sunset, they go to 80% brightness with a soft white temperature. Late at night, brightness drops to 35% and holds the soft white temperature.

Why Use a Script for the Logic

To make this work cleanly, I started by creating a script that holds the action sequence. I find it useful to separate the logic into a script when the action sequence is long or when you might want to reuse it in another automation. It also makes edits easier without touching the automation itself.

sequence:
  - choose:
      - conditions:
          - condition: sun
            before: sunset
            after: sunrise
        sequence:
          - action: light.turn_on
            metadata: {}
            data:
              color_temp_kelvin: 5000
              brightness_pct: 100
              transition: 1
            target:
              entity_id: light.lr_light
      - conditions:
          - condition: sun
            after: sunset
          - condition: time
            before: "22:30:00"
            enabled: true
        sequence:
          - action: light.turn_on
            metadata: {}
            data:
              color_temp_kelvin: 4000
              brightness_pct: 80
              transition: 1
            target:
              entity_id: light.lr_light
      - conditions:
          - condition: time
            after: "22:30:00"
            before: "05:00:00"
        sequence:
          - action: light.turn_on
            metadata: {}
            data:
              color_temp_kelvin: 4000
              brightness_pct: 35
              transition: 1
            target:
              entity_id: light.lr_light
alias: Living room light adaptive lighting
description: ""

The script uses a Choose action with three options.

Option 1 uses the Sun condition, set to after sunrise and before sunset. When that condition is met, it turns the lights on at 100% brightness and 5,000 Kelvin. The transition is set to 1 second for a smooth change.

Option 2 uses two conditions: after sunset and before 10:30 PM. When both are met, the lights go to 80% brightness and 4,000 Kelvin, also with a 1-second transition.

Option 3 uses the Time condition set to after 10:30 PM and before 5 AM. When this is met, it sets brightness to 35% and keeps the color temperature at 4,000 Kelvin.

Automation 1: Trigger on Light State Change

alias: Adaptive lighting
description: ""
triggers:
  - trigger: state
    entity_id:
      - light.lr_light
    to:
      - "on"
    from:
      - "off"
conditions: []
actions:
  - action: script.living_room_light_adaptive_lighting
    metadata: {}
    data: {}
mode: single

The automation triggers when the light changes from off to on, then runs the adaptive lighting script. Using the light state as the trigger covers both Home Assistant and a physical button.

Automation 2: Handle the Sunset Transition

What about when the light is already on and the time of day changes? For that, there is a second automation. The moment that mattered most to me was the transition right after sunset.

alias: Adaptive lighting 2
description: ""
triggers:
  - trigger: sun
    event: sunset
    offset: 0
conditions:
  - condition: state
    entity_id: light.lr_light
    state:
      - "on"
actions:
  - if:
      - condition: template
        value_template: "{{ state_attr('light.lr_light', 'brightness') | int(0) > 204 }}"
    then:
      - action: light.turn_on
        metadata: {}
        data:
          color_temp_kelvin: 4000
          brightness_pct: 80
          transition: 10
        target:
          entity_id: light.lr_light
mode: single

This automation uses the Sun trigger set to sunset. A state condition confirms the light is already on. Then, because I didn’t want the brightness jumping up if I already had it set lower, an if statement checks whether the current brightness is above 80%. If it is, it adjusts to 80% brightness and 4,000 Kelvin with a 10-second transition, which keeps the change gradual.