Carrier Infinity integration

@bdf0506 - Thanks for the info, that helps to fill in some dots on what it looks like with different thermostats. I’m surprised that the fancy thermostat is that disruptive to how the system works overall. If it were me - I would sell the fancy thermostat(s), put the old one(s) back and connect using Infinitive and @mww012’s component because you’re going to get a lot more functionality out of them when you can see and control them with HA. Obviously that’s my opinion but, for me, I was looking for whatever I could find that would get my system connected to HA, I don’t really care about the thermostat itself. That sucks that you had already upgraded though.

1 Like

Yea, I pretty much agree with you @Tj_Davis.

To recap for others that may come across this in the future…

If you have a non-touch thermostat, in my case, a circa 2005 SYSTXCCUID01-B, you CAN easily hook this up to Home Assistant. Follow the instructions outlined above with the RS-485 USB adapter, set it up on a linux server, and run Infinitive and the custom HA component written by @mww012, and you’ll have HA integration working in no time. Alexa integration isn’t possible here, though you could likely use Alexa to control Home Assistant for a monthly fee.

If you have a newer touch thermostat, in my case, circa 2017 SYSTXCCITC01-B (which retails for close to $1000, though can find cheaper on eBay like I did), you CAN NOT get this working with Home Assistant at this time. Infinitive will NOT work with this model thermostat. There is something strange with the way the program interacts with this thermostat, maybe support will be added at a later date. It seems like when this thermostat is installed, the temperature now “lives” on the thermostat instead of the main furnace computer, making it unable to be controlled with an app outside of the carrier ones. Instead you can use Infinitude by @nebulous as mentioned earlier in this thread. If you do this, you won’t need to use the RS-485 USB adapter. You’ll then connect the thermostat it to WiFi and add a proxy server in your WiFi settings on the thermostat to be able to point it to Infinitude. There is an API exposed within Infinitude, but I found it to be flaky and not update as often as I would have liked. Going this method, you’ll have a problem getting the weather forecast on the physical unit (Infinitude does somewhat support this, but it is with Weather Underground, and you need an API key which they don’t give out any longer - even though I have an API key, some icons were missing on the forecast still). One of the selling features of this thermostat for me was Alexa integration on this model, and when you use Infinitude, the delay between Alexa control and the thermostat receiving the commands was far too great. Sometimes it would never push down the Alexa command, and other times, the change you made on the physical thermostat would get overridden by stale data in the Carrier cloud.

Maybe one day in the future someone will come up with a way to have a newer touch thermostat AND Home Assistant integration.

For any smart home enthusiasts, I still would recommend against a Carrier Infinity system because you are so limited by these options.

3 Likes

Feel free to submit a PR to add your Dockerfile, @MizterB. I run Infinitude on a super-underpowered box where Docker isn’t an option, but I’m sure others would appreciate your efforts.

I’ve got a copy of home assistant running now and will be happy to help write/test/implement a HA climate platform to pair it with Infinitude. I’m not very familiar with home assistant yet, but can assist in my (almost infinitesimally small) free time. So far I just put infinitude in an iframe card and get settings with the REST component like so:

  - platform: rest
    resource: http://127.0.0.1:3000/api/status/oat
    name: "Outside temperature"
    value_template: '{{ value_json.oat }}'
  - platform: rest
    resource: http://127.0.0.1:3000/api/status/1
    name: infinitude_status
    value_template: '{{ value_json.rt[0] }}'
    json_attributes:
      - clsp
      - currentActivity
      - damperposition
      - enabled
      - fan
      - hold
      - htsp
      - id
      - name
      - otmr
      - rh
      - rt
      - zoneconditioning

Thanks! Grabbing the attributes is a nice start, but I believe the end result would be the ability to set a temperature using https://www.home-assistant.io/lovelace/thermostat/ - you can currently do this with the older thermostats that I mentioned in my post above. This way, you can use automations and such to be able to set temperature when somebody is home, away, etc. We can likely piggy back off of @mww012’s component which is mentioned above.

Infinitude is a great start (thanks for your effort in that project!), but I did experience issues with Infinitude and Alexa and WUnderground integration. I wonder if infinitude can be slightly modified where it can handle some of these items off the ABCD bus instead of having to proxy through to it. Those likely can be handled separately.

I did experience issues with Infinitude and Alexa and WUnderground integration

Wunderground is not strictly required. Infinitude will pass Carrier’s weather endpoints just fine if you’d like. When I first wrote Infinitude I had no desire to use any of Carrier’s services which is why I implemented a wx data replacement. In the years since, we’ve added a semi-transparent passthru to the Carrier API.

I wonder if infinitude can be slightly modified where it can handle some of these items off the ABCD bus instead of having to proxy through to it.

