From 8c2dacf0355c049393dbf67d0c8994ef96106913 Mon Sep 17 00:00:00 2001 From: serversdown Date: Thu, 24 Sep 2026 19:49:59 -0400 Subject: [PATCH] docs(series4): the schedule has a setup-less start action -- Thor never uses it 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 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 47 ++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index a0d9c53..5a0cd30 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -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