I have a Carrier System Access Module (SAM) and can provide data bus dumps

[neillt]

All,

I have a new-ish Carrier Infinity with the wifi touch stat. But I also threw down the coin for the Carrier System Access Module, which turns a published serial API into commands on the Carrier ABCD bus.

Is this useful for any kind of logging or behavior tracking? I can set modes, setpoints, etc via the SAM and see what commands it is spitting out on the 485 bus if it's useful.

[nebulous]

Nice! Totally useful. I’d love to see a dump of the discovery process on boot up and some temp sets with known inputs. The hardware required to control these things over the Internet is 1 esp8266 board and one rs485 board. Less than $10 in parts even on amazon.

On Jun 9, 2020, at 7:45 PM, neillt notifications@github.com wrote:

 All,

I have a new-ish Carrier Infinity with the wifi touch stat. But I also threw down the coin for the Carrier System Access Module, which turns a published serial API into commands on the Carrier ABCD bus.

Is this useful for any kind of logging or behavior tracking? I can set modes, setpoints, etc via the SAM and see what commands it is spitting out on the 485 bus if it's useful.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[scyto]

Wish I had known that it was interesting to you, had mine for 3years now, hooked it up to a tcpip to serial bridge. Haven played with it in 2 years....

[nebulous]

If large discovery dumps are a pain, I'd be most interested in writes to tables > 0x3F as @Zhentar worked out a while back.

https://github.com/nebulous/infinitude/issues/64#issuecomment-445586659

My goal is still to replace all of Infinitude with a single esp8266 or esp32 with an rs485 adaptor.

[scyto]

oops deleted my comment instead of an image tl;dr I have a serial to ip convertor i forgot i had, just hooked up, not getting anything I connected D+ to 485+ on the convertor and D- to 485- on the convertor.

I get these errors in the log but not sure if thats a code issue or a mis-configuration on my part on the convertor

[scyto]

more info - I seem to be connected to the TCPIP serial thing ok from this app - it shows raw data flowing

[scyto]

FIXED IT - issue was having null serial_TTY variable. Removed that and boom! Now I just have to remember how to do mass dumps....

[scyto]

Do you need me to actually use the RS232 on the SAM do things? and see responses?

[bdf0506]

Might be a little off topic, but is there any functional reason to connect serial to infinitude? I seem to remember with infinitIVE you could control it over the serial/ABCD channel, but using infinitude as the proxy interceptor, not sure there’s even a point? I used infinitive before I upgraded the thermostat to the touch screen version.

[nebulous]

Might be a little off topic, but is there any functional reason to connect serial to infinitude?

The only functional reason is to give infinitude read access to data that isn't available from the network api, such as coil temp and airflow. Well, really any data that's on the bus, but most fields haven't been mapped out yet. Which is the other slightly useful, but mainly fun feature: watching the stream and seeing what changes when.

[nebulous]

Now I just have to remember how to do mass dumps.... Do you need me to actually use the RS232 on the SAM do things? and see responses?

Having good dumps for a few of the most relevant SAM commands and their results on the 485 bus to actually control devices would be the most useful, but any traffic would be helpful - you don't owe us anything. Even the screenshot above is slightly helpful.

ref SAM commands and responses: https://dms.hvacpartners.com/docs/1009/Public/02/SAM01-01XA.pdf

I wrote cardump partially to make this easier from serial ports, but since you're already using a tcp serial bridge (glad to see that works for someone else!) it might be even simpler for you with nc(or whatever the Windows equiv. is)

[scyto]

I have WSL so running netcat is no issue (though i had never tried running it before) but just tried it an it sees the data ok, wish i had known about that tool before futzing with crappy windows serial programs!

I can definitely pipe that to a file it that's all that is needed?

Given infinitude is already getting all the data is there an easy way to have an option to just pipe that to a file as well as translating/rendering it?

Let me know if all I need is to pipe to a file and I can run for a few days (i might even install netcat in the container instead of using WSL).

