@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.
@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 
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
OK I am wondering if anyone else has installed this lately and if there are any hiccups on newer HA versions. I am wanting to do this to my Carrier thermostat (as shown above) also.
This still works today, using infinitude on Docker and then using the custom add on that MizterB wrote. I have it running on 118.4 without issue.
2 Likes
I’m on the newest version of HA and its still working very well. I dont think I’ve ever had an issue with it.
1 Like
Is it still the case that these “smart” thermostats cannot be integrated into HA? https://www.carrier.com/residential/en/us/products/thermostats/smart-thermostats/systxccitc01-b/
It works. This thread is about the integration that works by having the thermostat go through the infinitive proxy
@countertokens, It’s only as smart as Carrier Corp lets it be. I have a number of guesses as to what’s driving them to keep such a tight grip on accessing their supposedly open API. Theoretically, having skimmed the API, it should be fairly straight-forward to code an integration with this stone age system. However, to date, I know of exactly one Carrier-sanctioned integration with their API - a Skill for Amazon Echo, which is absolutely atrocious. Feel free to read some of the reviews here: https://www.amazon.com/Carrier-Corporation-Infinity®-Touch-Control/dp/B01N1T72HY
All that being said, after having installed a Carrier Infinity system in my previous house, I had the misfortune on stumbling on another one (Bryant Evolution), in the house we upgraded to. For the time being I’m running infinitude, which although wasn’t that difficult to set up, is an absolutely cumbersome solution, by 21st century standards.
Although one can simply rip out the Infinity thermostat, change a few jumpers on the furnace/ac control module, and be able to run a “normal” thermostat of your choice; however, you do end up losing out on some of the finer configuration details, system information and control parameters. As of now, I’ve decided against it.
/rant_off
Big thanks to @MizterB for making my Carrier work the way it should! This is the whole reason I started using HA. I thought I would share my thermostat setup so any newbies can see what is possible using only the Visual Editors.
3 Likes
Hi
I would love to see how you created this. All I have is a simple one with no scheduling, which is something I have the HVAC currently preforming.
5310
You have to understand 4 essential parts of HA:
- Events. Time is one of the events.
- Automations. That’s how you get HA to trigger on events.
- Helpers. That’s how you create the vaules. You can think of them as variables.
- States. That’s how you get values. Every State you can use is under Developer Tools.
You can search the forum for more info on these. I made 2 automations, one for the daytime, and one for the night. Also, the automation I created in the visual editor didn’t work as I planned. I had to do some minor custom yaml code for the “action” to get the automations to work properly. Here’s my automation for the nighttime (my climate service is named “main”):
alias: Thermostat Sleep
description: Sets the thermostat to nighttime temperatures
trigger:
- platform: time
at: input_datetime.night
condition: []
action:
- service: climate.set_temperature
data:
target_temp_low: '{{ states(''input_number.night_heat'') }}'
target_temp_high: '{{ states(''input_number.night_cool'') }}'
target:
entity_id: climate.main
mode: single
The “input_datetime” and "input_number"s are Helpers you must create. The part that really had me scratching my head was how to get those heat and cool Helper vaules into the climate service. That’s where States come in. The schedule control is simply an “Entities” card with the Helpers.
Can you share how you got the schedule into the thermostat?