Carrier Infinity

This topic has totally confused me my HVAC guy recomended the carrier system but when I told him I had to intragrate it with my HAI he was lost and all I told him was I wanted to supply the thermostats. How complacated can that be it worms up close a set of contacts! I don't understand why these guys have issues with that. Finally he recomended a zoning system so I think I am putting a 4 zone system in frount of the carrier system. I am still totally confused though.
 
I have the carrier infinity system (3 units) so I would need two of those commically priced interface units. If someone can crack the code that would be awesome. I really don't have the computer skills to do that myself. I also have a whole house audio system that uses rs485 that I would love to crack as well. It almost seems like the simpler way would be to buy a thermostat and solder up the buttons to relays and the lcd to some sort of interface that could translate the visual data back into the raw data.

Seriously, how in the world do they justify that price? Does anyone buy them? In a thousand years you would never realize sufficient savings to offset $1500. I could just pay someone to go to my house and change the settings for cheaper!
 
I have the carrier infinity system (3 units) so I would need two of those commically priced interface units. If someone can crack the code that would be awesome. I really don't have the computer skills to do that myself. I also have a whole house audio system that uses rs485 that I would love to crack as well. It almost seems like the simpler way would be to buy a thermostat and solder up the buttons to relays and the lcd to some sort of interface that could translate the visual data back into the raw data.

Seriously, how in the world do they justify that price? Does anyone buy them? In a thousand years you would never realize sufficient savings to offset $1500. I could just pay someone to go to my house and change the settings for cheaper!


I will jet off a email to carrier I guess if enought people complain there system is not resonibly compatable with home automation systems they will take it into consideration in the next design. One day I hope these companies will stop being narrow minded and propritary and make things play nice together, this home automation thing is not going away.
 
The Infinity Serial Access Module (SAM) has a documented protocol that can be used to interface to it. I've connected to the SAM via hyperterminal and successfully adjusted setpoints and such. A friend of mine (the owner of the Carrier system) recently commissioned Beelzerob to write a CQC driver for it that is working well.

The Infinity system uses a proprietary protocol for the thermostats to communicate with the other components. The HAI thermostats can't speak this language, and don't support all of the features that the Infinity system does anyway. Because of that, you can't just swap the thermostats. You could send preformatted serial strings from the Omni to perform basic control of the Infinity through the SAM, but the limited number of message strings available would prevent you from truly having a fully functional interface. If you just limited control to basic functions such as on, off, heat, cool, and some common temperature setpoints then you could probably make it work. The Omni is a great controller, but you'll need a software based system to really take full advantage of all the potential controls and data points.
 
It would be nice to know the protocol that thermostats use. The SAM's are so overpriced I would be embarrassed to work for Carrier and be put in the posiiton of telling people what they cost. The thermostats have got to run on an rs485 or similar scheme. With that protocol you could just wire directly in and avoid using the SAM all together.
 
Yeah, that would be nice. I know that a couple of people have tried to reverse engineer the protocol, but I don't think that anyone has gotten very far.
 
It needs someone who thinks more 0's and 1's than I! But I would sure encourage one of those people. If you are one of those types, I would be happy to call you and give you a pep talk!
 
To the last few posts...

That's what I and another person have been trying to accomplish. We have made some headway, but I posted earlier looking for someone with a SAM. This way the documented SAM command could be sent, and the resulting proprietary command can be viewed on the RS485 network. This is needed to determine how the SAM makes changes in the thermostat for scheduling and setpoints. Without that information, it is pointless to try to control the furnace or AC over the proprietary network since the thermostat is the "master" and resends its commands every 10 seconds or so. The idea is to not need the SAM at all.
 
So the SAM kind of acts like your finger on the thermostat buttons and your eyes on the screen????

Someone posted on this website about actually owning the SAM just recently. Did you notice that? I could probably hunt it up if you aren't sure where it is.

It would be nice to just hook the thermostat wire up to an RS232 port on your computer and have your computer send commands to the thermostat and read all of the variable status'. Sounds like that is what you are trying to do.
 
It would be nice to just hook the thermostat wire up to an RS232 port on your computer and have your computer send commands to the thermostat and read all of the variable status'. Sounds like that is what you are trying to do.
That's the idea. The problem is, I can read data from the thermostat but without seeing it get changed from the SAM, it will be nearly impossible to determine what is "safe" to write back to the thermostat without a risk of "bricking" the thermostat... not something I want to do.
 
It would be nice to just hook the thermostat wire up to an RS232 port on your computer and have your computer send commands to the thermostat and read all of the variable status'. Sounds like that is what you are trying to do.
That's the idea. The problem is, I can read data from the thermostat but without seeing it get changed from the SAM, it will be nearly impossible to determine what is "safe" to write back to the thermostat without a risk of "bricking" the thermostat... not something I want to do.

I've spent some time decoding 232/485 (and network) protocols over the years, most recently a number of messages on the Elk M1 485 bus to create my own devices, and have some questions for consideration:

1) Does the SAM connect to the ABCD bus or a different point? '485 half-duplex runs master-slave in a polled mode 99% of the time so if it isn't designed to have the SAM on it then it is highly unlikely you can get in the middle of the protocol and inject commands. The reference to the B&B device for diagnostics leads me to believe you can get on the bus and participate.

