Conversation
The open quarter only holds the energy accumulated so far, so it has to be completed before it is comparable with the closed 15-minute cells. Scaling it (value * 900 / seconds) divides by a small number early in the quarter -- an energy sensor reporting every 30 s leaves ~0 kWh over the first minute, which collapsed the point and made the forecast hand-off read as a spike -- and dropping it below a minute of coverage punched a 30-minute hole straddling the now marker, since both the observed and the forecast path lose that index. Complete it from the previous closed quarter instead: energy already seen plus that quarter's share of the time still to come. Continuous at both ends (all of the previous quarter at 0 s of coverage, all of the observed value at 900 s), and it never divides by a small number. Measured against a live snapshot at 18:20 with 332 s of coverage: the anchor goes from 0.245 to 0.337 kWh against a next forecast point of 0.331, turning a +35% step into -2%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The driver derived min_charge/discharge_power_w from the max_charge_power register's min (800 W on v2/v3). That is only the lowest ceiling the user may configure, not a power the hardware refuses to deliver: the setpoint registers (set_charge_power/set_discharge_power) accept 0 on every model. Read the floor from the setpoint registers instead, so it is 0 for all Marstek versions. Predictive charging falls back to its designed floor (user PD minimum, else the 100 W relay hold) and the thermal derate is no longer pinned at 800 W. Peak shaving does not read this capability and is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Venus A/D fills coupled packs sequentially, so the aggregate SOC and top-cell voltage can reach their ceiling while later packs are still charging. Discover and poll populated pack SOC registers, use the least-full pack for charge completion and BMS-cutoff arming, and the fullest pack for discharge limits while preserving aggregate behavior when pack telemetry is absent. Correct the Venus A/D aggregate SOC and stride-100 per-pack cell layout in registers.md, add translated diagnostic sensors, and cover pack discovery and control behavior with regression tests.
The 28-day quarter-hour profile was discarded whenever its configuration fingerprint moved. Two ways that hurt: - The fingerprint hashed the raw excluded-device fields, so the options form rewriting its own defaults (`ev_charger_no_telemetry` absent vs `false`) read as a source change. Walking the excluded-devices section without touching anything wiped a month of capture, and only what Recorder still held came back. - Even a real source change discarded everything, which costs far more than the small bias of mixing derivations. Learned days now survive every integration setting. A source change only breaks sample continuity — so the first reading under the new sources is a baseline, not a trapezoid spanning both — and starts a backfill of what is missing. The fingerprint stays, normalized by meaning rather than key presence, purely to detect that. A timezone change no longer discards the days either: `rebin_days_to_timezone` re-expresses each stored bin in the new zone through the same `_local_segments` splitter the capture path uses, carrying energy across the local-date boundary. The two edge days keep only part of their hours and are left incomplete on purpose, so Recorder backfill re-fetches them. An autumn repeated hour was already merged into one bin by capture, so it moves an hour early once a year; only a stored zone name that no longer exists still forces a fresh learn. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two independent gates kept the learned quarter-hour curve unusable. Maturity demanded two samples of the *same* weekday for 75% of the requested intervals, which a seven-day history cannot hold: the curve took a fortnight to appear and then vanished on whichever weekday held a single sample. Matching weekday/weekend samples now satisfy the gate, which the per-interval blend already fell back to. Learning itself was gated on the runtime switches: the 23:55 snapshot and the Recorder backfill of the consumption, legacy and solar histories all checked predictive_charging_enabled, so a user who enabled the feature later started from DEFAULT_BASE_CONSUMPTION_KWH sentinels with an unseeded profile. The caller already gates by configured presence; the inner value gates are gone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Days recorded at a wrong scale held the relative-energy median so high that every correct day after them was rejected. That also hid the new scale from the capacity-regime detector meant to retire the old one, which only looks at days that pass the very gate the old days were failing, so the profile expired as stale and could never heal itself. The relative-energy reference is now the newest days only, so a changed scale ages out. The regime change then carries the whole trailing run of days already matching the new peak into the new generation and marks only the boundary day as a transition: marking all three confirming days excluded their bins and left the new generation with no shape at all. Solar diagnostics gain a per-day admission verdict, so a rejected day names its own reason instead of only showing up as a lower count. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The SOC setpoint is a sub-feature of Charge Delay: is_charge_delayed() returns early and refresh_setpoint_blocks() clears its blocks when the delay switch is off. The Daily Operation timeline instead read _delay_soc_setpoint_enabled on its own, so an install with the delay off and "minimum SOC before delay" still on painted CONTEXT_SETPOINT (the mdi:target mark) on the live cell, on the projected cells and in the published setpoint metadata. Gate it once in _daily_operation_setpoint_enabled(), used by all three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Release/v1.4.0
Resolve the .gitignore conflict by preserving local Codex directory exclusions and upstream generated-report exclusions.
Document Huawei SUN2000 and LUNA2000 setup in English and Spanish, including Modbus proxy and control-path requirements. Add Huawei to the site navigation, supported-hardware listings, installation requirements, and README.
A battery that did not answer during setup raised ConfigEntryNotReady, which takes the whole config entry down: every other battery, the controller and the dashboard disappeared with it, and Home Assistant retried setup in a loop for as long as the device stayed off. A battery left on its side switch was enough. The unreachable battery is now set up unreachable instead. It is created with an empty telemetry snapshot and a seeded failure counter, so it shows up in non_responsive_battery_names, the non_responsive_batteries sensor and diagnostics from the first moment rather than looking healthy. Adopting it later cannot be done from the coordinator alone: the hardware configuration write, the driver's connect-time entity definitions (model detection, pack discovery) and the first telemetry read all happen in setup, and entities cannot be added to a platform that already finished setting up. The coordinator therefore schedules one entry reload the first time the battery answers, from either recovery path (a fresh reconnection or a plain successful poll). The flag is one-shot; the reloaded runtime re-arms it only if the battery is unreachable again. Two adjacent failure modes come with it: - A driver whose connect() raises rather than returning False (huawei reads telemetry, esphome resolves entities, zendure/sessy do aiohttp work) escaped the setup try block and left the entry in ERROR with no retry. It is now treated as "not there", like a refused connection. - The interrupted-active-balance migration hands off through the hardware. On an unreachable battery that path fails and latches manual mode into the entry data, freezing the battery once it returns. It now waits for the reload.
Feature PRs must link an approved discussion or issue; bug fixes need no prior approval. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix: keep the system up when a battery is switched off at start-up
…ry-setup" This reverts commit 9206f6f, reversing changes made to 73ee0a83f8f5d4c7b0e3e0a5b8e8f0d3f4e5a6b7. Not a rejection of the change: it targeted main, but feature work lands on the release branch here. It now lives on release/v1.5.0 (9979a81) together with its follow-up fixes, and main picks both up with the release merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…arging power was used, which resulted in unrealistically short charging durations and caused the charging process to start too late. With this change, the forecasted solar yield is now used to determine the charging duration.
|
Thanks for digging into this — the diagnosis in the first commit is real: I checked both commits in a worktree against the test suite (64 tests green on your branch). 1. The branch needs a rebaseThe PR is opened from your fork's 2. "Unify the calculation of charging efficiency" — please drop this commit
The delay breaks at dawn on a day the sun would have covered easily. The tell is already in the PR: four existing cushion tests had to be retuned ( The new test doesn't cover the change either. With the AC conversion disabled, If the forecast looks too optimistic in practice, that's a tuning discussion on 3. The time-backup commit is a no-op at the default safety marginI replaced The reason: So the improvement you saw at home most likely came from the efficiency commit, by accident. Two more things on that commit:
Also, What I'd need to merge
Minor: the new comment blocks run ~20 lines for 6 lines of code, well above the density of the rest of the file. Happy to keep the reasoning, just shorter. |
4 participants
What
When calculating the required charging duration, the maximum rated charging power was used, which resulted in unrealistically short charging estimates and caused the charging process to start too late.
With this change, the forecasted solar yield is now used to determine the charging duration.
Unifies the calculation of charging efficiency
Approved roadmap item
Discussion / issue: #
Tests
Tested on my setup at home