Problem
ParameterManager holds automation parameters in memory only. On restart every parameter reverts to the default declared in the runtime config — silently, with no log line and no operator-visible signal that it happened.
Observed on hardware 2026-08-08: impeller_pwm was set to 100 before an AUTO run; a reinstall restarted the runtime; the value was back at its config default of 255 with nothing said.
Why it matters
The failure is quiet and it points the wrong way. An operator who deliberately turns an actuator down gets it back at the config default after any restart or upgrade — i.e. the direction of the silent change is toward more actuation, not less. For an impeller on a shared 12 V rail that is the largest current transient the machine makes.
It also breaks a reasonable operator model: the HTTP API accepts a parameter write and reports success, so the value looks durable. Nothing in the API or the logs distinguishes "this is set" from "this is set until the next restart".
Compounding: a restart is not a rare event. It happens on every upgrade, every config change applied via install.sh, and every supervisor-driven provider recovery that takes the runtime with it.
The header claims otherwise
core/automation/parameter_manager.hpp:57 documents:
* - Optional persistence back to YAML (disabled by default)
There is no implementation — grep -n persist core/automation/parameter_manager.cpp returns nothing. So the type's own documentation describes a feature that does not exist, which is how a reader concludes persistence is merely switched off rather than absent.
Options, roughly in order of cost
- Say so. Log at INFO on startup which parameters took config defaults, and surface a
persisted: false (or a "defaults applied at ") field on GET /v0/parameters. Cheapest, and converts a silent revert into something an operator can see. Does not fix the loss.
- Persist on write. Write parameter changes to a runtime-owned state file (not back into the operator's YAML, which
install.sh treats as declarative input) and reload it at startup. Needs a decision about precedence when the config default and the persisted value disagree after an upgrade — the config is the operator's declared intent, the persisted value is their live tuning.
- Refuse to actuate on stale defaults. Out of scope here, but worth naming: parameters that drive actuation could require an explicit re-arm after a restart rather than silently resuming from defaults.
At minimum this issue should not close with the header comment still advertising an option that isn't there.
Related
Found during runbook §5 and the E-stop-under-AUTO interaction test on pi-g1, 2026-08-08.
Problem
ParameterManagerholds automation parameters in memory only. On restart every parameter reverts to the default declared in the runtime config — silently, with no log line and no operator-visible signal that it happened.Observed on hardware 2026-08-08:
impeller_pwmwas set to 100 before an AUTO run; a reinstall restarted the runtime; the value was back at its config default of 255 with nothing said.Why it matters
The failure is quiet and it points the wrong way. An operator who deliberately turns an actuator down gets it back at the config default after any restart or upgrade — i.e. the direction of the silent change is toward more actuation, not less. For an impeller on a shared 12 V rail that is the largest current transient the machine makes.
It also breaks a reasonable operator model: the HTTP API accepts a parameter write and reports success, so the value looks durable. Nothing in the API or the logs distinguishes "this is set" from "this is set until the next restart".
Compounding: a restart is not a rare event. It happens on every upgrade, every config change applied via
install.sh, and every supervisor-driven provider recovery that takes the runtime with it.The header claims otherwise
core/automation/parameter_manager.hpp:57documents:There is no implementation —
grep -n persist core/automation/parameter_manager.cppreturns nothing. So the type's own documentation describes a feature that does not exist, which is how a reader concludes persistence is merely switched off rather than absent.Options, roughly in order of cost
persisted: false(or a "defaults applied at ") field onGET /v0/parameters. Cheapest, and converts a silent revert into something an operator can see. Does not fix the loss.install.shtreats as declarative input) and reload it at startup. Needs a decision about precedence when the config default and the persisted value disagree after an upgrade — the config is the operator's declared intent, the persisted value is their live tuning.At minimum this issue should not close with the header comment still advertising an option that isn't there.
Related
impeller_pwm's default from 255 to 100, which reduces the blast radius of a silent revert but does not address the revert itself.Found during runbook §5 and the E-stop-under-AUTO interaction test on pi-g1, 2026-08-08.