jens/brewpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: update hendi lockout findings with v1.15 retest results

Browse Source 
--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
This commit is contained in:
jens
2026-07-02 18:19:06 +02:00
co-authored by Claude Sonnet 5
parent bc0aeb0ffd
commit 7ebd2aaa63
1 changed files with 16 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/hendi_lockout_findings.md
+16 -9
View File
@@ -1,7 +1,7 @@
# 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 two
`--trigger-error-state`, `--reset` and `--test-heater` flags, across three
firmware versions (`getSoftwareVersion()` / `I?`+`V?` via
`components/actor/hendiCtrl.py`).
@@ -11,16 +11,17 @@ 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
## Recovery attempts - v1.12 vs v1.14 vs v1.15
v1.14 flashed via `--update-firmware HendiCtrl_0114.srec`;
`getSoftwareVersion()` confirmed `v1.14` afterward.
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) |
|---|---|---|---|
| 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 |
| `--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 |
| Physical power cycle (device knob) | Full power-off/on of the unit | **Recovers** | Not retested on v1.14 (superseded by `--reset` working) |
| 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
@@ -40,3 +41,9 @@ 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.