Carrier Infinity
- Thread starter nov0798
- Start date
-
- Tags
- carrier hvac thermostats
Here is what I am thinking for the definition format.
At first, I wanted to use the output of my scanner, but that is a little too verbose and repetitive. One could use that to generate the shell of the definition format, but thats about it. Heres the format I'm considering:
Columns:
Data Types:
With this format, there needs to be a validation/utility script for the file format:
The only thing missing is some kind of lookup definition. For example, "weekday" in the example above has 0=Sunday. It would be nice to have an special data type that references another file or section in the definition format. Example:
Data Type: tbl8_1 (value interpreted as int8, but return string from lookup table 1)
Table 1:
0=Sunday
1=Monday
2=Tuesday
Etc
This could be used for my furnace that has 3 stages of heat. I know 1=Low, 2=Med,3=High but it would nice to have this embedded in the definition file, rather than hardcoding it somewhere.
Let me know your thoughts, but I think this is a good start.
At first, I wanted to use the output of my scanner, but that is a little too verbose and repetitive. One could use that to generate the shell of the definition format, but thats about it. Heres the format I'm considering:
Columns:
Code:
Source Address
Function (0C-write/06-read)
Register (Table and Row Address)
Start Byte (1 is the first character)
Data Type (see table)
Name (short)
Description (used to describe the value or units)
Notes (anything else that needs to get stored)
Code:
Name Bits Bytes Description
int8 8 1 Integer, 8 bits
int16 16 2 Integer, 16 bits
int16_d16 16 1 Integer, 16, bits, Divided by 16
str_8b 64 8 String, 8 bytes, returns 4 ASCII characters
bit8:1 8 1 Bit Field, 8 bits, 1st Bit
ukn_8b 64 8 Unknown, 8 bytes - used as a placeholder or questionable items- There would probably unsigned ints as well.
- Note that str_8b could have other ones like it and should be interpreted dynamically (should be able to do str_8b and str_20b without defining each size specifically)
- There may also be other dividing formats, if the need is discovered.
Code:
2001, 0C, 0202, 1, int8, hour , hour of the day ,24 hour base d
2001, 0C, 0202, 3, int8, minute , current minute ,
2001, 0C, 0202, 5, int8, weekday, current day of the week, 0=Sunday
2001, 0C, 0203, 1, int8, day , calendar day ,
2001, 0C, 0203, 3, int8, month , calendar month ,
2001, 0C, 0203, 5, int8, year , calendar year ,- validates the format of the file in general
- looks for data overlap (Example: Start Byte=1,int8, then another value with StartByte=2 they would overlap since an int is 2 bytes)
- create unknown data types for any gaps automatically, using the table definitions
- generate a nice excel file or html table
The only thing missing is some kind of lookup definition. For example, "weekday" in the example above has 0=Sunday. It would be nice to have an special data type that references another file or section in the definition format. Example:
Data Type: tbl8_1 (value interpreted as int8, but return string from lookup table 1)
Table 1:
0=Sunday
1=Monday
2=Tuesday
Etc
This could be used for my furnace that has 3 stages of heat. I know 1=Low, 2=Med,3=High but it would nice to have this embedded in the definition file, rather than hardcoding it somewhere.
Let me know your thoughts, but I think this is a good start.
az1324 said:
not necessarily important directly, but if we're going to try to iterate on the tables we have to define them somehow, and certain barriers could be removed by making definitions machine readable. Since we have the opportunity, why not(if it's easy)?
Warning: opinion follows. Please feel free to ignore/ridicule/throw away etc
Keeping it as simple and generic as possible is my preference, without reinventing more wheels than needed. 3Tones, as you're a python fan, maybe http://python.net/crew/theller/ctypes/reference.html#fundamental-data-types will be helpful. For simplicity and compatibility, I think where types are concerned none need to be invented. int16_d16 isn't actually a type. int16 is a type, and d16 helps define units. If I were Joe Programmer looking at the definition without extra context I would immediately understand int16, and if a units column said "expressed in 16ths of a degree Fahrenheit" I could decide how I wanted to use that well-defined number and no meta-definitions for types would be needed.
As ever, I'm just happy others are working on the problem. Hopefully my scatterbrained thoughts don't serve to confuse things.
Both good points.
Machine readable format: We started out (years ago) with a messy excel file to track some of the data. It quickly got out of hand. Also, with my mantra of storing all the raw data, and interpreting it later, a machine readable format becomes paramount. I now have almost 100mb of data from the bus, spanning almost a month. Do I need it all? Absolutely not. But after I have a year's worth of data, and I've seen that Bit X in Table Y hasn't changed, I can pretty safely mark it off the list of useful information. One could also use the format file to view information that was previously hidden in hex, should someone else decode that data. Finally, a strict format file keeps everyone in the same language: bits, bytes, characters, where to start counting from, etc - are all well defined.
Data Types: I agree that is a good reference, and I loosely based the data types on that. However, I had to veer off the course a little. We could probably use an array of chars for the strings, but there really isn't anything for a bitfield, or for the divide by 16 datatype. I do think it is a data type because it is a way to encode data. I wouldn't be surprised if there are other values (not temperature) encoded in such a way. When exploring, you could switch the data type, reparse the data, and see if it makes sense. There could be a case made for a dedicated units column, though.
Edit:
I went through the whole thread. We've been busy! I forgot people have written setpoints. I can integrate that into brybus if someone can give me an example. It would probably be a separate function since it is based on some other index, although understanding that might help me make a connection somewhere else!
Machine readable format: We started out (years ago) with a messy excel file to track some of the data. It quickly got out of hand. Also, with my mantra of storing all the raw data, and interpreting it later, a machine readable format becomes paramount. I now have almost 100mb of data from the bus, spanning almost a month. Do I need it all? Absolutely not. But after I have a year's worth of data, and I've seen that Bit X in Table Y hasn't changed, I can pretty safely mark it off the list of useful information. One could also use the format file to view information that was previously hidden in hex, should someone else decode that data. Finally, a strict format file keeps everyone in the same language: bits, bytes, characters, where to start counting from, etc - are all well defined.
Data Types: I agree that is a good reference, and I loosely based the data types on that. However, I had to veer off the course a little. We could probably use an array of chars for the strings, but there really isn't anything for a bitfield, or for the divide by 16 datatype. I do think it is a data type because it is a way to encode data. I wouldn't be surprised if there are other values (not temperature) encoded in such a way. When exploring, you could switch the data type, reparse the data, and see if it makes sense. There could be a case made for a dedicated units column, though.
Edit:
I went through the whole thread. We've been busy! I forgot people have written setpoints. I can integrate that into brybus if someone can give me an example. It would probably be a separate function since it is based on some other index, although understanding that might help me make a connection somewhere else!
Happy to see this thread is seeing some activity again.
I have been using a basic iOS app I have put together earlier this year, running my "FakeSAM" library (developed after examining real SAM logs kindly provided by az1324), to send write frames to my old STSTXBBUID01-B to control setpoints and furnace mode + read external temp etc.
A couple of months ago, I had a communicating A/C unit, zone controller and humidifier added to my system. All that came with the new WiFi thermostat, which apparently doesn't use the same registers for SAM integration.
Therefore, I have since been using the stock Bryant iOS app which works well enough (enough to make me lazy about this project) but not easy to use at all. I would love to go back scan the bus again, figure the registers out, update my code - with support for zoning this time. My code uses a file similar to what's being discussed here in the last few days: https://jumpshare.com/b/YcSjHBmI7b65UASl99FN
I don't have much time to spend on this at the moment but I will try to get organized and post what I have soon. Coming holidays should help.
I have been using a basic iOS app I have put together earlier this year, running my "FakeSAM" library (developed after examining real SAM logs kindly provided by az1324), to send write frames to my old STSTXBBUID01-B to control setpoints and furnace mode + read external temp etc.
A couple of months ago, I had a communicating A/C unit, zone controller and humidifier added to my system. All that came with the new WiFi thermostat, which apparently doesn't use the same registers for SAM integration.
Therefore, I have since been using the stock Bryant iOS app which works well enough (enough to make me lazy about this project) but not easy to use at all. I would love to go back scan the bus again, figure the registers out, update my code - with support for zoning this time. My code uses a file similar to what's being discussed here in the last few days: https://jumpshare.com/b/YcSjHBmI7b65UASl99FN
I don't have much time to spend on this at the moment but I will try to get organized and post what I have soon. Coming holidays should help.
Finally got a few tuits over the holiday to release a new version of Infinitude which actually allows for editing of setpoints, schedules, dealer info, etc. Several people have asked about it, and this seems to be the dominant Carrier/Bryant thread. So, if you have a network thermostat I'd love to get some feedback. One fun, albeit toy feature for the moment, is a real time rs485 serial monitor via websocket in addition to the normal webservice controls.
https://github.com/nebulous/infinitude
*Aside: if anyone has a remote temperature sensor I'd love to get some info on it. I have a 1-wire ibutton sensor plugged into the box, and it would be cool to make it appear as a remote sensor on the serial bus. Any other table definitions available?
https://github.com/nebulous/infinitude
*Aside: if anyone has a remote temperature sensor I'd love to get some info on it. I have a 1-wire ibutton sensor plugged into the box, and it would be cool to make it appear as a remote sensor on the serial bus. Any other table definitions available?
Thanks to all of your great information online, I got my Raspberry Pi hooked up to my Carrier HVAC system and reading from the bus (using 3tones Python code). I've updated the Infinitude wiki with the model info from my Carrier Infinity thermostat, furnace, zone damping control, and smart sensor.
One problem, however, is I've been unable to read from my Heat Pump, device 5001. The readraw.py script works well in phase 1 until it hits the first register of 5001, and then gets stuck in an infinite loop. Any idea why this or how to fix it?
Also, I noticed on subsequent readraw.py runs days later, that the furnace frequently tries to send a message to device 3001 (the Pi, right?) via the following message:
I thought making requests and reading from the bus using device 3001 would not add much to the long-term traffic, but this message is sent quite often. Any ideas to what it is and how to make it stop?
One problem, however, is I've been unable to read from my Heat Pump, device 5001. The readraw.py script works well in phase 1 until it hits the first register of 5001, and then gets stuck in an infinite loop. Any idea why this or how to fix it?
Also, I noticed on subsequent readraw.py runs days later, that the furnace frequently tries to send a message to device 3001 (the Pi, right?) via the following message:
Code:
3001 4001 1C 06 0001010020444556434F4E464700BC0619010301040178011E010601 5CC9I thought making requests and reading from the bus using device 3001 would not add much to the long-term traffic, but this message is sent quite often. Any ideas to what it is and how to make it stop?
Can you send the output of scandevtable.py so I can see where it gets hung up?synaptic said:
What you're seeing for readraw is normal. It builds that request on line 16, and puts it in the queue to put on the bus. What you posted above is it's reply. I should probably take that code out and put it into a demo script, and leave readraw to only do what it implies - read only.
I can't send you the whole file (something's wrong with my account, and I can't access the Members link), but here is a snippet. You can see how it builds the table with all devices but gets stuck at index 126 (the first row for 5001).
Code:
Opening /dev/ttyUSB0
starting phase 0
ending phase 0
Devices: ['2001', '4001', '5001', '6001', '2201']
starting phase 1
phase 1 queue built
...
126 500130010300000B000101347D 000130010100000B000000 False
...
write 125/315 400130010300000B003F0170DD
3001 4001 01 15 04 E74B
write 126/315 500130010300000B000101347D
F1F1 2001 17 0C 000420C022C0000F0100FB0200313755003A5000000000 0A57
write 126/315 500130010300000B000101347D
4001 2001 03 0B 000104 6D7E
write 126/315 500130010300000B000101347D
4001 2001 03 0B 000302 EC1C
write 126/315 500130010300000B000101347D
4001 2001 03 0B 000316 EC13
write 126/315 500130010300000B000101347D
4001 2001 03 0B 000404 6E2E
write 126/315 500130010300000B000101347D
4001 2001 03 0B 000402 EE2C
write 126/315 500130010300000B000101347D
4001 2001 07 0C 00040301010100 CC5B
write 126/315 500130010300000B000101347D
... ad infinitumThe way the code works is that it will continue to probe the register on the write queue until it gets a response (based on looking at the next frames information). The most obvious explanation to me is that device 5001 is not responding, or not there at all. However, I know you've indicated you have a heat pump. But, there may be something we don't know yet about how this all works.synaptic said:
scandevtable.py gets it's initial list of devices based on listening for 10 seconds. I'd suggest modifying line 67 (#devices = ['2001']
and put in the array of devices, excluding 5001. This will at least let the scan finish.Additionally, I'd run a capture for a while, and see what kind of traffic is communicating with 5001. You should be able to see if there are requests, but no responses. That would help answer some questions.
Let me know if there is anything I can help with.
The simplest way is with a usb->rs485 converter. I've tried both of the converters listed in the Hardware section of the infinitude wiki. The cheaper two-wire adapter worked for me for a while, but eventually stopped. The other one is a bit nicer since it has a block connector for sharing a common reference ground. I've been using it for quite some time now without issue.
