ooh, interesting. I need to get a usb key setup with old/new firmware to try it out. Need to make sure I'm able to downgrade if everything falls apart. MQTT is a much smarter way of doing thermostat control, so hopefully Infinitude will be able to support it as well.

I flashed the new firmware on my parents' thermostat. It does completely break the monitoring and control functionality, but it still appears to use the old API for time, weather, and update checking. I'm not sure if the MQTT data is sent over the configured proxy or not, but I certainly would hope so. In any case, it looks like the proxy hack will still be necessary because there is no way to control which server it uses for MQTT.

I flashed the new firmware on my parents' thermostat. It does completely break the monitoring and control functionality, but it still appears to use the old API for time, weather, and update checking. I'm not sure if the MQTT data is sent over the configured proxy or not, but I certainly would hope so. In any case, it looks like the proxy hack will still be necessary because there is no way to control which server it uses for MQTT.

maybe do a test and configure the thermostat to use a non existent proxy and see if the control info flows or not - if it does then we know MQTT bypasses the proxy....

I'm not sure if the MQTT data is sent over the configured proxy or not, but I certainly would hope so.

Infinitude only proxies http requests and MQTT would most-sanely be done via a websocket (though considering Carrier's past experience with api design choices who knows 🤷‍♂️) upgrade.

But I, like @scyto above would love to know if the 'stat is still operational via Carrier's app when the proxy is set to Infinitude (or to a non-existent proxy value).

Really worried about this.and breathlessly waiting for an update here... The energy tracking feature in the new firmware sounds delightful. The inability to control the thermostat locally is a deal breaker - as in I'm rewiring my thermostats if that happens.

If you care about it that much, just don't upgrade the FW (it doesn't happen automatically, at least not until 4.17 is already installed). But please, please don't rewire your thermostats. If you use Infinity equipment without the Infinity thermostat, you wasted your money on the equipment.

+1 for this feature as well... Looks like they bypass the proxy for the MQTT communications. MQTT is also over SSL which I haven't had any luck yet with getting a "transparent proxy" working via my router to intercept the traffic. They may have certificate pinning going on within their firmware (which is a good practice).
I really wish they'd open up their full API.

If they're pinning the cert and bypassing the proxy, we are essentially dead in the water, yes? No interception possible, and likely no local control?

The new firmware does not appear to fall back to the old protocol if the new protocol fails to connect. I inadvertently tested this with my setup after upgrading. I of course had the proxy configured for infinitude, but I also had a firewall rule allowing the thermostat only to connect to the proxy (not to anything on the Internet, thereby blocking the new protocol). The thermostat still requested time and weather through the old protocol, but nothing else.

The energy tracking feature in the new firmware sounds delightful.

