conversation continuation about ClimateTalk

[kdschlosser]

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.

[kpishere]

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

[kdschlosser]

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.

[kdschlosser]

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.

[kpishere]

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

[kdschlosser]

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.

[kpishere]

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

[kdschlosser]

the link is no good.

[kpishere]

Oh, odd. Well, I'd added the file to the folder in the project kpishere/Net485 anyhow.

[kdschlosser]

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,

[kpishere]

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'

[kdschlosser]

Now it is showing up when I just went and looked. It is the same script I have seen before.

[kpishere]

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.

[kpishere]

Image of the test rig.

[kdschlosser]

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

[kpishere]

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

[kdschlosser]

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.

[kpishere]

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

[kdschlosser]

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.

[kpishere]

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!

[kdschlosser]

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.

[kpishere]

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.

[kdschlosser]

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"

[kdschlosser]

what brand HVAC do you have?

[kdschlosser]

also Table 57 is for shit. "Node ID Filter" is actually "Node Type Filter" if you read that same paragraph I mentioned.

[kdschlosser]

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.

[kpishere]

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

[kdschlosser]

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.

[kdschlosser]

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.

[kdschlosser]

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

[kpishere]

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?

[kdschlosser]

I have a cross platform timer function I write that has a 13 microsecond precision. This is the timer I am going to use if i can use it locally. and if not I will see what I can come up with for MicroPython

[kdschlosser]

OK I did a test I can get down to 54 microsecond precision using MicroPython and that is the best I can get from it without messing around with hardware timers. 54us is fine for timing 3.5ms and 100ms. So if i have to go that route it shouldn't be an issue.

[kpishere]

That slot delay is explained with some detail in Network Spec. section 11.1. And mentioned throughout. It is for NetV2 only. I figured out that R2R question. In NetV1, the R2R message is sent to each V1 node in succession and a Ack_R2R is expected. In V2 network, this is different, there is a Token offer broadcast (on Subnet 3 only), there is a slot delay (a random delay by each device) then first response wins and they get an R2R message etc. from there. The V2 mechanism is more scalable.

[kdschlosser]

I honestly do not know how any company would want to willingly add this protocol to their furnaces. It is a complete mess. Try follow the getting and setting of configuration data. And this nothing about HVAC MDI profiles. You can see what they are supposed to look like at the bottom of the water heater profile API. I have not come across anything like that for HVAC. it tells you what the capabilities of the furnace is. I cannot locate an MDI for motors either.

[kpishere]

You're way into the functional stuff than me right now. :). I'm still sorting out the underbelly of the networking logic and mechanisms to facilitate communication. On that front, it has some nice features. It attempts to be very 'idiot proof' in that it tries to be plug and play. No device ids to set and stuff like that. Also, it attempts to be fault tolerant with coordinators negotiating and asserting themselves when needed. This is important for less than perfect installations. It is clearly a 'working document' and the later versions have gone dark as companies involved have cultural issues.

[kdschlosser]

I do agree on that. I think the largest problem is there were to many hands in the proverbial cookie jar when this thing was written. It has over complicated something that shouldn't be.

Instead of it being a protocol for HVAC they tried to design it as a protocol for anything really. And that is what has lead to the over complexity.

they should have let a furnace be a furnace, and a thermostat be a thermostat and so on and so forth. have a "coordinator" that would manage the handing out of network addresses. but that would be the extent of it's logic. A furnace should not be able to tell another furnace what to do. a furnace should not tell an AC what to do. This should be facilitated through a thermostat. or a zone controller. Those are the only things that should be able to send commands. to any other device on the network.

The setting up of the network by an installer would be to instruct the thermostat as to what devices it is supposed to control, so if there is more then a single thermostat on system then you can have specific devices control specific furnaces. if there is more then one furnace and a single thermostat then there would need to be an accessory temp sensor on the network for each additional furnace and the thermostat would be instructed to pair a temp sensor to a furnace so you can have a single thermostat act as a central control point.

