Version 2 sneak peak

[andrew-codechimp]

Thought I'd share a sneak peak of what will be version 2, which adds some big enhancements that have been mentioned in various discussions.
Still in very early dev so lots to test/fix/tidy but I have the basics working.

A new battery entity that echo's the real battery but adds all the attributes of Battery Notes, making it easier to create dashboard cards/templates/automations that cross between the battery and note entities.

A threshold, globally defaulted in the configuration.yaml, if omitted set to 10%, but overridden per device which sets a binary_sensor.battery_low entity true/false based on the threshold.

Still thinking about echo'd battery default name and whether to auto hide the existing battery, much like the stock "Change device type of switch" helper does.

[ThomDietrich]

Amazing! Looking forward to this :)

May I suggest to keep all additional entities as an option? For the "last replaced" we agreed on a configuration option, however, thinking about it, these could also just be disabled by default.

[andrew-codechimp]

If it's just a new sensor/attribute I'll not be adding options as they can easily be ignored but anything that could get in the way/change default functionality I'll definitely make an option.
Last Replaced had that button which you couldn't undo if pressed accidentally and would cause confusion so that's why it got an option.

[danielbrunt57]

Awesome progress!

[nicknol]

Awesome. Amazing.
Thanks a ton for 'Battery Notes' and the sneak peak for version 2.0.

Is it still time to add wishes to the list? If yes, I would appreciate to have an in-built automation that detects a battery change by e.g. an increase of the SOC (state of charge) aka battery state. The increase of SOC would be ideally configurable as an attribute or entity of the battery note.
This automation would avoid remembering to press the button 'last_replaced", instead it would press the button automatically.
I tried to write an automation for this - but failed. I could detect the battery replacement (battery state entity) but wasn't able to get the button (different entity) pressed.

[nicknol]

wow - a really in-depth and open-minded discussion. I am impressed (as a kind-of normal user).

I like the idea of having more than one event, the thresholds and the gradient should be configurable. e.g. reaching 60% could mean for some batteries there a close to be empty (as Daniel wrote) or some (recharable) batteries have been replaced (I have some cases), here the gradient could make the difference.

I would like to be able to react to a change of the battery-level of e.g. +15% to trigger the battery_replaced service, this would be useful if I change the batteries of many/all sensors in my house before going on vacation. Then I would even replace batteries having a battery-level of 50%, in order to survive my absence.
Makes sense?

[andrew-codechimp]

Kind of normal users come up with the best use cases so it really helps me.
You are right, we'll need a battery jump event to better handle replacement.
I'll work on the name and suitable triggers but shouldn't be hard now I have the low battery done.

[ThomDietrich]

I didnot at all think of events. The use cases are indeed perfect for events. Looking forward to this! Cheers

[danielbrunt57]

@andrew-codechimp: Here's a draft readme for the docs on what I have so far (just don't install this branch, I commit/push often as I work on multiple machines and it's usually broken code) https://github.com/andrew-codechimp/HA-Battery-Notes/blob/watcher/docs/events.md

I'm just wondering how I'd go about giving this branch a whirl but not sure the best way to do it. Or, are you close to a beta release (V3??) with events?

[andrew-codechimp]

I'd really not advise running any code in a branch, I swap between a laptop on the sofa and a desktop depending on the mood so use the branch as my sync between the machines so there is regularly broken code or even notes that force it to break to remind myself where I am, as an example today it will make bad entity_registry entry names so your HA will be littered with junk.
Be patient, it will be coming soon as a beta in HACS 😄

[danielbrunt57]

"If battery level becomes 100, and was below 100 before OR unavailable before, then...

I started working on tracking battery replacement dates not long before recently discovering this integration. I was using a variable I created using the Variables+History HACS integration and here is the automation I was testing:

alias: Track Battery Replaced Dates
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.front_door_lock_battery_level
      - sensor.garage_2_battery_level
      - sensor.garage_3_battery_level
      - sensor.garage_door_battery_level
      - sensor.laundry_room_battery_level
      - sensor.garage_door_lock_battery_level
      - sensor.4_in_1_multisensor_battery_level
      - sensor.front_door_multisensor_battery_level
      - sensor.garage_1_battery
      - sensor.office_battery
      - sensor.bedroom_battery
      - sensor.kitchen_battery
      - sensor.bathroom_battery
      - sensor.button_1_battery
      - sensor.landing_2_battery
      - sensor.front_porch_battery
      - sensor.landing_1_5_battery
      - sensor.living_room_battery
      - sensor.powder_room_battery
      - sensor.south_patio_battery
      - sensor.kitchen_mijia_battery
      - sensor.outside_weather_battery
      - sensor.southeast_patio_battery
      - sensor.southwest_patio_battery
      - sensor.rear_smart_timer_battery
      - sensor.front_smart_timer_battery
      - sensor.phillips_hue_switch_battery
    above: 99
    for:
      hours: 0
      minutes: 0
      seconds: 10
    enabled: true
    id: Battery
  - platform: state
    entity_id:
      - input_button.update_battery_replacement_date
    to: null
    id: Button