@brettonw
FWIW energy tracking data is available to Infinitude (see http://infinitudeIP/energy.json) with older versions of firmware at least.
A vacation mode editor and energy tracking feature have been on the long list of Infinitude feature requests for a while now, but if you use Home Assistant, a REST sensor should be able to make use of the above linked data.

The energy tracking feature in the new firmware sounds delightful.

@brettonw FWIW energy tracking data is available to Infinitude (see http://infinitudeIP/energy.json) with older versions of firmware at least. A vacation mode editor and energy tracking feature have been on the long list of Infinitude feature requests for a while now, but if you use Home Assistant, a REST sensor should be able to make use of the above linked data.

Woah! I didn't know that. I remember seeing the Energy Tracking in the request or todo list for Infinitude so I didn't think it was available. I'll be adding it to my Home Assistant sensor today!

I guess I'll be holding on to this firmware as well. I really want monitoring in HA more than control, so maybe I'll be able to get my serial adapter working so I could log it directly from the feed.

@mamarley Since you have a "real world" use case of the new firmware breaking what used to work with a mandatory proxy, you might try contacting Carrier to see if some feedback might be enough to get some future changes to the behavior regarding fallback or MQTT going through the proxy.

energy tracking data is available to Infinitude (see http://infinitudeIP/energy.json) with older versions of firmware at least. A vacation mode editor and energy tracking feature have been on the long list of Infinitude feature requests for a while now, but if you use Home Assistant, a REST sensor should be able to make use of the above linked data.

Thanks for bringing that up. I have looked at this data and it was good enough when I was getting started on tracking my energy usage. It gives day 1, day 2, month 1, month 2, year 1, and year 2 data for comparison purposes. Unfortunately it isn't at the level that I'm looking for now, and doesn't seem to be very accurate. I think it is just using the preset information about efficiency, not actually measuring power usage.

TL/DR:
I was hoping for real-time power tracking split out for the blower and compressor.

Details:
This discussion probably belongs in a different issue, but I thought it would be useful for other people to hear how I am solving this issue in Home Assistant, and to hear if there is a better way.

I have two separate Infinity units, one for upstairs and one for downstairs.

I've split out their power usage manually... I pull the api/status json to get the compressor state (off, stage 1, stage 2), and I manually measured the compressor power draw when in different states with a handheld Fluke meter (a bit of a challenge to get the compressor into the different states). I use a template sensor to report a power draw based on this information (assuming it's constant). I'm assuming the compressor is on when the thermostat says "running" or "heating" (I look for "ing" in the current mode).

I did a similar thing for the blower, assuming it is on when the compressor is on. This is not 100% true, but the Carrier tech told me the blower will only run for 90 seconds after the compressor shuts off, so it's close to true. I haven't measured the power draw on the blower yet, just assumed it's around 300W.

My total for the 4 pieces of information is within about 5% of the report coming from my whole home meter minus everything else I know about my house, so I'm happy enough with it for right now.

I'll have to do something different in the winter when I start caring about gas usage. The energy.json report may be all I can get, but if I track on/off times through a day, I might be able to divide a one day usage report by the actual time in use to get a "typical" consumption number.

Home Assistant doesn't make this process easy unless you just bought kWh meters for everything. I'm stubborn and 1) won't use ESPHome (just don't have any knowledge there), and 2) won't buy any product that puts information outside the local intranet.

For those who are curious, apparently with the latest 4.18 version, they backed out the MQTT implementation (also interesting, the 4.17 version is no longer available for download online, it's back to 4.05).
After doing some tinkering with my transparent proxy settings, I WAS able to intercept the SSL communications coming from the thermostat. Which is when I found out they took out MQTT. At that point I pointed my thermostat back to infinitude for the proxy, and then I was back in business.
Not sure when they'll try to go back to the MQTT implementation, but thought some folks might be interested in the latest there.

Just out of curiosity, from where are you getting 4.18? I was just at my parents' house last weekend and their system was not notifying about an update and I can't find 4.18 online anywhere.

I believe a couple weeks ago I got a notification of an update on the thermostat screen. I didn't pay much attention to what the update was when I saw it, other then just clicked on install. When I found out that I wasn't seeing any MQTT traffic, I checked the version on the thermostat and proceeded to check online for release notes on 4.18 (which I was unable to find). The specific version it's showing is: 131626-04.18
Sorry I can't be of more help on where to find that version.

I've had a hard time finding previous versions of firmware, so PSA: hang onto any versions of firmware that you download just in case.

I've split out their power usage manually... I pull the api/status json to get the compressor state (off, stage 1, stage 2), and I manually measured the compressor power draw when in different states with a handheld Fluke meter (a bit of a challenge to get the compressor into the different states). I use a template sensor to report a power draw based on this information (assuming it's constant). I'm assuming the compressor is on when the thermostat says "running" or "heating" (I look for "ing" in the current mode).

I did a similar thing for the blower, assuming it is on when the compressor is on. This is not 100% true, but the Carrier tech told me the blower will only run for 90 seconds after the compressor shuts off, so it's close to true. I haven't measured the power draw on the blower yet, just assumed it's around 300W.

