Send Notification for Battery Level

Blueprints Exchange
11

Hi,

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

Screenshot 2020-12-16 at 14.30.57
Screenshot 2020-12-16 at 14.30.572164×1212 177 KB

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/__init__.py:373
Integration: Automation ([documentation](https://www.home-assistant.io/integrations/automation), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+automation%22))
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.

12

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’
^

13

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

2 Likes
14

Thanks, it works :+1:

15

This is very nice. Any chance of some changes to support notification groups: https://www.home-assistant.io/integrations/notify.group/

1 Like
16

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
17

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.

18

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:

automation:
  trigger:
    - platform: state
      entity_id:
        - sensor.one
        - sensor.two
        - sensor.three
1 Like
20

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

21

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.

22

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

  trigger:
    - platform: state
      entity_id:
        - sensor.one
        - sensor.two
        - sensor.three

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

Neither of the following two examples work:

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

  trigger:
    - 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:

  trigger:
    - 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.

23

Well , that means that for using this blueprint you have to specify a “blueprint call” as long as the very blueprint:

  - alias: "Check all my batteries"
    description: ''
    use_blueprint:
      path: check_batteries.yaml
      input:
        first_sensor: sensor.one
        second_sensor: sensor.two
        third_sensor: sensor.three
        ..
        tenth_sensor: sensor.ten

So my point - there is no need to create a blueprint, use a usual automation:

  trigger:
    - platform: state
      entity_id:
        - sensor.one
        - sensor.two
        ...
        - sensor.ten

I do agree that the blueprint in this thread is very useful for study blueprints but will my all respect to the author I think that a usual automation (not a blueprint) is simpler.

24

I agree. In most cases, it will be simpler, shorter, and possibly more efficient as well.

However, there are users who, for whatever reason, are unable to create their own automations (even with the Automation Editor). Blueprints allow them to use other people’s automations.

Of course, it’s always been possible to use someone else’s automation. However, you had to change all the entities in their automation to make it work on your system. That process involved editing the automation’s text (YAML).

Blueprints let the user select the entities from lists in the UI so they never have to see or edit the actual automation. This is an advantage for new users. However, it means more work for the automation’s author because they have to convert it to a blueprint (and that process might require making the automation larger and more complicated).

25

Yes, it would be a simple automation. I used it to be able to easily duplicate it across multiple battery devices and then if I later need to update notification, a change in one place would change them all. Hopefully in the future blueprints will allow multiple selections in a list of a trigger similar to a target, then it would be much more helpful.

26

Personally, I find an automation only works well for this particular problem if the device you’re getting an alert for is your phone. Due to their power draw and usage phone battery level goes up and down quickly. Generally if you get an notification about your phone being at 15-20% or less you’re gonna go plug it in right away.

But for all the other IOT devices around my house, a low battery alert most likely isn’t urgent. I know I have to replace it but I’m not going to drop what I’m doing to go do so. Most of these devices take months or more to deplete the battery. So I prefer an alert since that will continue to bug me until I solve the problem.

For anyone interested, I did a quick write up of my own solution and shared it as a package here (didn’t want to clog up this thread with it). Can’t make it a blueprint unfortunately since its not an automation.

27

I had a quick look at the multiple inputs and found the below solution to work. This was for an Alexa notification, but should also work in your case.

blueprint:
  name: Multiple test
  description: 'Test for multiple selections.'

  domain: automation
  input:
    in1:
      name: Input1
      selector:
        entity:
          domain: media_player
    in2:
      name: Input2
      selector:
        entity:
          domain: media_player
    in3:
      name: Input3
      selector:
        entity:
          domain: media_player
    in4:
      name: Input4
      selector:
        entity:
          domain: media_player
mode: single

variables:
  input1: !input in1
  input2: !input in2
  input3: !input in3
  input4: !input in4
  inputs: " {{ input1 }}, {{ input2 }}, {{ input3 }}, {{ input4 }}"

trigger:
- platform: state
  entity_id: !input 'in1'
  from: "off"
  to: "on"

action:
  - service: persistent_notification.create
    data:
      message: "{{ inputs }}"
      title: "Test"
  
  - service: notify.alexa_media
    data:
      target: "{{ inputs }}"
      message: test, test, test
      data:
        type: tts
28

Also if you add Default: “” to your inputs it allows you to put in less than the maximum number.

echo_device2:
      name: Second Alexa
      description: The Second Alexa device to make the announcement on. Make a comma seperated list to announce on multiple devices.
      selector:
        entity:
          domain: media_player
      default: ""
29

All good till someone comes around needing 1 more device than you have inputs available in the blueprint :slight_smile: Hopefully in the future there is a selector solution for inputs that would solve this

30

@CentralCommand Everyone will have different preferences, let’s not lose sight that the blueprints are a tool to share your automations with someone else that may want to do the same thing. You could go through every one and decide it doesn’t work for you or you prefer it to be another way due to the large flexibility available for each scenario.

1 Like
31

Great Job! :slight_smile:saved me a lot of work figuring something ou myself.