Fix Home Assistant discovery: entity IDs and retained config - #73
Merged
Merged
Conversation
Home Assistant validates default_entity_id with cv.entity_id, which lowercases the value and then requires the form "domain.object_id". All 15 discovery payloads supplied a bare object id such as "%_charging_power", so every one failed validation and the entity fell back to Home Assistant's placeholder name, producing sensor.unnamed_device, sensor.unnamed_device_2 and so on. Because the integration supplies an entity id at all, Home Assistant also treats these ids as explicitly chosen, so the device page's "Recreate entity IDs" action reports "No renamable entity IDs" and refuses to correct them. The domain is taken from the discovery topic each payload is published to, so the two cannot drift apart. The switch payload for Enable Charging was also missing the underscore separator that every other entity uses; only the default_entity_id is corrected here, its unique_id is deliberately left alone because changing that would orphan the entity for existing installations. Note for existing installations: entity ids are sticky once registered, so this does not rename anything that already exists. Affected users need to delete the MQTT device in Home Assistant and let discovery recreate it.
Discovery is only published from OnMqttConnect, i.e. when this device connects to the broker. Published unretained, the messages are delivered only to subscribers that happen to be listening at that moment, so a Home Assistant instance that restarts afterwards finds nothing under homeassistant/+/+/config. Entities that publish state continuously appear to survive this, but everything with a command_topic (both switches and the number) stays "unavailable" until this device happens to reconnect, which in normal operation may not be for days. Retained discovery is delivered as soon as Home Assistant subscribes.
Owner
|
Thank you for the contribution! |
sadilek
added a commit
to sadilek/HeidelBridge
that referenced
this pull request
Aug 4, 2026
Comment-only: trims the explanatory comments to match what was submitted upstream, after Boris deleted the equivalent comment when merging BorisBrock#73. No functional change, so the running firmware does not need reflashing.
sadilek
added a commit
to sadilek/HeidelBridge
that referenced
this pull request
Aug 4, 2026
…rock#75, BorisBrock#76) into kupa5 Our three fixes are now upstream, so the fork no longer carries them. Boris made two edits when merging: ClampToWallboxRange and WriteCurrentLimitRegister moved from a file-local anonymous namespace to private members of HeidelbergWallbox, and InitialChargingCurrentLimitA is now defined as MaxChargingCurrentA instead of repeating 16.0f. Conflicts resolved in favour of upstream throughout, except for two items that stay fork-specific in MQTTManager.cpp: - The Enable Charging unique_id keeps its underscore. Upstream still has "%control_enable_charging"; reverting ours would orphan the existing entity in Home Assistant and break the automation that references it by entity id. - The diagnostic echo to {DeviceName}/internal/last_command is kept. It is not upstream and is deliberately not proposed, since it adds public topic surface. Also adopted from upstream: the discovery publish retry (publish() can silently return 0 when the TCP send buffer is full) and the Last Will plus availability_topic on every entity, which together complement the retained discovery from BorisBrock#73.
sadilek
added a commit
to sadilek/HeidelBridge
that referenced
this pull request
Aug 4, 2026
All three fixes are upstream now, so the "candidates for a PR" framing was stale. Replaced with a short history keyed to BorisBrock#73/BorisBrock#74/BorisBrock#75, plus Boris's edits when merging: the two helpers became private members, and InitialChargingCurrentLimitA is defined as MaxChargingCurrentA. Added an explicit list of what kupa5 still diverges on, so a future upstream merge does not discard it: the Enable Charging unique_id underscore (reverting would orphan the Home Assistant entity the automation references) and the diagnostic echo topic.
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
3 participants
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.
Two problems with the discovery messages.
All 15 payloads set
default_entity_idto a bare object id, e.g."%_charging_power". Home Assistant validates that field withcv.entity_id, which requiresdomain.object_id, so every payload fails validation and a fresh install getssensor.unnamed_device,number.unnamed_deviceand so on. It also can't be repaired from the UI: because the integration supplies an entity id at all, HA treats the ids as explicitly chosen and "Recreate entity IDs" reports "No renamable entity IDs". The fix derives the domain from the discovery topic so the two can't drift apart. (The error quoted in #58 is againstnumber.unnamed_device— that issue was about the value and is correctly fixed; the naming just went unremarked.)Discovery is also published unretained. Since it is only sent from
OnMqttConnect, a Home Assistant restart finds nothing underhomeassistant/+/+/config. Sensors disguise this by publishing state continuously, but everything with acommand_topic— both switches and the number — staysunavailableuntil the device reconnects.Entity ids are sticky once registered, so this renames nothing that already exists. Affected users need to delete the MQTT device and let discovery recreate it; worth a line in the release notes.
Not included: the
Enable Chargingunique_idis missing the underscore every other entity has. I fixed only itsdefault_entity_id, since changingunique_idwould orphan the entity and lose its history. Happy to send thatseparately.