Carrier Infinity

[nebulous]

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.

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

 
Nice! I look forward to trying out the new code. Do you have any suggestions for working out a common way to define datapoints? I like the idea of keeping some form of publicly editable documentation there, but text files, or even a mysql(or SQLite? That might be more portable) table would do afaic.
 
And speaking toward point #4 and potentially new frame information, I noticed that the mysterious 1F device/broadcast from thermostat shows up whenever a newcomer arrives on the bus. If I fake a frame from an as-yet-unknown device, the thermostat immediately interrogates it from 1F01.

 

[scyto]

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.

 
I assume this is the manual you are talking about http://dms.hvacpartners.com/docs/1009/Public/02/SAM01-01XA.pdf as i read it the internet access is incompatible and the the SAM RS232 stuff is "as-is" (at least thats what the manual says).  If i wanted to get one of these whats the best way to interface to the port - is there any type of IP to Serial device that could let me send and receive the ASCII without having to string up a PC and serial cable?

 

[nebulous]

I assume this is the manual you are talking about http://dms.hvacpartners.com/docs/1009/Public/02/SAM01-01XA.pdf as i read it the internet access is incompatible and the the SAM RS232 stuff is "as-is" (at least thats what the manual says).  If i wanted to get one of these whats the best way to interface to the port - is there any type of IP to Serial device that could let me send and receive the ASCII without having to string up a PC and serial cable?

 
3tones uses a Raspberry pi, ajgma uses a Beaglebone black, and I use a Pogoplug and before that a Linksys router, but there are also dedicated serial->ethernet devices (much more pricey) which can do the job. It really depends on how comfortable you are with little Linux boxes. There is certainly no need to drag a desktop computer into the mix if you only want to send rs232 from a terminal. If you'd like to interface with both sides of the SAM(and god bless you if this is what you're going to do) to see what it puts on the RS485 bus for given RS232 commands, you would need a rs232 to usb adaptor and a rs485 to usb adaptor, and something with a network port and 2 usb ports that can run linux.

 

[scyto]

Thanks, I am only about to dip my toe in the water with raspberry PI for my DSC alarm system links, so I may go that route if i am successful, I dabble in Linux about once every couple of years...
 
I did find this http://www.autelis.com/universal-rs232-serial-1wire-interface-isy.html which coupled with the ISY may give me what i need in terms of polling and setting things.
 
If i get that working i might try the RS485 thing if it helps folks here, though i expect i would need some hand holding
 
Either way happy to keep folks updated if i pull the trigger on this...
 
---edit---
http://www.autelis.com/universal-rs485-serial-interface-isy.html 
hmm they have  an RS485 one too..., is there enough knowledge on this forum to let me use the RS485 one and skip the RS232 and SAM route?

 

[az1324]

I assume this is the manual you are talking about http://dms.hvacpartners.com/docs/1009/Public/02/SAM01-01XA.pdf as i read it the internet access is incompatible and the the SAM RS232 stuff is "as-is" (at least thats what the manual says).  If i wanted to get one of these whats the best way to interface to the port - is there any type of IP to Serial device that could let me send and receive the ASCII without having to string up a PC and serial cable?

 
Which thermostat do you have?

 

[scyto]

 
Which thermostat do you have?

The SYSTXCCITW01-A

Page 18 implies it is compatible with a SAM of some sort http://dms.hvacpartners.com/docs/1009/public/07/systxccitw-07si.pdf

 

[3tones]

Nice! I look forward to trying out the new code. Do you have any suggestions for working out a common way to define datapoints? I like the idea of keeping some form of publicly editable documentation there, but text files, or even a mysql(or SQLite? That might be more portable) table would do afaic.

 
I've used a format like this:Addr,TBLName,TblAddr, TblRow, Row Len, ???, StartByte, NumBytes,Name,Interpretation
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
scandevtable.py outputs a format that I intended to use for this purpose too that is similar, but you get the gist above.  It's a little redundant, but easy to parse, and semi-usable for a human.  I'm not sure how to notate the interpretation in a way that different languages can use that in a conversion function that is relatively universal.  The >B was related to python, but doesn't work in instances where parts of a value are interpreted differently.  For example, Coil temp has 2 bytes but the first 12 bits are interpreted as an integer, while the last 4 bits are used as the decimal place.  (that's off memory so don't quote me)  I'm also not sure how to deal with situations where bits or a pair of bits represent the status of something - there is a case of that in the AC status.
 

