Carrier Infinity

It looks like these are the 2 packets:
 
20 01 42 01 7B 00 00 06 00 01 04 56 41 52 49 41 42 4C 45 20 53 50 45 45 44 20 46 41 4E 20 43 4F
42 01 20 01 03 00 00 0B 00 03 0D A7 A0 ...
 
The bold section actually says "VARIABLE SPEED FAN CO" but seems to be truncated.  So maybe you are missing data?
 
Maybe post a small section of your log: 1MB or so?
 
I agree with az1324 - it must be truncated.  The length is 7B, which is the same as my device for register 0x0104.
 
One thing I've strugged with when working on this protocol is that it seems like it is multimaster, but there is no control of who's turn it is to talk.  Although in my system the thermostat initiates most queries, I don't think I'm seeing the whole picture.  I have a fair amount of documentation I can provide to put on your site for the 485 protocol.
 
I am very curious to know specifically what equipment you have, and what the capabilities of the touch device you have are.  Can you set setpoints remotely?  I am also very interested in your startup log since you have a device of 0x4201, which I only saw requests for when my system starts up.
 
Ok. Full startup log (rs485-startup.log) and thermostat status as posted to Infinitude (the json files) added to github here:
 
https://github.com/nebulous/infinitude/tree/master/sniff
 
From a quick look at the log it appears that on bootup the thermostat sends a message to a broadcast address 1F 1F and asks for assorted equipment until everything on the network responds. 3tones, the specific models you requested are in the json files mentioned above. Yes, I can set the thermostat remotely through a web service that carrier runs, though I no longer use that as it frankly sucked. That's what Infinitude is: a reverse engineered web service that pretends to be Carrier's that I run myself. The thermostat happily doesn't know the difference and the interface is much better than theirs even at this early stage.

Since Infinitude works for me, I'm only playing with the RS485 bit to help others without the internet-connected models out, and because I find it insulting that Carrier/Bryant try to sell a serial converter/microcontroller (SAM module) for such a ridiculous sum. $50 would be acceptable(considering the serial adaptor I bought cost $2.50), albeit a severe markup. $700+ thru dealers only is extortion and it's time the market responded. Please send me any documentation you have. Better yet I'll create a wiki section on the Infinitude github project and you can post it all there. (edit: done. https://github.com/nebulous/infinitude/wiki)
 
edit:
Oh and 3tones: you might be interested to know that my thermostat seems to be a SAM/Thermostat in one. It identifies itself as samtype ING which I'll assume is Internet Network Gateway (making that up since Carrier doesn't release any information on its super-secret special knowledge)
 
I took a look at your logs.  I was convinced for about the past hour that it was a different protocol.  Then I relized your capture dropped all null bytes (00).  After looking at your posts where they have null bytes, that seems to be the case.  My parser has a fit when I try to plug the capture in because of this.  I tried to download your large capture, but it was too large to download with github (or maybe I need to log in... dunno).  Try another capture and I'll take another look.
 
3tones said:
I took a look at your logs.  I was convinced for about the past hour that it was a different protocol.  Then I relized your capture dropped all null bytes (00).  
Ugh, I probably still had line discipline enabled on the tty. That would explain why my parser barfed on it. I thought the broadcast packets must just be completely different. Hopefully I can post an update later today. It's incredibly repetitive data so I'll gzip the files on github as well as post the code that handles streaming in real time rather than chunks.
 
Ok, added a clean startup log (startup.log.gz) which actually parses(and pushed more recent version of parser). Raw mode ftw.
 
I just stumbled on this thread...
So I have a 2-zone Carrier Infinity system with a variable-speed furnace and a Greenspeed heatpump.
The thermostat is a hybrid-heat compatible SYSTXCCUIZ01, this is the non-touch version of the Infinity zoning control.
I also have the LAN+serial SAM, accessible on my network or VPN. The serial port is connected through an ELK-M1XSP with my ELK panel.
But I am not using it in any rules, as the options are very limited. ELK has not updated the firmware since about 2010.
This whole setup is mostly unsued, mainly due to lack of time for me to program around things. The thermostat runs the schedule and if any change is needed to it, it is a few clicks away to access the web interface of the SAM.
I would love to access the statistics of the runtimes, errors or other info available on the thermostat, or use the information what is available in the web-interface, such as status, temps, setpoints.
if I can be of any help in capturing data or testing, please let me know.
 
 
 
Hi lleo, adding logfiles (especially those from system startup where all of the devices identify themselves) would probably be quite helpful. There's a link on the github wiki (https://github.com/nebulous/infinitude/wiki/RS485-protocol) to one that's known to work(about $5 from Amazon or $2.50 on the slow boat from ebay China), but I think any old rs485 interface would do the job if you have one laying around. I just hooked mine into a router running openwrt near the air handler to get the logs presently in git.
 
