Carrier Infinity integration

Glad it’s helping people! All the reasons you listed are exactly the same reasons why I went down this path. Again, thanks to all you guys for staying engaged and being willing to try it out.

Next steps for me are to see what needs to be done to get a pull request submitted to HA so it can be an official integration. I’m also wanting to improve error handling. The “host unreachable” error that @scott.parmenter hit could have been caught and offered up suggestions to check the configuration and infinitive status. Stuff like that would probably be worth while. Last thing is it probably needs to be moved to it’s own repo instead of my generic ha_customconponents repo. If life gives me enough time to make progress on any of those I’ll let you guys know.

@Tj_Davis and @mww012 I’ve run into an issue with pushing the Infinitive climate entity to HomeKit via the HA HomeKit component.
The Infinitive Climate entity successfully shows up in HomeKit as a thermostat control and can be used to control the Carrier mode (e.g. off, heat, cool) but when I change the temperature from HomeKit it does not push the new temperature setting to Carrier. The Infinitive web-based interface is working and so is the interface with Home Assistant. Just no temperature control via the HomeKit component. Any thoughts?

That may have been a side affect of removing the SUPPORT_TARGET_TEMPERATURE attribute. As a test, try setting your mode to auto instead of heat/cool. If it works under auto then it’s probably that. If that’s it I’ll look through other climate integrations and see if I can get a hint based on what they’re doing.

I’ll test on my end if I can. I can’t get homekit to stay running so you’re doing better than me at the moment. No matter what I do it works for a bit then everything goes “no response”.

@mww012 - I’ve had the same issue with HomeKit not responding after awhile. It’s not super annoying but it will run for a day or 2 then I have to restart HA due to things not responding in the Home app. I thought maybe I was over powering the Raspberry Pi as I have a little over 100 devices on HomeKit and was planning to upgrade to a server soon. But you’re not on a Pi are you?

@mww012 changing the mode to Auto instead of Heat worked. When in Auto I can change the set temperatures for heat and cool. Is fixing the temperature setting in Infinitive for heat and cool possible?

@Tj_Davis I haven’t had issues with HomeKit on my Raspberry Pi 3 B+. Including the infinitive entity, I have 36 accessories passed over to HomeKit from Home Assistant.

@scott.parmenter yes, it should be fixable. I was doing some digging over the past little bit. The SUPPORT_TARGET_TEMP attribute that I thought was gone may actually just be missing from the base climate init.py. What’s odd is that the support for target_temp_high and low are there. Humidity has support_target_humidity as well as high and low. We should be able to make it work. I’ll try to get it fixed this week.

@scott.parmenter @Tj_Davis I’ve got less than 50 entities total and only 5-6 exposed through homekit. It’s getting really obnoxious and I haven’t found any info that’s helped.

@scott.parmenter @Tj_Davis @strikeir13
Hey guys. I worked over the past few evenings and I think I’ve got it back to normal. It should be back to the same behavior before the whole 0.92 upgrade mess. While I can keep homekit up and running I’m able to change my temps and things seem to work Pull the new changes when you guys get a chance and let me know how it goes.

Been stalking this thread for a while. I also have the Bryant Evolution system. My current thermostat (systxbbuid01-c) is starting to fail, manually switching from Heat to A/C is a little flaky. My dealer want’s $1,000 to upgrade to a new Wifi thermostat. Does this module handle any Humidity adjustments? That is an adjustable parameter on my current thermostat. Does this module act as a man-in-the middle, adding HA controls, but the original thermostat stays put?

The Infinitive front end doesn’t expose any humidity controls but the github seems to show that it does accept target humidity values. The climate component for Home Assistant also supports humidity, so the missing piece might just be in the custom component. Humidity is adjustable on my current thermostat, as well (not sure of model at present), I’ve just never tried to manipulate it with a call to Infinitive directly.

As far as this module, you are correct, it acts as a man-in-the-middle, but it’s more like a man-alongside. Once it’s installed, you can set the temperature, mode, fan, etc., from either Infinitive/Home Assistant OR your existing mounted thermostat and the changes are reflected in both interfaces. The serial-to-USB adapter connects directly to the furnace board and you don’t remove the existing thermostat wires. I actually had some wire nuts outside the furnace enclosure where my current thermostat connected and I was able to connect the serial adapter there for a pretty clean installation.

@mww012 thoughts on humidity? I’ll be able to test the current code tonight/this weekend and I’ll post back with my experience.

1 Like

@strikeir13 is right about the thermostat behavior. It basically emulates another thermostat connected to the same bus.

@michaelhdmd As far as the humidity piece goes, I believe I got that working when I first built the integration but haven’t tested it recently. I’ll give it a shot this week and see what we can do with it.

@mww012 your latest update fixed HomeKit! Well done and thanks!

Any thoughts to Home Assistant 0.93? I believe it has a fix for one of my other components, but don’t want to break Infinitive now that it’s working so well.

