Howto create battery alert without creating a template for every device

[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

[pdobrien3 (Dan)]

Are you creating your sensors manually? If so, add

device_class: battery

To each sensor. If you are using MQTT, you are going to have to wait for @NotoriousBDG to chime in. Also, he posted something earlier about clearing your MQTT topics.

I got that error because none of my battery sensors met the conditions of the package. No sensors, nothing to add to the group.

[gohassgo]

@pdobrien3

Are you creating your sensors manually?

No, a version not too long ago created the sensors just fine, but things broke down somewhere along the way…

I have a number of Z-wave devices with batteries that used to get detected automatically by this package, but no longer do.

[gohassgo]

I went into Configuration > Customization and set the device_class to battery for a couple of the Z-wave power-related entities and they showed up in the Battery Status card.

Any reason why this is necessary now? It was really nice before when things just showed up automagically.

Thanks!

EDIT: The ones that are now showing have “0” OR “0.0 W” for values, so I’m thinking those weren’t the correct entities to set the device_class on…

[pdobrien3 (Dan)]

Have you cleared your MQTT topics ?

[gohassgo]

No, why is that necessary? I thought that was only used to remove…

[NotoriousBDG]

@gohassgo

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?

That looks to happen when there are no battery sensors detected. I’ll have to add a condition to the automation to prevent that.

@gohassgo

I have a number of Z-wave devices with batteries that used to get detected automatically by this package, but no longer do.

Can you post a screenshot of the states page for the sensors that aren’t working? I need to see the attributes and entity_id for them to troubleshoot the issue.

@gohassgo

EDIT: The ones that are now showing have “0” OR “0.0 W” for values, so I’m thinking those weren’t the correct entities to set the device_class on…

Device_class would only need to be set on battery sensors that you create manually. Ones that are created automatically will already have it set.

[gohassgo]

@NotoriousBDG

Can you post a screenshot of the states page for the sensors that aren’t working? I need to see the atributes and entity_id for them to troubleshoot the issue.

Most all of my Z-wave devices used to show up with battery levels. Here are the states of one of the Aeotec multisensors.

I wonder if this has something to do with me manually editing entity_registry.yaml to “fix” the z-wave entity naming.

Thanks

EDIT: The “device_class: battery” for the .power entity is a remnant–that’s one device_class I Set manually and then deleted, but is still showing…

[NotoriousBDG]

@gohassgo

Most all of my Z-wave devices used to show up with battery levels. Here are the states of one of the Aeotec multisensors.

I wonder if this has something to do with me manually editing entity_registry.yaml to “fix” the z-wave entity naming.

None of those have battery attributes. Do you have a zwave.xxx entity that corresponds with that device?

[gohassgo]

Yeah, here’s the zwave.* entity.

There are a bunch with the battery attribute. Here are a few more…

[NotoriousBDG]

@gohassgo

Yeah, here’s the zwave.* entity.

Interesting, there is nothing there that would make me thing it wouldn’t work. Can you try a few things to help isolate where the issue is. First, watch MQTT messages using mosquitto_sub -h MQTT_IP -u MQTT_USERNAME -P 'MQTT_PASSWORD' -v -t 'homeassistant/sensor/#' then force a state change on the multisensor. Let me know if you see any MQTT messages show up. If you don’t see any messages, can you also check to see the last time the “Create Battery Sensor from Attributes” automation was triggered?