For the actual RS232 commands I used to use an autelis rs232 to ISY (a HA controller) bridge, my plan was to shift the HA controller to use infinitude 'rest API', but it is still on the wall, I will see if I can make that work at some point soon.

BTW love the serial bridge, seems to work simply (after the null env vars fiasco on my part) - anyway to make infinitude ignore env vars that are set but null (no worries if not)

-edit- PS (for anyone following along at home is windows through and through) The best alternative to netcat on windows seems to be netcat on windows ;-) https://eternallybored.org/misc/netcat/ - i hope someone adds this to choco or winget package managers, but WSL just as easy.

[nebulous]

Given infinitude is already getting all the data is there an easy way to have an option to just pipe that to a file as well as translating/rendering it?

I should totally add that as an option for people who want to share their logs - but no, it doesn't exist right now.

I can definitely pipe that to a file it that's all that is needed?

Yep, but to really get down to what individual commands do, it would be more useful to make a dumpfile for given commands. It gets a little bit confusing talking about multiple serial ports and network connections so maybe this diagram explains what I mean more clearly

BTW love the serial bridge, seems to work simply (after the null env vars fiasco on my part) - anyway to make infinitude ignore env vars that are set but null (no worries if not)

sure. If you file an issue with how to reproduce, I'll fix it.

[nebulous]

any of the above applies to @neillt as well. The more the merrier!

[scyto]

Yes understand the diagram, running 4 or 5 commands manually is something easy to do once i get the RS232 bridge up. I didn't fancy going through the whole PDF and executing every command (i am lazy :-) )

[scyto]

/offtopic I forgot the autelis actually parses content.

I ordered the same generic brand of the one i have working

For reference of anyone playing along at home https://www.amazon.com/dp/B00ATV2DX2/ref=twister_B07V5BSTXN?_encoding=UTF8&psc=1 (i own the PN1000 already, it works with the ABCD bus just fine, ordering the new PN1200 for the RS232)

[scyto]

Note to self, next time multiple virtual serial ports on windows don't seem to work don't assume it is windows, or the serial adapter. Instead reboot the fucking SAM.

(oh also in the end i found a virtual comm ports that didn't wan't to charge me any money, the others were between $99 and $250!

Anyhow, @nebulous now in a place i can do some testing. Want me to start with the first 4 you listed? any more? i would prefer to batch doing them if i can. Or are you looking for someone to walk the reference doc and do as many as possible?

• S1Z1CLSP?
• S1Z1HTSP?
• S1MODE?
• S1Z1CLSP!73

(ignore the typos above)

[nebulous]

Based on a quick browse of the PDF These are the most likely to be valuable to implement useful control. But nothing wrong with more if you're in a logging mood. I'd also be interested in the bootup/discovery sequence(if it exists) when everything powers down/back up.

S1MODE?
S1MODE!AUTO
S1MODE!COOL

S1Z1HOLD?
S1Z1HOLD!ON

S1Z1CLSP?
S1Z1HTSP?

S1Z1CLSP!73
S1Z1CLSP!73, 13:45

[scyto]

@nebulous boot up done, link below good until Friday 24th, password the same as this guthub project https://1drv.ms/u/s!AtFY20AHlltvjPUUfq9ubYe065H0aQ?e=iJiVjl

I powered SAM on first, waited 10 seconds, powered on system, stopped logging AFTER TSTAT was connected to infinitude aok.

[scyto]

@nebulous and I got inspired and I did a bunch more https://1drv.ms/u/s!AtFY20AHlltvjPUTJuXY76gLK-34kA?e=tpXqZI same password for the link (the zips are not password protected) this link also expires on Friday 24th.

I note if mode is COOL and one tries to set a HTSP then one gets a NAK VAL (not captured in the files). By setting mode to AUTO (it is on cool as it is summer) i was able to set the HTSP.

I haven't done any of the time ones, think I will do those as a batch for all the ones that support time.

[scyto]

@nebulous do you want me to reshare these?

[nebulous]

Ah! Sorry I never positively indicated that I got them, but I did. Thank You for your efforts! Trying to decide if I should write something in perl or modify brybus or infinitive code to make more general use of them.

[scyto]

No worries :-) glad they helped, when you need / want more lemme know.