@mww012 I may have spoken too soon. I’m getting an error message in the HA log. I’ve troubleshot it a bit and it appears to only crop up when I set the mode to auto:

2019-05-16 21:20:31 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall climate.set_temperature (c:062a1cc39dc14e17823a62b0c98d44bb): entity_id=[‘climate.infinitive’], temperature=72.5>
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/core.py”, line 1147, in _safe_execute
await self._execute_service(handler, service_call)
File “/usr/local/lib/python3.7/site-packages/homeassistant/core.py”, line 1160, in _execute_service
await handler.func(service_call)
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_component.py”, line 194, in handle_service
required_features
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/service.py”, line 316, in entity_service_call
future.result() # pop exception if have
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/service.py”, line 339, in _handle_service_platform_call
await func(entity, data)
File “/usr/local/lib/python3.7/site-packages/homeassistant/components/climate/init.py”, line 559, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
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 265, in set_temperature
if temperature_high - temperature_low < self._temp_min_spread:
TypeError: unsupported operand type(s) for -: ‘NoneType’ and ‘NoneType’

@scott.parmenter I’ve seen what you’re talking about. Long story short, you’ll need to reboot HA when you change from cool/heat to auto or vice versa. If anybody is curious I can go into detail but the tl;dr is to just keep in mind the reboot and you’ll be good. I’ve looked into it a bit but don’t really know how to go about fixing this one at the moment. Mostly because it has to do with how Lovelace presents the thermostat card in the different modes and that’s a side of HA I haven’t really explored.

Okay, thanks @mww012.

@MizterB, any chance we could add functionality to the custom component to allow HA to set Home/Away/Sleep/Wake on the thermostat? That’s one piece that is missing here, since instead of doing manual overrides all the time, which then expire in 2 hours, if you could instead set the program override. Happy to help where I can, but not sure how simple or complex it would be to do this.

@bdf0506 that is certainly possible. I could expose a service to change the current activity. I had been thinking about the same for the hold settings. Haven’t created services before, and I would also need to figure out the right API calls in Infinitude. So it might take a little time. Could you please log an issue on GitHub for me to track?

Sure, i’ll do that. I was messing with this code the other day, seeing what I could find to do this. The problem is I don’t know how Home Assistant will handle this. There isn’t a constant that allows for this. There is “away mode” and that is boolean, maybe that can be overridden to be a string list and we can utilize that?

I’ll log this in Github, I will help you get the right infinitude API calls - that part should be simple. I think you tried doing this at one point, since in the code I see references to activity around line 40 but they aren’t referenced properly after that. It is referenced in the API calls, but you then say it is manual in all calls. You actually have a “bug” in the activity index variables, since you reference away twice and don’t have one for wake. I say bug loosely, since it isn’t actually used so can’t really call it a bug :slight_smile:

ACTIVITY_INDEX = {
"home": 0,
"away": 1,
"sleep": 2,
"away": 3,
"manual": 4
}

Thanks. ACTIVITY_INDEX actually is used is in the set_temperature and set_fan_mode calls, because the Infinitude API (and the XML schema) references activities by ID, not name. But you are right, I’m only using the manual activity right now.

The logic being used right now is that when HA manually overrides either of those settings, the thermostat will apply the new temp ofrfan setting to the zone’s ‘manual’ activity. To then activate those settings, the manual activity is then enabled and ‘hold until’ flag is set, which effectively applies those settings until the next scheduled activity change (same default behavior as the thermostat).

As I’m writing this, I am remembering that this same approach is exactly what I need to do for your request - just apply a “hold until” on the requested activity, which will switch to that activity until the next schedule change!

To clarify the use of Away mode, if HA enables this setting, I place an indefinite hold on the ‘away’ activity profile. It’s probably not ideal if someone uses it for something like a ‘vacation mode’, where they might want the target temp to be something different than their daily ‘away’ profile. This is why I wanted to expose the ability to change the Hold setting through a service, so a script/automation/etc could enable such a scenario.

To conclude, services are the right way to provide the functionality both you and I are looking for (extending beyond the core capabilities of the HA climate platform). I just need to define the service handlers and create the corresponding services.yaml file - the rest of the foundation is already there.

Hey guys,
Since we originally kinda hijacked the infinitude integration thread that @bdf0506, @MizterB and others are working on, I’ve decided to start a new thread for the infinitive integration. This seems like it could get really confusing continuing two conversations here. Please jump over here and continue the infinitive conversation.

Thanks to the infinitude guys for letting me commandeer your thread!

New thread: Carrier/Bryant Infinitive Integration

@scott.parmenter @strikeir13 @michaelhdmd @Tj_Davis sorry if I’ve missed anybody else.

1 Like

For any others, future discussion about this particular feature (setting activity with custom HA component) is on GitHub - https://github.com/MizterB/homeassistant-infinitude/issues/12