From 98cbdad489353bce7203e32a35aa26bcc509104e Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 00:35:09 -0400 Subject: [PATCH] docs(series4): Repeat is folded into Action -- and [6] is not the repeat flag A capture that changed ONLY the Repeat Daily checkbox (pull schedule, disable repeat, push schedule) moved exactly one byte in the entire session: record @0 Action 0x03 -> 0x02 Record 2 unchanged, [6] unchanged, and 0xDA / 0x68 / 0x82 / 0x71 / 0x94 / 0x8D all byte-identical. Two corrections to the previous commit: * [6] is NOT the repeat flag. That was the field I predicted this capture would isolate; it stayed 2 and 16. Still unidentified. * The label "Action" on [0] was too simple -- it carries repeat behaviour too. Leading hypothesis: 2 and 3 are the two setup-bearing start actions the firmware names, with repeat selecting between them -- 0 = DUTYCYCLE_CALLHOME 2 = DUTYCYCLE_START_MONITOR_WITH_SETUP (repeat off) 3 = DUTYCYCLE_START_MONITOR_WITH_SETUP_STOP_COMPLETE (repeat on) Supported independently by the THOR manual, which says a repeating schedule hitting a Start Monitoring event while already monitoring will "stop the current monitoring session, run any Auto Call Home actions, load the compliance setup and continue monitoring" -- exactly what _STOP_COMPLETE should mean. A repeating start must terminate the in-progress session; a one-shot start need not. The firmware name, the manual's behaviour and the single moved byte all agree. Explicitly NOT claiming the enum ordering: the action names were recovered with `strings | sort`, so source order is lost. Do not infer 1 = START_MONITOR just because it falls between the two known values. Three of six codes observed. Also noted: Thor re-pushed the whole 2,090-byte config for a one-byte schedule change -- a third instance of the schedule<->config coupling. Capture provenance: the seismo_lab bins did not reach the dev box, but the socat relay on mint-mac keeps its own timestamped -x log, and the session was reconstructed from it byte-for-byte (25 frames each way, 0 bad checksums). That backup log is worth keeping in the loop -- it has now saved a capture once. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 49 ++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index 112015f..fb280af 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1546,9 +1546,52 @@ Action codes, so far: | `0` | **Auto Call Home** | | `3` | **Start monitoring, with setup** | -⚠ `[6]` is the one field still unidentified — `2` on the start entry, `16` on the -Auto Call Home entry. It is not the name length and not the time. A capture -that changes only the **Repeat** checkbox, or switches Day↔Week, would isolate it. +### The Repeat flag is folded into `Action` (2026-09-25) + +A capture that changed **only** the *Repeat Daily* checkbox — schedule pulled, +repeat disabled, schedule pushed — moved **exactly one byte in the whole +session**: + +``` +record @0 Action 0x03 → 0x02 (repeat ON → repeat OFF) +``` + +Nothing else moved. Record 2 unchanged, `[6]` unchanged, and `0xDA`, `0x68`, +`0x82`, `0x71`, `0x94`, `0x8D` all byte-identical. + +⚠ So **`[6]` is NOT the repeat flag** — the field predicted for that test is still +unidentified. And the earlier label on `[0]` was too simple: it is not a plain +action index, it carries the repeat behaviour too. + +**Leading hypothesis** — `2` and `3` are the two *setup-bearing start* actions the +firmware names, and repeat selects between them: + +| value | action | why | +|---|---|---| +| `0` | `DUTYCYCLE_CALLHOME` | the 19:30 entry, no setup name | +| `2` | `DUTYCYCLE_START_MONITOR_WITH_SETUP` | repeat **off** | +| `3` | `DUTYCYCLE_START_MONITOR_WITH_SETUP_STOP_COMPLETE` | repeat **on** | + +That reading is supported by the THOR manual's description of what a *repeating* +schedule does on hitting a Start Monitoring event while already monitoring: + +> *"the unit will stop the current monitoring session, run any Auto Call Home +> actions, load the compliance setup and continue monitoring."* + +Which is precisely what a name ending `_STOP_COMPLETE` would mean: a repeating +start has to terminate the in-progress session first, a one-shot start does not. +The firmware action name, the manual's behaviour, and the single byte that moved +all agree. + +⚠ **The enum's ordering is NOT known.** The action names were recovered with +`strings | sort`, so their source order is lost — do **not** infer that `1` is +`DUTYCYCLE_START_MONITOR` merely because it sits between the two known values, +tempting as that is. Three of six codes are observed (`0`, `2`, `3`); the +remaining three need entries that use those actions. + +⚠ Note also that Thor re-pushed the **entire 2,090-byte config block** for a +one-byte schedule change — a third instance of the coupling described in +*The schedule↔config coupling is Thor's, not the protocol's*. ⚠ Also still unknown: whether the file can hold more than the records in use (both captures had every used record contiguous from offset 0), and the remaining