The operator's test: start monitoring from the unit's keypad and see whether THOR
notices. It does not.
At 13:21:15, verified by an independent probe through the same relay:
unit on the wire 0x49 data[11]=0x02, 0x1C data[12]=0x0c -> MONITORING
THOR last contact 13:10:37 (a stop-monitoring command it issued itself)
THOR display Connected . Monitoring Mode: Idle . Last Updated 1:04:22
A unit is actively recording and THOR shows it as Idle. Had an event triggered
in that window THOR would not have known and would not have collected it. That
is the operational consequence of the wedge -- not a wrong indicator, but a
monitoring system that has silently stopped monitoring its monitor.
Further detail: THOR DID contact the unit at 13:10:37 and read MONITOR_STATUS,
yet Last Updated still reads 1:04:22. A successful exchange does not refresh
that timestamp; only the full status check does. The one honest field on the
screen is honest about the wrong thing, which makes it useless as a staleness
indicator exactly when staleness is the problem.
CORRECTS a documented constant. SUB 0x1C data[12] was recorded as "0x0E
monitoring / 0x00 idle". It read 0x0E on 2026-09-24 and 0x0C on 2026-09-25, both
while monitoring, so it carries sub-state in its low bits and is not a flag. Test
for NON-ZERO, never against a constant -- an implementation comparing to 0x0E
would have reported this unit idle. Same caution noted for 0x49 data[11], which
has only ever been seen as 0x02.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
8b6c89da42