I am aware of the pull request, and will get it integrated soon. I also need to update this to comply with the new directory structure requirements for components. Hopefully before this week is out.
Heads up to anyone using this component that 0.96.x introduces a rewrite of the climate integration, which in turn breaks this component. @mizterb is aware of this and it is filed as an issue on the repo, so best to monitor it there. For now best to stick to 0.95 if you rely on this component.
Status update…a pretty substantial rewrite is in progress. The new ‘preset’ feature fundamentally changes the way I think about the hold behavior and activity settings, so I’m working through it. I can’t personally upgrade HA until I get this fixed, so it is a priority!
1 Like
New version is up on GitHub, compatible with .96. This was a substantial rewrite, and it is quite possible I broke some things along the way. But so far, so good for my use cases. See the changelog for the new Preset behaviors.
Please let me know if you find any issues!
Changelog
0.6
- Rewritten for compatibility with the new climate spec in HA .96
- New presets available to quickly change activities and manage hold settings:
- ‘Scheduled’ preset restores the currently scheduled activity
- ‘Activity’ presets override the currently scheduled activity until the next schedule change
- ‘Override’ preset holds any setting changes until the next schedule change (automatically enabled on temperature & fan changes)
- ‘Hold’ preset holds any setting changes indefinitely
- Service set_hold_mode is mostly replaced by presets, but can still be used for setting specific ‘hold until’ times
Error while setting up platform infinitude
Traceback (most recent call last):
File "/usr/src/app/homeassistant/helpers/entity_platform.py", line 126, in _async_setup_platform
SLOW_SETUP_MAX_WAIT)
File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, 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/infinitude/climate.py", line 84, in setup_platform
devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
File "/config/custom_components/infinitude/climate.py", line 176, in __init__
self.update()
File "/config/custom_components/infinitude/climate.py", line 280, in update
"%Y-%m-%dT%H:%M:%S") # Strip the TZ offset, since this is already in local time
File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime
(data_string, format))
ValueError: time data '2019-07-27T16' does not match format '%Y-%m-%dT%H:%M:%S'
@ender7 a few users reported this issue before refactor. see the issue filed in GH here along with how to fix: https://github.com/MizterB/homeassistant-infinitude/issues/13
Here’s what I did after upgrading, and it worked:
- update line 279 by removing the timezone offset to this
dt = datetime.datetime.strptime(get_safe(self.system_status, "localTime"),
"%Y-%m-%dT%H:%M:%S") # Strip the TZ offset, since this is already in local time
- save and restart HA:
Thanks! That fixed it.
@MizterB, thanks for the rewrite! I like how HA finally got with the program and it now works way better with the architecture of these Carrier thermostats.
But there is one problem I have found. Before, I was utilizing an automation that was utilizing the service climate.set_away_mode and would set climate.thermostat to either true or false.
When set to true, it was essentially a HOLD on AWAY mode /api/config/zones/zone/0/?hold=on&holdActivity=away&otmr=
When set to false, it would return back to normal with /api/config/zones/zone/0/?hold=off&holdActivity=&otmr=
Since the 0.96 changes to climate, I can’t find a way to properly replicate. If I set it to AWAY preset with climate.set_preset_mode service, it will only set it to Away mode until the next schedule with something like /api/config/zones/zone/0/?hold=on&holdActivity=away&otmr=18%3A00.
If I instead set it to HOLD mode with climate.set_preset_mode service, it will do this: /api/config/zones/zone/0/?hold=on&holdActivity=manual&otmr=
If I set it to OVERRIDE, it will do this: /api/config/zones/zone/0/?hold=on&holdActivity=manual&otmr=18%3A00
On the flip side, I am able to set it back from away mode, by utilizing the SCHEDULE mode like this /api/config/zones/zone/0/?hold=off&holdActivity=&otmr=
But how can I set it so that it will set it to action of HOLD and activity of AWAY? Maybe I have to use two service calls to make this happen?
The presets won’t cover this. I believe you would need to have your automation call “infinitude.set_hold_mode” with the following data:
{"entity_id" : "YOUR CLIMATE ENTITY", "mode": "hold", "activity": "away"}
That should give you an indefinite hold on the away activity.
That does the trick. I was trying to keep it using the HA default services, but didn’t think that I could still use this infinitude service. Thanks @MizterB!
1 Like
@MizterB, thank you again for putting this component together! I just upgraded to 98.1 and updated this component as well. I got everything working but I’m having an interesting issue:
I have two, separate, Bryant systems (each with it’s own thermostat). I got them previously up and running by simply having two instance of this component running simultaneously, and using the custom zone name feature to differentiate the two in HA (as both systems run on Zone 1).
Now that the zone naming has been deprecated they both come in as “climate_zone_1” and “climate_zone_1_2”, respectively. The issue is that whenever I restart my HA server they’ll switch entity names depending on which one HA sees first, which wreaks havoc on my automations.
Is there a way to hardcode the zone name in the climate.py file as a hot fix? I tried changing line 184 from return self.zone_name to return self."Main_Level" in an attempt to hardcode the name to “Main Level”, but that broke HA and was obviously not the right move.
Thanks!
Anyway I can get some help with the above? I’m hoping it’s a pretty simple fix if someone’s just able to direct me how to hardcode a zone name so it doesn’t conflict with my other thermostat. Thank you
I’m a little preoccupied right now, so I won’t be able to look into a permanent change for bit. But if you are changing code yourself, try return "Main_Level", without the ‘self’.
I don’t know what I’m doing wrong but nothing shows up for me. 
Hey everyone. I’m new to Home Assistant and Infinitude, and was trying to get this working. I have Infinitude running successfully and can hit X.X.X.X:3000 in my Web browser (all is correct for my thermostats, zones, etc.). I followed these directions for Install Manually, triple checked it, and everything seems correct. But I’m not seeing my thermostats appear in Home Assistant. I’ve looked through the log files for Home Assistant, and I don’t see anything that’s throwing an error (but I also don’t see anything labeled custom_components, infinitude, or climate (although not really expecting that last one).
Should also note that this is all being done from the same internal network, and I’ve also tried rebooting Home Assistant multiple times. I’m running Home Assistant v0.103.6.
Any ideas what I might be doing wrong?
UPDATE 1:
I enabled debugging logs as @MizterB suggested using:
logger:
default: info
logs:
custom_components.infinitude.climate: debug
It looks like it’s actually pulling data (and the correct data). Snippet of the logs below. I’m just somehow not able to get a control object on my Home Assistant dashboard.
2020-02-08 19:17:20 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] http://A.B.C.D:3000/api/status
2020-02-08 19:17:20 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] {'cfgem': ['F'], 'cfgtype': ['heatcool'], 'filtrlvl': ['0'], 'humid': ['off'], 'humlvl': ['39'], 'idu': [{'cfm': ['417'], 'opstat': ['off'], 'type': ['furnace2stg']}], 'localTime': ['2020-02-08T19:14:14-05:02'], 'mode': ['off'], 'oat': ['46'], 'odu': [{'opmode': ['off'], 'opstat': ['off'], 'type': ['proteusac']}], 'oprstsmsg': [{}], 'uvlvl': ['39'], 'vacatrunning': ['off'], 'ventlvl': ['100'], 'version': '1.30', 'zones': [{'zone': [{'clsp': ['76.0'], 'currentActivity': ['manual'], 'damperposition': ['15'], 'enabled':
...
UPDATE 2:
I’m an idiot. I just had to manually add the cards. 
Nothing to see here…
But great work @MizterB! And I can confirm it works with v0.103.6 just fine.
1 Like
A new HA user and not a programmer. Questions:
-
Do you use the TP LInk Router that comes with the Carrier or are you connecting directly to your home WiFi?
-
Is there a “Dummies Guide” on how to set this up in HA?
1 Like
Hey all,
I have Infinitude up and running with my single zone Bryant Evolution setup.
I have an issue with one room in the house staying hotter than the rest (it’s our WFH “office”, on the second floor, always occupied during the day, full of computers, lol). The thermostat is on the first floor right next to the return vent. It’s always much cooler down there than up here. Airflow to the “office” is otherwise good.
What I’d like to do is rig up some kind of automation using a remote temperature sensor located in the office. What I’m thinking of is something like this:
if (thermostat_target_temp_reached == TRUE
&& (office_temp - thermostat_temp > 4) ) // 4 degrees hotter in the office than downstairs
{
turn_on_fan(low);
}
Hopefully this makes sense. I’m not sure how to create the automation to be conditionally dependent on thermostat settings and current temperature, but I’m also not certain how to use Infinitude to control the Bryant thermostat in such a way that it keeps the fan circulating even when the AC switches completely off due to the target temperature being reached.
Hopefully I’m not to off-base by asking this…
Thanks!
How would I code my configuration.yaml if I have 2 thermostats running off two infinitude servers with the same host (192.168.50.100) but on different ports (3000 & 3001)?
climate:
- platform: infinitude
host: 192.168.50.100
That is how I have it working for one thermostat, so that defaults to port 3000. Could I do?
climate:
- platform: infinitude
host: 192.168.50.100
port:
- 3000
- 3001
EDIT/UPDATE:
I ended up creating another custom_component folder called ‘infinitude2’ and just updated my yaml as follows and everything worked!
climate:
- platform: infinitude
host: 192.168.50.100
port: 3000
- platform: infinitude2
host: 192.168.50.100
port: 3001
1 Like
I’m a bit ignorant of the Infinity system as my house had them when I bought it, but it has 2 thermostats. Is this the preferred way to run Infinitude (one instance per thermostat)?