Repository navigation
docs(sigenergy): fix rate automation sensor names, re-apply mode on restart, stop zeroing import limit in freeze - #5464
Draft
chalfontchubby wants to merge 1 commit into
Draft
chalfontchubby wants to merge 1 commit into
chalfontchubby wants to merge 1 commit into
Conversation
…estart, stop zeroing import limit in freeze (#5459) - Rate automations: cap against the plant-level sensor.sigen_plant_ess_rated_charging/discharging_power (what the template's battery_rate_max already uses, and what matches the plant-level limits being written). The inverter prefix with "-ing" suffix used here doesn't exist in the integration. Skip the write if the rate input isn't a number (rather than writing 0kW), and treat an unavailable rated-power sensor as no cap. - Rework the renamed-entities note around the plant/inverter split, and warn that renaming charge_rate/discharge_rate in apps.yaml but not in the automations silently stops them firing. - Restarts: drop initial: from the three helpers so HA restores them instead of resetting them without a state change, and re-apply the mode on HA start and when Remote EMS goes from off to on. A restart at the end of a force export otherwise left the plant on Command Discharging while Predbat already wanted Demand and wrote nothing. Wait for the select and SoC sensor before writing, and make the Freeze Charging pin fall back to 0, not 100: a re-run with SoC unreadable would otherwise pin the cut-off at 99.75% and trigger the documented forced-import firmware bug. - Stop setting grid_import_limitation to 0 in both freeze modes (#4911): the cut-offs enforce the freeze, 0 contradicts Freeze Charging's own definition, and it stalls Sigenergy EV chargers behind the plant CT. Tell existing users to reset it once. - Say that Remote EMS must be on, fix the enable-list entry to the daily_load_consumption name the template uses, and add an optional Remote EMS watchdog. All of this is running on a live Sigenergy system: the import-limit change since 9 Sep, the rest since 9 Oct. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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
Fixes the Sigenergy Sigenstor setup instructions reported in #5459, plus three problems found while checking them against a live system:
sensor.sigen_plant_ess_rated_charging_power/..._discharging_power, as the SigEnergy Sigenstor setup documentation #5459 reporter found and as the template'sbattery_rate_maxalready does.As agreed with @gcoan on #5459, this PR is the write-up of the Sigenergy section: it brings the docs in line with the setup running on the live system.
Detail
Rate automations (#5459).
sensor.sigen_inverter_ess_rated_charging_power(inverter prefix with "-ing" suffix) matches neither of the integration's spellings, so the| floatraisedfloat got invalid input 'unknown'.charge_rate/discharge_rateinapps.yamlwithout changing the automations stops them firing, with nothing reported. That happened on the live system (also flagged by tdbegley28 on Sigenergy template locks grid import to 0 even when EV is charging #4911): the plant sat at a fixed 5.5 kW for months and never received Predbat's rate-0 holds.Restarts.
input_select.predbat_requested_modehadinitial: "Demand", so a restart reset it without a state change and the mode automation never fired. On the live system a restart at 18:59, at the end of an 18:30–19:00 force export, left the plant on Command Discharging. By then Predbat wanted Demand, saw Demand, and wrote nothing, so the battery exported at 5.5 kW from 33% to 22% until it was corrected by hand. The fix:initial:is dropped from the three helpers, so HA restores their state.homeassistant: startand on Remote EMS going from off to on.Import limit in freeze modes (#4911). The charge and discharge cut-offs enforce the freeze; the 0 kW import limit was left over from before #4392. It contradicts Freeze Charging's own definition (house load beyond solar comes from the grid), and it stalls Sigenergy EVAC/EVDC chargers behind the plant CT. Existing users are told to reset it once after updating.
Other changes
sensor.sigen_plant_daily_load_consumption, which is what the template uses.Testing
Documentation only. Every YAML block in the section parses, and the key templates render as expected with sample states, including
unknown/unavailableinputs. Pre-commit passes.The same automations are running on a live Sigenergy system (SigenStor, TypQxQ Sigenergy-Local-Modbus):
Not yet exercised live: the new restart trigger (it needs another HA restart in a non-Demand mode) and the first rate-0 hold reaching the inverter. I'll update here once both have been seen.
Closes #5459
Closes #4911
🤖 Generated with Claude Code