Bus protocol: how does SAM change and cancel overrider timer

[lurgh]

(Moving this question/discussion from #97 (comment))

Looking for someone with access to an actual SAM to kindly provide serial bus traces or low-level descriptions of how it talks to the Infinity control (thermostat) to manipulate the override time (aka "hold until" or "timed override") when there has been a temporary setpoint change. Especially focusing on what is seen on the bus when the SAM changes or cancels a timed override. We have it working but some aspects were not intuitive - so it would be helpful to know how SAM does it.

So for example (using the SAM serial protocol):

0. initial condition: t-stat is on its normal mode/schedule (no timed override is active)

1. SAM changes a temp setpoint, which starts a timed override of 2:00 hours, e.g. S1Z1HTSP!72

2. while the override is active, SAM changes the override time, e.g. S1Z1OTMR!00:30

3. while the override is active, SAM cancels the override, e.g. S1Z1OTMR!00:00

[nebulous]

@lurgh I think the behavior with the older style vs touch thermostats is a bit different, but here are the relevant frames/logs in jsonl format (which will expire in 24h) and some slop analyzing what I did.

SAM Timed Override Bus Protocol — 2026-04-01

Captured using sam-comparator bridging an Infinity Touch thermostat (CESR131379-03) with a SAM (SYSTXCCSAM01). The SAM was off the physical bus; frames were forwarded between the network bridge and SAM's RS485 port. ASCII commands were sent via the SAM's RS-232 port.

Full capture: timed-override-capture.jsonl (1223 events, SAM-related frames and ASCII commands only)

Commands Tested

#	ASCII Command	Purpose	Attempts to ACK
1	S1Z1CLSP!73	Set cool setpoint to 73°F (starts timed override)	7
2	S1Z1OTMR!00:30	Change override timer to 30 minutes	3
3	S1Z1OTMR!00:00	Cancel override	25

25-second settle period between commands. The SAM frequently misread characters: OTMR→NTMR (O→N), OTMR→OTLR (M→L), S1Z1→S0Z1 (1→0).

Bus Protocol After Each ACK

Timestamps relative to ASCII ACK. Negative = before ACK returned to host.

CLSP!73 (start override)

RelTime    Event
───────    ─────────────────────────────────────────────────────
-0.543s    Thermostat → SAM  write 3B0E ×3     (pre-ACK burst)
+0.000s    ASCII ACK received
+0.001s    SAM → Thermostat  read 3C14 ×7      (state verification)
+0.197s    Thermostat → SAM  read 0104 ×3      (normal polling resumes)
+2.706s    Thermostat → SAM  read 030D ×5      (status refresh)

3 × 3B0E total (single burst before ACK).

OTMR!00:30 (change override timer)

RelTime    Event
───────    ─────────────────────────────────────────────────────
-0.653s    Thermostat → SAM  write 3B0E ×3     (pre-ACK burst)
+0.000s    ASCII ACK received
+0.452s    SAM → Thermostat  read 3C14 ×7      (state verification)
+0.895s    Thermostat → SAM  write 3B0E ×3     (post-ACK burst)
+1.485s    Thermostat → SAM  read 030D ×5      (status refresh)

6 × 3B0E total (two triplicate bursts: before and +0.9s after ACK).

OTMR!00:00 (cancel override)

RelTime    Event
───────    ─────────────────────────────────────────────────────
-0.719s    Thermostat → SAM  write 3B0E ×3     (pre-ACK burst)
+0.000s    ASCII ACK received
+2.570s    Thermostat → SAM  read 0104 ×4      (normal polling)
+3.320s    SAM → Thermostat  read 3C0C ×6      (state verification)
+3.592s    Thermostat → SAM  write 3B0E ×3     (post-ACK burst)

6 × 3B0E total (two triplicate bursts: before and +3.6s after ACK).

Key Findings

1. OTMR set and cancel are identical at the bus level. Both produce 6 × 3B0E (two triplicate bursts). The thermostat doesn't distinguish between setting and canceling a timed override.

2. 3B0E acknowledgment appears before the ASCII ACK. The SAM propagates the change to the bus, receives the thermostat's 3B0E acknowledgment, then returns ACK on the ASCII port. The bus change is committed before the host receives confirmation.

3. OTMR uses system-level acknowledgment (3 × 3B0E per burst), not the extended zone-level pattern (~11 × 3B0E) seen with setpoint changes. Despite being a zone-prefixed command, the thermostat treats it as a lightweight operation.

4. CLSP produces fewer acknowledgments (3 × 3B0E) than expected for a zone command (~11). This may be due to the 6 preceding NAK attempts disrupting bus state, or the setpoint change itself may trigger a lighter acknowledgment when an override timer is implicitly involved.

5. SAM queries undocumented thermostat registers (3C14, 3C0C, 3C0D) after each command to verify the change propagated. These are not in the known SAM register space (3B02-3B0E).

Comparison with Previously Observed Commands

Command	3B0E Count	Pattern
BLIGHT!ON (system)	3	Single burst
MODE!COOL (system)	3	Single burst
OTMR!00:30 (zone)	6	Two bursts
OTMR!00:00 (zone)	6	Two bursts
FAN!MED (zone, clean)	11	Two bursts
HTSP!66 (zone)	~24*	Extended spread
CLSP!73 (zone)	3	Single burst*

* Possibly affected by prior command queuing or NAK retry state.

[lurgh]

Thanks for the detail and depth of this. This helped a lot. Funny that the "AI slop" commentary omits mentioning the SAM->stat writes, which kinda were the main point of the question, but I could see everything I needed in the capture log.

A couple other observations:

• SAM doesn't bother to clear the buffer that it uses to write, with much of the content being unrelated garbage, which really threw me at first
• when SAM tries to set the hold time to 30m, it is writing 0x0014, which is 20 minutes, not 30. i will put this down to flipping a bit in the ascii command "30" -> "20" unless you have another explanation. any idea why your setup has so much corruption in that direction?
• SAM's writes to the zoned fields (setpoint and timer) for zone 1 are not passing the 0x01xxxx flag in the write command. infinitive always sets that bit for zone 1, just as it would use 0x02xxxx for zone 2, and I didn't realize what tstat would do without that bit set, but i guess it just defaults to zone 1. say more if you know anything about this

[nebulous]

Yeah, @scyto mentioned that the SAM is quite unreliable and wow was he right. It seems to have little-to-no read buffering. If it's handling a frame on the rs485 port it can't deal with input on the rs232 port for instance. However the bit flips happen WAY too often for rs232's +12 to -12 signals, so that's likely due to my cheap usb 232 adaptor which I'm betting has no charge pump and uses 5v levels.

re the zone identification/masking - that is the direct output from the hardware, not my emulation. I don't have any zones or a zone board (though I would LOVE some traffic samples from someone who does) so any zone == the only zone

I really need to put together a release for all of the SAM serial stuff I've been working on over the last year or two. Hopefully it will help you, or vice-versa.

[lurgh]

OK well thanks for your work on this. I saw you made some significant additions to your protocol wiki pages, which I will need to dig into in more detail - while I gleaned some new things, I also spotted a few issues/gaps that I can help fill in based on my experience with a zoned system and a non-Touch (UIZ) thermostat.

Still so much to do and learn. -)