condition:
  - condition: template
    value_template: >-
      {{ trigger.from_state is not none and trigger.from_state.state not in
      ['unavailable','unknown'] and trigger.from_state.state|float(0) < 100 and
      trigger.to_state.state|float(0) > 99 }}
    enabled: true
action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - Battery
        sequence:
          - service: variable.update_sensor
            data:
              attributes:
                "{{ trigger.entity_id }}": "{{as_timestamp(now()) | timestamp_custom('%Y-%m-%d') }}"
              replace_attributes: false
            enabled: true
            target:
              entity_id: sensor.batteries_replaced
          - service: notify.o365_email_daniel
            metadata: {}
            data:
              title: Battery Replacement triggered
              message: >-
                {{ trigger.entity_id }} changed from state {{
                trigger.from_state.state }} to state {{ trigger.to_state.state
                }}
            enabled: true
      - conditions:
          - condition: trigger
            id:
              - Button
        sequence:
          - service: variable.update_sensor
            data:
              attributes:
                "{{ states('input_text.battery_sensor') }}": "{{as_timestamp(now()) | timestamp_custom('%Y-%m-%d') }}"
              replace_attributes: false
            enabled: true
            target:
              entity_id: sensor.batteries_replaced
trace:
  stored_traces: 30
mode: single

You may find it useful!

[danielbrunt57]

I'm going to try this version for the condition:

{{ trigger.from_state is not none and trigger.from_state.state not in ['unavailable','unknown'] and trigger.to_state.state|float(0) > trigger.from_state.state|float(0) + 10 }}

I've also changed the trigger from numeric_state above 99 to just state:

platform: state
entity_id:
  - sensor.front_door_lock_battery_level
  - sensor.garage_2_battery_level
  - sensor.garage_3_battery_level
  - sensor.garage_door_battery_level
  - sensor.laundry_room_battery_level
  - sensor.garage_door_lock_battery_level
  - sensor.4_in_1_multisensor_battery_level
  - sensor.front_door_multisensor_battery_level
  - sensor.garage_1_battery
  - sensor.office_battery
  - sensor.bedroom_battery
  - sensor.kitchen_battery
  - sensor.bathroom_battery
  - sensor.button_1_battery
  - sensor.landing_2_battery
  - sensor.front_porch_battery
  - sensor.landing_1_5_battery
  - sensor.living_room_battery
  - sensor.powder_room_battery
  - sensor.south_patio_battery
  - sensor.kitchen_mijia_battery
  - sensor.outside_weather_battery
  - sensor.southeast_patio_battery
  - sensor.southwest_patio_battery
  - sensor.rear_smart_timer_battery
  - sensor.front_smart_timer_battery
  - sensor.phillips_hue_switch_battery
for:
  hours: 0
  minutes: 0
  seconds: 10
enabled: true
id: Battery

Result:

[danielbrunt57]

While thinking about an automation to trigger an automatic battery replaced date, I've been trying to figure out how to programatically determine if the battery sensor triggering the automation is part of the Battery Notes integration, then find that device and the matching button sensor. But Battery Notes does not appear when I enumerate the integrations configured by the UI.

In Refererence: How to enumerate entities belong to an integration? Petro presented this template but when I execute it, I do not see anything looking like Battery Notes.
{{ states | map(attribute='entity_id') | map('device_id') | reject('eq',None) | map('device_attr', 'identifiers') | map('list') | map(attribute='0') | map('list') | reject('eq', []) | map(attribute='0') | unique | sort }}

[ "accuweather", "alexa_media", "auto_backup", "bhyve", "cert_expiry", "dnsip", "environment_canada", "fordpass", "fully_kiosk", "hacs", "harmony", "hassio", "holiday", "holidays", "Home Assistant", "hyperhdr", "insteon", "ipp", "localtuya", "mobile_app", "mqtt","nest", "nodered", "nut", "opengarage", "openweathermap", "pfsense", "pushbullet", "samsungtv_smart", "scheduler", "season","sonoff", "spook", "spotify", "sql", "sun", "sun2", "systemmonitor", "tomorrowio", "tuya", "uptime", "waze_travel_time", "webostv", "workday", "zwave_js" ]

Any ideas?

