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

docs(series4): the schedule has a setup-less start action -- Thor never uses it

Browse Source 
The schedule<->config coupling looked like it might be a workaround for the unit
crashing on a missing setup.  The firmware says otherwise: there are two distinct
start-monitoring actions in the scheduler's duty-cycle dispatch, and only one
involves a setup file.

    _PSA() case DUTYCYCLE_START_MONITOR
    _PSA() case DUTYCYCLE_START_MONITOR_WITH_SETUP

Full action set: START_MONITOR, START_MONITOR_WITH_SETUP, STOP_MONITOR,
CALLHOME, SELF_CHECK, plus ON/OFF/NEXT for scheduler state.

So the coupling is not a crash workaround -- Thor picks the more demanding of two
available actions every time.  SFM can emit START_MONITOR and skip the config.

On whether a missing setup would actually break the unit: the firmware suggests
graceful degradation (`Setup File Not Found`, and `Invalid parameters reset to
factory default - please review setup`, a deliberate fallback).  Untested, and
recorded as untested.

Hypothesis, flagged as such: the schedule entry's leading byte may be the action
code -- the one captured entry reads `03 00 00 00 0f 03 02 [namelen][name]` and
03 would fit START_MONITOR_WITH_SETUP.  One entry, nothing to diff, unverified.

Names the capture that would settle it, and which is worth more than the 0x47
disable/enable test: a schedule entry with a setup-less action (stop monitoring,
or call home).  It would confirm or kill the action-code hypothesis and prove
from the other direction that a schedule needs no config push.

Also noted: DUTYCYCLE_CALLHOME -> CMD_SCHEDULE_CALL_HOME means a scheduled
call-home can make a unit dial out on demand -- the one remaining lever on the
unsolved call-home direction.

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-24 19:49:59 -04:00
co-authored by Claude Opus 5
parent ebcc55e2ec
commit 8c2dacf035
1 changed files with 47 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+47
View File
@@ -1371,6 +1371,53 @@ other schedules — or the operator's own saved work — depend on. Nothing in
protocol or the ack reports that this happened. Validating the reference
instead of rewriting the referent avoids the whole class of problem.
#### The schedule has a setup-less start action — Thor just never uses it
The coupling above looked like it might be a workaround for the unit crashing on
a missing setup. The firmware says otherwise: **there are two distinct
start-monitoring actions**, and only one of them involves a setup file.
```
_PSA() case DUTYCYCLE_START_MONITOR
_PSA() case DUTYCYCLE_START_MONITOR_WITH_SETUP
```
The full duty-cycle action set, from the scheduler task's own dispatch strings:
| action | notes |
|---|---|
| `DUTYCYCLE_START_MONITOR` | **no setup involved** — uses whatever config is loaded |
| `DUTYCYCLE_START_MONITOR_WITH_SETUP` | the variant Thor always emits |
| `DUTYCYCLE_STOP_MONITOR` | |
| `DUTYCYCLE_CALLHOME` | `send ==> CMD_SCHEDULE_CALL_HOME` |
| `DUTYCYCLE_SELF_CHECK` | `call DailySelfCheck()` |
| `DUTYCYCLE_ON` / `OFF` / `NEXT` | scheduler state, not per-entry actions |
So the schedule↔config coupling is not a crash workaround — **Thor picks the more
demanding of two available actions, every time.** SFM can emit
`START_MONITOR` and skip the config entirely.
On whether a missing setup *would* break the unit: the firmware suggests
graceful degradation rather than a crash — `Setup File Not Found` exists, and so
does `Invalid parameters reset to factory default - please review setup`, which
is a deliberate fallback. ⚠ **Untested**, and not worth relying on until it is.
⚠ **Hypothesis, not a finding:** the schedule entry's leading byte may be the
action code — the one captured entry reads `03 00 00 00 0f 03 02 [namelen]
[name]`, and `03` would fit `START_MONITOR_WITH_SETUP` in an enum of the above.
Unverified; there is one entry and nothing to diff against.
**The capture that would settle it** (more valuable than the `0x47`
disable/enable test): build a schedule whose entry is **stop monitoring** or
**call home** — an action with no setup attached. That would (a) confirm or kill
the action-code hypothesis, since a setup-less action should change the leading
byte and drop the name, and (b) prove from the other direction that a schedule
can be sent with no config push at all.
Note also `DUTYCYCLE_CALLHOME` → `CMD_SCHEDULE_CALL_HOME`: **a scheduled
call-home is a way to make a unit dial out on demand**, which is the one
remaining lever on the unsolved call-home direction.
### What this implies for the build order
The read path is fully known and needs no Thor-shaped decisions, so a read-only