Carrier Infinity integration

@mww012

Did you read this? It states that requirements now have to go in the init.py file or in a manifest.json file (https://developers.home-assistant.io/docs/en/creating_integration_manifest.html). You have the pyinfinitive requirement in the climate.py file. Maybe that’s the only change needed?

You’re correct, a descriptive log entry would be nice…

Good catch. I think I read that back when it was released but it just didn’t register that I needed to move the REQUIREMENTS. I’ve opened a GH Issue so I don’t forget. Even if that isn’t the fix it needs to be done.

Commenting out the three lines didn’t work for me… Maybe the changes noted regarding the requirements will fix it.
@mww012 @Tj_Davis

Made some progress…not a ton but some. Back when I originally created the infinitive integration I started by copying the base climate __init__.py as the base that I would build from. Not sure if that’s the best way to handle things but I’d seen it done in other integrations and was able to get it working. On a hunch I pulled the current climate __init__.py and compared it with mine. There’s definitely been some updates to the file. After replacing the init.py in my infinitive integration, I restarted HA and the UI was back! Down side was that my infinitive thermostat still didn’t work. There’s still no logs to indicate why but at least I stopped breaking the UI. I’ll keep working on it over the next few evenings and hopefully get this back in gear for us. @scott.parmenter @Tj_Davis @strikeir13

@mww012 - great, thanks for the update. I’ll have a Pi I can test with tomorrow so let me know if there’s anything I can do to help.

Thanks @mww012

Just wanted to give you guys a heads up. I think I’ve almost got all the issues handled. Right now the component loads and works if your mode is set to auto. If it’s set to heat or cool it can pull the target temp and current temp but can’t actually change it. So for those modes it’s basically read-only. I had to change a few things to adapt to the HA changes. Hopefully I’m making smarter choices than I did the first time around. I’m going to try to fix the logic for heat and cool tonight. If I don’t get it finished tonight I expect to have it nailed down tomorrow.

As soon as it’s fully functional I’ll push the working code up to my repo and see if you guys can help test. I’ll do a full write up of what was changed as soon as it’s back up and running.

@Tj_Davis @scott.parmenter @strikeir13
Ok. Think I’ve got things straightened out. I created an ha_0.92 branch on my repo and pushed up the working component. If anybody would like to test it, please feel free. Once we think the ha_0.92 branch is stable I’ll merge it into the master. I’ll list the instructions below for anybody that wants them.

  1. cd .homeassistant/custom_components
  2. git clone https://github.com/mww012/ha_customcomponents.git
  3. git checkout ha_0.92

There’s a few things I had to change and a few that I chose to change. If you don’t care about the details just read the bold below.

  • The entity id is now climate.infinitive instead of climate.infinitive_thermostat. This was originally an unintentional change in my edits but I think it’s a cleaner naming scheme. If you’re referencing the old name you’ll just have to drop the “_thermostat”. If it really causes an issue for folks just let me know and I’ll look at changing it back.

  • Since I was already digging through the code, and have learned a little bit since I originally wrote the component, I decided to take another approach to the __init__.py file. I originally took the climate/__init__.py and copied it for my infinitive/__init__.py. There have been a number of changes to climate/__init__.py since I made my copy. Rather than just update my copy I decided to point the component directly at climate/__init__.py. Not sure if this is the best way to do it but it should be better than a static copy…hopefully.

  • In the current climate/__init__.py the SUPPORT_TARGET_TEMPERATURE attribute has been removed. That’s what I was using to show just a single temp if the operation mode was heat or cool. Since that’s gone I’ve had to remove that support. Now you’ll have a high and low temp set point no matter the operation mode. I’m not thrilled with it but at least I can get it running like this. I’ll see if there’s another way to add that support back.

  • Because of the bullet point above I had to change some of the logic. It’s not currently perfect but it’s usable. There’s a minimum temperature spread that defaults to 2 degrees. This mandates 2 degrees between the high and low set points. If you’re adjusting the high set point and lower it to < 2 degrees from the low set point, the low set point will move to accomodate. This doesn’t currently work if you’re adjusting the low set point higher. You’ll have to change the high set point to a warmer temp, then raise the low set point. Hoping to fix this but haven’t had the time to nail down a solution.

Awesome, thanks @mww012. I’ll give it a try on a dev system in the next few days.

@mww012 I gave this a shot tonight and got the error below in my HA log. Any help would be appreciated.

2019-05-08 21:34:06 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform infinitive
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py”, line 126, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File “/usr/local/lib/python3.7/asyncio/tasks.py”, line 416, in wait_for
return fut.result()
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/infinitive/climate.py”, line 72, in setup_platform
import pyinfinitive
ModuleNotFoundError: No module named ‘pyinfinitive’

:man_facepalming: May have found the issue. My manifest.json didn’t get pulled into my git repo. Don’t know how I overlooked that. The manifest is where the requirement to have pyinfinitive installed gets set. I don’t have the time tonight to tackle it but there may be a short-term fix.

Basically that means that your python environment doesn’t have the pyinfinitive module.

How are you running HA? HassIO, Docker, venv, etc.

I’m running HassIO

I’m not running HassIO so I can’t give you a step-by-step unfortunately. Basically, for a short term fix, if you can ssh into your HassIO environment and run “python3 -m pip install pyinfinitive” it should manually pull down that module and HA should be happy. I’ll try to get the fixed pushed to my repo this evening so if you don’t want to tackle the manual stuff you still shouldn’t have to wait long.

I’m working on testing this out and running into a few issues with the ‘go’ portion of @Tj_Davis’s instructions, specifically these steps:
7. Ran “apt-get install golang-go”
8. Ran “export GOPATH = /root/go”
9. Ran “go get github.com/Will1604/infinitive
10. Ran “go build github.com/Will1604/infinitive"
Since I’ve straightened them out (I think), I figured I’d post my fixes for anyone else who could use them.

For reference, I’m running Raspbian Stretch Lite dated 4-8-2019. As of 5/9/2019, Installing the default “golang-go” in the default repositories will give you go 1.7. Using go 1.7 and trying to run step 9 gives 3 errors and the “go build” command fails. I looked into the error codes and it appears a package used in the “go get” command (https://github.com/gin-gonic/gin) appears to have dropped support for go 1.7 as of 5/7/2019. I manually installed the latest go (go1.12.5 was the version I installed) using the steps in this link, including the PATH part, and the “go get” and “go build” commands completed without error.

Once that was done and Infinitive was up and running, I could actually test the custom component. I followed @mww012’s steps in post #88 above, though I also copied the Infinitive folder into my existing custom_components folder to get the yaml file to load. Unfortunately, the climate.infinitive entity didn’t show up and I ran out of time to keep troubleshooting tonight. I’ll try some more tomorrow or this weekend and report back.

Edit: I realized after all this that I haven’t tried @mww012’s comments about the pyinfinitive module. I’ll try that next.

1 Like

@strikeir13 @scott.parmenter
I just added the manifest.json file to the ha_0.92 branch. According to the dev docs(thanks again @Tj_Davis for the heads up) here, the manifest.json file should tell HA it needs to go pull the pyinfinitive module if it doesn’t already exist.

To test, I deleted the pyinfinitive module and then restarted HA. It seemed to do everything it needed to pull pyinfinitive back down and start running. Give it a shot and let me know how it goes.

@mww012 I tried the new custom component folder and am back to being hung up on reboot. Quite a few errors in the HA log. First two sets below, there are many more but I will refrain from attaching all:

019-05-10 09:26:52 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform infinitive
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/urllib3/connection.py”, line 159, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw)
File “/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py”, line 80, in create_connection
raise err
File “/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py”, line 70, in create_connection
sock.connect(sa)
OSError: [Errno 113] Host is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py”, line 600, in urlopen
chunked=chunked)
File “/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py”, line 354, in _make_request
conn.request(method, url, **httplib_request_kw)
File “/usr/local/lib/python3.7/http/client.py”, line 1229, in request
self._send_request(method, url, body, headers, encode_chunked)
File “/usr/local/lib/python3.7/http/client.py”, line 1275, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File “/usr/local/lib/python3.7/http/client.py”, line 1224, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File “/usr/local/lib/python3.7/http/client.py”, line 1016, in _send_output
self.send(msg)
File “/usr/local/lib/python3.7/http/client.py”, line 956, in send
self.connect()
File “/usr/local/lib/python3.7/site-packages/urllib3/connection.py”, line 181, in connect
conn = self._new_conn()
File “/usr/local/lib/python3.7/site-packages/urllib3/connection.py”, line 168, in _new_conn
self, “Failed to establish a new connection: %s” % e)
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x6d605e50>: Failed to establish a new connection: [Errno 113] Host is unreachable

