iOS 16.2 - New thermostat update

[EHylands]

Hi,
plugin has been working flawlessly.
Just upgraded to iOS 16.2 and updated Infinity touch thermostat firmware at the same moment.
Homekit, Homebridge and Carrier api are syncing without any issue.
Infinity touch thermostat is having intermittent connection problem with Carrier api.
(Changes on api not reflected on the thermostat)
Getting Server connetion status code 107 and 108 on the main thermostat.
Awaiting further Carrier technical support in that matter.
Anyone else experiencing the same situation ?
Any ideal on code 107 and 108 signification ?
Carrier open api documentation not mentionning those codes.
Tnx !

[tedinorbit]

I am having strange status issues after the Bryant update. I was using iOS 16.2 just fine until the carrier/Bryant update went out. It seems as though the thermostat won’t sync status with the api until someone opens the “new” Bryant home app, and even then it takes two attempts to get the correct status.

It’s almost as if they changed it so that the api must request an update from the wall control before it sends anything updated.

[grivkees]

Could you both share what series of thermostat control you have? Take a look at this link to help identify: https://github.com/grivkees/homebridge-carrier-infinity/wiki/Supported-Systems#example-thermostats

I have the older A series, and I'm guessing you both may have B, since it seems like B just received an update.

The release notes for the new Series B update (https://legacy.myinfinitytouch.carrier.com/Content/docs/v0431-20221128.pdf) says it includes "Data rate limiting until app usage is active."

[tedinorbit]

I have the series b, Bryant.

Software version 04.31.

Based on those release notes, that confirms the behavior I’ve been seeing: no updates until I open the “Bryant Home” app and start using it.

[grivkees]

Do you have to open the app each time you change something in homekit for the thermostat to update? Or was it just a one time thing?

[EHylands]

Also running a B serie !
I had a feeling some kind of rate limiting process was in place.

Still didn't get any reply from Carrier customer service.

I can use the Carrier iOS app without any problems, but my web online account doesn't show any information anymore ... I will call Carrier tomorrow.

Thank you for the information.
The issue is clearly not related with the plugin.

[EHylands]

Do you have to open the app each time you change something in homekit for the thermostat to update? Or was it just a one time thing?

Just did some testing AFTER openning Carrier iOS app.

• Homekit changes are almost synced instantaneously on the wall thermostat (much faster than before)
• Changes made on the thermostat take a bit longer ton sync with api.
• After playing a bit and doing many changes, sync are not occuring anymore between api and wall thermostat (rate limiting ?)
• Funny enough, the Zone current temperature is in sync, but not the set target temperature ...

Will check in next hours if iOS need to be launch for api to sync properly

[tedinorbit]

Do you have to open the app each time you change something in homekit for the thermostat to update? Or was it just a one time thing?

No, if I change things (temperature set point or zone comfort profiles) in HomeKit, it makes it to the thermostat just fine. HomeKit just fails to recieve any updates on the current temperature and heating/cooling status for each zone until I start using the app.

For example, when I leave home, I have an automation set all zones to away. I checked HomeKit 2-3 hours after leaving my home and was surprised to see the temperature of each zone was still 70, which is what it was set to while home (typically drops into the mid 60s after being gone for a few hours on a cold day). I opened the Bryant home app and saw the same status at first, and then it proceeded to update the current status after a few seconds. Checking back to HomeKit then reflected the correct status.

[tedinorbit]

It also appears as though changes to the thermostat directly don’t make it back to the api until the Bryant home app is opened also. Still testing to confirm, but that’s what it looks like to me at the moment

[tedinorbit]

I also still have the discontinued “MyEvolution” app on my phone and the behavior mirrors what I see in HomeKit. (I’m sure they deprecated it for a reason, but just interesting to see how the api is working)

[tedinorbit]

from the old MyEvolution app, showing that the last time the thermostat updated the api was 3:15pm (current time is 3:56pm)

[grivkees]

Sounds like there may be some new magic going on here.

Next time you see things get stuck, instead of opening the new app, can you try logging into the carrier or bryant website using the links here (https://github.com/grivkees/homebridge-carrier-infinity/wiki/Supported-Systems)?

I am curious to see if their website also has this new magic, or if it is just the new app that seems to be able to get things synced again.

For what its worth, this change actually hints at something exciting. There has never been a way to 'push' an update to the thermostat from the api, the thermostat polls the api every few min, and you have to wait for that to happen for it to sync. It sounds like the new update supports some kind of push, and the issues here are because as part of that change they got rid of (or changed) polling.

[tedinorbit]

Yes the website also supports it. It actually is even faster than the app (the app requires clicking around before the status actually updates)

[EHylands]

Sounds like there may be some new magic going on here.

Next time you see things get stuck, instead of opening the new app, can you try logging into the carrier or bryant website using the links here (https://github.com/grivkees/homebridge-carrier-infinity/wiki/Supported-Systems)?

I am curious to see if their website also has this new magic, or if it is just the new app that seems to be able to get things synced again.

For what its worth, this change actually hints at something exciting. There has never been a way to 'push' an update to the thermostat from the api, the thermostat polls the api every few min, and you have to wait for that to happen for it to sync. It sounds like the new update supports some kind of push, and the issues here are because as part of that change they got rid of (or changed) polling.

I see the following request on the online portal taking place before every location refresh:

Request URL: https://www.app-api.ing.carrier.com/users/[username]/activateSystems
Request Method: POST

I don't see any reference to that request in the Carrier open api documentation.
Is it of any interest ?

[grivkees]

I saw that also, and I don’t remember seeing that before. That’s my best guess too.

[tedinorbit]

So I hacked an extra call to the activateSystems endpoint in the code on my local system, so far it appears to be working. I don't think its in the right place in the code though since it seems to take two tries to get the latest status in HomeKit.

[EHylands]

So I hacked an extra call to the activateSystems endpoint in the code on my local system, so far it appears to be working. I don't think its in the right place in the code though since it seems to take two tries to get the latest status in HomeKit.

The web site also calls it twice everytime

Request URL: https://www.app-api.ing.carrier.com/users/***/activateSystems
Request Method: POST
Status Code: 200

Request URL: https://www.app-api.ing.carrier.com/users/***/activateSystems
Request Method: OPTIONS
Status Code: 204

Not familiar with the OPTIONS method though

[tedinorbit]

Yeah I noticed that too. I just added the POST call since that’s the one actually doing the work.

[jlg89]

I guess everyone has tried pulling the t-stat off the wall to fully power-cycle it post-update? Over the past few days, I've noticed that the outdoor temp (& presumably everything else) wasn't tracking the thermostat values, neither in the Carrier app nor the plugin. After putzing around with it awhile on the homebridge side, I finally just power-cycled the t-stat, and once it got its pants back on straight, everything seems to have synced up.

[jlg89]

Well, no, I take that back. The cloud isn't staying synced to the thermostat. When I open the Carrier app, the outside temp doesn't match what's on the t-stat, but it seems to update fairly quickly. I wonder if they changed something in the API that causes the sync to only occur if the app is active?

[tedinorbit]

Yep, that’s exactly what we’ve been discussing. There’s some sort of activation that must occur for the thermostat to update back to the cloud now with the latest firmware update. Which version of the thermostat do you have? I’m assuming it’s a B or C

[jlg89]

Thermostat:
model: SYSTXCCITCO1-B
software version: 131626-04.31

Carrier Home App v1.4.0

Ah, the joys of reverse-engineering a kludgy API...

[sebmerry]

I’m having the same issue.

Thermostat:
SYSTXCCWIC01-B

My HomeKit automations are running and attempting to change the thermostats active comfort profile but the changes don’t go through unless I’ve used the Carrier app recently.

[jlg89]

I don't know how long this feature has been there, but if you go into the Carrier Home app, in the hamburger menu, "My Infinity Portal," and then "My Apps," apparently there's a way to authorize third-party apps to access the API. If this is a new thing, it could have something to do with this issue. My recollection is that the Carrier TOS used to prohibit outside access.

[tedinorbit]

I don't know how long this feature has been there, but if you go into the Carrier Home app, in the hamburger menu, "My Infinity Portal," and then "My Apps," apparently there's a way to authorize third-party apps to access the API. If this is a new thing, it could have something to do with this issue. My recollection is that the Carrier TOS used to prohibit outside access.

No that’s been there for a while. It’s for the Alexa skill integration. I attempted to contact them and get a key and they said they aren’t authorizing random home automation projects

[sebmerry]

@tedinorbit do you have a pr for the updates need to get this working again? Thinking about this more I think your right, it’s the api not getting the real current status of the thermostat reliably…so my automation’s conditions aren’t being satisfied. It would be great to expose the last timestamp the thermostat updated the api so it would be easier to see how stale the data is.

[tedinorbit]

Unfortunately I haven’t really solved anything, except that I’m able to get the current status of my thermostat on the second try… I have to open the home app and then make it update a second time before I get the current status. I’m happy to share the lines of code I added if you’d like, but I doubt it’s going to help you in this case?

[sebmerry]

@grivkees thanks for the change! I will give it a try, Quick noob question, in the PR should it be forceActivate instead of forceRefreshToken?

[grivkees]

Whoops... Good catch.

Though it does still seem to be working for me.... Let me see what happens when I actually do the thing I meant to do.

[tedinorbit]

I will test it out today with my B thermostat!

I think A vs B quite possibly does make a difference as A has no longer been receiving firmware updates, correct? I used to have an A before I had to replace my AC unit (I guess the A wasn’t smart enough for the latest communicating AC units?) and I can’t remember a firmware update for a couple of years

[sebmerry]

I have 1.6.6 installed now (and a SYSTXCCWIC01-B thermostat).

So far, changes made in HomeKit (Eve app) propagate to the thermostat in under 10 seconds. Changes made on the thermostat propagate back to HomeKit (Eve app) in about 20 seconds. I measure that by manually refreshing the thermostat in the Eve app until I see the change show up. I will keep an eye on it over the next day to see if EVE and my thermostat get out-of-sync. Please let me know if there are any specific scenarios you'd like me to try.

[tedinorbit]

So far today from my testing I’ve noticed that if you are actively using it, making changes and such, both the changes and status propagate correctly and quickly, just like @sebmerry reports. However, if you haven’t opened HomeKit in a while, there does appear to be a race condition. I believe the intended flow is activate systems is called, this then triggers an update from the thermostat to the api, but before that process is complete, the plug-in checks the state from the api and reports a previous value. If you go back and immediately refresh it again, it appears correctly.

[grivkees]

Thanks for testing! Putting up a new version that may help somewhat by calling activateSystems periodically, even if you are not actively using homekit. I thought homekit would poll the plugin periodically on its own even if no one is checking the home app (which would cause this to run), but it doesnt look like it does.

This wont actually push any observed changes to homekit though, it will just make it more likely that when homekit polls for changes it will be up to date. I want to make the plugin poll for updates and push to homekit on its own.

[jlg89]

Thanks for testing! Putting up a new version that may help somewhat by calling activateSystems periodically, even if you are not actively using homekit. I thought homekit would poll the plugin periodically on its own even if no one is checking the home app (which would cause this to run), but it doesnt look like it does.

What if you set up an Automation that is triggered by a temperature event? I would think that would cause the Home Hub to poll the plugin on some kind of regular basis.

[sebmerry]

However, if you haven’t opened HomeKit in a while, there does appear to be a race condition. I believe the intended flow is activate systems is called, this then triggers an update from the thermostat to the api, but before that process is complete, the plug-in checks the state from the api and reports a previous value. If you go back and immediately refresh it again, it appears correctly.

After using these updates for a couple days it's much better. I agree with @tedinorbit. The plugin appears to be grabbing values before the API has updated with the latest data from the thermostat. If I refresh the Home/Eve 2-3 times, I will eventually get the expected current thermostat status in HomeKit.

I want to make the plugin poll for updates and push to homekit on its own.

That sounds like a great idea @grivkees!

[tedinorbit]

So I made a small hack and it seems to be working alright so far...since you added logic to only call activate once every 60s (and use the cached response subsequent calls), I attempted to give the api/thermostat a few seconds to do the activating and update back from the thermostat by adding an arbitrary 5 second wait... It obviously delays the initial update, but it does seem to give it enough time to report the correct status. I'm sure theres a more elegant solution though.

   async forceActivate() {
       this.log.info("calling activate systems")
       await this.axios.post(`/users/${this.username}/activateSystems`, null, {
           headers: {
               Accept: 'application/json',
           },
       });
       await new Promise(r => setTimeout(r, 5000));
       this.log.info("done activating")
   }

[tedinorbit]

I'm going to lower it to 2.5 seconds to see how that goes.

[sebmerry]

I'm new to TS but, looking at their code, it appears they call activate once every minute.

https://www.myinfinitytouch.carrier.com/static/js/lib/InfinityClient.ts

export const activateUserDevices = async (username: string) => {
  try {
    await commonAxiosInstance.post(`/users/${username}/activateSystems`);
  } catch (e) {
    await handleInfinityError(e);
  }
}

export const activateDevice = async (serialNumber: string) => {
  try {
    await commonAxiosInstance.post(`/systems/${serialNumber}/activate`);
  } catch (e) {
    await handleInfinityError(e);
  }
}

https://www.myinfinitytouch.carrier.com/static/js/hooks/useActive.ts

const activateUserDevicesInterval = setInterval(() => {
      activateUserDevices(username);
    }, ONE_MINUTE);

It's not clear to me that a response tells us if the API has been updated...But I wonder if we can just leverage the status' timestamp to wait x seconds before reading the API values? It looks like once the timestamp/localTime are linked to thermostat -> API updates.

[EHylands]

@grivkees
I'm running 1.6.7
Got following error from API while updating status page:
<error version="1.48"><message>Rate exceeded</message></error>
Profile and Config pages are refreshing fine
Is that related with the new ActivateSystem call ?

Also, the API error crashed Homebridge:
[1/31/2023, 10:15:32 PM] [CarrierInfinity] [****] [API] Failed to fetch updates: Request failed with status code 500 [1/31/2023, 10:15:32 PM] TypeError: Cannot read properties of null (reading 'status') at InfinityEvolutionSystemStatus.getOutdoorTemp (/usr/local/lib/node_modules/homebridge-carrier-infinity/src/infinityApi.ts:385:36) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) at OATSensorTemp.get (/usr/local/lib/node_modules/homebridge-carrier-infinity/src/accessory_oat.ts:10:7) at Immediate.<anonymous> (/usr/local/lib/node_modules/homebridge-carrier-infinity/src/characteristics_base.ts:60:40)

[grivkees]

What if you set up an Automation that is triggered by a temperature event? I would think that would cause the Home Hub to poll the plugin on some kind of regular basis.

@jlg89 Haven't checked, its possible. Feel free to give it a shot. But in any case, it's been on my todo list for a while to have the plugin poll carrier natively and push updates to homekit. Theres a few other usability reasons this is helpful as well.

After using these updates for a couple days it's much better. I agree with @tedinorbit. The plugin appears to be grabbing values before the API has updated with the latest data from the thermostat. If I refresh the Home/Eve 2-3 times, I will eventually get the expected current thermostat status in HomeKit.

@sebmerry As far as I can tell, the 'activate' call doesn't actually initiate a direct update from the thermostat to the carrier api. It seems to instead keep it in some sort of list of systems they are actively keeping the api updated for. And the api seems to only have new values (as judged by the timestamp in the response) every 10 seconds or so, regardless of how frequently I call activate.

So I made a small hack and it seems to be working alright so far...since you added logic to only call activate once every 60s (and use the cached response subsequent calls), I attempted to give the api/thermostat a few seconds to do the activating and update back from the thermostat by adding an arbitrary 5 second wait... It obviously delays the initial update, but it does seem to give it enough time to report the correct status. I'm sure theres a more elegant solution though.

@tedinorbit Activate doesn't actually return any response. Does this seem to help just on the first refresh you've done in a while, or on all of them? It's possible the first activate in a while could jump start the system, but then I fetch the response too quickly (before the update has happened), and the rate limiting logic means we end up waiting longer than we strictly need to to get the update.

It's not clear to me that a response tells us if the API has been updated...But I wonder if we can just leverage the status' timestamp to wait x seconds before reading the API values? It looks like once the timestamp/localTime are linked to thermostat -> API updates.

@sebmerry Yes, activate does not give any response. And as far as I can tell no matter how fast I call activate, the status/config apis still only has a new value ever 10 seconds or so. If you can get this lower, let me know. In any case, the idea of using the timestamps to try to sync fetches with how fast the api has new data is a good idea.

[grivkees]

@grivkees I'm running 1.6.7 Got following error from API while updating status page: <error version="1.48"><message>Rate exceeded</message></error> Profile and Config pages are refreshing fine Is that related with the new ActivateSystem call ?

@EHylands Did this happen just after updating, or right after restarting homebridge? In other words, did this error happen on the very first status fetch since the plugin / homebridge rebooted?

[EHylands]

@grivkees I'm running 1.6.7 Got following error from API while updating status page: <error version="1.48"><message>Rate exceeded</message></error> Profile and Config pages are refreshing fine Is that related with the new ActivateSystem call ?

@EHylands Did this happen just after updating, or right after restarting homebridge? In other words, did this error happen on the very first status fetch since the plugin / homebridge rebooted?

Right after a reboot.
Tried login on the online portal after and this is were i got the rate exceeded error

[EHylands]

@grivkees
API status went back to normal after a few hours of not playing with home app.
Openning and closing Home App many times in a short amount of time triggered the rate limitation process again.
Hope it can help!

[grivkees]

Thanks @EHylands. I'm going to add some backoff logic when we hit errors, and make sure it doesn't crash homebridge as a whole.