even with all of the functionality that is available with climatetalk I have not come across anything that allows me to set the modulation of a gas valve. I am beginning to wonder if a furnace is going to announce it's self as 2 motor devices and an HAVC device each needing to have it's own address set.

I moved onto the operation end of things because that is fairly straight forward most of the operational commands happen through a single network packet, the actual network communications are going to be far more complex to get working right and I am going to need to be connected to the network and see how the communications is being handled in a live environment.

I did manage to locate one of those thermostats I need for 300 bucks. It is actually from the same company where I got the furnaces from. I am going to call them today and see if they can do a deal for one of them.

[kdschlosser]

OK so I finally managed to locate the MDI sheets for the motor control and HVAC and zone controls. You would think they would be like the water heater and included in the water heater profile specification but NOOOOO. they have it in the command reference If that makes any real sense.. the command reference also has a hodgepodge of commands. nothing is really organized in that document. But it does contain information that is not found in the profile specifications for the different devices.

I think I may start to chop up the API documentation and organize it so that it makes sense. Put the HVAC stuff all together. put the motor stuff all together and so on and so forth. This bullshit of jumping from place to place to place and having to go back and change things because something new was found in some other portion of the documentation is crazy! It is pissing me off because I keep on having to go back and change things because I ended up finding a "new" piece of information.

as a note. do not take what the commands are at face value... you will need to read each of the profile docs and then the entire command reference to actually figure out what in the hell they are doing. I have been ping ponging back and forth between api docs trying to make heads or tales of what is going on. when I say read.. you need to read the damned things line for line do not really pay attetion to the tables for "quick" information

[kdschlosser]

also.. I wanted to tell you that one of the reasons why i moved onto the functional portion of the protocol was because I knew you were hammering out the lower level end of things. So this way with me having gotten most of the legwork done with the upper level of the protocol we would be able to have a meeting of the minds so to speak and be able to share what each other knows. Plus there would be some code to be able to follow on either end. It will help each of us to get to the goal faster. You writing a protocol binding in cpp and me writing one in Python. I figured that would be a better thing to do that way when I get to the point of dealing with the lower level stuff I have someone I would be able to ask for help if I was having an issue. and the same goes for you as well.

Seems like it would be a good way to go about it.

[kpishere]

@kdschlosser Further to this point, the interface point between the Coordinator+AutoNet and the virtual device (on a FFD, or 'the device' on an RFD with coordinator+autoNet behaviour disabled essentially) will be a local unix type port file descriptor port (it could even be an actual serial port). This may not be clear in the code yet but that is the intent of what will happen in the Net485Subord class.

So, with my test setup, the communication between device application and coordinator+autonet will be physical serial connection between Mega2560 and computer. In my planned thermostat, the same code on the Mega2560 will run on a Rasperry Pi Zero (or something like that) where it runs as a service in Linux. The device/application will run on same Linux in a different process.

In short, your implementation in Python would work just fine with this approach.

This should work OK on ESP32 also, I think you can have multiple threads on that device with RTOS or something.

[kdschlosser]

ESP32 are dual core processors. so I would make an assumption that they can run multiple threads. Actually I know they can because that is how I have the serial receiving and the TCP socket set up to run. Using queues to handle the swapping of data between them.

[kdschlosser]

I'll tell you what. These Config MDI's are a real ball buster. There is a large number of them and I still haven't really figured out how they get received. I am thinking that they get joined together into a single packet but I do not know if they get stacked on top of one another, or if they only have a single MDI and the items from the first one populate the second and the second populates the third, etc...

I guess it really doesn't matter at this point. once I get to that point is is fairly simple to subclass them together in that way if that is what needs to be done. I haven't come across the scructure for that just yet, I haven't really been looking either.

there are 2 different packets that get used to send the config MDI's if a change is made. But there are also commands that can be used that will also set some of the fields in the MDI. I am not sure if there is a command code because the field cannot be set in the MDI, That might be the case. I have not come across anything that provides that information.

