Thermostat reverts to schedule after changed by Carrier cloud API

[jlg89]

I'm using https://github.com/grivkees/homebridge-carrier-infinity to tie in the Carrier controls with HomeKit. Wasn't ever able to get homebridge-infinitude to work properly, in any of its iterations. The grivkees plugin interfaces with the Carrier cloud API. The behavior I'm seeing is that, when I enable the "Away" activity via the plugin, the change gets pushed to the cloud and is reflected in the Carrier Home app as expected, and within a couple minutes the thermostat reflects the change as expected. But the thermostat very quickly, and spontaneously, reverts to the scheduled activity. Disabling the infinitude proxy on the thermostat resolves the issue.

My infinitude config is pretty simple. Is there something I need to add, in order to keep infinitude from ignoring or reverting changes made from the cloud?

{"app_secret":"****","pass_reqs":1020,"serial_tty":"\/dev\/ttyUSB0"}

[jlg89]

Another issue that disabling the infinitude proxy resolves is firmware updates. Those never seem to make it through the proxy. I could be wrong here, but it seems like infinitude assumes that it's in charge of the thermostat, and pretty much ignores what's done on the thermostat itself or in the Carrier cloud. I can see where setting it up to monitor all three places for changes, and then determining which/when/how a change should be propagated, would be a pain.

Maybe the easiest solution would be a config flag that, if set, tells infinitude not to push its settings to the thermostat, and just display the passthrough data. Basically makes it a read-only app, for those who want the data monitoring that infinitude offers, but still want full function of the Carrier API (such as it is).

[thekev]

+1

changing settings in the walled garden in the sky should pass through to the thermostat unmolested.

[nebulous]

interesting. I've not seen that homebridge integration before. Looks like they just grabbed the oauth keys out of a decompile or something. I don't have a lot of respect for EULAs, but that was specifically prohibited by Carrier's terms of service, so Infinitude doesn't do that.

Also, I totally appreciate the fact that people want to use their walled sky garden app, which is why I wrote some limited support for it, and if I have time and tuits will try to install those apps again to see if I can sort out issues with them, but the whole point of Infinitude was to allow for local control of my thermostat without going out to any cloud service - and Carrier hasn't proved itself to be a particularly great cloud services provider 😄

[ericreich]

I am also seeing this issue.. You cannot manually change the temperature at the thermostat.. Something keeps flipping it right back a split second later to the previous mode and set point. Installer was here servicing the equipment and was getting lost and frustrated, was about to warranty the t-stat. I disabled Proxy and everything was good.

[nebulous]

This might be a timing issue - I changed the default Carrier API refresh timeout to 5 minutes - which is what I have mine set to and don't observe this problem. Though to be fair I almost never use their app since Home Assistant is so much better.

[ericreich]

I have continued to test this morning.. As long as the proxy is turned on, on the t-stat. You cannot control what comfort profile is running or temperature… Not thinking timing issue...

So for me Infinitude is not going to work. Wife acceptance factor is overriding me...

On Nov 12, 2022, at 12:17 PM, nebulous @.***> wrote:

This might be a timing issue - I changed the default Carrier API refresh timeout to 5 minutes - which is what I have mine set to and don't observe this problem. Though to be fair I almost never use their app since Home Assistant is so much better.

— Reply to this email directly, view it on GitHub https://github.com/nebulous/infinitude/issues/153#issuecomment-1312543173, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBYP34QHNF22LPRFTCCM3WH7NLXANCNFSM57H5JYYQ. You are receiving this because you commented.

[nebulous]

Sorry it's not going to work out for you. I'd love to be able to reproduce the problem to see if I can fix it(and always happy to accept patches), but when I change the temp at the thermostat it switches from schedule to manual hold and maintains that temp until the hold timer ends. Same when I change it from Home Assistant or from the Infinitude web interface. Not sure about the Carrier mobile app, but I trust their cloud services even less after discovering yesterday that the stat will give up plaintext wifi ssid/password upon request.

[ericreich]

I understand that Bryant / Carrier cloud is not up to par, but is required to run and maintain our system. It's an inverter driven 26seer variable speed system.

I can say that when I disable the proxy / infinitude everything works. T-stat can get to the internet to do software updates for not only the t-stat, but the outdoor condenser and furnace control boards, as well as adjust the temperature manually. Not sure how my system is different other than all components have the latest firmware from the vendor.