[dulitz]

I guess this is the place to discuss ABCD bus decoding? I have a SAM also and it works exactly as advertised. But the SAM lacks three features that I think are pretty critical.

• It will let you request the current mode (heat/cool/auto/off) but the SAM won't let you request the current state (heating, cooling, neither) or whether you're in stage 1 or stage 2.
• The damper controller is great, but the SAM won't show you which zones are actually getting air or how much.
• The SAM only has one RS-232 port, which means if it's connected to your home automation system you can't also connect to it to query it for state monitoring.

I was inspired by the ancient brybus code and wrote something similar in modern python, focusing more on observing the bus frames instead of writing frames. Since I wanted this to be a small project with a well-defined end date I called it finitude.

Today I used all that stuff to determine how the damper controller was being controlled. It's pretty interesting, to me.

But it's 2021. Does anyone care?

[dulitz]

Okay, I updated your wiki with what I know about the registers. Most of what I know is just from reading the infinitive code; the rest is from observing the two systems I have access to.

On topic for this thread: afaict the SAM only writes updates to the thermostat and only reads state from the thermostat, not from other devices. The infinitive code already emulates a SAM fairly well, reading and setting the TStatCurrentParams, TStatZoneParams, and TStatVacationParams registers. If there are specific SAM features not emulated by infinitive that you want to emulate, please be specific on this thread and I'll add it to my list.

