Sorry for the delay. Are you still having this issue? If so, are you running the latest version from Home-AssistantConfig/packages/battery_alert.yaml at master · notoriousbdg/Home-AssistantConfig · GitHub?
I’ll give it a go, now I’ll have to wait for a battery to get low lol
@NotoriousBDG
Still coming up “False” with a battery at 36% (39% input_number set) does the Max threshold need to be > -1?
Yes. Try setting min to -1 and max to 40.
Ah there we go, working properly now.
1 Like
HI @NotoriousBDG,
please let me ask a possibly taken care of question, but since ive reinstalled and dusted off my previous setup this became extra apparent to me.
Is it possible to have an option in the package to create alerts, but don’t create all the sensors? As it stands the package creates all double battery sensors, for sensors already handmade, based on other (custom-)components (eg like @robmarkcole’s excellent Hue.py Hue motion sensors + remotes: custom component) :
or automatically generated based on sensors already showing the batterylevel:
I can maybe take these out again, but that would over complicate the system, and force the need for extra internal documentation which component created which sensor…
omt: please have some version and/or date info inside the header of your package, that would certainly make it a bit easier to check if we use the latest version 
Cheers, and as always, thanks!
Marius
1 Like
What are the friendly names for sensor.corridor_motion_sensor_battery and sensor.hue_dimmer_switch_1_battery? Can you paste a screenshot showing their attributes?
You can fix sensor.tradfri_remote_control_2 by using customize to add the word battery to the entity’s the friendly name. You’ll need to clear the retained mqtt discovery topic for that sensor to get rid of the duplicate after you fix the entity friendly name.
Done.
Confess: i just noticed the group Battery_alert… it wasn’t found earlier, and only displayed on the default Home Page, where i never go…
Cant i just disable these sensors there? Or aren’t they taken into account then either.
Cheers,
Marius
Not quite sure what’s going on. First off, sensor.hue_dimmer_switch_1_battery doesn’t appear to be created by this package. The word “battery” in the friendly name would be capitalized and an “icon” attribute shouldn’t be there. I’m pretty sure sensor.hue_dimmer_switch_1_battery is being created elsewhere.
The only way I can think of that sensor.hue_dimmer_switch_1_battery_2 was created is if you have a *.hue_dimmer_switch_1 entity with a friendly name of “Hue dimmer switch 1”.
Can you show me what entities you have with “hue_dimmer_switch_1” in their names?
You could disable the “Battery Sensor from*” automations, but only do that if you want to disable creating and updating sensors for all entities with battery attributes.
You’re right, I may have expressed myself not precise enough: the sensors without the _2 already existed, your package created their versions _2. Which of course aren’t necessary.
Have to check in later on my Mac (iPhone now) to edit the sensors and screen them.
Disabling the sensors : not sure if doing so also disables checking the originals or just prevents creating the _2 doubles…
Will test and report back.
this is what i can see right now:
philips_hue_sensors:
name: Philips Hue sensors
entities:
#made by custom_component
- sensor.corridor_motion_sensor
#selfmade via Hue Api, rest binary sensor
- binary_sensor.motion_corridor_virtual
#templates derived from custom_component
- sensor.corridor_motion_sensor_battery
- sensor.corridor_motion_sensor_battery_2 #created by battery package
- sensor.corridor_motion_sensor_dark
- sensor.corridor_motion_sensor_daylight
- sensor.corridor_motion_sensor_light_level
- sensor.corridor_motion_sensor_lux
- sensor.corridor_motion_sensor_temperature
- sensor.corridor_motion_sensor_updated
- sensor.corridor_motion_sensor_on
- sensor.corridor_motion_sensor_reachable
- sensor.telefoon
#made by custom_component
- sensor.hue_dimmer_switch_1
#templates derived from custom_component
- sensor.hue_dimmer_switch_1_battery
- sensor.hue_dimmer_switch_1_battery_2 #created by battery package
- sensor.hue_dimmer_switch_1_updated
- sensor.hue_dimmer_switch_1_on
- sensor.hue_dimmer_switch_1_reachable
#made by custom_component
- sensor.auditorium_schakelaar
#templates derived from custom_component
- sensor.auditorium_schakelaar_updated
and for tradfri there’s also one now, bottom line:
ikea_tradfri:
name: Ikea Trädfri
icon: mdi:lightbulb-outline
entities:
# - device_tracker.gwdcefcaba509f
- binary_sensor.ikea_tradfri_hub
- device_tracker.ping_ikea_tradfri
- light.lounge_chair_long
- light.drawer
- light.gamer_den
- light.bureau
- light.inside
- light.outside
- sensor.draadloze_bewegingssensor_1 #hallway
- sensor.draadloze_bewegingssensor_1_battery
- sensor.draadloze_bewegingssensor_2 #hallway
- sensor.draadloze_bewegingssensor_3 #library
- sensor.draadloze_bewegingssensor_4 #office
- sensor.tradfri_remote_control #desk
- sensor.tradfri_remote_control_2
- sensor.tradfri_remote_control_2_battery #created by battery package
As you can see, the last entry was a sensor not yet including _battery, so your package added that. If one has a sensor already ending in _battery, your package creates a _battery_2…
While I believe it wouldn’t need to do that, but just check for its existence and track the battery value…
Might not be possible.
Cheers, let me know if i can do some further investigating for you
Marius
Basically if {{ trigger.event.data.new_state.object_id }}_battery exists don’t create a new one, or something to that effect.
yes, that seems the correct logic. With some sensors its a bit trickier though, since eg the tradfri is in fact showing the battery value, while being called a remote control…
which means a filter on the existence of the state for battery_level should apply also…
It’s odd because I think he accounted for that with the conditions: value_template: "{{ 'battery' not in trigger.event.data.new_state.name | lower }}" very strange.
It looks like sensor.corridor_motion_sensor_battery_2 is being created from sensor.corridor_motion_sensor. Can you show me the attributes for sensor.corridor_motion_sensor? Is sensor.corridor_motion_sensor_battery created by a template? If so, the easiest option would be to just remove that template and let the package create it.
The same goes for sensor.hue_dimmer_switch_1. Can you show me the attributes for sensor.hue_dimmer_switch_1? Again is sensor.hue_dimmer_switch_1_battery created by a template? If so, remove that template too.
For sensor.tradfri_remote_control_2, you have to use customize to add “Battery” to the entity’s friendly name then clear the retained mqtt value for homeassistant/sensor/tradfri_remote_control_2_battery/config.
1 Like
@NotoriousBDG
Just a thought, would it be possible to mix in the dynamic battery icon stuff into this as well for display in a group card in the UI?
Unfortunately, MQTT discovery doesn’t support specifying icons. If it did, that would be simple to add. I don’t have much python experience, but I may investigate what it would take to add that feature to MQTT discovery when I get adequate free time.
This only prevents creating a sensor from a sensor that has battery in its name. This is why using customize to add “Battery” to an entity’s friendly name will fix @Mariusthvdb’s issue with sensor.tradfri_remote_control_2.
Looking for {{ trigger.event.data.new_state.object_id }}_battery as you suggest isn’t hard to add if necessary.
true, on all accounts, check my #comments in the group setup
ill comment out these templates, so if for any reason your package is uninstalled ill have these templates back up in no time
Cool. That’s the reason why I wanted to create this solution. Creating all those templates is cumbersome and it’s easy to miss some. If you still have duplicates after removing those templates, let me know.