From e8d384e6fc433b66ab7f1fafa202dfe09739f280 Mon Sep 17 00:00:00 2001 From: Duncan Tourolle Date: Thu, 27 Aug 2026 20:00:01 +0200 Subject: [PATCH] A keep-alive on the command channel does not hold the cliff MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `--variant info --keepalive 10`, full run, paddles worked throughout the first 51 seconds and not one button frame after. 51.62s last button frame 51.75s STATUS flag=1 timer=900 61.51s keep-alive #7 sent 61.56s 0x3c reply, device metadata, as if nothing were wrong So the command channel is real and usable — `00 08 00` returns name `Zwift Click`, `0B-34C45903A18E`, version `B.0`, type byte `0x0B` and the address — and the pod goes on answering it *after* the cliff while refusing to report a single button. Which is the sharpest statement of the fault yet: the link is healthy, the device is responsive, and it withholds exactly one capability on a timer. Whatever re-arms that is not a periodic message on this channel, so A-2's "keep-alive" is either a different message or, as A-2 itself says, something that only ever worked for the right-hand pod. Co-Authored-By: Claude Opus 5 (1M context) --- REQUIREMENTS.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md index e8663fb..6d88d83 100644 --- a/REQUIREMENTS.md +++ b/REQUIREMENTS.md @@ -296,6 +296,16 @@ the daily unlock is needed on this path are both answered: it is, and this is th > the `+` pod, which reportedly never needed the blessing, or re-linking the `−` pod inside > its ~50 s window. +> **The command channel works; a keep-alive on it does not help — 2026-08-27.** Writing +> `00 08 00` gets a `0x3c` reply carrying device metadata: name `Zwift Click`, `0B-34C45903A18E`, +> version `B.0`, type byte `0x0B`, address. Sent every 10 s across a full run, the pod +> answered every one — **including after the cliff**, while refusing to report a single +> button. Last button frame 51.62 s, `flag=1 timer=900` at 51.75 s, nothing after. +> +> That is the sharpest framing of the fault so far: the link is healthy, the device is +> responsive, and it is withholding *one capability* on a timer. A periodic message is not +> what re-arms it. + > **Do not send `play-rideon` casually.** It reliably blanks the pod's output stream and > costs a recovery wait. It is kept in the probe because reproducing a finding matters, not > because it is safe to leave running.