Testing the windup-fix rework live against sude/sud_0030.json surfaced a
distinct bug: a HOLD overshoot from grain-fill-in cooling never decayed -
process_pid()'s pid_outer_y floor clamped to exactly 0.0, so pid_inner
fought the pot's own ambient loss to hold the overshot temperature flat
instead of declining back to setpoint (see docs/overshoot2.png).
Replace the hardcoded 0.0 floor with a configurable Outer.y_hold_min
(default 0.0, backward compatible), set to -0.1 in config.json, both
.tpl templates, and the demo scripts - small enough to avoid
reintroducing the bb5af3c limit cycle while letting HOLD request a
gentle decline matching passive ambient cooling.
Adds TestHoldOvershootRecoversToSetpoint and documents the finding in
docs/overshoot_hold_windup.md's Follow-up section and
components/pid/TODO.md. Confirmed against a live sud_0030 re-run, not
just the unit test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M2ierBoxW3v7nUbDw3M2pE
7.5 KiB
components/pid design backlog
Findings from a design review, refreshed against the current state of
master after the Kalman-filter removal and Smith-predictor rewrite (see
git history for temp_controller.py/temp_controller_smith.py).
-
FSM thresholds aren't configurable. Moved into an optional
TempCtrl.Thresholdsconfig section (HoldIdle,HoldHeat,IdleHeat,IdleHold,HeatHold,HeatIdle), merged overDEFAULT_THRESHOLDS(now intemp_controller_base.py, formerlytc_constants.py) so existing configs without the section keep working unchanged. -
matplotlib imported at module level in production code.
temp_controller.py,temp_controller_smith.py, andkalman.pyused tofrom matplotlib.pyplot import ...just to support their__main__self-test plots. The plotting demos (andkalman_eval.py) moved toscripts/demos/pid/demo_*.py; production modules no longer import matplotlib. -
Three Kalman filters share one tuning. No longer applicable:
temp_controller_smith.pywas rewritten to drop Kalman filtering entirely (see below), so there's no shared tuning to split anymore. -
Pid.scale()is a gain-scheduling hack, not anti-windup. Fixed: removedPid.scale()/self.kentirely.Pid.process(err, d, scale=1.0)now takes the gain multiplier as a plain per-call argument instead of mutable state, so there's nothing to go stale across areset().temp_controller*.pycomputehold_scale = 1.0/heatrate_soll_set if heatrate_soll_set > 0 else 1.0themselves and pass it throughprocess_pid(theta_err, heatrate_err, hold_scale)— the overshoot-compensation scheduling logic now lives entirely in the temp controller, not the genericPidblock. -
No automated tests for the heat-rate filtering or Smith correction specifically. An earlier
tests/components/pid/suite (stdlibunittest, no pytest) covering FSM transitions, anti-windup clamping, and Kalman convergence was removed before the Kalman-filter removal/Smith rewrite. A newtests/components/pid/suite was added alongside the HOLD-windup fix below (test_pid.py,test_temp_controller_closed_loop.py) covering theyi_maxclamp and closed-loop disturbance/ramp/transition behavior, but_compute_heatrate()'s backward-difference + low-pass filtering and the two-model Smith correction itself still have no dedicated coverage. This drives a physical heater — worth extending. -
set_model_powerisn't defined on every controller, butbrewpi.pywires it unconditionally.brewpi.pyalways doesheater.set_on_changed("power_set", tc.set_model_power)regardless ofController.pid_type. Onlytemp_controller_smith.py(the Smith predictor) definesset_model_power;temp_controller.py("Normal") does not, so starting the server with"pid_type": "Normal"crashes at wiring time withAttributeError: 'TempController' object has no attribute 'set_model_power'. Either add a no-opset_model_powertoTempControllerBase, or only wire it when the configured controller actually exposes a model to feed. -
Config access is unchecked
dict[key]everywhere.params['Hold'],params['Td'], etc., throughout, with no schema validation at load time. We already hit this bug class once (config.json.sim'sgain/Modelnesting mismatch). A small schema/dataclass validation layer at config-load would surface errors immediately instead of mid-__init__— and would have caught the deadTempCtrl.Kalman/Model.kn/Plant.knkeys that used to sit unused inconfig-sim.json.tpl/.sim(since deleted), and theModel.gain/Plant.gainkeys that did the same inconfig.json.simbefore that file was removed entirely —Potdroppedgainentirely, seecomponents/plant/TODO.md. -
pid_heatcan wind up during aHOLD-state disturbance with no anti-windup engagement. A cold-water disturbance while holding drovepid_heat's integral term up without ever saturatingy(peaked aty≈0.74of the1.0ceiling), so the existing back-calculation anti-windup (Pid.process(),pid.py:45-48) never triggered — the FSM never even leftHOLD(diffstayed underHoldHeat=1.0). The resulting overshoot took ~35s+ to unwind naturally. A flatyi_maxclamp was considered and rejected: sustaining a genuine 1.5 K/min ramp needsy≈0.7-0.75fromyialone at steady state, the same range the disturbance itself peaked at, so no single clamp value can suppress the windup without also capping legitimate ramps. An FSM-gating alternative (freeze the loop's output inHOLDunless engaged) was also superseded. Fixed: renamedpid_hold/pid_heat/pid_cooltopid_outer/pid_inner/pid_inner_cool(matching what actually runs when), and split the inner loop's config intoInner.Heat/Inner.Hold/Inner.Coolso the same PID instance gets a tightyi_maxonly whileHOLDis driving it and stays unclamped for realHEATramps — no freeze/thaw, bumpless transfer preserved for free. Seedocs/overshoot_hold_windup.mdfor the full writeup, anddocs/fsm_states.pngfor a static screenshot of the FSM-states panel of the cascade architecture diagram (states/thresholds, and the HOLD→HEAT no-reset note). The full interactive diagram (signal-flow cascade + FSM inset + config-mapping table) is a Claude Artifact, not a repo file: https://claude.ai/code/artifact/a32e4752-b4a6-4153-b344-eb2423eb6512 — only reachable by whoever has access to the Claude account/session that created it, not a durable link for the team;docs/fsm_states.pngis the durable copy. This was also a breaking config change (Hold/Heat/Cool→Outer/Inner.*) —config.json, the templates, and the demo scripts were all migrated. Test coverage (closed-loop disturbance/ramp/transition cases) was added undertests/components/pid/— see the "No automated tests" item above. -
HOLD overshoot was a permanent steady-state offset, not just a transient windup. Found testing the rework against a real Sud run (
sude/sud_0030.json): a grain-fill-in disturbance during aHOLDovershot by ~0.4°C (under theHoldCoolthreshold, so the FSM stayed inHOLD) and then never converged back —temp_istsat in a 55.3-55.4°C band for the rest of the 20-minute hold instead of returning to 55.0. Cause:process_pid()'s HOLD-state floor onpid_outer_yclamped to exactly0.0, so once overshot,heatrate_soll= 0 ("hold flat") andpid_inneractively fought the pot's own ambient loss to keep the overshot temperature flat instead of declining back to setpoint. Fixed: the floor is now a configurableOuter.y_hold_min(default0.0, backward compatible), set to-0.1inconfig.json/both.tpltemplates, letting HOLD request a gentle decline that roughly matches passive ambient cooling without reopening thebb5af3climit cycle (fully unclamped negative). See the "Follow-up" section indocs/overshoot_hold_windup.mdandTestHoldOvershootRecoversToSetpointintests/components/pid/test_temp_controller_closed_loop.py. -
kalman.pyis now dead code in production. Neithertemp_controller.pynortemp_controller_smith.pyusesKalmananymore; the only remaining references arescripts/demos/pid/demo_kalman.pyanddemo_kalman_eval.py. Decide whether to keep it as a documented standalone filtering example or delete it along with the demos.