Repository navigation
Investigate Zone Configurator failure to persist manual mappings after EPL entity renaming - #420
Merged
EverythingSmartHome merged 1 commit intoOct 29, 2026
Conversation
…r EPL entity renaming
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
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.
Summary
Entities a user maps manually in the Discovering Entities dialog are now saved correctly, kept on reload and re-sync, and never overwritten by auto-matches. Entities renamed in Home Assistant can still be matched automatically, assuming HA's registry keeps their original IDs (see the steps below).
Manual choices are saved as chosen
Manual overrides used to be written into the nested mapping under their template key. The flattening loops that run afterwards (
settingsEntities,zoneConfigEntities,trackingTargets, polygon groups) then wrote the auto-matched values over the same stored keys. Sensors could also end up withpresenceandpresenceEntitypointing at different entities. So a manual choice on an auto-matched field was lost, while one on an unmatched field such as Presence survived.The new
frontend/src/utils/manualOverrideMapping.tsfixes this:templateKeyToStorageKeyconverts template keys to stored keys (e.g.settingsEntities.maxDistance→maxDistance,trackingTargets.target1.x→target1X).applyOverridesToFlatMappingsruns after all flattening inhandleContinue, so manual choices are written last. Alias keys already present (presence/presenceEntity,distanceMinEntity/mmwaveDistanceMin) are updated too.applyOverridesToNestedMappingsupdates every nested copy of an overridden field in the mappings passed to the room or wizard. It works on a deep copy, so the discovery result is never mutated.Verification
everything-presence-mmwave-configurator/backend, runnpm ci && npm test. All tests should pass, includingsrc/domain/entityDiscovery.test.ts. Then runnpm run build;tscshould report no errors.everything-presence-mmwave-configurator/frontend, runnpm ci && npm test. All tests should pass, includingsrc/utils/seedManualOverrides.test.tsandsrc/utils/manualOverrideMapping.test.ts. Then runnpm run buildandnpm run lint; both should succeed.binary_sensor.<node>_occupancy(e.g. tobinary_sensor.prasenzmelder_esszimmer). Open Settings > Re-sync Entities. Presence should be auto-matched to the renamed entity.GET api/device-mappings/<deviceId>), each changed key and its alias (e.g.presenceandpresenceEntity) should hold your chosen entity.