Can you elaborate? Infinitude does support reads from the ABCD bus. Blower speed and CFM for instance come from the serial bus if enabled. Personally, I would love for all control to be based on the ABCD bus, but the registers are different between the touch and non-touch thermostats, so I’ve focused on web control of touch stats where acd has focused on serial control of non-touch stats.

I didn’t notice that piece working when I tested it, will revisit. Maybe I am not understanding the 17 min default value of the passthrough. When I made that value to something like 2 minutes, I found an issue where it would still take far too long for Alexa controls to get pushed down the the tstat, or the tstat wouldn’t be in sync with what the carrier cloud knew about the unit.

I think we are on the same page here. I’d prefer to be able to just use the ABCD bus for everything (like you can do on infinitive), but with these touch thermostats, that doesn’t appear to be an option. If you only use ABCD bus and don’t proxy through, it won’t give you any information about the internal temperature, a proxy is required. It’s likely more of the Carrier architecture vs something that can be coded in Infinitude.

@bdf0506 Thanks for the solid write-up. I really appreciate the effort you put in. I didn’t have the spare cash to throw down on a wifi thermostat so I’m glad somebody was able to give it a shot. Sorry it doesn’t work though.

@bdf0506 @nebulous I’m up for helping with this however I can. Just let me know what I can do.

Thanks. I did file two small bugs under issues on the github page of your HA custom extension. We’ll likely need to create a fork of what you did in order for it to work with infinitude and the api that it uses there.

This may be a red herring but I could probably also make Infinitude play nice as an MQTT Thermostat if that’s less work than making changes to @texnofobix’s (or other) module.

Docker PR for Infinitude is submitted. As noted in the description, I just tried rebuilding the Docker image, and am getting a Wunderground API build failure. So this is not ready to be committed yet. I’m interest in knowing if others are seeing the same issue in a ‘traditional’ deployment.

https://github.com/nebulous/infinitude/pull/72

I’ve also shared my old Infinitude custom component to GitHub. As noted on the README, I haven’t used it in about a year, and it isn’t working right now. I should be able to port the logic I created for my custom proxy server pretty easily. But for now, I just wanted to raise awareness that I have release this into the wild.

Didn’t Weather Underground just stop supporting their API service?

I really like this project, and have gotten pretty close, but when I put the component in the custom components folder and put climate:

  • platform: Infinitude
    host: 192.168.1.42
    port: 80
    into my configuration.yaml file I get an error,
    Invalid config for [climate]: required key not provided @ data['host']. Got None. (See /config/configuration.yaml, line 55). Please check the docs at https://home-assistant.io/components/climate/ any help is appreciated.

InfinitUDE is not presently working on HA. If you think you’ve found a way, would love for you to share more details.
InfinitIVE is currently working on HA.

A known working configuration for InfinitIVE look like this.

climate:
  - platform: infinitive
    host: 192.168.10.10
    port: 8080

@nebulous How up to date is the Infinitude API documentation at https://github.com/nebulous/infinitude/wiki/Infinitude-API-calls?

It looks like you may have made some changes last December to allow for additional gets/sets?

In order to get my HA component back up and running, I need the ability to update

/config/mode

as well as hold, holdActivity, and otmr within the config of each zone

Is this possible?

That documentation is… as up to date as I might expect :slight_smile:

Any variable should be accessible to the API. The documentation such as it is was intended to demonstrate that by example, but I’ve always had a knack for miscommunication, so here’s the basics of what Infinitude does.

Lowest level:
Infinitude at its core is a system to deterministically convert the stat’s xml to json, said json back to xml, and allow for it to be copied into the stat. So, one could, if sufficiently motivated, do all of the transformations outside of infinitude (with curl and jq for example) and pass in the results.

Medium level:
/api/config makes it a little bit simpler(though not much) to tweak one or two variables within that structure. It doesn’t use a full-featured path resolver like JSONPath, but maps basic URIs to attributes within in an admittedly haphazard way. Anything this level can’t do, the “lowest level can”, though I’ll be happy to tweak this to make things easier if I can. Apologies, I’m not in a location where I can explore my own setup to demonstrate right now, so this is all from memory, I recommend getting a JSON browser plugin to make it easy to visualize the structure, and hitting /api/config/(whatever paths) to explore the data.

/api/*path
where *path can be (key|index)/(key|index)/etcetc

Highest level:
Infinitude’s web interface is an editor for systems.json, display for status.json, and optionally renders the RS485 stream. It pulls /systems.json, changes values therein, and posts back to the server for conversion to xml and queues itself up to get downloaded by the thermostat.

Thank you - that is helpful, and I have been doing some experiments to confirm the behavior at the ‘medium’ level. I’m taking the leap to assume that the list indexes are constant and reliable (i.e. /activities/4/ is always ‘manual’), which I can work with for now. Hoping to get my Infinitude components full up and running again today.

For those who are interested, I have rebased by custom component for integrating Home Assistant and InfinitUDE here: