Send Notification for Battery Level

Sends a notification to the mobile app when a specified batter sensor drops below a specified value


Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

  name: Battery Level Notification
    Send a notification to a device when battery drops below a specified
  domain: automation
      name: Entity
          domain: sensor
          device_class: battery
      name: Battery level
      description: What level the device should be to trigger the notification.
      default: 50
          min: 1.0
          max: 100.0
          unit_of_measurement: "%"
          step: 1.0
          mode: slider
      name: Device to notify
        Device needs to run the official Home Assistant app to receive
          integration: mobile_app
      name: Message
      description: 'Default: " {{ entity_name }} battery has dropped to {{ battery_level }}% "'
      default: " {{ entity_name }} battery has dropped to {{ battery_level }}% "
  - platform: numeric_state
    entity_id: !input "battery_entity"
    below: !input "battery_level"
  entity_name: "{{ states[trigger.entity_id].name }}"
  battery_level: "{{ states(trigger.entity_id) }}"
  domain: mobile_app
  type: notify
  device_id: !input "notify_device"
  message: !input "message"

Minor correction:

Thanks, corrected it now

Pretty cool.


One wy this could be improved is if multiple sensors could be added to the same one. I guess I can check and add in yaml. but it would have been easy peasy (for me) to just add more and more. Not sure about the code implications though. Im not a coder.


Not sure it is possible to add a list or it is beyond my knowledge so I created an automation for each entity that I check from the same blueprint. I have also noticed that depending on the device that I need the check for different battery levels, for example my Z-Wave smoke detectors audibly report low battery when they show 80% but my Z-Wave lock works down to about 40% so the flexibility is better in my case.

Added a default message with template to show the entity name and battery level

wow this is amazing, these blueprints make it so easy!!! thank you for sharing this <3

Thanks much… I use inexpensive Zigbee PIR motion sensors… if the battery dies completely, they lose their pairing, which is a royal pain to set up again. This way I can catch them before the battery dies, which is a huge help.

Does the App expose options for the notification (eg, persistent notification) for really important or critical battery level warnings? It would be AWESOME to have it so I can’t swipe it away when it gets below a set percentage.

Hi! Is it possible to modify the blueprint to use a personal Telegram bot to be used for the notification?



This is the first time me trying out blueprints and I have one issue. Maybe someone can help me out to understand where could be the problem.

I have chosen my Tradfri on/off switch as the entity when I was setting up automation:
Used entity: sensor.tradfri_on_off_switch_main_battery_level
Which has state: 34
And state attributes:

event_id: tradfri_on_off_switch_main
unit_of_measurement: '%'
friendly_name: tradfri_on_off_switch_main Battery Level
device_class: battery

Then for the test, I executed the automation and nothing happened. I know that notifications work on my phone, as I have one notification sent when my HA restarts.

This is what I found out in the logs section:

Logger: homeassistant.components.automation.battery_level_notification_tradfri_on_off_switch
Source: components/automation/
Integration: Automation ([documentation](, [issues](
First occurred: 2:24:08 PM (1 occurrences)
Last logged: 2:24:08 PM

Error rendering variables: UndefinedError: 'trigger' is undefined

P.S. I wanted to upload 3x images to better describe the situation, but as a new user I was limited to 1, so I tried to quite some attributes of the entity and logs.

I have the same problem

When i look in this file /config/blueprints/automation/jazakrzewski/send-notification-for-battery-level.yaml with file editor it complains about

unknown tag !<!input> at line 39, column 37:
entity_id: !input ‘battery_entity’

To test you should manually change the state value from the developer tools, the execute won’t work


Thanks, it works :+1:

This is very nice. Any chance of some changes to support notification groups:

I was able to get it extended to pick 10 devices.

Could probably extend it even further. great job on it, as it made it pretty easy to extend thanks to the variables!

1 Like

Yes, just a copy and paste and more could be added as long as the check is at the same percentage. Would be nice if one day that automations could have a multiple selection function for sources for the trigger like exists with target for actions.

Regarding “check 10 batteries”.

I do not think it is the best solution.
Blueprints are invented to decrease a volume of code.
The blueprint for 10 devices is too large.
May be it is better to use ONE automation which covers all batteries, like this:

    - platform: state
        - sensor.two
        - sensor.three
1 Like

How do we implement this in the blueprint above? Sorry I’m new to using blueprints.

I do not think that we should implement it as a blueprint - I think it may be a usual automation.
I am also a newbie and it would be great to get an opinion of some expert.

You are correct. Ideally, the automation should use a State Trigger that looks like this where entity_id is given a list of entities:

    - platform: state
        - sensor.two
        - sensor.three

Unfortunately, a blueprint’s selectors cannot be inserted into a list like that.

Neither of the following two examples work:

    - platform: state
        - !input first_sensor
        - !input second_sensor
        - !input third_sensor
    - platform: state
      entity_id: !input first_sensor, !input second_sensor, !input third_sensor

That’s why you see the State Trigger used this way in a blueprint:

    - platform: state
      entity_id: !input first_sensor
    - platform: state
      entity_id: !input second_sensor
    - platform: state
      entity_id: !input third_sensor

My personal opinion is that if someone is capable of composing an automation, the end-result will be more compact than an automation adapted for use as a blueprint. Future versions of the blueprint feature may change that but, for now, that’s the situation.