You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Docs: Hanchu, Predbat clears all six app time slots when it takes control #5668
The component writes all three charge and all three discharge slots, setting unused ones to 00:00–00:00, so anything a user has set in the Hanchu app is cleared as soon as Predbat takes control. Worth a line in the Hanchu docs/template for users moving from app-based schedules, so they aren't surprised their slots disappear.
🤖 Automated first-pass triage — a maintainer will review before any action is taken.
Classification: documentation request (enhancement) — the behaviour it describes is real, deliberate and confirmed in the code, so this is a wording addition, not a bug.
What I verified against current main (v9.4.2-13-gb743b502, which includes the Hanchu component from #5305):
The premise is correct, and intentional on the component's part. apps/predbat/hanchu.py:1407-1409 (build_write_payload docstring) states: "Every one of the three charge and three discharge slots is written, and any the plan does not use is set to 00:00-00:00 — User-defined mode runs all six, so a slot left over from the Hanchu app would otherwise fight the plan." The implementation matches: _slot_pairs() pads each direction to three pairs with the disabled sentinel (HANCHU_SLOT_DISABLED = 0, i.e. 00:00-00:00: hanchu_const.py:292, hanchu_const.py:416), and build_write_payload() writes all six start/end keys (hanchu.py:1445-1448).
The headline's timing is also accurate: nothing is cleared at startup or while monitoring only. Slots are written only after control has been requested for a serial (control_active, hanchu.py:228-231), so app-set slots survive until Predbat actually takes control — the first schedule write.
One suggestion for the docs line: it should carry the reason alongside the warning — in User-defined mode any leftover enabled app slot runs alongside Predbat's plan and would fight it, which is why unused slots are zeroed rather than left alone.
Where the line fits: the native component has no dedicated docs section yet — the "Hanchu iESS" section in docs/inverter-setup.md covers the older service-API bridge (hanchu_cloud.yaml), which already notes slot zeroing as its disable mechanism (inverter-setup.md:879). Users of the native component read templates/hanchu.yaml, so a short block there near hanchu_control_enable (around line 52) is the natural home — the template already uses that style for its "IMPORTANT" work-mode note.
Activity
springfall2008 commentedon Oct 20, 2026
🤖 Automated first-pass triage — a maintainer will review before any action is taken.
Classification: documentation request (enhancement) — the behaviour it describes is real, deliberate and confirmed in the code, so this is a wording addition, not a bug.
What I verified against current main (v9.4.2-13-gb743b502, which includes the Hanchu component from #5305):
apps/predbat/hanchu.py:1407-1409(build_write_payloaddocstring) states: "Every one of the three charge and three discharge slots is written, and any the plan does not use is set to 00:00-00:00 — User-defined mode runs all six, so a slot left over from the Hanchu app would otherwise fight the plan." The implementation matches:_slot_pairs()pads each direction to three pairs with the disabled sentinel (HANCHU_SLOT_DISABLED = 0, i.e. 00:00-00:00:hanchu_const.py:292,hanchu_const.py:416), andbuild_write_payload()writes all six start/end keys (hanchu.py:1445-1448).control_active,hanchu.py:228-231), so app-set slots survive until Predbat actually takes control — the first schedule write.One suggestion for the docs line: it should carry the reason alongside the warning — in User-defined mode any leftover enabled app slot runs alongside Predbat's plan and would fight it, which is why unused slots are zeroed rather than left alone.
Where the line fits: the native component has no dedicated docs section yet — the "Hanchu iESS" section in
docs/inverter-setup.mdcovers the older service-API bridge (hanchu_cloud.yaml), which already notes slot zeroing as its disable mechanism (inverter-setup.md:879). Users of the native component readtemplates/hanchu.yaml, so a short block there nearhanchu_control_enable(around line 52) is the natural home — the template already uses that style for its "IMPORTANT" work-mode note.Related to the Hanchu family: #5305, #5664, #5665, #5667.
No priority set (documentation request).
fix(hanchu): event-loop write fix, #5672 review fixes, model ratings,…