Report the standby state that Init() actually wrote - #75
Merged
BorisBrock merged 2 commits intoAug 4, 2026
Merged
Conversation
Init() writes register 258 to configure standby, but it did not record what it wrote. mStandbyEnabled therefore kept its header default of true while the register held the opposite, since AllowStandby is false. GetStandbyEnabled() reads the register on every publish and corrects the flag, so the mismatch normally lasts less than a publish cycle and is invisible. It stops being invisible when reads fail: the getter then falls back to the flag and returns the stale default, so the Standby Mode entity reports enabled while the wallbox has standby suppressed. That is the state described in the second half of issue BorisBrock#72, alongside the plug state reading "disconnected" for the same reason. The underlying cause there was the Lilygo RTS pin, fixed in 4.0.1; this only stops one of its symptoms from misreporting. Init() now stores the value it wrote, on success only. The transition check in SetStandbyEnabled is deliberately left alone. It is safe because GetStandbyEnabled() keeps the flag in sync with the register on every publish, and because a failed write leaves the flag unchanged, so repeating the command still writes.
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.
Init() writes register 258 to configure standby, but it did not record what it wrote. mStandbyEnabled therefore kept its header default of true while the register held the opposite, since AllowStandby is false.
GetStandbyEnabled() reads the register on every publish and corrects the flag, so the mismatch normally lasts less than a publish cycle and is invisible. It stops being invisible when reads fail: the getter then falls back to the flag and returns the stale default, so the Standby Mode entity reports enabled while the wallbox has standby suppressed. That is the state described in the second half of issue #72, alongside the plug state reading "disconnected" for the same reason. The underlying cause there was the Lilygo RTS pin, fixed in 4.0.1; this only stops one of its symptoms from misreporting.
Init() now stores the value it wrote, on success only.
The transition check in SetStandbyEnabled is deliberately left alone. It is safe because GetStandbyEnabled() keeps the flag in sync with the register on every publish, and because a failed write leaves the flag unchanged, so repeating the command still writes.