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…
Now I reload much often because the OS reminds me and does it almost automatically. I have screenshot from last year. Is this issue still valid? Then it should have its own WTH.
Integrations in need of reload capabilities (and other modernization): Alerts, history stats, utility meter, logging
Edit: And of course recorder - WTF there's no option to reload recorder configuration from the UI/without a restart
1 Like
All SNMP sensors, switches etc need restart ):
18/25 of the integrations I use in the UI have the reload option… Of those very few of them ever seem to actually get fixed or update from issuing the reload… Most of the time I end up having to reboot HA even though the problem seems to be a DSM device not showing up or a HomeKit device acting up etc.
So ya, need to restart all of HA OFTEN.
1 Like
HA not, devs can. but likely doesn’t care.
HA is built in a way that all modules are part of single runtime. When HA core starts all its modules are being included and started too.
HACS and its custom components ‘pretend’ to be just another modules of HA. Which obviously require restart of HA to be run.
But it’s not true modules couldn’t be initialized independently, added during HA runtime etc. But it requires programming effort (and likely strategic decisions of HA owners prior to that).
As long as HA is a monolith it will require restart to run its modules. Vote for changing HA architecture in WTH
2 Likes
@frenck I do think it is possible to add options to update custom integrations without the need to restart core:
- Update - Unload the entries created by the integration (same as the existing implementation) and reload the integration (similar to what happens when a user adds an integration), of course this relies on the integration to unload correctly, but is possible.
- Remove - Just unload (user needs to delete the files after or it will be reloaded after restart)
- Add : two options:
a. Add button to rescan custom integrations and load newer integrations
b. When user clicks on the “Add integration” button, rescan custom integration folders and load new integrations
1 Like