Thanks for the willingness to try and reproduce the issue!!

On Nov 13, 2022, at 7:03 AM, nebulous @.***> wrote:

Sorry it's not going to work out for you. I'd love to be able to reproduce the problem to see if I can fix it(and always happy to accept patches), but when I change the temp at the thermostat it switches from schedule to manual hold and maintains that temp until the hold timer ends. Same when I change it from Home Assistant or from the Infinitude web interface. Not sure about the Carrier mobile app, but I trust their cloud services even less after discovering yesterday that the stat will give up plaintext wifi ssid/password upon request.

— Reply to this email directly, view it on GitHub https://github.com/nebulous/infinitude/issues/153#issuecomment-1312725859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBYP4WRQQQDDDF2QR2UTLWIDRIXANCNFSM57H5JYYQ. You are receiving this because you commented.

[jshep321]

Hi guys. Just installed infinitude and I'm seeing the same thing. Interesting change on my thermostat is that several items are gone/greyed out. The touch-n-go section just says "select activity" instead of the previous "holding until..." or "schedule". The schedules and vacation icons are gone!

The temperatures aren't changeable. It's reduced the wall thermostat to essentially a monitor. This is very much not wife approved. :)

Happy to do some debug/logging if this helps.

[kd7gab]

I've had this happen to my thermostat. You'll need to get into the installer menu and enable schedules. I am not at home, so I can't give you more specific instructions. A little googling should get you what you need...

[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 open up the possibility of better (optional) interaction between infinitude and the cloud.

[jshep321]

I've had this happen to my thermostat. You'll need to get into the installer menu and enable schedules. I am not at home, so I can't give you more specific instructions. A little googling should get you what you need...

This worked. But the lack of sync / indeterminate behavior caused me to disable infinitude for now.

[dragonflight]

I just started to try to use infinitude. I had to revert the tstat to 4.05 (anyone know of a source for 4.17?) and got communication working but as described above, changes from the Byrant app (old app) don't stick. This is not a particular problem as I already monitor the system through the 485 (and it makes my blood boil at how bad the temperature control is ...) and I have other plans and ..., but The last perl project I worked on I used perl4 so it's been a while! I thought what better way to figure out what was going on than to delve into why the settings wouldn't stick. A week later and lots of tweaks and shots in the dark I'm stuck and perplexed. What its come down to is as follows: WORKING: set proxy to www,api.eng.bryant.com:80, all messaging is in plain-text direct from tstat to Bryant (use ing.carrier if Carrier) and monitored messaging with wireshark starting with tstat

POST STATUS ---> REPLY OK( config changes) GET CONFIG ---> REPLY OK( alterered config) POST NOTIFICATIONS ---> REPLY OK POST STATUS(updated with changes) ---> REPLY OK ( no changes)

and all is fine the POST STATUS's are sent ever 15 secs

Each of the messages sent are sent as HTTP/1.1, all the responses are HTTP/1.0 and each pair is a separate TCP connection

NOT WORKING set proxy to infinitude (my desktop):3000. I have modified (decimated) infinitude to merely relay the messages back and forth (including the HTTP/1.0 for the replies) and to forward them to port 80 so I can easily wireshark the responses.

POST STATUS ---> REPLY OK( config changes) GET CONFIG ---> REPLY OK( alterered config) POST NOTIFICATIONS ---> REPLY OK POST STATUS(with changes ---> REPLY OK ( config changes)

(of course there are 2 copies of each message, the bodies are identical and the headers seem correct(?)) This repeats ad infinitum with no break (I think it sometimes stops if I quit the app and connect back in again)

In the infinitude case the loop is broken because of the caching. If this break is long enough it appears that the config reverts to the original (hence the change does not stick) and the loop is broken, otherwise it starts over again.

I am at a loss at what to try next, so I am looking for ideas. At first I thought perhaps there was something in the replies being sent to the tstat as HTTP/1.1 originally, so I figured out how to make them HTTP/1.0, but I am suspecting there is some reason the cloud is not accepting the new POST STATUS config as being equal to the CONFIG reply it sent. During the test I changed the heat setpoint and visually checked that both (STATUS and CONFIG) contain the new setpoint. I also tried other parameters with no difference. resetting the setpoint in the app does not fix the problem. If there is a change (like the temperature changes because of the setpoint change) the tstat POSTs a "systems/ which seems to make the cloud happy.

[github-actions[bot]]

Stale issue message