puk
December 13, 2024, 8:05pm
1
It’s not clear from the UI what happens when you rename an entity with historical data; it’s also not configurable. Figuring out what it’s usually going to do took a bunch of conversations on discord; I never found it in the documentation (though it could be there now).
It would be great if there was an (optional) UI element that let you configure it. When I rename an entity, sometimes it makes sense to rename the historical data (fixing spelling); sometimes it does not (repurposing a device). Similarly, sometimes when you delete an entity you want to keep the history (device replacement) and sometimes you don’t (device no longer needed).
The UI would probably be slightly more complex for renaming a device with multiple entities, but still seems possible.
Thanks!
puk:
rename an entity
If by “rename” you mean “change entity_id” - check here .
In short - changing “entity_id” causes a new series of data in DB.
petro
(Petro)
December 14, 2024, 1:31pm
3
It doesn’t do that anymore, it just updates the metadata key’s value. Each entity id has an associated metadata key, right now its just an integer. So the states table’s “label” is just an integer. There’s a separate table that stores the entity_id in relation to the metadata key. So when you update the entity_id, the relation is just updated and nothing in the history changes.
e.g.
time (below), metadata key →
24
72
2024-10-10 00:00:00
1
7
2024-10-10 01:00:00
3
4
2024-10-10 02:00:00
4
9
etc
etc
etc
entity_id
metadata key
sensor.abc
24
sensor.xyz
72
etc
etc
OK, then how you can explain this gap:
and another entity_id (renamed) filled DB within this gap.
This is probably how it is supposed to work, otherwise there is no need to use metadata_id as a key. But in fact i got this:
More description was provided here.
These are tests with 2024.12.
If it was changed - then it happened recently.
petro
(Petro)
December 14, 2024, 2:25pm
5
This was changed mid 2023.
And what?)
These are screenshots from DB.
petro
(Petro)
December 14, 2024, 2:29pm
7
The entity_id conversion was changed in 2023, that’s what I’m saying. It’s not a recent change, your history will follow your entity_id renaming using the system outlined above.
But it does not.
The history has a gap.
This gap was filled by another entity.
And there 2 different metadata_id for different entity_id (old & new).
petro
(Petro)
December 14, 2024, 2:32pm
9
Not sure what to tell you. This was added along time ago and it works, whatever you’re doing to rename the entity_id doesn’t allow the function to work.
If you go into the cog wheel on any entity, and adjust the entity_id, the history will follow. Full stop.
This means it’s restricted to UI created entities (or unique_id entities).
I am renaming this entity in more-info.
You have not read the link I provided, it was all described there with screenshots.
petro
(Petro)
December 14, 2024, 2:36pm
12
Then there’s a bug, write it up.
EDIT: Looks like it’s already written up.
EDIT2: And just to prove to you that it was added a long time ago, march 19th 2023 Here’s the PR
home-assistant:dev
← home-assistant:entity_rename_history
opened 09:34PM - 19 Mar 23 UTC
## Proposed change
<!--
Describe the big picture of your changes here to com… municate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue in the
additional information section.
-->
History will now be retained when renaming an `entity_id`
https://community.home-assistant.io/t/wth-when-i-rename-an-entity-most-of-the-time-its-history-is-lost/469199/4
https://community.home-assistant.io/t/rename-entities-while-retaining-history/412589
https://community.home-assistant.io/t/rename-of-sensor-loss-of-history/355122/3
This feature requires up to 24 hours for background data migration to complete after installing 2023.4.0 or later. As with earlier versions, entities renamed before the background data migration completes will not retain history. For the avoidance of doubt, if you want to be sure the history will be retained after an entity_id rename, wait 24 hours after the migration message disappears from the persistent notifications after upgrading to 2023.4.0 or later.
## Type of change
<!--
What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [ ] Local tests pass. **Your PR cannot be merged unless tests pass**
- [ ] There is no commented out code in this PR.
- [ ] I have followed the [development checklist][dev-checklist]
- [ ] I have followed the [perfect PR recommendations][perfect-pr]
- [ ] The code has been formatted using Black (`black --fast homeassistant tests`)
- [x] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [ ] Untested files have been added to `.coveragerc`.
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
[perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr
1 Like
I would definitely agree that using metadata_id as a key was supposed to keep a history consistent after renaming entity_id (wrote here, by the way ).
But now we have what we have. Bug or not, no idea.
Thanks for posting a link to PR.
petro
(Petro)
December 14, 2024, 2:39pm
14
is it retaining the history? No → bug.
Well, technically - yes, a bug)))).
But - it has some positive outcome in some cases.
Can you post a link here?
BTW, I have not seen this “New entity_id is already in use” error when testing with renaming entity_id . Saying this with confidence since I definitely checked Log.
petro
(Petro)
December 14, 2024, 2:44pm
17
I assumed that was the bug that was written up. I have not searched for an issue
Then maybe you are hitting yet another bug.
The bottom line is that the history transfer is not working currently. But the LTS should transfer just fine.
At least that is how it behaved the last time I checked.
1 Like
petro
(Petro)
December 14, 2024, 2:45pm
19
Same here, I’ve even made guides for people so that they could transfer history from 1 entity to another by abusing this system.
OK, I will try to find this issue if it is registered.
Honestly, in a normal scenario I usually rename entity_ids right after installing an integration providing these entities when there is no history accumulated yet. But this functionality should predictably work.