Yes it would be great to log the bus using the RS485 tool while at the same time running through all the commands the SAM is capable of because that is potentially the best thing to emulate.
 
I use a 232-485 adapter I had laying around, but can also vouch for the one from sparkfun.  One thing to watch out for is that 485 is a half duplex bus.  When any of the transceivers goes high (or low... don't remember) all the other ones stop.  Some transceivers tie this to one of the serial command lines, to control the RS485 chip, rather than the TX line itself.  This is all great until you leave the RS485 connected but shut down your program/terminal, at which point the RS485 goes high to transmit, causing all communication to stop - and your system has a heart attack until it is corrected.
 
I am very interested in seeing the comm with a SAM on the bus.  I would even be willing to contribute web-based/phone time to help you capture if you are not up to speed, but it sounds like just by asking, you probably are.
 
az1324 said:
@3tones is the source to your parser available?
 
I'll have some PTO when my wife has her baby, and my intention is to work on this a little to look at the other logs and post something.  It's in python.  My latest rig for working on my system is a raspberry pi with a wifi card, and the USB-485 adapter.  Kind of slick... beats running cables from the laundry room to the couch so I can work on it.
 
Here's what I've gleaned from nebulous's capture so far.
 
The primary devices are 5001 (AC) ,2001 (Stat), 4201 (Furnace).  1F01 does a lot of interrogation up front, including capturing the furnace model number, but after startup remains silent for the capture (at least for the startup log).  It seemed to interrogate a lot of other addresses that I don't recall on mine, but I'll have to verify that (new ones for me are: 5101, 4202, 6001, 6101, 0E01, 2401, 2501, 2601, 2701, 2801 - none of the devices respond in his capture).  2001 still manages the time of the system using broadcasts, like mine.  2001 also captures the model number like mine.  I don't remember 1F01 on my system, but I'll need to do a startup capture myself again.
 
I also forgot how crappy it is there is no coordination among devices - They all just seem to talk whenever they want and rely on retries and repeating the same thing alot to ensure communication.  This makes it really hard to parse at times, and very difficult to determine when to inject packets into the live comm.  I have yet to see a rhyme or reason to this - I keep dwelling on it because it seems like really poor design, but I've yet to come up with a better theory.
 
As for the tools for this effort here's what I've thought of, but I don't have a ton of working code.
 
I've been working towards a tool, that can:
1) capture and optionally store raw data
2) interpret data in real time
3) inject packets into the stream
4) watch each register/table for changes, and only show those
5) allow filters to hone on on specific data
 
My hope is that the tool would be able to capture the changes in raw data and store it in a database with a timestamp.  Then, as the mappings are determined you could make trends of data you have been capturing but didn't necessarily know the meaning of at the time.  If it is in a database over time, you could also look back at specific bytes and only focus on ones that change to try to interpret them.  Part of what I have struggled with is how to store the interpretations of data in a way that is useful and forward looking. Right now my file looks like this:
 

2001,SYSTIME ,02,01,13,01,1,19
2001,SYSTIME ,02,02,03,03,1,1,Hours,>B
2001,SYSTIME ,02,02,03,03,2,1,Minutes,>B
2001,SYSTIME ,02,02,03,03,3,1
2001,SYSTIME ,02,03,03,03,1,1,Day,>B
2001,SYSTIME ,02,03,03,03,2,1,Month,>B
2001,SYSTIME ,02,03,03,03,3,1,Year,>B

2001 is the device from which the request comes
SYSTIME is any text, but it refers to the table name
02 is the table address
the next column is the row in the table
the next column is the length of the row (number of bytes in hex)
the next column is a value from the table structure register (generally at a pattern of 0x??01)  I think it relates to the number of values in a row, but it isn't consistent.
Then you have the byte to start, and how many bytes to take, a name to give it, and how to interpret the data (a string that feeds into a python function)
 
The problem is I am expecting values to be within a byte or bytes, where it is completely possible for a byte to contain multiple pieces of data.  I'm considering adding a bitmask and bitwise shift value to deal with this. 
 
I realize I'm getting ahead of myself with my nomenclature and have made alot of assumptions in this post so far.  I'll digress into that for a minute. 
The data in the system is somewhat self describing.  The register as I call it is generally 2 bytes - a table and a row.  The first row defines the table, and the following rows have data.  This table identical in device 5001 (my AC unit), but it is where a broadcast from 2001 (my stat) write the data every minute or so.
 

0x0201 00 21 53 59 53 54 49 4d 45 20 00 19 03 13 01 03 03 03 03
0x0202 0d 36 06
0x0203 05 0c 0a

So 0x02 is the table, and the following byte is the row.  I'll walk across the first row and show how it defines the table.  You can only get this row by asking for it from the device.
I don't recall what 0021 is.
The next 8 bytes are the name of the table = 53595354494d4520 is SYSTIME with a trailing space (ascii)
00 19 relates to the size of the table (25 bytes)
03 is the total number of rows in the table
13 is the bytes of this row (in hex) and 01 is unknown
03 is the bytes in the second row, and 03 is unknown
03 is the bytes in the third row, and 03 is unknown.
 
