2026-03-17 GoSungrow default_entity_id for HA#144
Open
Paraphraser wants to merge 1 commit intoMickMake:masterfrom
Open
2026-03-17 GoSungrow default_entity_id for HA#144Paraphraser wants to merge 1 commit intoMickMake:masterfrom
Paraphraser wants to merge 1 commit intoMickMake:masterfrom
Conversation
Home Assistant has been logging errors with the following pattern: ``` The configuration for entity «thing» uses the deprecated option 'object_id' to set the default entity id. Replace the "object_id": "«value»"' option with "default_entity_id": "«value»" in your published discovery configuration to fix this issue, or contact the maintainer of the integration that published this config to fix this. This will stop working in Home Assistant Core 2026.4 ``` [This post](https://community.home-assistant.io/t/mqtt-discovery-information-not-correctly-interpreted/976459/9) says that, rather than **replacing** `object_id`, one way to deal with this problem is to **add** the `default_entity_id` key to the MQTT JSON. My testing shows this is correct. Adding the key has the desired effect of silencing the log messages from Home Assistant, whilst maintaining compatibility for anyone else who may be using GoSungrow in other contexts where downstream processing may assume that `object_id` just won't up and vanish someday to suit the whim of another ecosystem. I have a simple Sungrow environment (SG5.0RS plus meter plus comms) so I can't claim that the patches proposed in this PR, which do work for me, will necessarily work in all environments. The approach I adopted was to observe that, whenever the 'object_id' key was present in an MQTT message, the `unique_id` key was also present, and the two had the same value. I augmented each such instance with the `default_entity_id` key. If anyone comes across situations where Home Assistant is still complaining then please comment on this PR and I will endeavour to nail the sucker. I have updated [the gist](https://gist.github.com/Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37) to remove part 2 (the triamazikamno binaries and associated Docker images won't work post Home Assistant Core 2026.4). I have rewritten part 5 accordingly. Fixes: MickMake#142 MickMake#143 Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com>
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.
Home Assistant has been logging errors with the following pattern:
This post says that, rather than replacing
object_id, one way to deal with this problem is to add thedefault_entity_idkey to the MQTT JSON.My testing shows this is correct. Adding the key has the desired effect of silencing the log messages from Home Assistant, whilst maintaining compatibility for anyone else who may be using GoSungrow in other contexts where downstream processing may assume that
object_idjust won't up and vanish someday to suit the whim of another ecosystem.I have a simple Sungrow environment (SG5.0RS plus meter plus comms) so I can't claim that the patches proposed in this PR, which do work for me, will necessarily work in all environments.
The approach I adopted was to observe that, whenever the 'object_id' key was present in an MQTT message, the
unique_idkey was also present, and the two had the same value. I augmented each such instance with thedefault_entity_idkey.If anyone comes across situations where Home Assistant is still complaining then please comment on this PR and I will endeavour to nail the sucker.
I have updated the gist to remove part 2 (the triamazikamno binaries and associated Docker images won't work post Home Assistant Core 2026.4). I have rewritten part 5 accordingly.
Fixes: #142 #143