[danielbrunt57]

I've managed to put this together:

{% set entity = "sensor.bathroom_battery" %}
{%- set device_id = device_id(entity) %}
{% if (device_id != None) %}
Manufacturer: {{ device_attr('a79617834365fd6c11997048e5b2711d', 'manufacturer') }}
Entity: {{ entity }}
Device ID: {{ device_id }}
{% for sensor in (device_entities(device_id) | select('search','button.*battery_replaced')) -%}
>> Battery Replaced button: {{ sensor }}
{%- endfor %}
All sensors:
{{ device_entities(device_id) }}
{% endif %}

and stripping out the informative stuff...

{% set entity = "sensor.bathroom_battery" %}
{%- set device_id = device_id(entity) %}
{% if (device_id != None) %}
{% for sensor in (device_entities(device_id) | select('search','button.*battery_replaced')) -%}
{{ sensor }}
{%- endfor %}
{% endif %}

Now to code that somehow into the automation...

[andrew-codechimp]

Rather than string mashing the entity id's you could use this which will be more reliable for when entity id's have changed

service: battery_notes.set_battery_replaced
data:
  device_id: "{{ device_id(trigger.entity_id) }}"

[ThomDietrich]

@andrew-codechimp this device_id: "{{ device_id(trigger.entity_id) }}" should go into documentation :) Btw why not make entity_id a direct option?

[danielbrunt57]

I just finished coming up with this.
It finds the matching button and presses it if it exists...

if:
  - condition: template
    value_template: >
      {%- set device_id = device_id(trigger.entity_id) -%} {%- if (device_id !=
      None) -%} {%- for sensor in (device_entities(device_id) |
      select('search','button.*battery_replaced')) -%} {{ states.sensor.state is
      defined }}{%- endfor -%}{% endif -%}
then:
  - service: button.press
    metadata: {}
    data: {}
    target:
      entity_id: >-
        {%- set device_id = device_id(trigger.entity_id) -%}{%- if (device_id !=
        None) -%} {%- for sensor in (device_entities(device_id) |
        select('search','button.*battery_replaced')) -%} {{ sensor }}{%- endfor
        -%}{% endif -%}

For your suggested service call, if I call it with an entity_id which was not added to battery notes, are there are negative effects?

[andrew-codechimp]

I know! I've just launched yesterday a proper documentation site which I fully intend having some example automations/blueprints.

I've been rather full on with the actual integration to take a breath and do some automations myself so you guys are ahead of me on actually using this for more than display!

Traversing the entity_id's to device and other entity_id's is messy, which is what I'm trying to tidy up as part of the super battery.

[andrew-codechimp]

For your suggested service call, if I call it with an entity_id which was not added to battery notes, are there are negative effects?

I'm guessing a log error, probably not a pretty one 😄
I'll do more testing around that as part of V2.

[danielbrunt57]

I got a green checkmark when I submitted one of my few non-battery_notes battery sensors and see nothing in HA logs...

[andrew-codechimp]

I should probably at least log that it didn't do anything.

@danielbrunt57 if ok with you I'll add your automation example but with the service call to the community examples, crediting yourself of course!

[danielbrunt57]

No problem! I'm only too happy to share when I can! I'm still trying to figure out the best way though...

[andrew-codechimp]

I'll hold off until you've tested some more, I don't want to create support headaches for you or me.

[andrew-codechimp]

Version 2.0 has just been released in beta and will probably stay there for a few weeks as this is a big lot of changes.

Thanks to those who've contributed to shaping these features, I hope I'll please at least most with the options available.

If you want to try this you will have to go into HACS/Battery Notes/Redownload and switch on Betas to see version 2

🚀 New Features

• A new Battery Plus sensor, it echo's the normal battery but has additional attributes from Battery Notes to make it easier to use in the ui and automations, you can optionally hide the original battery with a configuration setting.
• A Battery Low binary sensor, it uses a global default threshold (10%, changeable in configuration) to indicate when a battery is low, you can also manually configure a device in battery notes and set a specific threshold for each device.
• A Battery Threshold event which is fired when the battery goes low, or returns high. Useful for notification automations.
• A Battery Increased event which is fired when a battery increases by a certain percentage (25%, changeable in configuration). Useful for battery replaced automations.

Read the docs for how to get the most from these new features
Community Examples
Entities
Events
Configuration

[ThomDietrich]

Hey @andrew-codechimp my system still shows the additional decimal place, even though I believe to have seen something about that in the release notes some time ago... Did you look into these already?
#570 (reply in thread)

Thanks!!

[andrew-codechimp]

I added a new configuration option to handle this

battery_notes:
  round_battery: true

