Has anyone run into an issue when using ‘reload groups’ that the groups from this package don’t get reloaded?
Notorious pointed out in another post that there is a bug in Home Assistant that prevents groups from being refreshed when inside of packages. You have to do a full restart. I ended up just moving the groups to my groups.yaml.
1 Like
Do you know if an issue was ever reported on it?
I dont but I have seen other posts in other threads about it so it seems like a known issue.
1 Like
You’re right. This should be on GitHub. You can find it at Home-AssistantConfig/packages/battery_alert.yaml at master · notoriousbdg/Home-AssistantConfig · GitHub now.
, it’s not coming from notify.* because those only run twice per day. It sounds like something is making persistent notifications into a notification on your phone. Maybe you have some other automation that does that? Anyway, try the latest version to see if the issue still persists.
The last update I saw was that the issue was not going to be fixed.
1 Like
Good to know, thank you. I’ll just update my groups.yaml to compensate for the bug (in home-assistant). 
Automations are affected too. So you may want to move them as well…
1 Like
smart! I do have something like that, but it is specifically targeted at intruders, not battery-levels …
the search continues.
Loaded question, but how hard would it be to add battery checking as a native function in Home Assistant? I can see it as a higher priority item that people want as Home Assistant becomes more popular.
1 Like
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.