TLDR: Yes, it’s working for me. But, not great. Copy/paste your configuration here so we can help more.
I’ve been meaning to test since I first got Infinitude and this integration working on a single thermostat a couple weeks ago anyways. Now that I’m trying to get it to work on a 3 thermostat / 5 zone configuration, I need to sort out some things to understand what works reliably on a single instance so that I can effectively troubleshoot my more complicated configuration.
Things that were not clear to me after researching Infinitude and this integration’s HA community and GitHub pages and configuring it for a single instance:
Should the network mode be set to home or bridge? If both work, which one is more reliable or faster?
Does the Carrier app work reliably when using the Infinitude proxy? It should, but my initial observations suggested otherwise. Could this be related to the network mode?
Do I even have this thing configured properly?
My setup and test methodology:
SYSTXCCITC01-A Infinity Touch thermostat with three zones (testing focused on primary zone/thermostat), Infinitude proxy installed as a Portainer add-on from the @alexbelgium repo (hassio-addons/portainer at master · alexbelgium/hassio-addons · GitHub), this HA custom integration thanks to @MizterB, the built-in HA climate card configured with this climate entity.
All tests pairs (1/2, 3/4) started in my currently scheduled comfort preset (Away) and were returned to schedule.
I started a stopwatch when I made the change in Column 4 on the device/UI in Column 3 and then wrote down the elapsed time when that change was reflected on the device/UI in Columns 5-10. The color indicates good (green) to bad (red)
If the change was not reflected after 3 minutes, I called it a fail.
If I could not test a ‘return to Schedule’ because the initial change failed, I called it invalid.
Using Infinitude means not using the Carrier app to control the system. @nebulous This may be a recent issue as documented here, so here’s another reference point for you. It seems this configuration essentially puts the thermostat>Infinitude>HA integration in local control mostly isolated from Carrier’s servers. Of course, I can just create a HA view that looks and (probably) functions better than the Carrier app anyways and if I ever need remote diagnostics from Carrier or my local HVAC company, I can temporarily disable the proxy on the thermostat.
With that in mind, let’s clean up the data (remove the Carrier app) for what actually matters for this local configuration:
I think I do have a single instance set up properly because there’s not much to mess up when using this Wiki guide.
This local system works well for the thing I need most - relatively quick mode changes from HA (via UI and/or automation) to the thermostat (indicated in green). But, changes at the thermostat could take up to 1:30 to reflect across HA (orange/red).
In HA, pay attention to the mode. Be patient for the temperature range to catch up because it could take in excess of a minute. @MizterB possible bug worth looking into?
For a single instance, the network mode does not seem to matter for reliability or speed (total time for all mode changes was within 2%). Portainer’s documentation explains bridge mode (Networks - Portainer Documentation) (which sounds right since the containers are standalone and need to be able to talk to each other), but no description of host.
In HA, when returning to Schedule, choose the ‘Schedule’ preset, not the desired preset by name (e.g. Away)
As I move on to my 3 thermostat / 5 zone configuration, I’ll set it up using stacks as detailed by @MizterBhere and focus my testing on Home Assistant to Thermostat changes using these results as the baseline.
I’m having the same issue - not sure what’s up exactly.
Running infinitude via docker on a RPI, port 3000 is open. The site opens, but has no thermostat data.
The thermostat is updated to the latest firmware, is updating to the carrier home app, and I’ve set the proxy to be the IP of homeassitant (with port 3000) - same as what loads the unpopulated site. Same issue - does not populate any thermostat data.
Pretty sure newer firmware on newer thermostats have moved to MQTT over TLS, and does not honor the proxy settings, so they do not work with Infinitude.
That happened about a year ago and I think it only affected the B series thermostats, since it looks like the A series is on a different firmware. I have an A series thermostat and it’s still working
I’ve tried both host and bridged network modes in docker. I’ve also wiped my server and started over, installing Infinitude first before anything else with the same results. As mattster98 pointed out, new firmware has broken things, and least for the B series thermostats, which is what we have. I’m going to try downgrading tomorrow and see what happens.
For those interested, since @MizterB no longer seems to be maintaining this repo and there are a couple of PR’s that have been pending for a little while, you can add the following attributes using bcochrane’s PR:
Filter Status (filtrlvl)
Humidity Level Setting (humlvl)
Vent Level/Status (ventlvl)
UV Level Setting (uvlvl)
Humidifier Status (humid)
IDU Modulation (idu_modulation) - I think IDU = Indoor Unit, but I don’t know what modulation status it’s meant to indicate. My three systems all indicate ‘null.’
Note - It appears that if a system does not have a capability (e.g. humidification, UV, etc.), the respective value defaults to 100. Of course, you can just ignore that attribute.
Thanks for the detailed research, @GoodyGizmos!
I can add a bit of color re how the thermostat polls and how Infinitude works which may help to explain some of this.
First, the thermostat gets all updates, be they from Infinitude, or passed down from Carrier, by way of periodic polling. So if you’re unlucky enough to make a change toward the beginning of the polling window, then that will have to timeout before any changes are reflected elsewhere. Infinitude lowers the default polling length substantially however. I think Carrier’s default was several minutes, and Infinitude reduces that to several times per minute. This quick timeout only applies to communications between the thermostat and Infinitude on the local network.
Additionally, Infinitude throttles how often (if at all) it will phone the Carrier mothership with any given url. This is a substantially higher number, but is tunable using the PASS_REQS environment variable. Mine is set to 300seconds which is the default. Of course I don’t happen to care a bit about using the Carrier apps since I use the HA app to control Infinitude via @MizterB’s integration.
Speaking of, said integration has its own polling timeout that can be specified in the config yaml scan_interval. Here’s mine for example:
Hello, very new user to HA trying to add my Carrier Infinity unit. I have followed the instructions to the best of my ability but cannot seem to get this thing working. I am running HA 2023.4.1 on a RPI. Below is the entry I was instructed to add:
The IP address is for the Carrier unit thermostat (WiFi) and I only have one zone. I have HACS installed in HA and I see “Carrier Infinity via Infinitude Proxy” under HACS Integrations tab.
I unable to locate the Carrier thermostat under devices/entities in HA. I am sure I am doing to stupid as I am new. Any help would be greatly appreciated.
Welcome to HA! This integration uses a separate Infinitude server that does the actual communication with your thermostat. The Host IP address it’s asking for is that for the Infinitude server, not your thermostat. Using this approach allows a fully local process, but requires you to run the Infinitude server, either on a different RPI or some other server in your environment.
There is a different custom integration available in HACS called “Carrier Infinity Thermostat” that is simpler to set up (at least in my experience.) It uses the Carrier internet API instead of an Infinitude server though, so it’s not a fully local solution.
Bottom line: if fully local is a requirement for you, you need to set up an Infinitude server before this integration will work. If internet usage is ok for you, check out the “Carrier Infinity Thermostat” integration instead.
Local is not mandatory right now so I will try the “Carrier Infinity Thermostat” integration. No trying to figure out how to add in my config.yaml file. Thats a topic for another post.
It feels this is somehow related … The HA_CARRIER integration (GitHub - dahlb/ha_carrier: Carrier Infinity Integration for Home Assistant) for Home Assistant is able to pull the AC Stage and the Heating Stage from the carrier online server.
Is it possible to extract the same information with the infinitude integration?
Depends…are you able to see this information in Infinitude or its XML files? If so, it can get pulled into the integration. Just need to know where the info is stored.
It’s early days, but I’m playing with a complete rewrite of this integration to bring it up to modern HA standards - the recent deprecations lit a fire under me. Data such as this could be pulled in sensors. No timetable on completion though…
finally, I’d say that the thermostat is communicating to the carrier server the operating stages of the equipment, and it can be read with the Carrier App, on the Carrier Website and with the HA_carrier integration as per my earlier post
For the time being I’ve downgraded to the 4.05 version of the Thermostat firmware and installed infinitude … 1) finally I don’t depend on the unstable connection with the Carrier servers and 2) my automations work also when internet is down … go tell wife the heater is off because the internet is down…
ANNOUCEMENT
I have just released a new version of this component, homeassistant-infinitude-beyond. It has been rebuilt from scratch, taking advantage of the many improvements to Home Assistant since the original integration was released in 2019.
To aid in the transition, this next version can be run side-by-side with the original.
The initial release retains the functionality and data that was available in the other project, although much of the data that was originally exposed via attributes is now exposed as sensors.
Say goodbye to YAML as well! We now use config flows to connect to Infinitude. All zones are automatically discovered, and you can edit names directly in Home Assistant.
Once this stabilizes, I will look into implementing other features that were requested for the old integration.
This is great - thank you! But aren’t there still serious issues with the Infinitude side of things, such as it not working with current versions of the Carrier firmware?