I did find this http://www.autelis.com/universal-rs232-serial-1wire-interface-isy.html which coupled with the ISY may give me what i need in terms of polling and setting things.

That is an interesting find, but I'm not sure at this point if it would be capable of reading or controlling the 485 bus directly. It could probably do status, but with the CRC calculation and timing, I'm not sure about writing to the bus. I'd hold off if I were you. PS, I have an ISY too.

 

[scyto]

 That is an interesting find, but I'm not sure at this point if it would be capable of reading or controlling the 485 bus directly. It could probably do status, but with the CRC calculation and timing, I'm not sure about writing to the bus. I'd hold off if I were you. PS, I have an ISY too.

 
Thanks for the advice, I already ordered the RS232 version  i have asked my dealer for a quote on the B-SAM, i also pulled the trigger on 2xSYSTXCCRWF01 that were $99 'as-is' off e-bay, worst that can happen from my gamble is i get 2 broken units...
 
Best that can happen is i get two working units and can sell one ;-)

 

[az1324]

What a bargain. That is just what you need. I have a feeling nebulous is going to want your spare one.

 

[nebulous]

 
I've used a format like this:

Addr,TBLName,TblAddr, TblRow, Row Len, ???, StartByte, NumBytes,Name,Interpretation
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

scandevtable.py outputs a format that I intended to use for this purpose too that is similar, but you get the gist above.  It's a little redundant, but easy to parse, and semi-usable for a human.  I'm not sure how to notate the interpretation in a way that different languages can use that in a conversion function that is relatively universal.  The >B was related to python, but doesn't work in instances where parts of a value are interpreted differently.  For example, Coil temp has 2 bytes but the first 12 bits are interpreted as an integer, while the last 4 bits are used as the decimal place.  (that's off memory so don't quote me)  I'm also not sure how to deal with situations where bits or a pair of bits represent the status of something - there is a case of that in the AC status.

 
I'll try to be patient and see how newer scandevtable output looks I can write up a script to generate wiki tables out of some reasonably well-defined table format so it will be a bit easier to look up what's known and what's missing.
 
wrt data types my inclination would be to use C types where possible. Coil temp for instance is a 16 bit signed integer (int16_t) with a fixed point divisor of 16. Maybe a units column could be added to clarify things like divisor in that case. "16ths of a degree f"
As for bitfields, are there any non-byte-aligned fields that contain anything but single bit flags?
edit: I see you mentioned pairs of bits. Perhaps instead of startbyte and numbyte we could have startbit and numbits?

 

[3tones]

I updated brybus on github. https://github.com/3tones/brybus I have one more script to post that logs data to mysql, but I need to do a little more cleanup and documentation before I post it.

There were some big changes. First, I combined all of the communication library to brybus.py. Second, I built a table-based CRC calculation to improve performance, as it was bringing my rPi to it's knees. Third, I updated all of the scanning scripts to reflect the changes and updated the wiki https://github.com/3tones/brybus/wiki to walk through the scanning process to help people interrogate their devices.

I added issues https://github.com/3tones/brybus/issues for the outstanding items I want to change in the library. If anyone from this forum takes inititive to start working on it, send me a PM so I know who you are on github, and I'll pay closer attention to your requests on github.

Also see this wiki entry https://github.com/3tones/brybus/wiki/Scanning-Devices for more information about the output file, that may be modified to act as a unified way to interpret data. Mainly we just need to add start byte, num bytes, and interpretation to the file, and it could be parsed to interpret data.

 

[nebulous]

Pulled the new code and confirm it at least executes on my system.

 

[3tones]

I just fixed an error that dealt with outputting bad data when dealing with Device 5001, Table 3E. I don't know why, but the first row doesn't describe a valid table. There is data there, however. I spotted model/serial in rows 08 and 09. This was keeping nebulous from moving onto the next step without manually editing the file.

 

[3tones]

A few more fixes. I updated the read function to actually consider the CRC (thanks nebulous). Added dblogger.py, which allows the changed data to be logged to a mysql database. Documentation is a little sparse, but feel free to give it a spin and let me know. You can run the logger without doing any of the table scans, although it does query a couple of interesting tables in the thermostat, such as setpoints and schedules. Those requests are built for the SYSTXCCUID01, and I'm not sure if they would be of any use on other stats, but I suspect they would be fine.

 

[3tones]

brybus Updates: Added config file. Added sqlite support. Added realtime table for MySQL (with just the latest data) - I'm going to use this to query what it is doing in realtime.