According to the infinitive code, register 3b02 byte offset 22 has the mode in the lower 5 bits and the stage number in the upper 3 bits (where 0 is off), and that is correct for Infinity Touch thermostats on firmware 3.60. This answers my first bullet point of "missing SAM functionality," except for the case where mode is AUTO, where we don't know just from this whether it's heating or cooling. You can compare CurrentTemp for each zone in register 3b02 with the setpoints in register 3b03 and learn whether the thermostat is commanding heating or cooling. (Though I don't know the algorithm for heating-versus-cooling if some zones are above the cool setpoint while other zones are below the heat setpoint.) So one thing to discover going forward is how the thermostat commands the furnace and/or compressor to turn on and off.

The four-zone damper controller SYSTXCC4ZC01 is interesting. First note that there are max 8 zones in an Infinity system, so there can be either 0, 1, or 2 damper controllers. System 1 I have access to is a single zone with no damper control, while system 2 is 3 zones with one damper controller. I have observed the thermostat reads from damper register 0302 and writes to damper register 3404. I don't know what those do.

Damper registers 0308 and 0319 are a matched set. The thermostat only writes to 0308 and only reads from 0319. Both registers are 8 bytes long, with each byte representing the damper position for zones 1-8 respectively. 0x00 is fully closed, and 0x0f is fully open. The thermostat writes the damper positions for all 8 zones to all damper controllers, using 0 for zones that do not exist. The damper controller is configured (using DIP switches on the board) for zones 1-4 or 5-8. When the thermostat reads from register 0319, the damper controller uses 0xff for zones it is not configured for (in my case zones 5-8).

The damper controller can also control an HRV/ERV -- that might have something to do with register 3404 which is only one byte long.

[dulitz]

I added a ground-up review of the protocol to my wiki: https://github.com/dulitz/finitude/wiki/Connecting-to-the-Infinity-System

[nebulous]

Finally managed to control my Touch-based thermostat via RS485. Wrote directly to table 0x40 rather than SAMINFO. Woot. Can finally replace a SAM (and Infinitude, actually) with a $2 ESP8266 device!

[ChrisMurf2900]

Could you share what you did (or the code)? I would be really interested in being able to read all info directly from RS485 and also controlling. That would get rid of the need to somehow get Carrier’s latest MQTT over TLS working with infinitude.

[nebulous]

Could you share what you did (or the code)? I would be really interested in being able to read all info directly from RS485 and also controlling. That would get rid of the need to somehow get Carrier’s latest MQTT over TLS working with infinitude.

I'm working(sloooowly) on the esp project at https://github.com/nebulous/infinitesp - but if you run infinitude with an RS485 adaptor attached and enable thermostat scanning with the SCAN_THERMOSTAT environment variable you should be able to see the extended tables being parsed in your serial tab. The 0x40 table is called SCHEDULE and contains the schedule for zones 1-8 at 0x4002 - 0x4009 and setpoints for zones 1-8 at 0x400A-0x4011

[scyto]

@nebulous did you get a SAM in the end? I still have mine here, no longer connected, willing to go to a free home where it will be useful, no strings attached...

[jerremy]

@scyto I'd be interested in getting your SAM if it is still available. Please let me know. Cheers, Jerremy

On Oct 2 2023, at 9:31 pm, scyto @.***> wrote:

@nebulous (https://github.com/nebulous) did you get a SAM in the end? I still have mine here, no longer connected, willing to go to a free home where it will be useful, no strings attached...

— Reply to this email directly, view it on GitHub (https://github.com/nebulous/infinitude/issues/97#issuecomment-1744182042), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAHCSFHD2WSEMAC4H25OZMTX5OILBAVCNFSM4NZ3S4PKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZUGQYTQMRQGQZA). You are receiving this because you are subscribed to this thread.

[nebulous]

Hey @scyto - I did not ever get a SAM, but thanks in large part to your logs I was able to write to a Touch thermostat via rs485. I would still of course love a SAM so that I could make a more comprehensive emulator, though practically with my schedule that might not happen soon.

[scyto]

It really is no strings attached - you won't get me pressuring you. DM me an address and I will send it, i never need it back as I will never use it via serial lol.

---

From: nebulous @.> Sent: Tuesday, October 3, 2023 11:43 AM To: nebulous/infinitude @.> Cc: scyto @.>; Mention @.> Subject: Re: [nebulous/infinitude] I have a Carrier System Access Module (SAM) and can provide data bus dumps (#97)

Hey @scytohttps://github.com/scyto - I did not ever get a SAM, but thanks in large part to your logs I was able to write to a Touch thermostat via rs485. I would still of course love a SAM so that I could make a more comprehensive emulator, though practically with my schedule that might not happen soon.

— Reply to this email directly, view it on GitHubhttps://github.com/nebulous/infinitude/issues/97#issuecomment-1745526293, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACWXVXAOUFKH7RNMTPW2A6LX5RMDRAVCNFSM4NZ3S4PKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZUGU2TENRSHEZQ. You are receiving this because you were mentioned.Message ID: @.***>

[dragonflight]

I would also like to throw my name in the hat for the SAM. I am retired so I have time (though I 'm often inhibited by chronic headaches..) to at least scan and record the SAM's commands and responses and then forward the SAM to whomever.

I currently have a Microchip PIC/RS232 reading/writing my ABCD bus, a USBtty+some hw monitoring the bus and 90% of Infinitude rewritten in C running on my desktop that is PICOW/ESP... ready (minimal writes to NVRAM).

I run Linux machines so it is very easy for me to create scripts to run through commands and record the results

There may be a problem with the touch tstat only exposing data that it has configured. I have noted that the SAMINFO table is all zeros (I haven't yet programmed the PIC to respond to startup as a SAM) if it doesn't find a SAM on startup. I only have a HP (280anv/25vna0) and an air handler (FE4ANF005)

There may be a slight problem as I live in Canada, though if that is an issue it can be sent to my sister in Michigan who will forward it to me.

mike

[scyto]

sorry folks, it's already in flight to Nebulous.