Custom Component: Carrier Infinity Touch control via Infinitude

Thank you so much MizterB for a great component. I’ve been using it for over a year now with good result.

I occasionally run into a problem where the server won’t accept any changes. In the past it has seemed that rebooting the proxy and the thermostats fixes it, but today that is not working.

I’m running Infinitude:latest in a container. There doesn’t seem to have been a recent update to that, so that’s not the problem. The proxy server is connecting, and it reflects the current state of the thermostat. However, I cannot make any changes through the proxy web interface, it simply reverts after a few seconds.

Has anyone run into this? How did you solve it?

Actually - I think I’ve figured it out. I’ve been switching back and forth between heating and cooling (t’s that time of year…). The heat setpoint can’t be set any higher than the cooling setpoint, so it rejects the change when my existing cooling setpoint is below my new heating setpoint. If I manually go set the cooling setpoint back to 90, everything starts working as expected. I’ll have to investigate how to make sure this stops happening from the HASS side, but in case anybody else runs into this weird situation it’s documented…

Having a hard time sorting out an issue that just appeared with no intentional change on my end. The container is running and the accessible via http. The thermostat seems to interact with the proxy as well. But HA ha started throwing and error and the climate entity no longer works.

I get errors along the lines of:


This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/infinitude/climate.py:371 
Integration: infinitude (documentation) 
First occurred: 10:32:02 PM (1 occurrences) 
Last logged: 10:32:02 PM

Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
    devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
  File "/config/custom_components/infinitude/climate.py", line 216, in __init__
    self.update()
  File "/config/custom_components/infinitude/climate.py", line 371, in update
    dt = datetime.datetime(
OverflowError: date value out of range

Or it just times out. Any idea where I can look to resolve this. HA has been getting flaky again and I’m worried this might just be another dying SD card.

Edit: Made sure that Docker had the right time settings, made sure the thermostat itself had the right time settings, then the thermostat popped up saying it needed an update. After the update its reporting localTime to the proxy and HA is working.

Having some trouble getting the integration up and running, I get an “Error while setting up infinitude platform for climate”:

Logger: homeassistant.components.climate
Source: custom_components/infinitude/climate.py:342
Integration: Climate (documentation, issues)
First occurred: 2:14:01 PM (1 occurrences)
Last logged: 2:14:01 PM

Error while setting up infinitude platform for climate
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
    devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
  File "/config/custom_components/infinitude/climate.py", line 216, in __init__
    self.update()
  File "/config/custom_components/infinitude/climate.py", line 342, in update
    matches = re.match(
  File "/usr/local/lib/python3.9/re.py", line 191, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object

Here is my config.yaml:

climate:
  - platform: infinitude
    host: infinitude.mydomain.net
    port: 3000

Proxy webpage is running and accessible from the domain/port. The thermostat is reporting to the proxy and can receive updates. I poked around in the climate.py and it seems like its unable to retrive the “localTime”. Any ideas?

I had a few questions for you for getting this going.

  1. What type of HA are you using? Supervised/HASSIO or whatever, or using a container?

  2. What should be put for the host? I generally dont know what this means. Should I be putting the IP address of my HA server? I dont know what infinitude.mydomain.net is referring to here.

  3. What port to use? Just stick with 3000? 8080? 0080? I dont think I can use 0080 since its being used by another program

  4. I assume we are all using the evolution connex controller, so the network setup should be similar. It involves setting up a proxy I’m sure but I dont understand what I should do here. Should I do anything with the “MyEvolution server settings”? Right now it just has the default server address for Bryant and the server port 80. What about Proxy settings? I put in my IP address for my HA server, and the port 3000, but I dont see that its done anything. I tried to see if the proxy was running by typing in http:my.IP.address:3000 into a web browser but it just says access denied or nothing is there etc.

  1. If you are using portainer to run a docker container for infinitude, how did you get portainer installed on HA supervised (assuming you are using a supervised install). It seems that HA removed the portainer pluggin so I’m stuck with that route as well.

This thread might be helpful to answer some of your questions:

  1. I’m running HASSIO on a proxmox VM. Easiest way to get full functionality for me as I have a proxmox cluster at home doing tons of other things.

  2. The host is the IP address (or a url that should resolve to the IP) of the proxy server. This is not necessarily the IP of HA(unless you’re running the proxy on the HA machine). infinitude.mydomain.net is a URL that resolves to my infinitude proxy server via my local DNS. This just means I don’t have to remember IPs, everything on my network typically has a URL. For example, my HA web page is at hass.mydomain.net.

  3. I just used 3000 because it was the default. TBH it doesn’t really matter unless you’re overlapping with some other service. 80 is http, 8080 is used as an alternate to http, and 3000 is typically an API port, so it works perfectly fine in this case. If you’re using 80 for http access to HA and are running infinitude on the HA machine, then you’re correct, you shouldn’t use 80.

  4. I have the infinity touch thermostat, but should be similar on the others, you enter the proxy server information into the proxy settings on the thermostat. What you are doing here is telling the thermostat to not talk to Bryant directly, instead go through the proxy. Don’t change the other servers. In fact even if I change the main servers, it resets back to the default after I try to save anyway.

  5. I am running infinitude on my docker VM. So in my case my infinitude proxy server has a completely different IP from my HA’s IP. I’ve never user portainer because I have a completely separate machine for docker containers so unfortunately I cant help there.

TLDR: The thermostat and HA should both be pointing to infinitude’s hostname/IP and port. If you cant get to http://my.Infinitudes.IP:3000 from your browser then infinitude isn’t running properly. You need infinitude running properly in order to the thermostat to talk to HA. If portainer isn’t an option anymore, you’ll have to find some other way to host the infinitude server.

Thanks for the details on this. One thing I hate about HA is how the naming for the setups is always confusing. I believe we are using the same install (i.e., HA supervised), its just that you are using proxmox VM to be able to run more than just HA whereas my NUC is just running the HASS OS and nothing else. Makes me think its better to install it your way instead of just relying on HASS OS, the lack of flexibility is annoying. Only problem is that I dont know linux commands well and its such a pain to get everything working right.

Anyway, I guess the first step is getting the Infinitude up and running, because if that isnt accessible than for sure the thermostat cant communicate with it.

Since I installed Infinitude through HACS and my NUC is just running the HA supervised, than my understanding is that my proxy server address IP should be the same as my HA IP. There’s no other place showing where the IP address may be different.

This is my configuration:

climate:
  - platform: infinitude
    host: 192.168.0.152
    port: 3000
    zone_names:
      - ZONE 1

I try typing in http://192.168.0.152:3000, and I get the “This site can’t be reached. 192.168.0.152 refused to connect”

So this just sounds like the proxy server isnt doing anything. Is there a way to see what the errors could be for this?

Is the hassio-addons different than HACS?

Yea, HACS are custom components that you install through HACS. Add-ons are the ones you can see in the supervisor page.
image

There are repositories that you can add in the add-on store in which you can install versions of portainer that work.

Ok because Portainer used to be on the Add ons page in HA but it got removed. I’m curious if I can just add it through the repository that you linked. I"ll give it a try and see.

I’m running the VM listed here as “KVM/Proxmox(.qcow2)”. If you go back one page to the full list on installations i see the chart at the bottom talking about OS vs Core vs Supervisor. I assume i am running the OS version. But TBH I have no idea because your right its confusing haha.

I’d run a hypervisor for anything like this, I would even do it on a NUC, hell maybe even a Pi. The overhead is so low and the flexibility and portability of VMs/containers is to valuable to rely on bare metal installs anymore. All of this stuff is just a hobby to me, and by no means am I an expert in building data centers, but leaning to use a hypervisor is probably the most valuable thing I’ve learned in the past few years. Proxmox is quite easy to get going, and once its up, building new machines is a process that takes literally seconds.

This is where I think the misunderstanding is coming from. Installing the Infinitude HACS integration is not the same as running the proxy server. The HACS integration only allows HA to talk to the Infinitude proxy. You need something that can run the docker container for Infinitude itself to actually run the proxy (Portainer or like in my case a separate VM with a docker instance). You get the “This site cant be reached” because the site doesn’t exist.

And we have a winner!

Thank you so much for explaining this to me. It was not clear to me at ALL that just installing the HACS infinitude wasnt actually installing the proxy. Of course I didnt really know what the proxy was anyway, but from what I was reading, all I could tell was that HACS was supposed to install it.

So here’s how I fixed this, I installed portainer thanks to the links moto2000 gave above, which was really easy. Had to go around the fact that HA removed portainer recently bc who the hell knows why, but adding the repository from here (GitHub - alexbelgium/hassio-addons: My home assistant addons) allowed me to install portainer no problem. Of course now my HA says its running an “unsupported installation”. Oh well.

Now for adding the container I followed these instructions (Installing on Home Assistant · nebulous/infinitude Wiki · GitHub), and then used this code in the configurations file:

climate:
  - platform: infinitude
    host: localhost
    port: 3000
    zone_names:
      - ZONE 1

I typed http://192.168.0.152:3000 into my web browser and it worked immediately.

I then went up to my thermostat (its an evolution connex running a Bryant HP with aux furnace backup), went into wifi settings, went to advanced settings, went to proxy settings, then put in my HA IP address for the proxy, and using the port 3000. Came back to my computer and BAM, its reporting all the correct info/status.

Now the trick will be migrating this information into HA on a card or something rather than having to go directly to the website. I’m assuming someone around here has also been able to figure this out. Have you migrated the info from the proxy to your HA dashboard/overview?

Edit: I actually just finished this and got it working. First had to create some template sensors to extract the HVAC attributes from the climate entity:

  - platform: template
    sensors:
      hvac_outdoor_temperature:
        friendly_name: "Outdoor Temperature"
        unit_of_measurement: '°F'
        value_template: "{{ state_attr('climate.zone_1', 'outdoor_temperature') }}"
  - platform: template
    sensors:
      hvac_current_temperature:
        friendly_name: "Current Temperature"
        unit_of_measurement: '°F'
        value_template: "{{ state_attr('climate.zone_1', 'current_temperature') }}"
  - platform: template
    sensors:
      hvac_current_humidity:
        friendly_name: "Current Humidity"
        unit_of_measurement: '%'
        value_template: "{{ state_attr('climate.zone_1', 'current_humidity') }}"
  - platform: template
    sensors:
      hvac_target_temp_high:
        friendly_name: "Thermostat High Temperature Setting"
        unit_of_measurement: '°F'
        value_template: "{{ state_attr('climate.zone_1', 'target_temp_high') }}"
  - platform: template
    sensors:
      hvac_target_temp_low:
        friendly_name: "Thermostat Low Temperature Setting"
        unit_of_measurement: '°F'
        value_template: "{{ state_attr('climate.zone_1', 'target_temp_low') }}"
  - platform: template
    sensors:
      hvac_fan_mode:
        friendly_name: "HVAC Fan Mode"
        value_template: "{{ state_attr('climate.zone_1', 'fan_mode') }}"
  - platform: template
    sensors:
      hvac_action_mode:
        friendly_name: "HVAC Current Setting"
        value_template: "{{ state_attr('climate.zone_1', 'hvac_action') }}"
  - platform: template
    sensors:
      hvac_preset_mode:
        friendly_name: "HVAC Preset Setting"
        value_template: "{{ state_attr('climate.zone_1', 'preset_mode') }}"
  - platform: template
    sensors:
      hvac_current_activity:
        friendly_name: "HVAC Current Activity"
        value_template: "{{ state_attr('climate.zone_1', 'current_activity') }}"
  - platform: template
    sensors:
      hvac_scheduled_activity:
        friendly_name: "HVAC Scheduled Activity"
        value_template: "{{ state_attr('climate.zone_1', 'scheduled_activity') }}"
  - platform: template
    sensors:
      hvac_airflow_cfm:
        friendly_name: "HVAC Fan Airflow CFM"
        value_template: "{{ state_attr('climate.zone_1', 'airflow_cfm') }}"
  - platform: template
    sensors:
      hvac_occupancy:
        friendly_name: "HVAC Occupancy Sensor"
        value_template: "{{ state_attr('climate.zone_1', 'occupancy') }}"
  - platform: template
    sensors:
      hvac_hold_activity:
        friendly_name: "HVAC Hold Activity"
        value_template: "{{ state_attr('climate.zone_1', 'hold_activity') }}"

I put the above code into the configuration file, restarted HA, and all these attributes became sensors that I then put into an entities card to see on HA. Works wonderfully but I’m sure there are nicer ways to visualize the data.

1 Like

In your instructions, why are you setting the network setting to “bridge”, when this set of instructions says to set it to “host”: Installing on Home Assistant · nebulous/infinitude Wiki · GitHub

The simple answer is I’m not sure. My Docker skill Is pretty limited. All I know is I tried host and it didn’t work. I had a different container running another solution that was set to bridge and working and once I moved the proxy to bridge it worked. Must be my HA environment?

I believe the bridge he is talking about is the docker’s bridge device linking it to the HA machines network and not the climate config in HA. Glad you got it working! As for the UI, there is a default climate UI tile you can use.

Thanks, but I was wondering how you figured out what the property values were? I.e., “outdoor_temperature”, etc? I have a carrier system and I see tons of data on the :3000 web page but have no idea how to get HA to show that.

Thanks @MizterB this custom component is huge game changer for our new carrier heatpump system just installed this week.

I am coming from an Ecobee system with multiple remote sensors and the InfinityTouch thermostat leaves a lot to be desired, HA integration really eases the transition.

I have two questions though…

  1. Is there a way to get the heat pump stage value into HA? I see it in the infinitude web portal but would like that data to be integrated into my HVAC logging in HA.

  2. Have you figured out if its possible to spoof the InfinityTouch internal temperature by pushing values through infinitude? The reason I ask is I am considering keeping my Ecobee and sensors powered for the temp/occupancy data and then using HA to create a “follow me” system to tell the InfinityTouch what room temp to control to.

Thanks again!

For example, to get the outdoor temperature, you can create a template sensor in your config file, such as below. Of course update per what the zone name, desired unique id, etc. for your respective system.

template:
  - sensor:
      - name: "AC Outdoor Temperature"
        unit_of_measurement: "°F"
        unique_id: "ac_coutdoor_temperature"
        state: >
          {{ states.climate.zone_1.attributes.outdoor_temperature }}

Thank you sooo much for your post. I have been trying to get this working under HASSIO for days. Your post gave me all of the information to get it going. Particularly important were how to get the Portainer add on and that I had to set the proxy server in my Carrier thermostat wireless settings.

Michael