[ThomDietrich]

Working. Thank you, you are the best!

I am not sure who would want any digits for the percentage value, which anyhow is just an approximate. You probably have a good reason for the config option :)

Don't mind the "null". The device is unavailable since before I installed Battery Notes last.

[andrew-codechimp]

Great, worried I'd missed something.
Some of my own devices have digits for the percentage, it depends on the integration. I didn't want to lose precision by default, even though I switched it on as soon as I implemented it.

[ThomDietrich]

I see! :) Scientifically speaking it is not "precision" we are talking about here :) Your decimals are merely the result of division. Some developer missed to do his job in rounding the result.
An alternative implementation could look something like this: res = res if res%1 >= 0.01 else int(res) (simplified)

[danielbrunt57]

Have I mentioned yet that this new integration is "the greatest thing since slided bread!" for battery devices in HA?? I've purged my system of the very old and unmaintained Battery Alert Package by NotoriousBDG as I now have something vastly superior and as good as if not better than HomeSeer's SDJ-Health Plug-in which I used up until 3 years ago when I switched to HA.
One feature missing perhaps that SDJ-Health has is a notification if a device fails to wake up and send a battery report which could indicate the battery has died.

[danielbrunt57]

Here's an interesting one for you!
My illuminance sensor in the kitchen is a MiJia and it's reporting 0% battery but is still working fine!

[andrew-codechimp]

I don't think there's much I can do with bad reporting sensors, though I am going to look at devices dropping off totally and what I can do about those later. That will be post 2.0 though

[danielbrunt57]

No, that is pretty impossible! My Southeast Patio light sensor same make/model went from 100% to 0% last night and voltage was around 2800 mV. Just looked at it now to get the actual mV but now it reads 100% and 3081 mV. ¯_(ツ)_/¯

[ThomDietrich]

While on the topic of weird sensors (Andrew you will love that this is ZHA related 😄) https://community.home-assistant.io/t/battery-levels-over-100-for-ikea/618151/4

[andrew-codechimp]

Maybe I need an overly high Boolean just for ZHA 😃

[danielbrunt57]

To ∞ and beyond!

[danielbrunt57]

My new battery dashboard...

[ThomDietrich]

Works like a charm! I've added the last_reported_level only. The exact datetime is secondary assuming that we know the device went offline in the last 1-2 days...

type: custom:vertical-stack-in-card
title: Batteries
cards:
  - type: custom:auto-entities
    card:
      type: custom:battery-state-card
      secondary_info: '{attributes.battery_type_and_quantity}'
      bulk_rename:
        - from: ' Battery+'
        - from: ' Batterie+'
      card_mod:
        style: 'ha-card {border: none !important}'
    filter:
      include:
        - integration: battery_notes
          domain: sensor
          attributes:
            device_class: battery
          state: < 50
      exclude:
        - integration: mobile_app
        - name: Kostal-*
    sort:
      method: state
      numeric: true
  - type: custom:auto-entities
    card:
      type: custom:battery-state-card
      secondary_info: >-
        {attributes.battery_type_and_quantity} (Last known level:
        {attributes.battery_last_reported_level}%)
      bulk_rename:
        - from: ' Battery+'
        - from: ' Batterie+'
      card_mod:
        style: 'ha-card {border: none !important}'
    filter:
      include:
        - integration: battery_notes
          domain: sensor
          attributes:
            device_class: battery
          state: unknown
        - integration: battery_notes
          domain: sensor
          attributes:
            device_class: battery
          state: unavailable
      exclude:
        - integration: mobile_app
        - name: Kostal-*
    sort:
      method: state
      numeric: true
  - type: custom:auto-entities
    card:
      type: custom:battery-state-card
      secondary_info: '{attributes.battery_type_and_quantity}'
      bulk_rename:
        - from: ' Battery+'
        - from: ' Batterie+'
      card_mod:
        style: 'ha-card {border: none !important}'
    filter:
      include:
        - integration: battery_notes
          domain: sensor
          attributes:
            device_class: battery
          state: '>= 50'
      exclude:
        - integration: mobile_app
        - name: Kostal-*
    sort:
      method: state
      numeric: true

[andrew-codechimp]

Thanks for the updated yaml, I'm getting little time to do anything cool with these new features myself so I'll probably grab that.
Just like to check when someone specifically asks for something if I can close it off as a done feature and move onto the next 😄

[danielbrunt57]

Works like a charm! I've added the last_reported_level only. The exact datetime is secondary assuming that we know the device went offline in the last 1-2 days...

I tried your card code but am scratching my head as to why all but one of my icons are incorrect...

[ThomDietrich]

