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
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.