Carrier Infinity

[az1324]

The first byte seems to indicate the zone # or subrecord set # (zero based).  The second two bytes represent 16 bit flags that enable the overwriting of the marked subrecords.  However, the data can be divided into subrecords in any way and a subrecord can be from 1 bit to many bytes.  So a knowledge of the structure and numbering of the subrecords is necessary before writing.  This functionality may be limited to only certain tables.

 

[3tones]

I've been paying attention, but we recently had another child so it's been a little nuts...
 
I spot checked my 2001-3B table, and it seemed to match what he had defined a few posts earlier (I check temps, setpoints, etc).  At least 3B is a one stop shop for status information.
 
Based on the information being posted, I assume lleo had some success?  Otherwise, I'm not really sure where az1324 is coming up with his latest batch of information???  Just curious.

 

[az1324]

Yes lleo came through.

 

[3tones]

2001,003B02,29 bytes
B25 - day of week (0=sun)
B26-27 - sec minutes from midnight
 
I have a poll of the entire 2001,3B table running, logging that and all changes on the bus to mysql.  Data is stored in text form, so you can write SQL against it to interpret it.  I'll hopefully have some more information on how to read the status of the system based on the writes to the furnace and AC from the stat.

 

[nebulous]

I'm still following as well, but have had limited time for fun hvac hacking of late. One question about the time variable: 
 

B26-27 - sec from midnight

 
How is that possible? Aren't there 86400 seconds in a day? A 16 bit int can only hold 65536 unique values.

 

[3tones]

I'm still following as well, but have had limited time for fun hvac hacking of late. One question about the time variable: 
 
 
How is that possible? Aren't there 86400 seconds in a day? A 16 bit int can only hold 65536 unique values.

 
I meant minutes from midnight.

 

[DevXen]

lleo,
 
i am attempting to emulate SAM on the bus to control the thermostat.
 
any chance you can share the sniff log from your system with the SAM module connected? a system startup log would be particularly useful.
 
thanks.

 

[nebulous]

I too would love to see that. I've been too busy as usual, but have actually gotten useful data in/out of the stat via rs485 now in the interim.

 

[az1324]

@DevXen - welcome. which thermostat/version do you have?

@nebulous - interesting, do you have any more info on the new data? logs?

 

[lleo]

I am out of town. I removed the logs I shared with AZ1234, but will post new ones shortly.

 

[DevXen]

az1324,
 
​I have a SYSTXBBUID01-B thermostat and a 355CAV gas furnace.
 

For table 003B, the only one the SAM writes to, the first 3 bytes of a write command are important parameters specifying what data to overwrite (i.e. not the whole record).  I haven't tried to decode them yet. 
 
At this point, you should be able to dump the tables listed above and verify that your data matches these patterns.

 
do you have a log or sample frames of SAM writing to 2001, 003BXX you could share? I would like to test writing into this table if I can come up with a theory of what the initial 3 bytes might represent but I have no samples.

 

[az1324]

I will PM you.

 

[DevXen]

samples provided by az1324 were very helpful. i am now able to modify temperature set points, fan speed, etc. by emulating a SAM on the bus.
 
thankfully the thermostat doesn't ignore the fake SAM messages due to lack of proper device registration or prior handshake.
 
the meaning of the initial three "selector" bytes in the write function is still a bit fuzzy at this point, but given the finite number of write use cases, I just decided to follow the SAM's lead and not get stuck on it. after my tests, I believe the first byte is the device/furnace/air handler and the next two bytes are a bit field that somehow corresponds to one or more records that is a subset of the row. i should also mention that another reason I decided to defer fully understanding these bytes is, when a particular selector value from SAM samples is used, the thermostat properly ignores the rest of the values in the write data.
 
upon receipt of a write message from the fake-SAM, the thermostat sends an acknowledgement (06 00) and later sends a write message back to SAM for table 003B row 0E which is a single byte r/w register. the values I have received so far are 1 (when the SAM request to write to thermostat table 003B succeeds) or 0 (when it fails.)

 

[kskenyon]

Hi, I am dabbling with the Carrier Infinity Touch protocols.   The fake SAM would be useful to me.  How can I learn more? My first step is to get some data logging going then expand from there.  Nebulous has been a great help so far.

 

[gfb]

Sorry to be a bit off-topic. Could someone post a pic of the back of the circuit board on the evolution connex or infinity touch controller? I am working on adding the wifi module to a non-wifi unit and need to figure out what other components are missing from the board.
 
Also waiting on my rs485<->usb adapter to upload some captures. I have a few odds & ends in the infinity/evolution line: -b inf controller, latest evol non-touch controller, non-wifi inf touch, sam, and zone.
 
Thanks!