The second byte of the last three lines of my description might relate to the number of pieces of data in this row, although I haven't confirmed this.  In this case row 2 each byte represents hour, minute, and day of week, and in row 3 each byte is day, month, year.  This was discovered by watching data, and intrepreting the table name. This one is a good example to start with and everything is pretty clear, but other tables are more difficult.
 
Here's what I've gleaned from nebulous's capture so far.
 
The primary devices are 5001 (AC) ,2001 (Stat), 4201 (Furnace).  1F01 does a lot of interrogation up front, including capturing the furnace model number, but after startup remains silent for the capture (at least for the startup log).  It seemed to interrogate a lot of other addresses that I don't recall on mine, but I'll have to verify that (new ones for me are: 5101, 4202, 6001, 6101, 0E01, 2401, 2501, 2601, 2701, 2801 - none of the devices respond in his capture).  2001 still manages the time of the system using broadcasts, like mine.  2001 also captures the model number like mine.  I don't remember 1F01 on my system, but I'll need to do a startup capture myself again.
 
I also forgot how crappy it is there is no coordination among devices - They all just seem to talk whenever they want and rely on retries and repeating the same thing alot to ensure communication.  This makes it really hard to parse at times, and very difficult to determine when to inject packets into the live comm.  I have yet to see a rhyme or reason to this - I keep dwelling on it because it seems like really poor design, but I've yet to come up with a better theory.
 
As for the tools for this effort here's what I've thought of, but I don't have a ton of working code.
 
I've been working towards a tool, that can:
1) capture and optionally store raw data
2) interpret data in real time
3) inject packets into the stream
4) watch each register/table for changes, and only show those
5) allow filters to hone on on specific data
 
My hope is that the tool would be able to capture the changes in raw data and store it in a database with a timestamp.  Then, as the mappings are determined you could make trends of data you have been capturing but didn't necessarily know the meaning of at the time.  If it is in a database over time, you could also look back at specific bytes and only focus on ones that change to try to interpret them.  Part of what I have struggled with is how to store the interpretations of data in a way that is useful and forward looking. Right now my file looks like this:
 

2001,SYSTIME ,02,01,13,01,1,19
2001,SYSTIME ,02,02,03,03,1,1,Hours,>B
2001,SYSTIME ,02,02,03,03,2,1,Minutes,>B
2001,SYSTIME ,02,02,03,03,3,1
2001,SYSTIME ,02,03,03,03,1,1,Day,>B
2001,SYSTIME ,02,03,03,03,2,1,Month,>B
2001,SYSTIME ,02,03,03,03,3,1,Year,>B

2001 is the device from which the request comes
SYSTIME is any text, but it refers to the table name
02 is the table address
the next column is the row in the table
the next column is the length of the row (number of bytes in hex)
the next column is a value from the table structure register (generally at a pattern of 0x??01)  I think it relates to the number of values in a row, but it isn't consistent.
Then you have the byte to start, and how many bytes to take, a name to give it, and how to interpret the data (a string that feeds into a python function)
 
The problem is I am expecting values to be within a byte or bytes, where it is completely possible for a byte to contain multiple pieces of data.  I'm considering adding a bitmask and bitwise shift value to deal with this. 
 
I realize I'm getting ahead of myself with my nomenclature and have made alot of assumptions in this post so far.  I'll digress into that for a minute. 
The data in the system is somewhat self describing.  The register as I call it is generally 2 bytes - a table and a row.  The first row defines the table, and the following rows have data.  This table identical in device 5001 (my AC unit), but it is where a broadcast from 2001 (my stat) write the data every minute or so.
 

0x0201 00 21 53 59 53 54 49 4d 45 20 00 19 03 13 01 03 03 03 03
0x0202 0d 36 06
0x0203 05 0c 0a

So 0x02 is the table, and the following byte is the row.  I'll walk across the first row and show how it defines the table.  You can only get this row by asking for it from the device.
I don't recall what 0021 is.
The next 8 bytes are the name of the table = 53595354494d4520 is SYSTIME with a trailing space (ascii)
00 19 relates to the size of the table (25 bytes)
03 is the total number of rows in the table
13 is the bytes of this row (in hex) and 01 is unknown
03 is the bytes in the second row, and 03 is unknown
03 is the bytes in the third row, and 03 is unknown.
 
The second byte of the last three lines of my description might relate to the number of pieces of data in this row, although I haven't confirmed this.  In this case row 2 each byte represents hour, minute, and day of week, and in row 3 each byte is day, month, year.  This was discovered by watching data, and intrepreting the table name. This one is a good example to start with and everything is pretty clear, but other tables are more difficult.
 
Back
Top