Files
brewpi/docs/hendi_lockout_findings.md
T
jensandClaude Sonnet 5 91a1b1ea62 docs: record hendi remote-control lockout findings for firmware v1.12
Baseline for the planned firmware fix: reset/reconnect don't clear the
ungraceful-disconnect lockout, only a physical power cycle does.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpePKZiEZWbGo9HrfuML6U
2026-07-02 17:45:44 +02:00

1.8 KiB

Hendi remote-control lockout findings

Firmware under test: v1.12 (getSoftwareVersion() / I?+V? via components/actor/hendiCtrl.py). Reproduced and verified on real hardware using scripts/hendi_ctrl_app.py's --trigger-error-state, --reset and --test-heater flags.

Trigger

Calling remoteEnable(True) (R1) and then disconnecting/exiting without a matching remoteEnable(False) (R0) - i.e. an ungraceful disconnect while remote control is enabled - puts the device into a locked-out state.

Recovery attempts

# Recovery method Mechanism Result
1 --reset (toggle DTR/RTS reset line) Soft reset via serial control lines, no power loss Fails - remoteEnable(True) still returns HendiException("Communication error") on the next connection
2 --reset immediately followed by --test-heater in the same process/connection Soft reset, then reuse the still-open serial connection Succeeded once, but not reproducible across repeat isolated attempts - not a reliable recovery path
3 Physical power cycle (device knob) Full power-off/on of the unit Recovers - remoteEnable(True) succeeds immediately afterward, heater sweep runs cleanly

Symptom while locked out

  • I? / V? (software identifier/version queries) still respond normally.
  • R1 (remoteEnable(True)) fails with a communication error - this is the only observed symptom, and it blocks any command path that needs remote control enabled (e.g. --test-heater).

Conclusion

On firmware v1.12, only a physical power cycle clears the lockout; neither a serial soft-reset nor a fresh serial reconnect does. This is the behavior the planned firmware fix should address - a graceful-disconnect timeout, an explicit unlock command, or making the DTR/RTS reset line actually clear the lockout flag.