[nebulous]

Please do feel free to make any edits to the wiki pages. They were getting so stale that I figured some updates were better than none.

If you have a zone damper control board I'd love to see traffic from it. was considering buying one from eBay just to poke around but yikes those things are expensive

[lurgh]

Hi again... there is a little discussion ongoing in an issue thread on my Infinitive repo, regarding the dilemma of a person who has several Infinity systems, most of which being the classic UIZ control but at least one now has a modern ITC-C Touch control. They have been using Infinitive successfully for the older devices and would like to be able to control all their systems consistently. Unfortunately, Infinitive's attempts to talk to the ITC-C mostly fail, due to the sam_* tables (esp 3B03) not being populated or recognized.

The crux of it maybe comes down to whether one could successfully impersonate a modern SAM (RTC01 version), since the -C Touch model claims not to be compatible with the original SAM01 SAM, which is what Infinitive impersonates (and, not super thoroughly - just enough to get by on the older devices). I see you did a fair amount of study on SAM impersonation, which could be helpful. Was your testing done on a SAM01 or a newer model?

So... I wonder if you could contribute to questions like:

• Do you know if an ITC-C really cannot talk to an (emulated) SAM01, as its manual states?
• Do you know how a SAM01 differs from RTC01, in terms of how it talks on the bus? Do you know what it would take to be ITC-C compatible? Does your SAM Emulator work with an ITC-C?

You could reply to me here or, I invite you top join the chat over there, at lurgh/infinitive/issue#14