as the device_class is battery, @dbrunt is correct and HA is doing the translation. Which isn’t working in my case - all the batteries are given the 100% icon.
I have a few battery devices connected via Zigbee2MQTT. Here’s one…
{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x00158d0004869868"],"manufacturer":"Xiaomi","model":"Aqara human body movement and illuminance sensor (RTCGQ11LM)","name":"Living Room Motion","sw_version":"Zigbee2MQTT 1.21.2"},"device_class":"battery","enabled_by_default":true,"json_attributes_topic":"zigbee2mqtt/Living Room Motion","name":"Living Room Motion battery","state_class":"measurement","state_topic":"zigbee2mqtt/Living Room Motion","unique_id":"0x00158d0004869868_battery_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.battery }}"}
Now that I am examining my icons more closely, I appear to have the same issue…
It could be the absence of the icon: mdi:battery-## attribute as I only have three with that and they display correctly in both views whereas I think the battery-state-card may be compensating for the lack or or overriding the icon: mdi:battery-## attribute:
Daniel’s Cell Phone (Mobile App)
Front Timer (BHyve)
Rear Timer (BHyve)
Fixed.
default_config:
homeassistant:
customize: !include customize.yaml
customize_domain:
switch:
templates:
icon_color: >
if (state == 'on') return 'green';
return 'red';
icon: >
if (state == 'on') return 'mdi:toggle-switch-outline';
return 'mdi:toggle-switch-off-outline';
light:
templates:
icon: >
if (state == 'on') return 'mdi:lightbulb';
return 'mdi:lightbulb-outline';
lock:
templates:
icon_color: >
if (state == 'locked') return 'green'; return 'red';
sensor.*_battery:
templates:
icon_color: >
if (state < 30) return 'red';
if (state < 80) return 'yellow';
return 'green';
icon: >
if (state < 15) return 'mdi:battery-10';
if (state < 25) return 'mdi:battery-20';
if (state < 35) return 'mdi:battery-30';
if (state < 45) return 'mdi:battery-40';
if (state < 55) return 'mdi:battery-50';
if (state < 65) return 'mdi:battery-60';
if (state < 75) return 'mdi:battery-70';
if (state < 85) return 'mdi:battery-80';
if (state < 95) return 'mdi:battery-90';
return 'mdi:battery';
binary_sensor.*:
templates:
binary_sensor.*_motion:
templates:
icon: >
if (state == 'on') return 'mdi:motion-sensor';
return 'mdi:human-male';
icon_color: >
if (state == 'on') return 'yellow';
return 'grey';
binary_sensor.*_occupancy:
templates:
icon: >
if (state == 'on') return 'mdi:motion-sensor';
return 'mdi:human-male';
icon_color: >
if (state == 'on') return 'yellow';
return 'grey';
packages: !include_dir_named packages/
Is there a way to use this for batteries that aren’t directly monitorable in a device? As in, the periodic replacement of batteries in things like smoke alarms, UPS units that don’t have monitoring, or other offline devices that should be checked on the basis of dates?
The lead acid batteries a UPS typically need replacing every 3 years. I have several units spread around the house (for DVRs, PCs, etc). It’d be handy to have a way to see if there’s several with upcoming battery replacement deadlines, so I could perhaps make quantity order and do them all together rather than an endless cascade of yet another one died… order another replace, repeat… A card on my HA dashboard that pops up when one is getting close, and shows the values of others, maybe?
The same sort of thing applies for filters in a furnace air handler, the de/humidifier pads or just periodic cleaning of the condensate pumps.
Simple answer, no. This is meant only for low battery levels that are already reported to HA.
You’d have to devise something else like input helpers that store a date and then automations that trigger on days elepsed since the input date value and alert you plus maybe an input boolean for actual replacement that you could toggle to true which would trigger another automation to reset the date last changed helper to today’s date and reset the boolean helper back to false. Most Smart UPS’s have some means of monitoring battery expiration and alerting. There are HA add-ons for some USB based UPS’s…
Fair point, and thanks for the added descriptions of what might be necessary. It’s good to know when something is or isn’t the right tool to use for a job. I’ll make use of this for what it’s already doing, and look for other ways to get a similar sort of scheme for the other kinds of ‘expiring maintenance’ items like batteries.
And, yes, when a UPS has a direct USB input I’d certainly consider using it. But several of the ones I’ve got around the house have nothing with a USB port near them that would be useful for managing them. There’s a balance to be struck between actively “knowing” the condition of a battery by monitoring and simply guesstimating when it’s likely to be failing and replacing it proactively. Having active monitoring often adds YET ANOTHER piece of tech to have to babysit, follow me? Versus ignoring it completely and getting awoken at 3am to a squealing UPS that’s starting to make smoke.
I think input booleans/input date helpers/automations might be you answer. I may set that up for my furnace filter. My 2 APC SmartUPS’s have periodic batttery checks and start beeping when they need new batteries so that is sufficient for me. I have automated my coffee maker and added a coffee filter counter so I am alerted that I need to go buy more. …
FWIW, I reported a new issue for the battery_alert package, issue 37. Even with issues, this package works (well, except for devices that dies before reporting low battery) so I am still using it.
Hi Everyone, I’m looking to do this exact thing - just wondering (and sorry if this is covered above, I havent read all 1000 posts!!)
is still the best way of doing this since the last update to the code was 2 years ago?
Also I notice it uses MQTT - does this mean it will only work for my MQTT devices or is that just the way that it handles doing things?
I’ve not found a better way. It deals with all battery entities and entities with a battery_level attribute. It only uses MQTT to create new sensors for devices that have a battery_level attribute. See automation battery_sensor_from_attributes.
although I’m unsure if i need to call out each of those different sensors individually?
The second possible way seems to be available in Lovelace - the “Delete a Battery Sensor” option - I can’t find a description of what this does anywhere tho or how to use it (and for that matter, which to use - the text box or the toggle)
