Carrier Infinity

[jt099]

The touchscreen stat I have has wifi. Table 3B is "SAMINFO" which made me suspect it would be similar to the non-touchscreen stat.
 
Tables in the stat I have are: (from the scandevtables script)
 
2001,01,0020,DEVCONFG,0092,04,01,15,01
2001,02,0021,SYSTIME,008D,0A,01,21,01
2001,03,0030,INGUI,004F,0A,01,21,01
2001,04,0020,SSSBCAST,0061,20,01,4D,01
2001,06,0020,LINESET,0052,1E,01,49,01
2001,2F,0020,STARTUP,0197,0D,01,27,01
2001,31,0020,INGDATA,01DD,33,01,73,01
2001,3B,0020,SAMINFO,0116,06,01,19,01
 
Has anyone been successful at tricking the stat into thinking a SAM is present in the system? That's kind of what I am trying to do, more for data access and logging rather than controlling the system.

 

[nebulous]

If your stat has wifi and you're primarily interested in logging, hopefully infinitude will do exactly what you want. If you just want to test that and aren't paranoid about me stealing your air conditioner's serial number for my own personal gain, I can temporarily set you up with a test implementation of it to find out if it works for you.

 

[az1324]

Your tables are slightly different than nebulous's.  Maybe you should compare model & version numbers.  Can you post or PM your whole table 3B?  To answer your question there is no record of anyone emulating a SAM with a Touch thermostat yet.

 

[gfb]

Gah! Of course, you're right az1324. I keep forgetting that not all touch stats have network access. gfb's efforts looked promising, but the controller for the MRF chip seemed to be a one-off. If I had infinite free time I suppose I could log the data in and out of said controller with the buspirate to figure out what's needed there.

 
Yeah, unfortunately I made no progress getting the wifi radio to talk to the stock thermostat code. I think the MRF chip is the same but suspect that the firmware only enables the radio if it detects a wifi flag or possibly from the model number.
 
Anyone have any thoughts on how to change the model # in the os?

 

[ajgma]

@az1324 & @DevXen,
I'm looking to pick up the work you two had done with emulating the SAM node on a Carrier Infinity network.  I have the SYSTXCCUID01-V standard UI (pre-touch) and no network on a single zone with a PWM valve furnace and AC.  I've seen the Nebulous/infinitude and the brybus from 3tones and am starting by sniffing the network.
 
It looks like I can piece together how to query the enumerated tables and query table entries.  Post #148 listed out table entries for a particular device and #163 stated that it's possible to write to entries despite no SAM being registered on startup.  Is there any link to programs or further information for the polling the status available through the UI (room temperature, setpoint, humidity, etc) and then set items available through UI (setpoint, vacation time remaining, etc)? 
 
Ultimately the intent is to be able to monitor the status and remotely change the setpoint.  I'm open to providing any programs to the existing repositories.  Thanks for any help.

 

[Qwijib0]

If your stat has wifi and you're primarily interested in logging, hopefully infinitude will do exactly what you want. If you just want to test that and aren't paranoid about me stealing your air conditioner's serial number for my own personal gain, I can temporarily set you up with a test implementation of it to find out if it works for you.

 
I am unconcerned with handing out a serial-- but unless I'm not fully understanding infinitude (which is totally possible), infininitude is a replacement for-- not an addition to-- carrier's own service, so I can't use the carrier app anymore.

 

[ajgma]

I am now able to use all of the brybus functions to request and interpret tables.  Post earlier listed out the interesting locations for setpoint, outdoor temp, etc.  I'm using the Kedsum RS485 to USB device from Amazon with the CH340T chip and a BeagleBone Black.
 

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.)

I'm looking for any leads about the "selector" bytes for a write or examples of the actual SAM writing to registers of interest that are commonly accessed from the thermostat or Carrier provided website. 
 
Alternatively the best path may be to sniff all write transactions and then probe the written to register in order to decipher the function of the "selector: bytes.  Thanks for any feedback.

 

[nebulous]