Not sure if the data aggregated by the infinity systems is accurate enough. My understanding is that they use a fixed value (e.g. compressor uses 2.5KW) and the runtime to determine usage. This is often far off from reality.

I am using a greeneye monitor with 15 second intervals to get a more accurate picture. There are similar (and maybe cheaper) devices as well. My Blower uses up to 425 W, the rest is system standby consumption. Data is passed into Home Assistant and then into Influx/Grafana. I am considering adding some monitoring for my gas meter as well once the winter comes along.

Indeed, after measuring my furnace multiple times I now use 700W as the multiplier.

@nebulous On the comment about previous firmware versions. The latest Carrier thermostat firmware can be downloaded here: https://legacy.myinfinitytouch.carrier.com/Infinity/Downloads
4.31: https://cacbdpapps.net/marketing/eula/Infinity_System_Control_V0431_EULA.html
4.05: https://cacbdpapps.net/marketing/eula/Infinity_System_Control_V0405_EULA.html
3.94: https://cacbdpapps.net/marketing/eula/Infinity_System_Control_V0394_EULA.html
3.62: https://cacbdpapps.net/marketing/eula/Infinity_System_Control_V0362_EULA.html

For Bryant thermostats
Latest: https://legacy.myevolutionconnex.bryant.com/Evolution/Downloads
4.31: https://cacbdpapps.net/marketing/eula/Evolution_Connex_V0431_EULA.html
4.05: https://cacbdpapps.net/marketing/eula/Evolution_Connex_V0405_EULA.html
3.94: https://cacbdpapps.net/marketing/eula/Evolution_Connex_V0394_EULA.html
3.62: https://cacbdpapps.net/marketing/eula/Evolution_Connex_V0362_EULA.html

If you have the ICP ION variant of the thermostat you can get all the previous firmware versions here
https://airquest.hvacpartners.com/products/detail/SYST0101CW
4.31: https://cacbdpapps.net/marketing/eula/ICP_Ion_V0431_EULA.html
4.05: https://cacbdpapps.net/marketing/eula/ICP_Ion_V0405_EULA.html
3.94: https://cacbdpapps.net/marketing/eula/ICP_Ion_V0394_EULA.html

For the Carrier & Bryant firmware it appears you can get access to their API with this legal agreement
https://www.shareddocs.com/hvac/docs/1010/Public/07/sw_openapi_gs_2019.pdf
https://carrier.hvacpartners.com/products/detail/SYSTXCCITC01-B

Thanks for those links @LukeSkaff ! Do you have any idea if Bryant firmware is able to be downgraded? I stumbled upon this project after building a new house with a Bryant unit, only to find out that I must have bought at an unlucky time because mine came with 4.17 and it's not giving me an option to upgrade :(

Yeah, it does sound like your system(s) was/were installed wrong. You mention that you think the thermostat is in the wrong place and, in all likelihood, it is. As far as I am concerned, there simply isn't a good place to put a single thermostat in a multi-room space of any significant size. The problem is that the thermostat usually ends up getting put in a central hallway or something in the middle of the house. The problem with that is that all the heat load, both from external sources and from internal activities, tends to be placed on the edges of the space, as far away from the thermostat as possible. Combine that with bang-bang constant air volume (CAV) control that often provides no ventilation when the compressor is off and it can take quite some time for the thermostat to react to changes in temperature in the rooms in which people actually spend time.

The place where the Infinity control really shines is in combination with inverter-driven outdoor units (the 25VNA4 and the 25VNA8) in combination with Infinity zoning. When you have an ODU with 5 stages (25VNA8) or fully variable (25VNA4) combined with a variable-speed AHU (all modern Infinity AHUs have this) and modulating zone dampers (this means the position of the dampers is variable rather than being full-on or full-off) with a zone thermostat in each room (or at least much closer to them), you can achieve a much better method of control. Under this paradigm, instead of switching on when the temperature gets too high and off when it gets too low, the system runs more or less continuously and supplies enough cold air to each zone to keep it at temperature without cycling. The constant provision of cold air keeps rooms from getting stuffy and is also ideal for dehumidification. It is, as far as I am aware, pretty much as close as you can get to a commercial-style variable air volume (VAV) system as you can get with residential equipment.

