jensandClaude Sonnet 5
7ebd2aaa63
--reset still reliably clears the lockout on v1.15, same as v1.14. A plain reconnect without --reset now succeeds intermittently (1 of 3 trials) where it always failed before, but that's unreliable enough to flag as a remaining race condition rather than a fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GpePKZiEZWbGo9HrfuML6U
2.8 KiB
Hendi remote-control lockout findings
Reproduced and verified on real hardware using scripts/hendi_ctrl_app.py's
--trigger-error-state, --reset and --test-heater flags, across three
firmware versions (getSoftwareVersion() / I?+V? via
components/actor/hendiCtrl.py).
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 - v1.12 vs v1.14 vs v1.15
v1.14 flashed via --update-firmware HendiCtrl_0114.srec; v1.15 via
HendiCtrl_0115.srec. getSoftwareVersion() confirmed each version after
flashing.
| Recovery method | Mechanism | v1.12 (original) | v1.14 (firmware fix) | v1.15 (firmware fix) |
|---|---|---|---|---|
Plain reconnect, no --reset |
Fresh serial connection only, no DTR/RTS toggle | Fails | Fails - unchanged, a bare reconnect alone still does not clear the lockout | Intermittent - recovered on 1 of 3 isolated trigger/reconnect cycles, failed the other 2; not a reliable recovery path |
--reset, isolated process |
Soft reset via DTR/RTS toggle, no power loss | Fails (one fluke recovery when combined with --test-heater in the same process/connection - not reproducible in isolation) |
Recovers - reproducible across two independent trigger/reset/verify cycles | Recovers - reproducible across all trigger/reset/verify cycles run |
| Physical power cycle (device knob) | Full power-off/on of the unit | Recovers | Not retested (superseded by --reset working) |
Not retested (superseded by --reset working) |
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 reliably.
Firmware v1.14 fixes this partially: a soft reset (--reset, i.e.
toggling the DTR/RTS line) now reliably clears the lockout, confirmed across
two independent trigger/reset/verify cycles - no physical power cycle
needed. However, a plain reconnect without --reset still does not clear
it, so the fix specifically ties recovery to the DTR/RTS reset line rather
than to any new connection.
Firmware v1.15 keeps --reset working reliably, same as v1.14. It also
introduces an intermittent plain-reconnect recovery (1 of 3 isolated trials)
that v1.14 didn't show at all - but since it fails the majority of the time,
it should be treated as a remaining bug/race condition rather than a fix,
and --reset is still the recommended recovery path.