kpishere
conversation continuation about ClimateTalk
OK so the mini split thing is a kind of good idea.. I bought 4 Rheem 96%EF modulating furnaces with EC blowers (DC Variable speed) 60K BTU output each furnace. and a 20 seer Rheem 2 Ton modulating Condenser (variable from 20% output to 100% in 1% steps) and a set of High Efficiency coils with housing included for 4000.00 USD delivered. the AC was 1000 and the coils were 200 600 for each furnace.. so at 1200 that's pretty darn cheap for a 20 seer AC. the mini split probably cost ya a little bit more then that.
I wanted to throw something at ya that I built. I used a simple Arduino Uno and 6 thermisters and an ethernet shield for the Arduino I used 2 thermisters for each of my 3 furnaces. I put one into the intake plenum before the filter. and the second went in the output plenum about 12" from the exchanger but out of direct view of it. wired them up to the Arduino. I collect input and output temperature readings. get the difference between the 2 (delta-t rise). If you look on the label inside the door on your furnace it will tell you what the max delta-t rise is for the furnace. I plug this number into the program.. and presto I now have notifications of when my filters need to be changed. This is a real world thing and not based on a length of time. It all depends on how much dust and dirt if floating around in the house.. so say if I am doing some construction work I would have to change my filter more often. This tells me exactly when it needs to be replaced.
if (out_temp - input_temp) >= max_delta_t_rise - 1:
trigger a notification
I have mine set up to send me an sms text message to my phone to change the filter.
The reason why this works is because when the filter gets clogged up the air moving through it slows down. and this slow moving air takes longer to cross the heat exchanger providing more time for the air to collect heat. if that temperature gets to high the furnace will short cycle.
One of the things I want to be able to do when i finally get around to going full tilt into writing the software to interface with ClimateTalk is I am going to add an outdoor air temp sensor. I am then going to code in a learning routine so it will know how long the temperature is going to take to drop in my house. I want to design the thing so the furnaces never turn off. I want them to stay running all of the time.
you may think that is bonkers.. So take this math.
a good furnace cycling time is 4-5 times an hour and it should run for 7-10 minutes each time. so call it 4 times an hour at 8 minutes runtime.
some rounding and that's 30 minutes out of every single hour the furnace is going to run for, 100K btu furnace. this is going to consume 50K btu's of heat energy per hour. so if i run a furnace at 50% for the whole hour there is no additional cost.
benefits are 1/2 as loud. no fluctuation in the temperature in the house less wear and tear on the furnace.
It's funny how the math actually works. because when a conventional furnace turns on it is running at 100%. it has to heat the house by usually 4 degrees. when you set the thermostat to a temperature it will not turn a furnace on until it is 1 - 2 degrees below that set temperature. there is also a "warmup time" for the furnace.. so lets make the number an event 2.. well the same thing applies when it turns off. it somewhere between 1 and 2 degrees above the set temperature..
If the furnace is running all of the time you are not making 4 degree swings in the temperature. so if the furnace is running all of the time you would need to set it to output a lot less then 50%. this is where that outside temperature helps in the calculations. that outside temp is what is going to dictate the btu output. You can do it without also by sampling the temperature in the house measuring the time it takes for the temperature to change and make adjustments according to that. I would use a combination of both.
also EC motors become more efficient the slower the speed they are at.. so you have electricity savings as well..
I had to install 3 furnaces because they do not make a high efficiency furnace that outputs over 120K BTUs unless you go commercial. plus my house is 3 stories tall and i got tired of having 3 different climates in my house. the original furnace was to small for the home and the ductwork was completely wrong. They had a single return for the furnace and 7 registers 4 of the 7 registers were 3" ducts and the rest was 6". my house is almost 3000 sqft poor insulation (r7 walls, r19 roof no attic). now I have 24 registers 19 of them have 6" ducts. and the rest are 4" they are all insulated rigid ducts. I also have 9 returns one in each bedroom and the rest scattered about the house. my gas consumption dropped by 50% from the old furnace which was a 120K btu. where as I am at 180K now. now my furnaces actually turn off when it's -20F (-29C) outside.
@kdschlosser There are a number of things to comment on here, I'll tackle one for now. The idea of the thermistors at intake and exhaust for monitoring filter. Lots of positives about that namely cheap reliable and fulfilling the need for real filter condition monitoring. Are you aware that the ECM motors are speed controlled? That is, computer sets their speed and then they provide the power to match it. That is a little different than a PSC motor which has a speed fallback profile as it is loaded. The fan motor will get more loaded when the filters are dirty. So, your thermistors are a lagging indicator. What will happen is your ECM motors will get to a load point where they eventually do slow down OR where the blower becomes less efficient because of the back pressure. Only then will your thermistors show the expected temperature difference. Nothing beats real-world testing though, how is it working? I wonder, if you measured the current on the motor with new filters and then with clogged filters, you see the difference? They may be noisier when clogged too. A pressure difference sensor on either side of the filter is a more direct measure but those are more expensive than thermistors. Measuring speed vs. power to the ECM motor would be a good indicator too -- I think some motors can report this. Still measuring temp in/out is a good fallback measure.
Ahhh.. See this is where K.I.S.S. (Keep It Stupid Simple) applies..
I am aware that the fan gets throttled back. If the furnace does not have a modulating gas valve the results will be the same. less air flow over the heat exchanger at a fixed btu output is going to give a high delta-t. So no issue there..
Now.. say the furnace does have a modulating gas valve. it is going to know the delta-t is to high and it will modulate the valve so the btu output matches the air flow. This would make you believe that using thermisters would not work. It takes 20 or 30 seconds for a furnace to make the adjustments and for the adjustments to show in the readings. The furnace is not going to react to a single high temp reading. it is going to need to see multiple readings of increasing values before it is going to do anything, then you also have the amount of time it takes for the temp to come back down. This is a large enough window to know if the filter is dirty or not.
The funny thing is what does the furnace use to monitor the input and output temperatures? Thermisters. the exact same thing used in my setup.
Don't get me wrong, it did take some tinkering with the threshold for the notification before I got it right. a furnace is not going to use a pressure switch or a sail switch to make this measurement. a pressure switch that would be designed for longevity and also be able to handle 160F temperatures is not going to be a cheap thing. sail switches are mechanical and would be susceptible to dust causing problems with it. so those are out. Now you have something that is purpose built for high heat. it may get a slightly skewed reading from dust but not going to cause it to stop working. it has not a single mechanical part. and it's also very small and doesn't need to have an elaborate mounting point made. And the cost is less then 1.00 USD.
I know they use thermistors because I had to install the ones that came with my furnaces, they put it into a fancy metal tube so it looks like an extra long meat thermometer with 2 wires coming out of it. taking a cigarette and putting it into a cigar box does not make it a cigar. LOL.
The EC motors in my furnace and basically giant computer fans. they are DC powered and have PWM to control the speed and also a tach wire. I am sure I could attach to the tach wire to know what the sped is. but knowing the speed or even the current draw is pointless to know. because the end result is the furnace is going to set the PWM to a specific output. then adjust the BTU output to maximize the delta-t. using the same type of design the manufacturer uses to make the btu adjustments are going to be the best way of knowing when it is dirty.
Now pressure sensors would 100% not work. on EC furnaces. the reason why is if the furnace makes a change to the fan speed it is going to cause a wild pressure spike or drop until the system can equalize. and that length of time is going to vary base on what the static pressure is in the dusts before the change was made the friction inside of the ducts is also going to come into play. a sail switch is also going to have an issue with this same thing as well.
instant readings is not what you use. I oversimplified my explanation. it's a moving sample dataset that I use. I take a sample every 250 milliseconds and i buffer 20 seconds worth of readings. once the buffer gets full i drop the first reading in the buffer and then add the new reading. average it out and that is the number i use. if that number is over a set threshold I send a single notification. once the readings come within 10% of each other (in and out) a flag to send a notification get set. so only a single notification gets sent for each time the furnace turn on. 3-4 times an hour, just enough to make me go and change the filter.
I did this setup because i have 5" thick filters. they should last between a year and a half and 2 years possibly more between changes.
This is not teste to work yet as I do not have a 5" thick dirty filter. only had the filters in for 6 months. I tested it by sliding a piece of plywood in to cover portion of the filter. best I could do. The blower in a furnace may adjust it's own sped based on current draw being to high this is not something that is going to be regulated by the furnace. The only thing a furnace is going to make adjustments to is the BTU output because in the end that is the single thing that can burn down a house. so a furnace is always designed to stay within a temperature limit. if it is outside the limit it is going to react. modulating furnaces will throttle the flame. single stage or 2 stage will shut down the flame until a predefined time has passed.
Yep, furnace just may do that, I can't say for certain. You know, it should already be measuring inlet and outlet temperature. I'll keep it in mind when going through specs again and when getting back into this. I'd agree that it likely isn't measuring current to the motor. It is only measuring actual speed and dictating set speed for the blower. If there is a difference, it will error out. These internal measures to the furnace, should be accessible via ClimateTalk protocol BTW, again, whilst I'm coding my own ClimateTalk thermostat, would be good to reference! I really want a thermostat that shows performance and health metrics but that just does not exist right now. Also, for interests sake, here are some references on motor types. Most are CFM (speed) controlled but not all apparently. Actually, after reading this link, since 2006 there have been constant torque models too. (X12 and a PSC direct replacement one) that have a simulated profile to PSC motors -- to accommodate poor installations! :). But regardless, if you have one of those kinds of ECM motors, then temp in/out works 100%. https://github.com/kpishere/Net485/blob/master/ElectricMotorsandFiltration.pptx
I know there is a HUGE amount of information that can be obtained from the furnaces using climatetalk. I would be able to ditch the setup i made for monitoring if the filter needs to be changed because I would be able to get those sensor readings from the furnace directly.
I am not sure how the whole lawsuit panned out between Carrier and Goodman (Dakin) for patent violation with respect to Goodman using the ClimateTalk protocol. This is why climate talk vanished overnight. I know they settled but the terms are not disclosed. I would imagine that climatetalk can still be used But because it dissolved in 2012 i think they simply are not going to get the standard going again. this is 7 years later and most of the manufacturers have developed their own system. which sucks for us end users. To be honest the 900.00 USD thermostat that works with ClimateControl2 is a POS. and there really isn't all that much out there that i able to work with it... But the climatecontrol2 is an unaltered climatetalk so interfacing would be easier then using say the Rheem EcoNet which is a spin off of climatetalk and has all kinds of authentication because of the wifi and wan attachments,
I do know that Rheem does make an EcoNet to ClimateControl2 adapter. They state it is only for connecting an EcoNet furnace to a ClimateControl2 air conditioner. I do not see how it would be that specific because it is simply going to act a a general packet converter. I would be really surprised if they specifically designed it to not handle the whole protocol..
Another thing I am going to tackle is my tankless water heater. There is a 4 pin header on the main board and I am almost willing to bet that it is an rs485 connection and it has the econet protocol on it. The reason I say this is because you can connect a wifi module to the electric version but not the gas version. The boards are going to be the same they will have different firmware is all. the only thing that is really different between the gas and electric is one has a heating element and the other has a modulating gas valve,
The funny thing about all companies that make energy efficient furnaces and water heaters is that if you purchase say a 95% efficient unit. It is actually 98% efficient. they make a single high efficiency unit and sell it as 98%, 97%, 96%, and 95% the only thing they change is the model number and the packaging. I found this out because of the production run sticker on the box.. It states 98% when i bought 95% efficient water hater. with Rheem I looked up the parts between the models.. They are the same parts.. Oh yeah they also change the price. 1000.00 bump in price to go from a 95% to a 98% and you actually get nothing for it.
They are like auto manufacturers in this respect. Take a GMC Yukon Denali and a Cadillac Escalade. 25000.00 USD difference in price and the only things that are different are the front bumper, hood, front fenders, headlamps, tail lamps and grille. Oh I forgot the emblems also. There is maybe 1000.00 difference in the cost of the parts. and they charge you 25000.00 for it.
Ohh, don't get me started with this industry. I'll must move on to something more constructuve. I've just uploaded a Python program somebody wrote (no author, it was posted in a chat room). I have yet to use it but people were probing climate talk with it. You could search by the file name and you'll likely find the same threads. Useful for you since you have a working network. https://github.com/kpishere/Net485/blob/master/pollClimateTalk.py
Oh, odd. Well, I'd added the file to the folder in the project kpishere/Net485 anyhow.
nope it's not added to a project or aded to the repo.. I would like to have a look see at the script. I am wondering if it is the same as I have happened upon before,
I don't understand. If you look at the change history, you'll see the following commit
'kpishere committed 4 days ago 1 parent b1a94d2 commit 844048087f98a413ad7710dfd6c6fe0521f25301'
Now it is showing up when I just went and looked. It is the same script I have seen before.
Hi @kdschlosser, by way of update, check out the 'diag' folder of this project. Python is just not my thing, so I've written a new monitor program, in Swift 4.2. Only a few packet types are defined right now. Swift may not bet your thing but still should be easy to add other packet definitions.
I just picked up an ESP32 yesterday. I couldn't find an RS485 board at the place I picked up the ESP from. I have to order one. I do not know if you are familiar with the ESP32 or not.
dual powerXtensa®32-bitLX6microprocessors @ 240 MHZ 448 KB of ROM for booting and core functions. 520 KB of on-chip SRAM for data and instructions. 4MB of additional storage. 802.11 b/g/n (802.11n up to 150 Mbps) Bluetooth v4.2 BR/EDR and BLE 18 analog GPIO pins 6 digital GPIO pins native communications support: UART, SPI, SDIO, I2C, PWM, I2S
These things can run Python. and several other high level programming languages. and the best part is it was only 10.00 USD
@kdschlosser Yes, I have seen that enhancement, it is all the rage. I have not moved on from ESP8266 yet. However, I do see advancement with swift on micro-controllers such as this -- this is likely good enough reason for me to make the move. https://www.madmachine.io , https://forums.swift.org/t/swift-for-bare-metal-rtos-based-microcontroller/19372 and https://github.com/swift-embedded/swift-embedded
I tried with that Python and it just isn't my thing -- let's just say scars from Fortran days and fussing with indents. :)
That would definitely make a nice device for monitoring and forwarding data without having to string up much wiring.
I believe it would. There is a modbus library already made for Python. This would take a whole lot of the work out of writing an interface for the ClimateTalk protocol. Maybe it can help you with your writing in swift.
@kdschlosser Climate Talk is not like modbus at all. (you probably realized that now but put down for sake of others). CT has way more to it from its prescription at the physical layer all the way up to the application layer with stuff like shared data services and messaging mechanism to an interface capable device and menu functionality.
I started working on a Python binding for ClimateTalk. https://github.com/kdschlosser/ClimateTalk
I for my ESP32 and a MAX485 all wired up running MicroPython, currently it is set up to relay the rs485 data to my PC. I am going to have some tinkering to do because of the packet timings. I am probably going to handle that end of it in MicroPython, The speed in which data gets sent to and from the ESP is not good. and it would cause an issue.
I have a large chunk of the classes done for the various commands and those classes subclass a man packet class. This makes it easier when accessing the data in a packet because it can be done by a friendly name instead of having to use byte and bit numbers all the time.
The ClimateTalk API is horribly written There are a bunch of things they do not give information on how a packet should look. Tho I might find something elsewhere in the API docs because re seems to be a bunch of repeat information.
I am willing to bet there was an SDK available at one point in time. I say this because of the generic application specification and it's use of c functions for commands.
Also I mentioned ModBus because I saw somewhere in the API documentation that ModBus was an alternative lower level protocol. It could have been in the LWP spec, but honestly I do not remember.
Ah yes, the LWP spec. I recall reading that and thinking, ok, easy-peasy, then the realization came in. :). Yes, I have had to re-read the spec. a number of times now. There may be repetition but also key bits that are only ever stated once. So, it does require some imagination to fill in the rest and piece it all together. One thing I'm finding confusing right now is message 0x76 (Address Confirmation). It says a number of times that this message is broadcast on subnet 3. However, the API shows a response message which means that this is (or can be maybe?) a routed message. Also, when something is broadcast, it usually does not get a response UNLESS it is a slotted time response. So, this is a little confusing. Maybe it will clear up when I get to focusing on the data flow cycle.
Good to hear you're making progress on data logging. Such records will help clear up these kinds of questions!
Now that I have finally gotten over a nasty hurdle with the ESP32 I am finally ready to connect this thing to my furnaces. The nice thing is i am going to be able to have all 3 furnaces tied together on a single bus.
The thing is I am not sure how much logging I am going to see taking place because I do not own a thermostat that is communicating. I am probably going to have to figure out how to become the Coordinator and also get the AutoNet working. which is a complete mystery because there is not any information really in the api about it.
I may reach out to Emerson or EcoBee and see if they might be able to help and shed some light on some of the protocol. ya never know they may have the SDK and would be willing to share it. I know Rheem would be a waste of time to try and contact. they have so much misinformation on their website about their own product.
Hmm .. well you're in the same boat as me then. Very liability save in this case. :) Although, regardless, reverse engineering by protocol snooping is 100% legal. Gonna have to get a communicating thermostat for there to be something to snoop. I'm gonna bet, one or more furnaces are FFD devices so you'll see them announce themselves when they are powered up but then they'll go quiet as they fail to find a thermostat. Just a guess. Looking forward to hearing the answer.
yeah but in my boat spending 500 beans on a thermostat for only testing purposes is a hefty price to pay.
also I figured out the whole broadcast snafu you were having. look in the CT-485 API Reference in page 41 read the paragraph right below Table 57. This will explain broadcast messages and how they "don't receive responses"
also Table 57 is for shit. "Node ID Filter" is actually "Node Type Filter" if you read that same paragraph I mentioned.
Tho I have 3 furnaces and one of them is going to have to hammer out who the coordinator is. so I should be able to get a decent chunk coded just based on that.
The problem with my furnaces are these damned memory cards in them that save all operating data between power cycles. I am hoping this does not also include the state of the RS485 network.
what brand HVAC do you have?
I have Amana (AMVM97). Just noticed branding changes to 'ComfortLink' that comes with internet bridges etc. extensions to this protocol which are likely not fully documented with what was released and with what were working with. Thanks for the typo-sightings! (No wonder I was confused with that a while back!)
The API documentation is riddled with wrong names of things. if you start to really read the AutoNet and the portion about the coordinator you will see that they are telling you to use commands that do not exist. you have to get a little creative and match the name they are saying to the actual command name in the Command API docs.
The same issue exists in the Generic Application specification as well. I am thinking that the same people that wrote the command specification didn't have a hand in writing any of the other documentation. and the people that wrote the other docs didn't go and check the actual command names.
I am still trying to figure out what in the hell a slot delay is. I saw a description of it, if that is what you want to call it. It explains nothing about what it does.
I got really creative with the MAC address and session id creation. I used a guid generator and bit shifted the bottom 64 bits for the session id and the bottom 58 bits for the MAC address off of the guid. Best and easiest way I could think of to generate a random number of that size, no sense in reinventing the wheel. Then I bit shifted them into separate bytes so they can be sent. For the MAC address I shifted the 2 bytes needed for the manufacturer id together and the 5 for the device id so they can be output as hex for logging purposes. Easier to read that way.
I just pushed a new commit to to my repo if you wanted to have a look see. I have almost all of the command packets completed, requests and responses. once that is finished then I am going to have to start on what needs to get send and when. That is going to take a lot of time to sift through to figure out. I do know that the 3.5ms byte timing and 100ms packet timing is going to be the hardest thing to lock down if I am not processing any of the packet data on the ESP. It is just so much easier to develop on the PC without needing to flash the esp over and over again to test. we will wait and see what happens with that end of it.
I wish that using the ESP and flashing it was not so problematic. and frankly the documentation for MicroPython sucks!...
Heads up to you. do not use any ADC2 pins if you use the WiFi on the ESP32. the WiFi goes all screwy if you do and so do the ADC2 pins you are connected to. Took me a few days to figure that out. No mentioned by expressif or MicroPython. It is not a MicroPython specific issue, it's a problem with the Expressif SDK. older versions of the SDK work better then newer ones with respect to that problem. I wanted to mention that to help save you some hair pulling. I know at my age I want to keep as much up there as I can.
https://www.comfortbridge.com/
You can sue them!!!
states this right on their webpage
Technology compatible with any control system
If they do not have a public API for their protocol then it is not compatible with "any" control system. It is compatible with the the control systems they are partnered with which is only themselves I believe. a Goodman thermostat will NOT work on my Rheem Furnaces. Even tho they use the same protocol for communications. There are changes made to the protocol after climatetalk disappeared that were made by the manufacturers that were apart of the alliance that ssps the protocl from working between manufacturers.
At least you have this thermostat available for your furnace.
This is what I have available
and can you believe that most places charge around 700.00 for that thing. best I have found is 500.00
Ohh, that is good link for a laugh. Yeah, no I don't have the communicating controller thermostat. Otherwise, this project would have been done long ago as I would have just made a limited functional device for my heat pump so that it could control the air handler of the furnace. And hence, this becomes a hobby/obsession because the idiocy of this business in unbearable. Success will be measured in getting these 'incompatible' brand islands working with each other.
NOTE : https://github.com/slaff/Sming and/or https://github.com/SmingHub/SmingRTOS (I think the RTOS one works with ESP32?) as they have host emulator available in their build chain. Or, if you're using micro-python, you'd think the big advantage of that is you can run in a 'host emulator'. That should speed up development.
Also note this timing thing, I actually nailed for the ESP8255 in this repository. I'd used oscilloscope to verify and calibrate timings and it is all interrupt regulated. It could be reasonably portable to ESP32, you'd have to re-calibrate timings however (there is a seconds per clock tic factor in there). don't know how this can be reliably controlled in micro-python. Maybe make a c++ library and link to that?