Notification with entity name not working

Configuration
1

I’m trying to setup a notification to change my door lock battery if it goes below 20%. However, I want the notification to include which lock it is actually low. Looked around the examples and they all seem to point to {{ trigger.name }} but it’s not working. The notification comes through but the entity name string is not being substituted in. Can anyone provide some guidance?

alias: Yale Lock Battery Low
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.front_door_battery
    below: 20
  - trigger: numeric_state
    entity_id:
      - sensor.kitchen_door_battery
    below: 20
conditions: []
actions:
  - action: notify.mobile_app_iphone
    metadata: {}
    data:
      message: Battery Low - {{ trigger.name }}
mode: single
2 
{{ trigger.to_state.attributes.friendly_name }}
3

Tried it, but now the notification is not coming through.

4

How did you test the automation?

If you tested it with the Run command then it’s not an effective test for this particular application.

The Run command only executes the automation’s actions, not its triggers. Your notify action refers to the trigger variable which only exists when the automation is triggered by one of its triggers. Otherwise, it’s undefined.

Reference

Numeric State Trigger - Trigger properties

5

Gotcha. That makes sense.

6

I want to change it so that it’d nag me to about the battery. Just to test I changed the trigger to time_pattern that fires every minute. However, it doesn’t seem to be triggering the notification at all anymore. Furthermore, if I move the entities to the conditions field, I’m guessing I need to change the template for the entity names?

alias: Yale Lock Battery Low
description: ""
triggers:
  - trigger: time_pattern
    minutes: /1
conditions:
  - condition: or
    conditions:
      - condition: numeric_state
        entity_id: sensor.front_door_battery
        below: 20
      - condition: numeric_state
        entity_id: sensor.kitchen_door_battery
        below: 20
actions:
  - action: notify.mobile_app_iphone
    metadata: {}
    data:
      message: Battery Low - {{ trigger.to_state.attributes.friendly_name }}
mode: single
7

Your new automation will only run if one of those sensors is actually reporting below 20. Is it?

The new automation also has no trigger.to_state because the trigger is not a state trigger.

Finally, the original automation you posted will only run when the state goes from above 20 to below 20. If the hardware is reliable, that will happen exactly once (until you replace the battery and it drops down to 20 again). If you want the automation to nag you, presumably you want it to do so more than once per battery replacement cycle—so what you want is probably a version of the time_pattern trigger set to fire as often as you want to be nagged, with the conditions correctly specified.

Is any of this information helpful?

8

Yes I’d like it to nag as often as I want, which I can adjust via the time_pattern. As you said, the original version will only notify when it went from above 20 to below 20. Which will only happen once, which I don’t want to miss changing the battery for. That said, if I’m to go with the new version, how do I make it notify and state which entity is low on battery?

9

With the current approach of using a time_pattern trigger with conditions, you will need an if: statement in your automation’s action block to check the individual battery states. In a way, it might seem redundant with the conditions block where you are already checking the inequality, but the conditions block only controls whether the automation runs. Once it runs, it needs to again consult the state or the batteries to figure out which battery/ies are low.

Alternatively, you can have a separate automation (with its own conditions block) for each battery.

10

Got it. Thanks.

11

Other options:

  1. Use the original automation, but put the notification action in a Repeat action with a delay.
  2. Alert integration
12

Your automation will trigger 525600 times a year to detect potentially 2 instances of “low battery”?

I suggest creating a Trigger-based Template Binary Sensor that uses a Numeric State Trigger to detect when the battery level decreases below 20 plus another trigger as backup to handle the rare possibilty that the Numeric State Trigger is missed.

The “backup trigger” can fire when some sort of occasional, benign event occurs (like when automations are reloaded or even when a door opens). The template checks both battery levels and if either are below 20, sets the state to on.

The Alert integration monitors the Trigger-based Template Binary Sensor’s state and, when on, warns you repeatedly (plus it provides better control of the alerting behavior).

Example of Trigger-based Template Binary Sensor

template:
  - trigger:
      - trigger: numeric_state 
        entity_id:
          - sensor.front_door_battery
          - sensor.kitchen_door_battery
        below: 20
      - trigger: time
        at: 08:00:00
    binary_sensor:
      - name: Low Battery Detector
        state: >
          {{ ['sensor.front_door_battery', 'sensor.kitchen_door_battery']
           | map('states') | map('int', 0) | min < 20 }}

Example Alert integration

# Example configuration.yaml entry
alert:
  low_battery:
    name: Low Battery Detected
    entity_id: binary_sensor.low_battery_detector
    state: "on"
    repeat: 5
    can_acknowledge: true
    notifiers:
      - mobile_app_iphone
13

I think that time_pattern trigger was just to debug.

14

I agree base off this statement!

1 Like
15

It appears the OP intends to use a Time Pattern Trigger.

They want it because of a concern that the Numeric State Trigger might fail to fire.

If the intent is to reduce the polling frequency to once an hour, that’s still 8760 times a year just to mitigate the unlikely possibility that a Numeric State Trigger will fail to trigger.

Plus if the goal is to send repeated reminders, its frequency is currently tied to the Time Pattern Trigger’s frequency. Ideally it should be managed separately (such as with the Alert integration).

16

Okay, they can reduce the time_pattern.

Once every day or two seems appropriate. Or whatever OP needs.

I don’t see the benefit of introducing a whole other integration to solve this simple problem.

17

The Time Pattern Trigger isn’t needed at all. I described a more efficient alternative in my previous post.

18

One that requires the use of a whole new integration.

You’re not wrong. The OP can pick the appropriate solution.

19

True but I didn’t see a constraint that it must be done exclusively with an automation.

It’s a few lines of YAML that provides superior functionality and control of the notification process. It decouples the task of detecting a low-battery condition from the task of repeatedly reporting it (along with the ability to acknowledge and dismiss it).

FWIW, Didgeridrew already suggested the use of the Alert integration.

1 Like
20

Yes, I agree with that.

Still, the beauty of automations in HA, in my own opinion, is that they can be very ad hoc. I tend to overthink things.

Either way, your point is valid. It might ultimately be the OP’s best solution, too.