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):
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.
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.
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.
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
@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
If I want to change logging levels, to temporarily investigate something, two HA restarts are needed last I checked, (The 2nd one is need3d to turn logging back down).
Thanks - I hadn’t seen that. There is documentation, like the MQTT logging page, that only show changing logging via configuration entries. MQTT Logging - Home Assistant
(Note the MQTT logging page is linked from the list of topics on the right hand side of all docs pages, so it isn’t exactly an obscure documentation reference.)
home assistant docs are separated per integration. If you want to read up on logger functionality, you go to the logger integration docs, not the MQTT integrations docs.
Totally correct. That being said, this is kinda a WTH IMO. Debug logging is a handy tool to have in your toolkit when facing issues and it currently requires a lot of insider knowledge to turn it on.
I made a separate WTH about this @rct . It’s not a restart issue so it’s off topic here but I agree it is unnecessarily confusing.
I was going to mention that, this is the only drawback and not so clear in the docs that you need to do it for the services to work, when I ask people for logs I do ask them to add the loggers to configuration.yaml and restart core mainly because I don’t know if they have it already.
I wonder if we can convert the logger to config flow so it would be possible just to add it and maybe even select components from the UI… I will try to discuss it with other members.
Thanks. So your earlier post wasn’t quite correct, as at least one restart is needed (after you figure all of this out).
Would it be possible to have a reload configuration option that rescans the configuration files and loads new integrations that haven’t previously been loaded?
I understand the issue that reload support is needed in each integration for a reload everything to work. However, if an integration hasn’t been loaded yet, that problem wouldn’t apply and possibly a few restarts could be avoided.
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!