Home Assistant Blueprint: Low battery level detection & notification for all battery sensors with Time Pattern

low-battery-level-detection-notification-for-all-battery-sensors-with-time-pattern.yaml

blueprint:
  name: Low battery level detection & notification for all battery sensors with Time Pattern Detection
  description: Regularly test all sensors with 'battery' device-class for crossing
    a certain battery level threshold and if so execute an action. Modified version to allow for Time-Pattern based detection.
  domain: automation
  input:
    threshold:
      name: Battery warning level threshold
      description: Battery sensors below threshold are assumed to be low-battery (as
        well as binary battery sensors with value 'on').
      default: 20
      selector:
        number:
          min: 5.0
          max: 100.0
          unit_of_measurement: '%'
          mode: slider
          step: 5.0
    hours:
      name: Hour (time pattern)
      description: When to trigger, '*' for any hour, 0-23 for the specific hour of the day. (or other time-pattern)
      default: '*'
      selector:
        text:
    minuites:
      name: Minute (time pattern)
      description: When to trigger, '*' for any hour, 0-59 for the specific minute of the hour. (or other time-pattern)
      default: '*'
      selector:
        text:
    seconds:
      name: Second (time pattern)
      description: When to trigger, '*' for any hour, 0-59 for the specific second of the minute. (or other time-pattern)
      default: '1'
      selector:
        text:
    day:
      name: Weekday to test on
      description: 'Test is run at configured time either everyday (0) or on a given
        weekday (1: Monday ... 7: Sunday)'
      default: 0
      selector:
        number:
          min: 0.0
          max: 7.0
          mode: slider
          step: 1.0
    exclude:
      name: Excluded Sensors
      description: Battery sensors (e.g. smartphone) to exclude from detection. Only entities are supported, devices must be expanded!
      default: {entity_id: []}
      selector:
        target:
          entity:
            device_class: battery
    actions:
      name: Actions
      description: Notifications or similar to be run. {{sensors}} is replaced with
        the names of sensors being low on battery.
      selector:
        action: {}
  source_url: https://gist.github.com/sbyx/1f6f434f0903b872b84c4302637d0890
variables:
  day: !input 'day'
  threshold: !input 'threshold'
  exclude: !input 'exclude'
  sensors: >-
    {% set result = namespace(sensors=[]) %}
    {% for state in states.sensor | selectattr('attributes.device_class', '==', 'battery') %}
      {% if 0 <= state.state | int(-1) < threshold | int and not state.entity_id in exclude.entity_id %}
        {% set result.sensors = result.sensors + [state.name ~ ' (' ~ state.state ~ ' %)'] %}
      {% endif %}
    {% endfor %}
    {% for state in states.binary_sensor | selectattr('attributes.device_class', '==', 'battery') | selectattr('state', '==', 'on') %}
      {% if not state.entity_id in exclude.entity_id %}
        {% set result.sensors = result.sensors + [state.name] %}
      {% endif %}
    {% endfor %}
    {{result.sensors|join(', ')}}
trigger:
- platform: time_pattern
  hours: !input 'hours'
  minutes: !input 'minuites'
  seconds: !input 'seconds'
condition:
- '{{ sensors != '''' and (day | int == 0 or day | int == now().isoweekday()) }}'
action:
- choose: []
  default: !input 'actions'
mode: single

Substituted the Time (single run at that time) for Time Pattern, where you can specify to run multiple times over the day (which is the case I need in my setup).

Changed default on the 'seconds' to 1, as with all '*', means this would run every seconds, every minute, every hour. Now it will run on second '1' every minute.

Nice adoption! Thanks for this. A question regarding wording for minutes and second settings Descriptions for these settings read in part "When to trigger, '*' for any hour, 0-59 for the specific ". In the case of minutes, should the word hour not be replaced with minute, and in the case of seconds, should it not be replaced with seconds?

EDIT: Just noticed an issue that needs to be addresses. I've set the attributes to perform a check on the 55 minute mark. The automation (Blueprint) discovered a device with a low battery. It performed as it should have, sending a message to my cellphone. Problem is, it continued to send the same message every two seconds until the time passed 55 minutes. I received 30 messages on my cell. Each, 2 seconds apart. Is this the intended behavior of the blueprint? If yes, how do I configure the automation such that this behavior doesn't occur?

Okay, figured out the problem! With hours and seconds set to "*", the action is fired every other second. To get around this I set the seconds to 1. Now the message is sent once, 1 second after the specified minutes.

Hey rclackwell
I had indeed done both of those updates for the description, and also set the default for second to ‘1’ - should be revision 16. (as I found the exact same thing, I guess time-patterns is not the same as typical cron).
I guess you had an earlier download… or I forgot to publish the changes? if you have a moment could you re-check the file (in gist.github.com) and let me know if you see the updates?
Cheers
Matt

Hi Matt,

The blueprint I’m using came from git yesterday. It matches what I see posted today. I see there is a default of 1 for seconds. Perhaps the blueprint shouldn’t allow “*” to be utilized for seconds? Only allow 0-59. Now that I understand how time works, I don’t see a situation where the wildcard would/could be used. Eliminating the wildcard choice would eliminate the problem I (and you) saw earlier.

As for descriptions; the minutes and second description still read in part "When to trigger, ‘*’ for any hour , 0-59 for the specific ". In the case of minutes, should the word hour not be replaced with minute , and in the case of seconds , should it not be replaced with seconds ?

Hi Matt,

Noticed one more thing - When I load the blueprint into Studio Code Server for editing, an error is reported on line 61. The {}'s are not required after "action:"