Ah ha! That’s the culprit. You could add a condition that excludes forwarding when entity_id is persistent_notification.lowbatteryalert.
cool, ill try .
something else for fine-tuning : mqtt: discovery:true is necessary for your package, but is also causes fake sensors in my system to show up. Don’t know why, don’t know how, but they do.
Would it be possible to have discovery only discover the entity_id’s your covering in your package? Reading MQTT - Home Assistant i tend to believe that should be possible, but am a bit puzzled what would be the optimal setting. Not wanting to hardcode all exceptions, just like your packages doesn’t hardcode but uses templating.
We need only battery_sensors…
Cheers,
Marius
Discovery requires a pretty specific topic and payload. Something must be deliberately sending messages to create those other sensors. Do you have any other automations that use the mqtt.publish service?
No, i have none… only your package and a package i have parked out of sight of HomeAssistant, and never used yet.
They are consistent. Suddenly appeared after enabling your package with mqtt discovery. As far as i can test it, it has nothing to do with your package since taking that out and only leaving discovery enabled still creates these extra sensors.
Must take it out of this thread therefor… but please do suggest how to debug this will you?
Chees,
Marius
Use mosquitto_sub to check for retained topics for those sensors. If there are some, clear them and see if they come back.
couldn’t find any, but cleared them anyway:
mosquitto_pub -h ipaddress -p 1883 -u username -P password -t "homeassistant/sensor/cv_garage_actueel_2" -r -n
restarted discovery and the sensors show up again…
@NotoriousBDG I have a battery level reading 33% but the conditions on the automations keep returning “False” when I put them into the template section. Any suggestions?
No alerts are disabled.
@NotoriousBDG
Using your alert with MQTT-broker, Mosquitto, works great.
One thing is that when restarting Hassio or rebooting ResinOS, the set threshold values are defaulted to minus (-1) one.
Is there any way of making the threshold values persistent?
Has Hassio any mechanism for such values or maybe write it to a file?
Is it an idea to move the sliding values to the front of the slide? On small mobile devises the values are not present
And please mark your Github code with a version number. Makes it easy to check for updated versions.
Thanks again for an excellent “addon”.
UPDATE: Thanks @firstof9,
The enteties input_number.battery_alert_threshold_max and input_number.battery_alert_threshold_min, I think are not checked and re-used in the code.
( RPI3/Z-Wave Aeon Labs Z-Stick Gen5/Zigbee ConBee-deCONZ-USB /Hassio 0.63.0)
Enable the recorder to save input_number states:
Example:
recorder:
purge_interval: 2
purge_keep_days: 14
include:
domains:
- sensor
- input_boolean
- input_select
- input_number
When I restart HASS my sliders go back to the settings I’ve last saved them at.
If you enable the recorder and they are not going back, make sure there isn’t an initial: -1 set for that entity.
My bad. Looks like it works. I had been playing around with my recorder and history code. Did not work right after sorting it out, but after 12 hours it worked again.
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.