What about custom integrations (coming via HACS)? Is there any way to simply reload them after upgrade and can be implemented by integration devs or is it still HA limitation that the whole core needs to be reloaded?
That I already answered above:
1 Like
That is a different thing btw… An upgrade is change of source code, only a restart can solve that.
3 Likes
Exactly what came to my mind at 1st when reading the WTH month blog post! It even is my number 1 point in my personal HA documentation I started two years ago when starting to use HA, section “What really annoys me”:
Need for restarting HA Core for reloading components (integrations, alert, many YAML based stuff)
- I really hated this right from the beginning. I really appreciate that a lot of things can be reloaded meanwhile using the dev-tools yaml section. But not everything, not at all. Think about the famous, so powerful and so little love-receiving alert integration.
- And some things (like “command_line sensors”) create issues:
once I reload command line sensors, they are reloaded - but at the same time a duplicate (shadow entity) is created, e. g. “sensor.thing_a” will have a “sensor.thing_a_2” brother, after another reload another sibling “sensor.thing_a_3” joyns the party and so on.(see WTH why do we need to restart HA core so much? - #19 by petro) The “fix” is: a full HA restart. - Back to the root cause, need for restarting HA:
- restarting creates a downtime (“single unplanned/planned maintenance window”) of at least 6 minutes in my case (Pi 4, SD card, running HA OS, few integrations taking quite some time to load). Which is pretty much if you are
- a) working heavyly on your configuration and have
- b) many systems integrated which all now NEED HA to be alive/online, otherwise the smart home turns into a pretty dumb home (wall switches not working, lights not being turned on by motion sensors, data not collecting, automations not running, notifictions not being sent, … - basically feels like there’s a power outage). Creating follow-up issues like
- missed automations which should have run meanwhile etc.
- “wrong” last-updated / last-changed states of entities - yes, I’ve restarted HA, but I didn’t turn on or off this light/switch/… (all entities are initialized and get a new state update in the recorder so basically they are “reset” to the HA restart timestamp)
- …
- restarting creates a downtime (“single unplanned/planned maintenance window”) of at least 6 minutes in my case (Pi 4, SD card, running HA OS, few integrations taking quite some time to load). Which is pretty much if you are
So many things which could be avoided if we wouldn’t need to restart HA that often.
Bit of reality maths:
I’m using HA in production state roughly since december 2020. Using SQL - Home Assistant with a simple SELECT run_id AS "Anzahl HA-Starts" FROM "recorder_runs" ORDER BY "created" DESC LIMIT 1; statement I created a sensor.ha_starts_count sensor, currently showing:
So roughly 639 days since starting using HA and that many restarts (since few months I made a big step back and only update HA Core once a month cause there’s usually no need to update every 20yy.mm.XX release if XX does not contain an important fix - since then I quite often have uptimes of 14 to 21 days, not adding or configuring anything) makes a mean run time of amazing:
2 Likes
Use a unique_id. Otherwise the system doesn’t know it’s the same entity because it already exists when you reload. Providing a unique_id to your command line lets the system know “Hey this is that sensor, don’t make a new one”.
2 Likes
Uff, thanks for reminding me of Command Line - Home Assistant ! Started using CL sensors before learning to read the existing docs first…
I’m going to 
over all my CL sensors now, let’s see what happens when reloading then without a HA Core restart.
I guess: finally “fixed” this little piece, so substract that minor pain point from the list and focus on the remaining ones (only examples…) 
Update on this: for bad news see
The homekit integration has the restart/reload option but I have found that it never actually works when I edit the YAML, only a full HA reboot work. Also there are many integrations that don’t have a reboot option.
Nabu Casa cloud: can’t be reloaded via yaml WTH
google_assistant: can’t be yaml reloaded
panel_custom: can’t be reloaded
tts: can’t be reloaded
Yaml reloading Location & Customizations is so generic sounding I often press it just in case.
1 Like
Related question:
What’s the rationale for having such fine-grained yaml reloading? Seems that these all reload pretty quickly so a single “reload all config” would be fine?
1 Like
The integration needs code put in place in order for reloading to even occur. So reloading all wouldn’t do what you think it does. There’s no ‘click on and everything will be reloaded’ option in the code. It has to be built per integration, which is essentially why it’s shown per integration.
1 Like
Sure, but that’s an implementation detail. It shouldn’t be too hard to have the reloaders register centrally so that a single button on the UI would reload them all?
Services are just registered, there’s no ‘repository’ that knows what the services are doing. Just a big ole registry. You could make an automation that reloads all of them. But there’s really no difference than restarting at that point IMO.
Presuambly they have to do something to appear in the reload UI list?
As a human I can fairly quickly click on all the options in this list (which I sometimes do if I don’t know the category of the config I changed, or if I’m desperate). Surely the UI itself could do this for me?
Is there a downside to reloading everything this way?
Yes, they make a specific call in the onboarding process. I haven’t look at the calls’ details to know exactly what it does beyond that.
Not really. I’ve personally never seen the need. How often are you editing all yaml entries? It’s usually 2 or 3 at most for me. Template entites (or another integrations entities) and/or scripts and/or automations. And the order matters there.
1 Like
When you reload automations any currently running automations are stopped. Specifically that means delays, wait steps and for x time options in triggers/conditions will be cut short. Same with scripts.
For all entities the other consequence is history. When you reload an integration then all entities made by that integration go to state unavailable then (sometimes, depends on the integration) unknown and then finally back to the state they are supposed to be in. These changes triggers state changes if any automations are watching them and updates the last_changed and last_updated values of these entities.
If you’re fine with all that then no, there’s no consequences. I generally prefer to reload no more then necessary.
2 Likes
We have to restart several times a day just to refresh Lifx Scenes. We have to restart every time we add something from HACS. 'nuf said.
1 Like
Update few days and HA restarts later @petro regarding WTH why do we need to restart HA core so much? - #20 by e-raser:
Unfortunately when setting a unique_id for (command_line) sensors after using them already, it seems one ends up with a lost history from before that change.
- An entity now having a unique_id can not be mapped to the former one with the same name but without the unique_id.
- Probably “works as intended” but a big downside for me as I use some sensors for long term statistics - which are now gone (no matching in HA recorder database)
Random example below (added unique_id at October 1st 00:27:57 for this entity):
In case there’s a trick to merge the database entries of the former “unique_id-less” entities with the newer ones now being unique… please let me now!
1 Like
that sounds like a problem with Lifx not HA.
Right. Because HA has to incorporate the new code into the system.
without that then HA has no idea it even exists until it reads in and initializes all the new custom things.
I dfoubt there’s anything HA can really do about either of those in regard to restarts.
1 Like
the database has no link to unique_id, it’s entity_id driven. Remove the old entity_id, restart, rename the new unqiue_id driven entity_id to the old entity_id, done.
1 Like
That’s what I did. Please note:
- I got plenty of “_2” entities (the former shadow entities), without having the “normal” ones. So I renamed those “_2” entities, e. g. “sensor.cpu_clock_2” now is “sensor.cpu_clock”. I think that might be the actual reason. Root issue: why there were only the “_2” entities after adding unique_id’s and reloading the sensors.
- I think another “logical miracle” additionally kicked in here: HA was running for longer (18 days) than the recorder “purge_keep_days” setting (14 days) which is why there were no states for many entities (because of a lack of entity value updates during the last 14 days).
Pretty complicated, don’t think I can get the history back (without needing to fiddle around directly in the database which is what I hate and for that reason there’s Fix Individual Entity Data Points and similar).
Lesson learned (the hard way, by loosing plenty of history): always add a unique_id right from the beginning when creating a new sensor. Saves tons of time…