or the ODU there is 000304 which has a single byte vary from 20 to AF.  Then the first two bytes of 003E01 vary from 031F to 04B0 which is equivalent to 799 to 1200 aka 79.9 to 120.0 coil temperature perhaps.  The next two bytes also vary in that range and are usually close in value.  Perhaps some other temperature sensor in another part of the unit.

 
Confirmed this evening that the first two bytes of my outdoor unit's 000301 are the outside air temperature. It's a signed(two's complement) 16 bit integer divided by 16. Strangely it is returned from the ODU in degrees Fahrenheit. Haven't changed my thermostat to Celsius mode to determine if that's part of the initial negotiation, or if the protocol is US-centric. Tested by injecting fake reply frames from my ODU and waiting for touch thermostat to post outside air temp to Infinitude/update display. It's rather amusing to have the thermostat show an outdoor temp of 2,000 degrees F.
 
So:
0x07B0 = 123f
0xF850 = -123f
x0320 = 50f
0xFCE0 = -50f
0xFCEF = -49f

 

[scyto]

Hi, long time lurker first time poster.  I think I understand about 10% of this thread.  But is the basic upshot that there is no way to control my carrier system from other systems (say ISY994i, micasa vera, some random program, etc)? 
 
Does infinitude / nebulous give me the ability to query the state (temperature of each zone) and change desired cool / heat settings?
 
Is there any way to replace the infinity wifi touch control with an alternate mainstream connected set of thermostats?  (I noticed that the box on the furnace has traditional wiring points as well as the carrier bus?)
 
alex

 

[nebulous]

scyto: Upshot is, it depends, and it's changing over time (for the better).
 
I have all the info needed to make Infinitude control network-enabled touch thermostats, but at the moment it only logs data from the stat without controlling. So, exactly right now you can query the stat's state with Infinitude and a network touch stat, but not change setpoints. This deficiency is purely due to my lack of time and attention to turn that crank, there is no technical barrier. 
 
Despite having wifi control, I'm far more excited by the prospect of controlling the devices via the FieldBus'y serial protocol. (I actually just bought three new rs485 interfaces so I can potentially bridge between all three devices in a star rather than have them share a common bus. I'm not sure when I thought I'd have the time to actually implement that though...) This is a slipperier one, but thanks to some great work by people in this thread, is slowly making progress.
 
ajgma indicated a software emulated SAM is working for him*, but I believe that may only work with non-touch stats.
 
I can only offer anecdotal evidence wrt replacing the infinity touch control. I used to have a Proliphix network thermostat which I loved. When my new HVAC system was installed, one requirement was that it be compatible with the Proliphix. The installers said it was, were unable to get it to work, then as a result gave me a "deal" on the touch stat. <rant>Carrier's touch stat being SO EFFING EXPENSIVE to do LESS than what my 10 year old Proliphix did was what motivated me to start working on replacement software.</rant>
 
*I take this opportunity to request updates to the infinitude wiki. This thread is awesome, but a documentation source on github is much more reliably awesome. Maybe we can get started on documenting tables?

 

[scyto]

Thanks for the detailed reply.
 
I will keep an eye on the thread, happy to help as I can but as non-electronics non-programmer not sure what I can do other than test stuff (which I love doing). 
 
I hear you on the price of the thermostat, I had one of the older carrier infinity thermostats when i moved into this house last year (heck exactly a year ago now I look at the date!) and my dealer quoted me $1500 to fit the touch wifi one.  I got one off ebay for $600 which was both an awesome deal (I think?) and horrific compared to price of things like the ecobee.  And oh how crappy is the infinity app...
 
If I got the SAM board would I be able to hook up a HA system, or again is it closed protocols so only expensive things like Creston and Control4 work?
 
Have you ever thought about just connecting a regular thermostat control to the standard wiring on the main board by the furnace?  (IIRC I remember seeing a CYB etc wiring point)

 

[nebulous]

If I got the SAM board would I be able to hook up a HA system, or again is it closed protocols so only expensive things like Creston and Control4 work?

My manual had an entry about the SAM not working with the Touch stats, but I've yet to determine why, other than the data tables in the stat are slightly different than those in older models. It is definitely possible to control the devices (furnace/blower/etc) but not necessarily the thermostat. With infinity time I plan to use multiple rs485 adaptors to bridge between all devices and possibly override requests/responses from/to the stat.

Have you ever thought about just connecting a regular thermostat control to the standard wiring on the main board by the furnace?  (IIRC I remember seeing a CYB etc wiring point)

That is in fact what the installers did originally. It did not work correctly, and they couldn't figure out why. They did not impress me with their thinking and troubleshooting skills however, so I'm sure that might work out.

 

[az1324]

Supposedly the newer b-sam works with all the touch thermostats. But I am not sure anyone has tested that setup.

 

[3tones]

Hey guys.  I've watching the emails from this thread and finally got back around to playing with this.  I'm glad to see ajgma got my code to work!  So a general update.  For those that are new here: I have a I've discovered a lot since I first started this project in 2010 and turned the "matrix" into things that actually made sense, and I'm glad to see some other people have made some headway and I'm not alone in the effort.
 
I have a 3 stage furnace, with a heat pump, and a non-touch stat.  I'm running brybus (my library) with a rPi and a 485 converter to the bus.  Using the library, I have code that listens to the bus, and keeps an internal table of all the frames passed on the bus, and stores a new frame if it changed from the previous.  That really helps one focus on the changes, rather then the many duplicate transmissions that get sent.  It then sends the new frame to mysql.  I wanted something that could capture everything that goes on, and be able to interpret the data later as things are learned.  It also has the ability to inject a request onto the bus to get data that is not normally available just from listening - the setpoint or room temp for example.  My focus all along has been to monitor the system.
 
I picked this project up last week and learned the following. 

1. The OAT sensor on the outside unit is crap.  I've seen in the trends that when the compressor shuts off, the OAT spikes due to latent heat in the enclosure for more than a few minutes.  Its kind of fun to watch the coil temp drop below the OAT as the heat pump extracts heat from the 35deg air, though.
   [sharedmedia=gallery:images:785]
    
   
2. The mysql database has been indispensible in figuring out the sequence.  I identified the entire defrost sequence of the heat pump, which helped me identifiy a couple of registers.
3. There are many duplicate status indicators.  Fan RPM shows up at least 3 times, for example.
4. There seems to be an abort transmission signal, where transmissions mysterisously end with one of these: 00FC, 00FD, 00FE, 00FF.  I assume they all mean something different, but not sure what.  I need to update brybus to account for this, otherwise some of the data it returns is garbage.  I previously thought the garbage was two devices trying to send at once, but I'm not sure that is the case anymore.

I hope to have my data logging program, associated SQL queries, and an updated brybus in the next week or so to acount for the abort transmission code.

 

[scyto]

Not sure if this helps, i saw this carrier SAM driver on CQC site http://cocoontech.com/forums/topic/11372-carrier-infinity/page-13 (the latest version is on page 2) - maybe the guy who developed it may have insights....