After working with this for a bit, it seems the original script is creating the battery entities for every device except for my Aeotec Door/Window Sensor 6 devices. It lists the battery for even my older First Alert Smoke/CO detectors but not the door/window sensors.
I tried the updated script and when I re-loaded HA, I would initially see the battery devices in the entities list, but by the time HA finished loading fully, they were gone.
@justyns I’m having the same issue with the battery items not showing up if the include is being used or all devices duplicated which aren’t being hidden via customize.
The logs show the settings are being picked up by the component:
Dec 29 13:57:03 homeassistant hass[4275]: 16-12-29 13:57:03 INFO (Thread-3) [custom_components.battery_state] The ‘battery’ component is ready!Include list: [‘sensor.everspring_sm103_doorwindow_sensor_sensor_8_0’, ‘sensor.everspring_sm103_doorwindow_sensor_sensor_9_0’, ‘sensor.fibaro_system_fgms001_motion_sensor_sensor_3_0’]. Exclude list: . Attribute list: [‘battery_level’, ‘battery’]
Which should work since these devices had a _battery item as well once I wasn’t using the include option.
Is it possible to add a group named “group.all_battery_states” and contain a dynamic update of this group within the component, a dynamic group creation in the configuration.yaml seems to be not possible?
Maybe this helps to get it a little bit more dynamic
hmmm… still a lot work manually, i have soon 40 sensor nodes and more i don’t want to add each device manually to a group :-).
Thank you so much for contributing this! You inspired me to finally try out a custom component and it wasn’t difficult at all. Now I just need to learn to actually write the code.
I really like the other comment about turning this into an attribute sensor. Thanks again!
@justyns Did you have a chance to have a go at the general attribute component? I may have some time in the coming weeks to have a look at this.
I can’t seem to change the Friendly Name via the customize component. It seems like the Battery Level component overrides any changes you make. I tried deleting this line in the Battery Level component:
'friendly_name': "%s Battery" % new_state.attributes['friendly_name'],
This only made the name of the sensors in lowercase instead of capitalized. Anyone have any idea how set a different friendly name?
No idea how to implement a group in that component? 
@tinglis1 I started on the generic attribute component, but haven’t had time to finish it. I’ll work on it this weekend, and post a PR for it for you to review (or work on if I don’t get that far)
@DuckY1987 I haven’t looked at how to automatically add sensors to a group, but I’ll see if it’s possible since I’d love to have that feature too!
@ciswindell I’m pretty sure the friendly name gets overridden because it is set every time the value is changed. I can probably change how the sensors are being created to fix that, otherwise I’m not sure if I need to look up the customization settings myself. I’ll look into it though; thanks for bringing it to my attention!
@StormStrikes can you check if your Aeotec Door/Window Sensor 6 device has one of the attributes the script is looking for? If it does, I can paste a version of the script with a bunch of debug statements that might give us a better idea why it wouldn’t be picking it up.
Also I realized I haven’t updated my rpi that has zwave on it recently (still has the old sensor id naming scheme), so I’ll do that this weekend and test if mine breaks in the same way as @StormStrikes and @syphernl
Edit: Thanks everyone who’s tested this script out so far, much appreciated!
@justyns did you manage already to integrate a group.all?
Btw i figured out we need to ignore values below 0 (-1), the value “NULL” and add an exception to ignore battery value for powered sensor nodes.
This has been working for quite some time for me but with the 0.40.0 update, now I am getting multiple battery sensors for the same devices.
@tinglis1, @justyns I had a time to create generic attribute sensor with added benefits
What i did was that i took sensor.template, changed the behaviour how to select entities and added some fixed templates.
Features
last_changed or last_triggered and you specify time_format your datetime will get translated to your local timezone and will be formatted like strftime(). Cheatsheet here
battery or battery_level and you don’t specify icon you will get battery icon with fullness ie. mdi:battery-50, mdi:battery-40, mdi:battery-outline etc.sensor:
- platform: attributes
friendly_name: "Last changed"
attribute: last_triggered
icon: 'mdi:clock'
time_format: '%d, %m - %H:%M:%S'
entities:
- automation.temp_changed
- platform: attributes
friendly_name: "Batteries"
attribute: battery_level
unit_of_measurement: "%"
entities:
- sensor.myslipo_1_0
- sensor.myslipo_2_0
- sensor.myslipo_3_0
- sensor.myslipo_4_0
Resulting name of you sensor is its name plus attribute, ie.: sensor.myslipo_1_0_battery_level
https://github.com/pilotak/Home-AssistantConfig/blob/master/custom_components/sensor/attributes.py
I will hopefully find some time and do some readme.
Looks really good.
I will try it out on my system over the next week and let you know how it goes.
You should make any documentation you write in the format ready for merging into HA.
A minor fix for your code after browsing it.
The icon for battery 50% is missing the number for the icon.
There maybe a more elegant way to write that section using rounding and concatenation.
But what you have is functional so I wouldn’t worry unless you are asked to change it when merging with HA.
It can definitely be written more elegant, but as you say it works.
I don’t think this is something to be merged with HA. It’s just a helper not a new component all this can be done using regular sensor.template, this is template sensor for lazy people and for those who like the code clean.
I have corrected missing 50%. If you feel this is usable for more people than here in this thread I can create a special repo and you can contribute.
Nice work, @pilotak! I’ll try it out the next time I update my HA install. I haven’t actually had as much of a need for my original battery script due to the zwave component creating battery_level sensors on its own now, but this is definitely still helpful for non-zwave sensors.
I agree with @tinglis1 that there may be a cleaner method to handle the icon template, but I also wouldn’t worry about it if it’s working for now.
Your example works but gives me multiple sensors with the friendly name battery and no way to know which battery relates to which entities. Anyone good at templating and manage to show the friendly name & battery for each of the specified entities so rather than “battery” it would show “myslipo_1_0 battery” or whatever the friendly name is set to.
sensor:
- platform: attributes
friendly_name: "Last changed"
attribute: last_triggered
icon: 'mdi:clock'
time_format: '%d, %m - %H:%M:%S'
entities:
- automation.temp_changed
- platform: attributes
friendly_name: "Batteries"
attribute: battery_level
unit_of_measurement: "%"
entities:
- sensor.myslipo_1_0
- sensor.myslipo_2_0
- sensor.myslipo_3_0
- sensor.myslipo_4_0
I’ve tried templates it but just end up breaking it.
@stevenhorner I though about doing name tepmlate, but it came up pretty complicated, so i started with this easier variant. The solution is quite simple, you have two options:
homeassistant:
customize:
sensor.myslipo_1_0_battery_level:
friendly_name: 'Living room batteries'
sensor.myslipo_2_0_battery_level:
friendly_name: 'Bedroom batteries'
sensor:
- platform: attributes
friendly_name: "Batteries"
attribute: battery_level
unit_of_measurement: "%"
entities:
- sensor.myslipo_1_0
- sensor.myslipo_2_0
sensor:
- platform: attributes
friendly_name: "Living room batteries"
attribute: battery_level
unit_of_measurement: "%"
entities:
- sensor.myslipo_1_0
- platform: attributes
friendly_name: "Bedroom batteries"
attribute: battery_level
unit_of_measurement: "%"
entities:
- sensor.myslipo_2_0
I tried both and they do not break anything.
It’s up to you to decide which variant suits you.
This sounds interesting.
Do you by chance know where is the documentation for this attributes’ platform?
I cannot seem to find it and I was interested in knowing if I would be able to specify icon_template for it, to fully replace my current setup (using template sensors).
Thanks in advance.