Two findings from a UM20147 run that was only meant to capture fixture bytes.
1. A MONITORING UNIT ANSWERS READS NORMALLY. UM20147 was read while actively
monitoring -- monitoring=True on both indicators, which agree -- and served
POLL, serial, state, monitor status and a 5-entry setup walk with no special
handling.
This confirms the SESSION_RESET finding with our own client. Series III
REQUIRES a bare 41 03 before POLL or a monitoring unit will not answer over
TCP. That was inferred from its absence in THOR's captures; it is now
demonstrated directly, on the other firmware line, by a client that never
sends one. (THOR's refusal to send a SETUP while monitoring is a write
restriction -- reads are unaffected.)
Monitoring moves two values, so neither is stable to compare against:
battery drifted 3.55 -> 3.50 V and memory free 15,000,000 -> 14,848,448.
2. SETUP-NAME CASE IS NOT CONSISTENT BETWEEN COMMANDS. Same unit, same
session, same file: 0x41 reported "test2.MMB" and 0x40 reported
"test2.mmb". A run 45 minutes earlier reported "test2.mmb" from both, so it
is not fixed per command either; what changed between is that the unit
started monitoring.
Cause is a guess from two samples. The consequence does not depend on it:
compare setup file names CASE-INSENSITIVELY. An exact-string test of "is
the active setup one I know about?" answers no on this unit. Worth fixing
before it is a field bug, since name matching is on the path for anything
that replaces THOR's setup/scheduler coupling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
ea229ed19d