I'm not sure if you need my help to do something more elegant, since I have kludges on top of hacks on top of duct tape in a single zone system with assorted Home Assistant/esphome mods. One of the most effective hacks thusfar is installing a 6 inch inline duct booster in the basement feeding one of my upstairs registers from ambient basement air. Setup a speed controller connected to esphome/home assistant to run it. Worked far better than I could have expected, even with only 240cfm it worked better than just running the house blower all the time. I worry about feature creep, but Infinitude could probably stand to expose some rs485-only data in json - blower motor speed in particular - to get a more accurate idea of running state. I have a separate booster fan in another duct also running esphome with a temp/humidity/pressure sensor that can detect running state fairly well too, so that's also an option. You can see the temperature and humidity values spike very detectably when the system is actually conditioning, but unfortunately the pressure sensor can't reliably detect a change in duct pressure, so I don't use that.

Edit: I looked at other open issues and see that people are having trouble with 4.31 so I guess I'll stick with 4.05, though it looks like people are able to downgrade.

I see there have been 2 additional firmware releases. Neither mention MQTT anymore.
Was anyone able to confirm if downgrade is an option or know if these newer versions work with Infinitude?
https://www.myinfinitytouch.carrier.com/Content/docs/v0431-20221128.pdf

Version 4.31 (November 2022) 
Version 4.31 software includes the following updates to the Series B Carrier® Infinity® System 
Control: 
 Data rate limiting until app usage is active. 
 Reminder alerting homeowners that they must download and use the new mobile app 
(Pop up message reminding users to transition from the legacy app to the newer app). 
 System monitor – feature added to alert any potential issues with temperature control 
 Enable/disable for system monitor (provide an option to turn on or off this feature) 
 Ability to clear stored Wi-Fi credentials (existing control with new homeowner) 
 New Vertex coils added to coil selection screen for refrigerant charging 
Version 4.22 (August 2022) 
Version 4.22 software includes the following updates to the Series B Carrier® Infinity® System 
Control: 
 Updated cloud connection interface to improve the response time between mobile app 
and 
 Added QR code generation & display support for wall control models. 
 Added QR Code feature to access consumer site and release notes directly from mobile 
device. 
 Updated UI Help text for Quiet Mode and Capacity Limiting screens. 
 Changed reminder Icon to reminders & alerts where the user can now set Low and High 
temperature and humidity alert (fault codes 187 – 191) this "trip point" will then send a 
notification to the end user for an out-of-range condition. 
 Added ability to reset equipment reminders via mobile app. 
 Updated Filter check logic to operate based on pressure monitor status. 
 Addressed the issue to report consistent Energy tracking information between wall 
control display and mobile app. 
 Updates to reflect the accurate Carrier® Infinity® 24/26 ODU configuration when installed 
with FE4ANF005 model fan coil. 

Data rate limiting until app usage is active.

also reads to me as potentially "don't have the stat send anything but an alive message until the new version of the app is installed which uses a different interface"