Just like to check when someone specifically asks for something if I can close it off as a done feature and move onto the next 😄

You've added exactly what I was hoping for. Thank you very much!

[ThomDietrich]

@danielbrunt57 two weird differences.

1. You do not have the one decimal point I am seeing (which I actually would like to get rid of
2. All your batteries without an icon have no space between number and unit. What's up with that?

[danielbrunt57]

in case you don't read the release notes (who does!) there's now a last_reported and last_reported_level attribute on Battery+ so you can tell whether a battery is likely dead when it's disappeared.

What I would love to achieve is the equivalent of the HS3 SDJ-Health plug-in's primary function which is:

• The main alert is for when a device dies, i.e. stops communicating

Now that you have the last_reported timestamp saved, if we could add a user configurable parameter "should report every xx days" (with an appropriate overall configurable number, or no alerting if unconfigured) then you might be able to raise an alert (i.e. trigger an event) that the device has not reported in on time. What do you think?

[ThomDietrich]

Always happy about useful out-of-the-box functionality. But help me out here, what's missing to accomplish this within a simple automation?

[andrew-codechimp]

Doing automations to cover all the batteries is trickier than an event based trigger I think is the main reason here.

[danielbrunt57]

@ThomDietrich Always happy about useful out-of-the-box functionality. But help me out here, what's missing to accomplish this within a simple automation?
@andrew-codechimp Doing automations to cover all the batteries is trickier than an event based trigger I think is the main reason here.

Exactly. The automation would need a hard-coded list of entities which brings us right back to the main feature of v2 using event based notifications in the first place.

The two entitied displaying correctly in the battery-state-card both originate from the Orbit B-hyve integration.
All the others are from Z-WaveJS, Zigbee2MQTT, Fully Kiosk Browser, Fordpass, or Mobile App.
I implemented round_battery: true from the git-go. I also implemented hide_battery: true straight away.

I tried removing round_battery: true and 'hide_battery: trueand then just added a basiccustom:battery-state-card` with no additional parameters and it's, well, still weird:

I then narrowed it down to those two entities both having an attribute battery_level: and none of the others do. I deleted that attribute on one of them via Dev Tools > States and it then displayed like all the others. I focused on the battery-state-card and went looking in HACS - it showed I had v3.1.6 but I re-downloaded it, refreshed the browser and all is well now!

[andrew-codechimp]

I have the last_reported event in dev now, decided to go with a service to trigger checks rather than implement my own timer, that way you can have fine control over when you want the check to happen.
Here's a preview of the docs for an example implementation.

[danielbrunt57]

Very nice!

[danielbrunt57]

My latest custom card handiwork...

[TheBisk]

type: custom:auto-entities
card:
  type: entities
  title: Low Batteries
  debug: false
  card_mod:
    class: inline-card
filter:
  include:
    - integration: battery_notes
      domain: sensor
      attributes:
        device_class: battery
      state: < 51
      options:
        type: custom:template-entity-row
        entity: this.entity_id
        name: >-
          {{state_attr(config.entity,'friendly_name')}}
          ({{state_attr(config.entity,'battery_type_and_quantity')}})
        secondary: >-
          Replaced: {{
          state_attr(config.entity,'battery_last_replaced')|relative_time() }}
          ago
        state: '{{ states(config.entity)|int(0) }}%'
        hold_action: |
          {
            "action": "call-service",
            "service": "battery_notes.set_battery_replaced",
            "data": {
              "device_id": "{{ device_id(config.entity) }}",
              },
            "confirmation": {
              "text": "Update Battery Replaced Date",
              },
          }
    - integration: battery_notes
      domain: sensor
      attributes:
        device_class: battery
      state: unknown
  exclude:
    - integration: mobile_app
sort:
  method: state
  numeric: true

[danielbrunt57]

That yaml works fine on my system...

Try re-downloading auto-entities but more importantly, template-entity-row...

And make sure you've cleared your browser cache!

[TheBisk]

I tried everything but nothing....anyway thank you for your support.
By the way, Is there a way to put an input_number in the state of the battery to list the entities? I mean something like this:

[danielbrunt57]

By the way, Is there a way to put an input_number in the state of the battery to list the entities?

If you are referring to the state: filter in auto-entities, I don't believe there is any way to template that, but you'd be better off posting that question in the HA Community forum.

filter:
  include:
    - integration: battery_notes
      domain: sensor
      attributes:
        device_class: battery
    *****************
    * state: <= 100 *
    *****************
      options:
        type: custom:template-entity-row

[danielbrunt57]

@TheBisk
Try adding state_color: true to your card config...

type: entities
title: Low Batteries
entities: []
state_color: true