2) '485 is typically implemented using a 9-bit word length with the 9th bit being an address indication that is easily processed by slave devices so they can always establish a sync point. While most PC '232 ports don't support it these days an application can enable mark/space and "fake" a 9th bit that most communication software won't see. If you watch the port it will show up as occasional parity errors (with parity enabled) or framing errors (dropped characters) with it disabled.

3) Most busses have a checksum on all packets sent/received to validate them. Most are simple two's-complement or other well known method but Elk has a pretty messy one. If you can't generate the checksum then you can't talk on the bus.

4) Timing is critical in a polled mode, especially if the master is expecting dedicated devices that have a known response time. Since there are diagnostic tools they use on the PC there is a good chance there is tolerance for a PC handling the communications (Elk isn't tolerant) but if you add a USB serial interface buffering characters you may have issues.

5) If you are going to try and decode this the other very helpful detail to have is inter-character timing. This is at the millisecond level. Combined with the 9th bit (or lack of seeing the 9th bit) it lets you see what was back-to-back followed by delay then response. In a polled environment with dedicated hardware the response time may be as short as 10ms or less so special equipment may be necessary to watch this. The fact that you see what looks like packets of information but it doesn't always line up leans towards dropped characters from framing that visibility to timing would show.

6) Something else to watch very carefully is the start-up discovery of the bus where it finds all the devices (or enrollment on Elk) and keep-alive poll. To inject commands you have to play nice and follow the rules. Also, watching it start from scratch may provide insight into packet boundaries and message types because it is usually slower and repeated if something doesn't answer.

This is not meant to discourage anyone, just some insight to limit head beating and increase your chance for success should you dive in all the way. For decoding the Elk I used an Ethernut v2.1 that has '485, 9-bit data and millisecond level timing to generate ASCII-Hex packets with timestamps (based on 9th bit as start-of-packet) and stream them out TCP. Packet structure and message types became pretty obvious after that.

Jay
 
As referenced above, a friend of mine owns a a functional SAM that is being used with CQC. Most dealers seem to quote ridiculous prices for these, but it's worth noting that he paid less than $600 for his. That's still not cheap, but about half of what I usually see quoted.

I *may* be able to assist with some testing and comparison of commands if necessary. It would be slow going though since I don't have a SAM (or Infinity system for that matter) myself, and would only be able to test on occasion through his system.
 
Zac,

I might consider paying $600 for one of those. How did he get it so cheap? No one I have spoken to even keeps it in stock and they all quote list price. There can't be more than $50 in manufacturing costs for something like that and if carrier just charged $200 I bet they would get half or more of the installations to include it. At $1500 I can't believe they sell but a couple a year.
 
To answer Jay's questions:

And to clarify... this is NOT the SAM protocol, this is the protocol used on the ABCD bus that communicates between the thermostat, furnace, AC, and SAM.

1) The SAM connects to the ABCD bus. The ABCD protocol is mostly master slave. For the most part, the thermostat does the reading and writing, except there is a case where the furnace writes to what I'm assuming is another furnace address. So technically, it is multimaster, although I have no idea how collisions don't seem to happen - there must be more to the timing or order than I have seen.
2) I don't think that's the case. It's 38400 8n1.
3) It does use a CRC16 checksum with the result in a swapped byte order (at least according to the algoritm I used).
4) I haven't looked at the timing very much, although it does seem to be key.
6) The start up does search for a number of devices, but otherwise is very similar to the ongoing communication. It does however search for a few devices I don't have. My suspicion is that one of them is the SAM.

This is by no means discouraging. The nuts and bolts of the protocol are pretty obvious... the "registers" and data are difficult to figure out. (I come from a modbus world, so registers are the best term I could come up with). This is why having a SAM would be helpful, mainly to see if the SAM is a master on the bus, or a slave to the thermostat. This could be determined with a 20 second capture from the ABCD bus, assuming one has a RS485 adapter.

Here is the general packet structure:
Code:
[---------- HEADER ------------------------------]
[2 bytes][2 bytes][1 byte][1 byte][1 byte][1 byte][X bytes][2 bytes]
  Dest	  Src	 Func	 ?	   ?	 Length   Data	Checksum

Dest and Src are the addresses of devices - 2001 Thermostat, 4001 Furnace, 5001 AC/HP.
The first 3 bytes of the data above are a "register address" that signifies what data is being read or written.
For example:
Code:
Example Packet:
[-----FRAME------------------------------]
[Header][ -------DATA----------][Checksum]		
		[00 03 16] [00]   [01]   
		[Address ][Byte1][Byte2]

Functions are as follows:
Code:
Typical Function Codes:
================================================================================
===========
	0x06	Response
		1 Byte Length, Data=0x00 ? Seems to be an ACK to a write
		Variable Length > 3 bytes ? a response to a read request
	0x0B	Read Request
		3 byte Length, Data=register of data to get
	0x0C	Write Request
		Variable Length > 3 bytes
		First 3 bytes of data are register to write
		Following bytes are data to write
	0x15	Error?
		1 Byte Length, Data=0x0A
		Not sure of this ? think it is an error response
 
Back
Top