Can confirm 4.31 is connecting to mqtt.res.carrier.io port 8883 (MQTT over TLS) even though the proxy is set. Not getting anything from the thermostat in Infinitude. :(

Not sure if anyone has had the patience, but I'm trying to see if it eventually falls back to the proxy if the MQTT doesn't make it. Currently blocking at the firewall and it appears to be using some sort of backoff timer between retries.

@mattster98 any news on fallback with 8883 blocked? It's nice to see Carrier joining the 21st century using mqtt to control IoT devices, but it is rather annoying that in so doing they're making it harder for people who'd like to control their IoT devices 😄 I'd also be interested to know if there are any configuration options for setting the mqtt hostname. Perhaps in the "secret" service menu?

Sadly, no. I gave it a few days and gave up.

There is the "MyInfinity server address" which is set to www.api.ing.carrier.com:80

It does list a MyInfinity Data Server and a MyInfinity OTA Server separately on the remote access status, but I can't find a hostname setting anywhere. Nothing in the secret service menu.

New user here… I’m glad I found this thread. Since I started this adventure running 4.31, I was wondering why nothing was working. After reading through here I downgraded to 4.05 and now all is well. I’m not sure what system features I might have lost with the downgrade but I haven’t noticed anything.

I have a recent Carrier Infinity install, and it upgraded to 4.31 on day 1 after connecting to wifi. After using the thermostat a little, I was disappointed with the lack of control.
I setup Infinitude on my HA and then I was disappointed that the thermostat didn't communicate with Infinitude (not blaming anyone, the code hasn't been tweaked yet for 4.31 and the MQTT, etc).

Anyways, the point of this post is not to complain, but to say that I was able to successfully downgrade to 4.05 and Infinitude is getting all the data it needs!