The “host is unreachable” sounds like either your config is pointing to the wrong IP/port or infinitive isn’t running. Can you double check those things?

You were right @mww012. For some reason the PI running Infinitive dropped offline. I restarted it and then restarted HA on my other PI and I’m in business! Thanks!

wooooooooooo @mww012 success for me, too!
image
For me and my use case, the minimum 2 degree temperature spread is a non-issue. There is more variation between my upstairs and downstairs temperatures than 2 degrees, so I don’t need exacting precision from my thermostat.

Big thanks to @mww012 for the custom component and to @Tj_Davis for his installation write-up! I don’t think I could have figured this out without both of your help and guidance.

Now that it’s 100% working, I should mention that I’m actually using this with a Bryant Evolution system instead of the Carrier Infinity system. The Infinitive docs suggest that it should work with the Bryant Evolution but I can now confirm that first-hand. When we moved into our new house last year, I was told that it would be a significant loss in efficiency if we installed a Nest instead of the existing Bryant Evolution thermostat as it would reduce our modulating furnace to a basic two-stage furnace (albeit with whatever intelligence the Nest would have provided). Getting the Bryant wifi thermostat would have been $300-500 dollars and anecdotal reports were that the servers were very flaky, often totally unavailable, which completely defeats the point of the wifi-connected thermostat and the remote access it affords. Now, with Infinitive and Home Assistant, I’ve largely replicated the remote management functionality of the Nest for hundreds of dollars less, and I have a much more flexible home automation system to boot!

1 Like

@strikeir13 Awesome! I’m glad that my instructions helped and can definitely understand the excitement of getting it working without having to pay a ton of money or downgrade the functionality of the system.

@mww012 is definitely the one that has put in the largest effort, by far, to make this available so huge thank you to him again.