Step 2 of docs/micromate_client_spec.md: micromate/protocol.py plus 35
offline tests. Reads only; nothing here writes, erases or changes
monitoring state.
The tests replay Thor's captured responses through a scripted transport and
assert the bytes we emit are the bytes Thor emits -- including a full replay
of the six-event download session, all 56 0x5A frames byte-for-byte. A
passing test therefore means a real unit has already answered exactly that
frame.
Measuring the spec's command table against the captures found three more
errors in it, on top of the three the framing work found:
1. SUB 0x0A is the MONITOR-LOG WALK, not a keyed "event header, 30 B list
record" read. The same request repeated returns successive 297-byte
records -- serial, mode, thresholds -- until an 11-byte ack ends the
list. The device holds the cursor; nothing in the request selects a
record, and all nine captured frames carry identical params.
Structural divergence worth noting: Series III reaches the same data via
a record-type discriminator on its event chain, so partials and events
share one walk. Here the monitor log has its own cursor and the event
chain never sees it.
2. 0x1E/0x1F carry token 0xFE at params[7]. The protocol reference
documents all-zero params -- that was our own browse probing, which also
worked. Thor sends 0xFE on browse and download alike.
3. SUB 0x01 (device info) is never read by Thor in any captured session.
Its 0xFFFF offset comes from our own probes, so it is the one read in
the table with no Thor precedent. Flagged in the docstring.
Two useful negatives, both from absence rather than presence:
- No SESSION_RESET (41 03). Series III needs that 2-byte signal or a
monitoring unit will not answer POLL over TCP. Zero occurrences across
all 8 sessions, including 40 frames exchanged with a unit that WAS
monitoring.
- No universal preamble. The only invariant is that a session opens with
POLL; POLL -> SERIAL -> 0x49 -> POLL is Thor's connection check and
appears in 3 of 8 sessions. Setup pushes and scheduler reads open
differently.
Two deliberate divergences from the Series III sibling:
- strict_checksums defaults True and RAISES. minimateplus logs and
continues because its parser cannot always tell an inner-frame delimiter
from a checksum byte; that does not apply here, where the rule is exact
on 251/251 frames. The lenient default is instructive -- it hid a wrong
checksum rule for two days.
- read_event_file() raises ShortRead rather than returning a truncated
event. The expected length is known up front, so the check is free, and
a silently short event is the failure mode this codebase keeps hitting.
Every exchange resets the parser before sending, so a leftover frame is
discarded rather than answered with -- expected_sub catches a mismatched
SUB, but a same-SUB leftover would sail through with data for the wrong key.
File transfer (0x94/0x48) is deliberately out of scope: it needs a
data-carrying request frame, which is the frame type writes use, and that
boundary is worth keeping crisp in a read-only pass.
Full suite unchanged at 16 pre-existing failures (missing gitignored
fixtures); 419 passed, up 35.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
a7e3a8f20a