There is a plethora of repeat parts and pieces. I just finally hammered out the command codes. They really messed up the API because they have an HVAC profile doc that outlines AC components, motor components thermostat components and furnace components all smooshed into a single document under a single profile name. This profile actually does not exist. profiles get attached to node types. and there is no "HVAC" node. HVAC is a grouping of nodes. What nodes are going to be available is variable.

This is the tricky bit I am attempting to deal with. If a thermostat is available on the bus then what do I have the program emulate? the thermostat is the master of all. So in order to control the nodes I need to take over the role of being the thermostat. I have thought about this a bit and I am thinking that if I advertise a higher climate talk protocol version I can assume the AutoNet and coordinator roles. at that time I would be able to put the thermostat on a different subnet. I could then set up virtual nodes on that subnet and act as a gateway to the subnet the actual nodes are on.

This way the program can be a thermostat while still having a thermostat connected. This way everything wil be able to be changed. There are control codes that have to be exposed for "remote" use. But it does not allow for "full" control using them. What I do not know is how a thermostat will react if all of a sudden it received some data form the furnace that was not changed by it. I am hoping it is going to absorb the changes and not pitch a fit or reverse the changes.

[kdschlosser]

well I just finished up writing all of the classes for the MDI's

quite a bit of bit and byte operations. fun stuff.... Glad it's done. I am hoping that it is bug free. LOL probably not even close but hey I can dream right?

One ya get past the mess that is the API and ya figure out where things are located in the damned thing it becomes easier to read it. Portions of it start making more sense when you read about a piece in a different section of the API.

It has always boggled my mind why API's get written like this one is. Nothing that lays out what needs to be done beginning to end to make something work. You have to jump from one place to another to try and put it together. There is no real definition of the flow other then an OSI model but the documentation is not completely laid out like the flow diagram.

The MDI's are an enormous chunk of the thing. It lays out the byte order of the packets and the bits for each of the bytes. It is set up so that ou can set a device targeting a specific variable using the command codes. But the getting is done using the Status MDI's and all variables are returned by the device in those MDI's

I am still wondering if I can completely ditch using the command codes all together and use the config MDI's for setting variables on the devices. I know that you can set a config MDI to a device I just don't know if the device will do what it is supposed to do if I do use the config MDI instead of the command codes.

I have to keep on reading. I am sure I will come across the answer soon enough.

[kpishere]

thanks for the updates, enjoying them. I've got a few commits to push too but holding on to them until I can say there is a virtual device that can communicate with its coordinator. And similarly for a net device, that it too can communicate as a client.

[kdschlosser]

I missed the schedule MDI's Tho I only added them for completeness. I am going to be able to build a scheduling class that will have a bunch more versatility then simply temp up or temp down and only being able to do that 4 times a day for heat and 4 times a day for cool 7 days a week as a maximum.

I am going to build one that is not going to be limited to only a repeating 7 days, Tho this can be done if it is wanted. There will be no limit to the number of times in the day that you will able able to adjust the temperature. The ability to change the stage or modulation is going to be available. Or to turn just the fan on or off and set it to a specific speed if supported. Open and close dampers as well.

Basically anything that is able to be changed can be changed using the scheduling system I will write into it.

once I am done with the scheduling part I am going to start work on the node classes. These classes are going to be the work horses and will handle node specific communications.

From what I have managed to figure out is that you will want to have the program emulate a thermostat You can optionally be the coordinator but it is not something that needs to be done. Neither does being the autonet. all of the major devices are going to assume this responsibility if you do not offer it. You have to remember there has not been to many products made that use climatetalk. I do not believe anyone has released any external sensors or dampers I am almost sure it is all large devices like Furnaces, zone controllers, water heaters. These devices will assume the role of the coordinator and autonet.

[kdschlosser]

