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

docs: record 10s idle-timeout (remote->suspend) findings for v1.16

Browse Source 
Confirmed on hardware: 15s idle while remote-enabled with the heater
on and powered auto-suspends (R? and S? both drop to 0). P? does not
read literal 0 though - it lands on 4095, the raw register's max value
past the calibrated curve's low end, not the digit 0. Any check
expecting P?=="0" to confirm zero power would be wrong on this
firmware; S? is the correct check.

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:51:18 +02:00
co-authored by Claude Sonnet 5
parent 5bc278e875
commit bd6249af6b
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/hendi_lockout_findings.md
+27
View File
@@ -23,6 +23,33 @@ confirmed each version after flashing.
| `--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 | Not retested (superseded by plain reconnect working) | | `--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 | Not retested (superseded by plain reconnect working) |
| 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) | Not retested (superseded by plain reconnect working) | | 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) | Not retested (superseded by plain reconnect working) |
## 10s idle-timeout (remote -> suspend)
Tested on v1.16: with remote enabled (`R1`), the heater switched on (`S1`)
and a non-zero power applied (`P3151`, ~1000W), going idle for 15s with no
further commands sent causes the device to auto-suspend:
| Register | Before idle (`R1`/`S1`/`P3151`) | After 15s idle |
|---|---|---|
| `R?` (remote enabled) | `1` | **`0`** - timer drops remote back to suspend |
| `S?` (switch) | `1` | **`0`** - heater switched off |
| `P?` (power digits) | `3151` (~1000W) | **`4095`** - see note below |
`P?` does **not** read the literal digit `0` after the timeout. The
power/digit mapping is inverted (`components/actor/hendiCtrl.py`'s
`poly_w2d`/`poly_d2w`: higher digit = lower watts, calibrated down to
`pwr_digits_min` = 4092 for the lowest calibrated point, 500W). `4095` is
the raw 12-bit register's maximum value (2^12 - 1), one past the
lowest-calibrated end of that curve (`toWatts(4095)` extrapolates to
~518W) - i.e. the hardware's actual "off" register value, not the number
`0`. Any check that expects `P?` to equal `"0"` to confirm the heater has
zero power would be wrong on this firmware; the correct check is `S?` (or
`P?` >= `pwr_digits_min`).
Device remained healthy afterward - no lockout was triggered, since remote
was already back to `0` (via the timer) before the test script's connection
closed.
## Symptom while locked out ## Symptom while locked out
- `I?` / `V?` (software identifier/version queries) still respond normally. - `I?` / `V?` (software identifier/version queries) still respond normally.