The device is a plain HTTP client. It polls /state every CONFIG_HERDR_POLL_PERIOD_MS (1 s by default) plus one round trip, and asks for /stats only every fifth poll — session figures move slower than the mood, and that endpoint is the expensive one, because the bridge reads the agents' own logs to answer it. The two bodies are the whole contract:

GET /state
{"v":1,"gen":17285,"stale":false,
 "agents":[{"id":"w5:p1","kind":"omp","label":"PoC","status":"working","focus":true}]}

GET /stats
{"v":1,"gen":17285,"stale":false,"sessions":1,
 "totals":{"in":25120,"out":6103,"calls":188,"messages":160,"age_s":1840,"cost_micro":4564666},
 "agents":[{"id":"w5:p1","in":25120,"out":6103,"calls":188,"messages":160,"age_s":1840,
            "cost_micro":4564666,"model":"opus","tok_s":85}]}

Three details carry most of the weight. gen bumps on every successful poll and stale flips true five seconds after the last one, so a client can tell "same picture, re-sent" from "new picture" without diffing. The agent list is sorted before it is sent — blocked, working, done, idle, unknown, ties by pane id — so the first row is always the one that wants attention. And money travels as integer micro-dollars (1_000_000 = $1), which lets the device print two decimals with integer arithmetic and no float drift.

The bridge ASCII-sanitises every string on the way out: herdr prefixes terminal titles with markers like π > or ⠸, and the bundled Montserrat fonts stop at 0x7F, so anything beyond that would render as a missing glyph. Labels are truncated to 40 bytes and model names to 15, for the device's 16-byte buffer.

Failures degrade rather than break. The poller keeps the last agent rows and flips online off after three consecutive failed polls; the renderer then clears the list, because a stale "working" is worse than a blank — but the snapshot is only hidden, not thrown away, so the rows return on the first successful poll. Both HTTP clients pin IPv4 (HTTP_ADDR_TYPE_INET) because the bridge listens on 0.0.0.0 while the router also answers an AAAA for its name, and an unpinned lookup can hand lwIP that one first: a connect timeout that looks exactly like a firewall or a stale address.

Touch did nothing for a whole session while the driver looked healthy, the boot log was clean and the I2C health check said all was well. Three faults were stacked.

The read shape. The AXS5106 answers the vendor's two transactions — write the register address, then read in a separate transaction with a STOP between — and NACKs a read joined to the address phase by a repeated start. A probe that tried all four shapes over a single touch made it unambiguous: two-step 8 and 14 bytes both returned ESP_OK; one-call 8 and 14 both returned ESP_ERR_INVALID_STATE. The returned block decodes to one finger at x=93, y=197. The project keeps the two-step form but now checks the transmit result, so a blind receive never follows an unacknowledged address phase — that is what used to knock the QMI8658A on the same bus out of its own reads. The read is 8 bytes (count + finger 1, registers 0x01–0x08) rather than the vendor's 14: this panel is single-touch, so there is nothing beyond finger 1 to fetch.

The lost release. Reading only on the asserting edge loses the end of a touch, and it fails silently. A release that is not announced as another report leaves the last finger-down sample sitting in the touch handle, and nothing else clears it: the coordinate getter consumes the sample by zeroing the point count. LVGL then held one pointer press that never came up — no tap, no long press, no swipe, with a healthy driver and a clean log. The driver now also reads while its own last report said a finger was down, and treats a read that finds nothing pending as the release (finger up (no report pending)).

The pulse. The controller announces a report with a short pulse, not a held level, so a driver sampling the INT level from LVGL's indev timer saw roughly one touch in eight — and the one it did see worked perfectly end to end, which made a missed report look like a gesture-recognition bug. The driver now registers an ISR on the falling edge and reads when the ISR flag is set, or the line freshly asserts (a missed edge, or a held line), or the last report said finger down. Init logs report interrupt registered on GPIO 21, so the running image says which mechanism it has.

Two smaller things came out of the same hunt. Reading on every poll — the vendor IDF driver's behaviour — gets every read NACKed at idle and lets the controller latch into a state it does not recover from, so an idle panel must not be polled for data. And reset timing is now the vendor's own Arduino timing, 200 ms asserted and 300 ms settle: the earlier 10 ms pulse brought the controller up far enough to ACK and report a point count while leaving its coordinate registers at zero, which is exactly where the (172,0) coordinates came from.

Worth knowing before trusting a clean boot: the vendor's touch_axs5106_init() is literally return ESP_OK; — no chip-ID check — and its i2c_write() had its body commented out and fell off the end of a non-void function. A clean boot proves nothing about the panel; only a press does. A failed read is retried once 3 ms later, and eight consecutive failures reset the controller through its reset pin — this part has one, unlike the IMU.