OK I had a conversation with the head engineer at ewc controls. they have a zone controller that uses the climatetalk

communicating thermostats that will work with climatetalk daikin goodman amana rheem comfort control 2 ruud comfort control 2 white rogers honeywell (do your research on this one)

Those are the ones that he mentioned.

The guy was on the board for climatetalk, he stated to me that they shutdown because of lack of interest. even tho there had been companies that joined only a small number of them did anything with the protocol. I did learn that Rheem EcoNet is a spinoff of Carrier's Infinity protocol. Rheem hired 2 engineer from carrier and had them design a protocol and what they designed was very similiar to what the infinity protocol is.

He did state to me that a bus can only have a single furnace, thermostat and air conditioner. I found that to be an odd statement because of the subnetting abilities of the climatetalk protocol and also because of the large number of address that are possible with the protocol as well. The coordinator software would need to be coded in a manner that would allow you to pair thermostats furnaces and air conditioners and the coordinator would then at that point place them on their own subnets. for the most part all network traffic has to flo through the coordinator.

I did also find out that there is nothing made that allows for full demand control. no thermostats and no zone controllers they all have pre defined "stages" and the demand cannot be adjusted for the stages.

if he weather is cold enough I want to be able to keep my furnaces running 24/7 and have the demand adjusted up or down as needed to maintain the temperature. I should be able to do this using the temperature. It can also be done from using the signals from a thermostat. the thermostat even tho it is connected using the rs485 still functions like a traditional thermostat. It tells the coordinator that heat is needed and the coordinator handles things from there. and the thermostat tells the coordinator when no more heat is needed. some simple code to raise the demand by 1% every 30 seconds or so until the thermostat tells the coordinator no more heat is needed then the coordinator will throttle back the demand at a rate of 1% every 30 seconds or so until the thermostat calls for heat again. since the duration is known as well as the number of steps taken for the demand a middle of the road number could be used. and the duration would be changed to 1 minute. It would not be a difficult thing to hammer out.

[kpishere]

Interesting. Sounds like he is only speaking about NET version 1 which would only support one of each node type. Yah just never know until some live systems have their traffic captured.

[kdschlosser]

even if it is not originally designed to be used that way. since almost all traffic MUST be routed through the coordinator and the coordinator is selected based on how high a climatetalk version that it announces it would not be all that difficult to bend the protocol in a manner that would allow multiple furnaces on the same bus, or to alter the demand rates or calls from a thermostat to a furnace to suit different needs. and this can be done so the other devices would not have a clue that anything like that is happening.

[cowwoc]

@kdschlosser Out of curiosity, was the head engineer over at EWC controls named John? If so, take what he says with a grain of salt. I recently reached out to him for help and, although he meant well, the advice he gave turned out to be factually incorrect.

Out of curiosity, does any one of you happen to know what physical protocol is used by the Daikin One+ thermostat? I have a zoned installation with two Daikin One+ thermostats connected to an UltraTalk 3000 zoning panel. I'm wondering whether it's using RS485 under the hood, and whether the communication protocol is Climate Talk. For the wiring, see page 13 of https://daikinone.com/smart_thermostats/oneplus/pros/DaikinOnePlusProfessionals.pdf

I don't have any experience reverse-engineering communication over hardware. Where do I start if I want to sniff what is being sent over the wire, and check whether it is RS485 and Climate Talk? What hardware/software do I need to do this?

[kpishere]

@cowwoc That is definitely CT device. It is RS485 too. CT defines physical spec, data transfer, protocol and packetisation, and application APIs. the menus in the manual look like classic CT.

I'd taken a break from this project, it is a huge undertaking but I'd like to finish it with same energy I'd started it with.

The simulation framework is key to that.

[cowwoc]

How can you tell that they are using RS485 on the wiring level? And is there any hardware/software/youtube video you could point me at that would teach me how to sniff the communication over the wire to confirm it really is RS485 with ClimateTalk? :)