Also, for clarity (because I wasn't sure): when adding the proxy IP address to the thermostat, do NOT include http:// or anything. I just added the IP address for my Infinitude/HA and port 3000 and it worked.

Well, it mostly worked. The Thermostat to Infinitude is working, but temperature changes in the Android Carrier app aren't making it to the Thermostat. I'll go looking for a solution to that now.

@slootsky I also have issues with the mobile app pushing changes to the thermostat when outside of my home, which is only a problem when I'm on vacation, but inconvenient. I don't have HA exposed to the outside world

+1 to this being important (and the carrier app being junk!).

If I can help with debugging/etc. happy to chip in.

for those who downgraded from 4.31 to 4.05, was it microsd only or usb for the B tstat model? I despise the 4.31 upgrade as it's been their attempt to force users off of the infinity app onto the carrier app (which is horrific, both UI, UX and from a reliability perspective - I've been on their beta for it and don't recall them responding to any feedback... additionally the visual logic is backwards). Sigh.
Really glad I found infinitude & this thread though.

Has anyone tested to see if using a DNS lookup override to have Infinitude act as a MITM, or to just block the MQTT traffic altogether?

My Bryant Evolution thermostat does three DNS querries to the WiFi's DNS servers on boot:

1. www.ota.eng.bryant.com
2. pool.ntp.org (this is not the NTP server provided by the DHCP server)
3. mqtt.res.carrier.io

The thermostat then connects to mqtt.res.carrier.io on 8883. It looks like they're using an old version of AWS IoT core under the hood. It's possible that either they don't enfocre cert checking, or even better, if MQTT fails, it falls back to the old API calls that can be intercepted by Infinitude.

Unfortunately it's the "C" model of the stat, so it only has OTA FW updates :(, so no rollback; and I think other smart thermostats don't support Carrier's variable speed hybrid heat pumps.

It's been a minute since I did tcpdumps on this but if I recall, it was not using the DHCP assigned DNS servers. Still possible to spoof/MITM with the right setup, but outside the scope of infinitude either way.

It looks like they're using an old version of AWS IoT core under the hood. It's possible that either they don't enfocre cert checking, or even better, if MQTT fails, it falls back to the old API calls that can be intercepted by Infinitude.

My experience with AWS IoT core is that they've enforced cert checking and only allowed authentication via client certificates since day one. I expect blocking will the the only path, and only if carrier supports fall-back.

I'm running a block check right now with pcap. It's still trying to connect to AWS IoT Core on 8883... 5 min in.

I suspect that Carrier just used the AWS IoT core client library, so cert checking would be enforced on the client side as well.

For the text I'm just blocking port 8883 connections, so we'll see if it tries to do anything else.

Funny though that carrier is still using the a2pznvrwmtzhom-beta.iot.us-east-1.amazonaws.com endpoint

I'm running a block check right now with pcap. It's still trying to connect to AWS IoT Core on 8883... 5 min in.

No luck on a fallback to another API. 15 min in and it's still trying to hit the MQTT endpoint.

... Well this sucks.

Also Carrier won't even send out B version stats out to my HVAC tech, even if it's a replacement. They told him he would have to scavenge for a spare part in someones inventory or wait for a salvage part.

No luck on a fallback to another API. 15 min in and it's still trying to hit the MQTT endpoint.

Can your firewall that's blocking generate a RST, rather than a drop? Maybe if it gets a closed port it would fall-back? I'm doubtful this will work, they probably have replaced the old code entirely with the new stuff, but you never know.

Good thinking. It can generate an RST for the TCP/8883 traffic. I'll get everything set up again to pcap and try again.

not sure what system features I might have lost with the downgrade...

Just tagging your reply in hopes someone might see this and be spared my fate. The one thing I lost when downgrading was scheduling - I have been setting schedules with the app, and confirming I see them on infinitude, but the thermostat isn't honoring them. The schedule button was greyed out! I have been running for months thinking it was changing via the schedule and just never looked closely enough to confirm.

I had to go into the service menu, to the thermostat settings and enable schedules.. no idea why that'd be a toggle that defaults to off, but there it was. Schedules are enabled now.

Hoping that someone might be able to assist me with this. I've followed the guides and I have Portainer installed and added the IP to my thermostat proxy. In Infinitude under status I only see Humidity and Fltr. Usage. Is that normal?

Stale issue message

This issue is closed, but it looks like the place for this discussion. I received an email from my service company where they delivered some news:

We were recently notified by Carrier that there will be a critical update sent to all of the Infinity Controls connected to the Wi-Fi network. If you would like to receive the update, please make sure your thermostat is connected to Wi-Fi since the update will occur randomly over the next few weeks.

For those of you not currently connected but are interested in being connected it's important that you do so now. Any controls that have not received the update will not be able to connect to the Wi-Fi network after April 30, 2024.

Correcting for the generic language, it sounds to me like they may be shutting off the old API servers and only leaving the MQTT service up. I think Infinitude would still be able to control the thermostats, since (I believe) it works when the internet connection is out. But I'm not sure how the firmware will act if it (for example) can't even look up its API servers after the address expires from cache.

If this is truly the case, I would suggest that we should wind down this project and direct people using HA to https://github.com/dahlb/ha_carrier

We'll see on April 30th!

@secabeen @johnataravir - Considering a new installation and going back and forth between Carrier and Lennox -- access and control from HA is high on my must include list. I'm just curious what you've found after the update on April 30th?

I recently had a Bryant Evolution installed which is the same as Carrier Infinity.
None of the local control options supported the new firmware on the touch thermostat. Infinitude http proxy mode failed.
Directly connecting to the ABCD bus with infinitve or finitude will collect some stats but can not decode new thermostat codes.

Ha_carrier cloud integration is working well. I mostly use HA for logging stats on the system. The thermostat is very smart with managing scheduled changes to minimize energy usage with variable speed heat pump. I do have an automation to shut-off the system when a window is opened and I will be adding something to shut-off during high cost utility events.
I added Shelly-EM to monitor power consumption on the Heat Pump and Furnace.

I do miss the remote room sensors form my old EcoBee. I was able to add a hardwired remote sensor in my bedroom which overrides the hallway thermostat temperature sensor. The Carrier zoned system looks like a great solution but it’s hardwired room sensors and I could not fit the required dampers in my finished basement ceilings.

@secabeen @johnataravir - Considering a new installation and going back and forth between Carrier and Lennox -- access and control from HA is high on my must include list. I'm just curious what you've found after the update on April 30th?

Sorry to say, but I ended up moving before the 30th, so I don't have any new information. I will say that, for new installs, there's an option in some cases with Carrier to have an Ecobee control the system directly, without a Carrier thermostat in the mix at all. I'm not sure which systems support that, but it might be worth a look. Ecobee has great remote sensors, a robust API, HomeKit, Google and Alexa support, etc.