serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): Repeat is folded into Action -- and [6] is not the repeat flag

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
serversdown
2026-09-25 00:35:09 -04:00
co-authored by Claude Opus 5
parent 4a1cccf3f5
commit 98cbdad489
1 changed files with 46 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+46 -3
View File
@@ -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