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.
You could not find documentation because it did’t exist. 
I have set up a new repo for my custom components with appropriate documentation in case somebody wants to contribute and maybe later can be merged into HA.
@andrey So I pushed it into the main repo, but it was refused. We should use sensor.template was answered.
Never mind I still think it is useful and will continue using it as it’s easier and looks cleaner in config.
I made a PR to @pilotak repo recently which gets the friendly name of the original entity, if you don’t specify any friendly_name in the attributes config.
merged yesterday…
Creating a template for each battery is a ballache.
Creating a value template for icon is even more… especially with sensors with batteries. I have 20-30 batteries to track.
Thanks for this I will give it a try…
@pilotak maybe make a small note that it has to go into custom_components/sensor/ i bumped my head into this thing, since it was my first component and the first topic it was also in custom_components/ directly. Could not find install instruction of the .py itself in your repo so not sure if you wanted it there.