Howto create battery alert without creating a template for every device

[NotoriousBDG]

@pdobrien3

I did notice that all the entities with batteries have a battery_level attribute. Is this common outside of my setup?

That is the most common method, but there are numerous exceptions. The automations that rely on MQTT discovery have been designed to handle all of the attribute variations that have been identified so far.

[zoeperman]

maybe a weird question, but is the mqqt part needed if you don’t have a mqqt sensor wich uses batteries?

[NotoriousBDG]

@zoeperman

maybe a weird question, but is the mqqt part needed if you don’t have a mqqt sensor wich uses batteries?

It replaces the need to manually create template sensors for entities that have battery attributes. It determines if an entity (not just MQTT ones) has battery level stored as an attribute, and it automatically creates a sensor based on that attribute.

[pdobrien3 (Dan)]

ok, I have been testing everything with the alert threshold at 100%. I recently moved it to 55% and had to restart HA for some other changes. I noticed all the automations were off. Is this normal or did something get bumped during the restart? All the automations should be kept on correct?

thanks

[klogg]

I’m really late to this but love the way this has gone from a really simply idea of about 50 lines of code to a quite sophisticated component of nearly 700 lines of code

Can I ask a dumb question?

What is the significance of the ‘*’ and ‘&’ prefixes, as in for example:

  action:
    - condition: template
      value_template: *low_battery_check

and

  action:
    - condition: template
      value_template: &low_battery_check >

and

  action:
    - condition: template
      value_template: *low_battery_check
    - service: notify.telegram
      data_template:
        title: "Low Battery Levels"
        message: *message

[pdobrien3 (Dan)]

I believe one of them, I think the &, defines the template for use later within the code. Then the other, the *, just calls the same template to keep from having to paste the same template over and over. Just allows for cleaner yaml.

Where can I create macros for templates?

I have searched the archives and I haven’t been able to find an answer to my question. I have several sensor templates for battery levels and smoke detectors that have pretty much the same content. I read in the Jinja2 documentation that macros can be used like functions. This is exactly what I am looking for and when I try it out in the dev-template section of HA they work great, but the question I have is where do I put the macro definitions?

[NotoriousBDG]

Release 1.1.0 is available now on GitHub. Deleting battery sensor should be quite a bit easier now with this release. There is a new input text box named “MQTT Topic to Clear” that will send the appropriate MQTT message to clear retained topics. You just need to grab the values of mqtt_state_topic and mqtt_config_topic attributes from the sensor you wish to remove and enter them into the input text box one at a time. Restart Home Assistant, and the sensor should be gone.

Changelog

Added

• Added input text box named MQTT Topic to Clear, which can be used to clear MQTT topics with retained messages
• Set initial_state to on for all automations to ensure they are enabled on startup

Changed

• Consider entities with battery in their entity_id or friendly_name a battery sensor if neither an icon nor a device class is defined
• Consolidated the battery_sensor_from_* automations into a single automation

notoriousbdg/Home-AssistantConfig/blob/master/packages/battery_alert.yaml

[NotoriousBDG]

@pdobrien3

I also noticed that the sensors I created, named sensor.my_entity_battery are only added when I go into customize and add a mdi:battery.

If I change all the sensors to sensor.my_entity_battery_level , will it automatically be added to the battery status group?

This is fixed in the 1.1.1 release.

@pdobrien3

I noticed all the automations were off. Is this normal or did something get bumped during the restart? All the automations should be kept on correct?

I had a similar issue when I first started using Home Assistant. Some automations wouldn’t be enabled on startup. I never figured out the root cause, because I found a simple workaround using customize_domain that ensures all automations are enabled at startup.

To help, I’ve added initial_state: 'on' to the automations in the package so they should be enabled on start automatically now.

homeassistant:
  customize_domain:
    automation:
      initial_state: 'on'

@klogg

I’m really late to this but love the way this has gone from a really simply idea of about 50 lines of code to a quite sophisticated component of nearly 700 lines of code

Thanks for the kind words. It still surprises me too.

@klogg

Can I ask a dumb question?

What is the significance of the ‘*’ and ‘&’ prefixes

Those are a feature of yaml known as anchors and references. It allows you to eliminate some duplication of code. For example, *low_battery_check gets automatically replaced with the value after &low_battery_check. There is some examples of the feature at daemonl.

[nebbiadigiorno (nebbia)]

sorry for the dumb question, i have to create a templeta for every deivce that has a bettery sensor (for ex a xiaomi open close sensor)? or your code it will create for me? becouse i add your package but the only sensor i can see is from the xiaomi vacuum for wich i have manually create a sensor.

[NotoriousBDG]

@nebbiadigiorno

i have to create a templeta for every deivce that has a bettery sensor (for ex a xiaomi open close sensor)? or your code it will create for me?

It should create the battery sensors automatically.

@nebbiadigiorno

becouse i add your package but the only sensor i can see is from the xiaomi vacuum for wich i have manually create a sensor.

MQTT discovery is needed for that feature to work. Can you confirm that it’s enabled? Can you also post a screenshot of the entity that’s not working from the http://hassio.local:8123/dev-states page so I can see its entity_id and attributes?

[nebbiadigiorno (nebbia)]

after a restart your code gad created some. but i have much more. mqtt is enable. that are the screenshot:

and after another restart they all gone again:

that’s is my mqtt config:

> #MQTT
> mqtt:
>   discovery: true
>   discovery_prefix: homeassistant

is it possible that the sensor will show up only when the sensor itself get update?

[NotoriousBDG]

@nebbiadigiorno

