fix(gecloud): honour battery_rate_max over charge_rate's max attribute - #4929
Closed
kennedy-nic wants to merge 1 commit into
Closed
fix(gecloud): honour battery_rate_max over charge_rate's max attribute#4929kennedy-nic wants to merge 1 commit into
kennedy-nic wants to merge 1 commit into
Conversation
For GEC/GEE (GivEnergy Cloud) inverters, battery_rate_max_raw was always derived from the charge_rate entity's max attribute, which reflects a live register limit that GivEnergy's cloud API can read back stale/low (2600W on a 20kW 3-phase inverter). gecloud.py already computes and publishes an accurate battery_rate_max sensor from the device's model/capability data, but it was being silently ignored for GEC/GEE. battery_rate_max now takes priority when configured, fixing charge/discharge being capped at 2600W. Fixes springfall2008#4908. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Djbv5fZh1Nr7MEYF7AqznT
kennedy-nic
marked this pull request as ready for review
September 5, 2026 06:06
Owner
|
Fixed a slightly different way here: #4954 |
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
2 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.
charge_rateentity'smaxattribute, which GivEnergy's cloud API can report as a stale/low value (2600W on a 20kW 3-phase inverter) instead of the real capability.gecloud.pyalready computes and publishes an accuratebattery_rate_maxsensor from the device's model/capability data, but it was being silently ignored for GEC/GEE.battery_rate_maxnow takes priority overcharge_rate'smaxattribute when configured, fixing the incorrect 2600W cap.Precedent: this brings GE-family inverters in line with how
battery_rate_maxalready works for AlphaESS, which is documented as an override, in watts, for the battery's max charge/discharge rate specifically because its API doesn't reliably report one. Same situation here – an untrustworthy API-reported value with a manual correction – so this reuses the existing key rather than introducing a new, differently-named one for the same job.Who this affects: I checked all three default GivEnergy templates (
givenergy_givtcp.yaml/GE,givenergy_cloud.yaml/GEC,givenergy_ems.yaml/GEE) and none of them setbattery_rate_max, commented or otherwise – the GEE template in fact states that apps.yaml entries in that section are ignored entirely in favour of Cloud auto-configuration. So only a user who has deliberately addedbattery_rate_maxthemselves (as this fix requires) would see a behaviour change; anyone on a stock template is unaffected regardless of inverter type.Fixes #4908
Test plan
test_gecloud_battery_rate_max_priorityregression test (GEC uses thebattery_rate_maxsensor; GE still falls back tocharge_rate's max attribute)./run_all --test inverterpasses./run_pre_commit– passes except two pre-existing failures confirmed to reproduce identically on a cleanmaintree, unrelated to this change (a Windows-onlytriage-daemon-testsPOSIX-path bug, and afile-contents-sorterCRLF no-op onrequirements.txt)./run_all --quick– no regressions from this change; two further pre-existing failures confirmed environment-specific to this fresh Windows setup (a missingencoding="utf-8"in an unrelated test helper, and adebug_casesgolden-plan mismatch caused by the compiled prediction kernel not being built here)🤖 Generated with Claude Code
https://claude.ai/code/session_01Djbv5fZh1Nr7MEYF7AqznT