Repair entity ids that carry the device name twice (3.0.0b2) - #25
Merged
Merged
Conversation
Upgrading from 2.x produced ids like sensor.hall_hall_ip_address. Fresh installs are unaffected: on one instance, same version, a device added fresh got sensor.hub_ip_address while three upgraded ones doubled. So it is specific to that upgrade, not to the sensor code. Not reproduced outside a real upgraded instance. A clean registry, a registry pre-populated with 2.6.0-style entities, and a check for colliding ids all generate correctly, so there is no root cause to fix with confidence. This repairs the result instead, which is deterministic and testable. The rename keeps the unique_id, so recorder history follows the entity to its corrected id. Only entities this integration created are touched, only where the doubled prefix is present, and only when the target id is free. Cosmetic throughout: the displayed name, state and history were always correct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrading from 2.x produced diagnostic sensor ids with the device name twice:
Cosmetic. The displayed name, state and history were always correct.
What is known
Fresh installs are unaffected. On one instance running a single version, a device
added fresh got
sensor.hub_ip_addresswhile three devices upgraded from 2.xdoubled. So it is specific to the upgrade, not to the sensor code.
What is not known
It has not been reproduced outside a real upgraded instance. A clean registry, a
registry pre-populated with 2.6.0-style entities, and a check for colliding ids
all generate correctly.
Rather than guess at a cause, this repairs the result. The rename keeps the
unique_id, so recorder history follows the entity to its corrected id. Onlyentities this integration created are touched, only where the doubled prefix is
actually present, and only when the target id is free.
Note
Renaming an entity id is user-visible. Anything referencing the doubled id would
need updating, though these sensors only appeared in 3.0.0b1 and are diagnostics,
so that is unlikely.
75 tests. Also on the 4.0.0b1 branch, which carries the same repair.