after a restart your code gad created some. but i have much more. mqtt is enable. that are the screenshot:

Those look like they should all work. I suspect that the missing ones haven’t had a state change since you added the package. Try making each of those sensors change state, and you should see the battery sensor get created.

@nebbiadigiorno

and after another restart they all gone again:

Which MQTT broker are you using? I suspect there might be an issue with the retain flag with your broker. Personally, I use Mosquitto…

@nebbiadigiorno

is it possible that the sensor will show up only when the sensor itself get update?

Yes, that’s true for the initial creation of the sensor, but the MQTT retain flag is set to make them persist through reboots.

[jsternadel]

I use html5 push notifications and a different mqtt discovery topic so I made a few improvements (well i think they are improvements) to your package file.

• New MQTT Discovery Topic input text field that sets the appropriate topic.
  • I couldnt figure out how to default this to ‘homeassistant’ and use the recorder at the same time so on initial load it didn’t pick up any sensors. Once i added my ‘hass’ topic and restarted HA it worked like a charm
• New HTML5 notifier name field that sets the notify.NOTIFIER_NAME value
  • This will default to notify.notify if you dont have a notifier name set
  • Will also let you target specific devices. If your notifier name is ‘hass’ and your phone is called ‘my_droid’ then entering ‘hass_my_droid’ will push notifications to that device only
  • see docs here https://www.home-assistant.io/components/notify.html5/#automating-notification-events

https://gist.github.com/jsternadel/29ed6a6e245629e77a59a232b08956b5

[nebbiadigiorno (nebbia)]

i use the embedded mqtt broker.
that’s my config:

#MQTT
mqtt:
  discovery: true
  discovery_prefix: homeassistant

any advice?

i install mosquitto and now my config is;

mqtt:
  broker: core-mosquitto
  discovery: true
  discovery_prefix: homeassistant

but i still have the same problem.

[mouth4war]

join notification support please!

[jsternadel]

Had a spot of trouble clearing some failed nodes from the mqtt discovery. I use Mosquitto running in a docker on my unRAID server. I set channel to clear as “hass/sensor” and could see it being published to Mosquitto in the log. However 0 bytes were sent with it which never seems to trigger mosquittos’s built in save event.

I had to manually stop Mosquitto and Home Assistant dockers. Delete the mosquitto.db file and remove the bad battery nodes from the entities_registry.yaml file in home assistant. Finally that seemed to clean out unknown node and unkown node 2 from HA.

Should I be turning off the automations for Create Batter Sensor from Attributes and Update Battery Status Group Members before doing inclusion on new z-wave nodes?

[jsternadel]

I updated my Gist with the basic automation for Join. I don’t have it currently setup in my HA instance so I am unable to test. I did trigger it and no errors were found in the log so I assume it works. Hopefully its enough to at least get you started.

Also I’m not sure if you’re a hero or a jerk for introducing my brain to Join. Now it won’t stop thinking of all the things I can use it for to support automation on my Shield TV.

https://gist.github.com/jsternadel/29ed6a6e245629e77a59a232b08956b5

[klogg]

@pdobrien3, @NotoriousBDG
Thanks for explaining that, I am now going to look at my garden irrigation system to see if I can use it there. I like anything that reduces the duplication of code especially in yaml files which seem to grow at absurd speeds!

This realty is one of the great things about HA and some of the people involved. I don’t even have any batteries to monitor yet unless you count our our phones and not only has this project inspired me to push ahead with my plans for door and window sensors but I have learnt something totally unrelated. Actually, two things because I also had the ‘automations-not-always-being-on-after-a-restart’ issue and you have provided a solution/workaround!

[NotoriousBDG]

@jsternadel

I use html5 push notifications and a different mqtt discovery topic so I made a few improvements (well i think they are improvements) to your package file.

Very cool. What you’ve done with the notifier name is really interesting. Now you’ve got me thinking about how that feature can help reduce the sprawl of notification options. I’m definitely going to include this.

I’ll include the discovery topic input text field in the next release too. I can appreciate how helpful that can be.

@nebbiadigiorno

i install mosquitto and now my config is;

mqtt:

broker: core-mosquitto
discovery: true
discovery_prefix: homeassistant

but i still have the same problem.

You’ll need to add at least broker, username, and password options to make it use your Mosquito broker. There is some additional details at MQTT - Home Assistant.

@mouth4war

join notification support please!

Looks like @jsternadel already posted an example. I’ll incorporate that in the next release.

@jsternadel

Had a spot of trouble clearing some failed nodes from the mqtt discovery. I use Mosquitto running in a docker on my unRAID server. I set channel to clear as “hass/sensor” and could see it being published to Mosquitto in the log. However 0 bytes were sent with it which never seems to trigger mosquittos’s built in save event.

It should be sending a null payload with retain flag set, so 0 bytes sounds right. It looks like you’ve got an error in the condition of the clear_mqtt_topic automation. Try this instead:

value_template: "{{ '/sensor/' in states.input_text.clear_mqtt_topic.state }}"

@jsternadel

Should I be turning off the automations for Create Batter Sensor from Attributes and Update Battery Status Group Members before doing inclusion on new z-wave nodes?

No, it shouldn’t be necessary.

[gohassgo]

@pdobrien3

Invalid service data for group.set: Entity ID is an invalid entity id for dictionary value @ data[‘entities’]. Got ‘’

I have this error as well. Been getting it for a few revisions (now running a fresh copy) and no battery sensors are being created, but the Battery Alert group/view and all of its things show up.

Any ideas on how to fix this?

Thanks