Able to read data, but not set

[nebulous]

Able to read data, but not set

[cribbstechnologies]

I'm trying to figure out why this is happening so I can use it :) I've opened the proxy so all requests go to carrier and get logged and the corresponding controller endpoints just return the message that came from carrier but the thermostat never reaches back out to get more data (that I can find, at least). I've modified the headers to match what comes back from carrier and I'm generating an Etag based on the body and adding it but the thermostat never calls back for the updates the status messages tell it's there.

[mpcookson]

This appears to be exactly what's happening to me as well. I'm running version 131493-14.01 of the WiFi thermostat code, having installed an update for it around March.

If I adjust things (change from "away" to "home") via the Android app, the app updates its display, but the thermostat doesn't get the update so it still shows "away". I see new files being generated in the infinitude/status directory, though none contain the text "home".

If I adjust the away/home setting from the thermostat, the Android app updates and the infinitude display updates and I see "home" in the "req-systems-4216W######-status.txt" file in the status directory.

It appears that infinitude is blocking updates coming down from the Carrier website, or not able to correctly pass them on, or not handshaking correctly with Carrier, or something, and that's the likely reason why it's not able to change the thermostat's settings.

I would love to help debug this if anyone can think of next steps.

[nebulous]

I'm swamped by outside obligations these days, but if you're looking for next debugging steps, I would guess based on this evidence that the cacheing of requests/replies between Infinitude and Carrier has a bug which causes only the first request to actually hit Carrier's servers, never again to ping the mothership.

[cribbstechnologies]

I removed the cache check and every request phones home. I modified the endpoint to return the actual response from carrier rather than the generated XML including all of the headers received on the Carrier response and the thermostat never calls to get the updated config. There's gotta be something that's not 100% correct about the response to make the thermostat not think it should reach back out to get config. I'm definitely interested in helping figure this out but I've tried everything I can think of.

[sejgit]

Some info which may be helpful. Been using infinitude in my workflow since around February
An update direct to the web ui has worked back to thermo fine; but update from the iPhone app has not. Not part of my flo so I have let it be (I have a python program handling geofencing to my home automation, ISY based). This would say the recent update may not be the issue. Interested to help as well ; would be gravy for me in my system.

[mpcookson]

@cribbstechnologies How did you remove the cache check? I would be willing to forego app to thermostat control if I could get my own code able to check and change the thermostat. Right now nothing works, the thermostat appears cut off in both directions, though reports no errors with its phone home traffic.

I'm wondering if Infinitude (or a library it uses) isn't doing the hash of the http request correctly so it's being thrown out? Maybe Carrier changed the format of the incoming or outgoing request subtly and Infinitude needs a tweak?

Ideas on where to look next?

[cribbstechnologies]

There's an if block at the top I commented out. I've got a python client that can read all of the data from the thermostat and I was able to get that information into Home Assistant.

The phone app doesn't seem like it's been able to control the thermostat for quite a while so there's no loss there for me.

There's something different in the request/response chain because even spitting the same exact request back to the thermostat doesn't trigger a reload.

[cribbstechnologies]

Has anyone been able to get more info?

[MizterB]

I am experiencing the same issue, where I can read values just fine, but the thermostats refuses to apply any config changes being passed through Infinitude. I suspect this is due to API/firmware changes over the past year as Carrier launched their OpenAccess program.

I've tried to do some debugging through a proxy server, and it looks like the changes that are breaking Infinitude writes could be due the response when the thermostats POSTs to /system/[id]/status. When POSTing to Infinitude, the response looks like:

<serverStatus version="1.6"> <configHasChanges>false</configHasChanges> <pingRate>12</pingRate> <serverHasChanges>false</serverHasChanges> </serverStatus>

When POSTing to this URL direct to Carrier, the response looks like this:
<status version="1.29" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link rel="self" href="http://www.api.ing.carrier.com/systems/3515W008158/status" /> <atom:link rel="http://www.api.ing.carrier.com/rels/system" href="http://www.api.ing.carrier.com/systems/3515W008158" /> <timestamp>2018-01-21T17:44:53Z</timestamp> <pingRate>10</pingRate> <iduStatusPingRate>93600</iduStatusPingRate> <iduFaultsPingRate>86400</iduFaultsPingRate> <oduStatusPingRate>90000</oduStatusPingRate> <oduFaultsPingRate>82800</oduFaultsPingRate> <historyPingRate>75600</historyPingRate> <equipEventsPingRate>79200</equipEventsPingRate> <rootCausePingRate>72000</rootCausePingRate> <serverHasChanges>false</serverHasChanges> <configHasChanges>false</configHasChanges> <dealerHasChanges>false</dealerHasChanges> <dealerLogoHasChanges>false</dealerLogoHasChanges> <oduConfigHasChanges>false</oduConfigHasChanges> <iduConfigHasChanges>false</iduConfigHasChanges> <utilityEventsHasChanges>false</utilityEventsHasChanges> </status>

I don't know that all of the returned XML nodes are necessary, but since the root element differs, I suspect that the thermostat can no longer parse the response to see the "serverhaschanges" or "confighaschanges" tags and take appropriate action.

@nebulous - does this make sense to you?

[plagiarize]

I'm hopeful this can be resolved by @nebulous or someone else, as I really want to use this to integrate my Carrier with Google Home. With Stringify I can tie http put commands to various triggers and automated settings, but I'm having the same problem here with the thermostat failing to pick up the changes. I've tried rolling back to the previous firmware on the thermostat, rebooting, etc. All the correct data shows. My http commands show in infinitude, but they never apply. I'm going to try more troubleshooting before I throw the towel in (since I don't know much about coding), but I have my fingers tightly crossed that this project isn't dead, and that this will be resolved by someone. The man in the middle approach is such a smart way of handling this. I just wish it still worked!

[plagiarize]

I was able to find the v12 firmware (had tried 13 and 14) and get this working. After starting the service, I also deleted the state folder. I haven't verified yet whether the firmware or deleting the state folder was the workaround, but it's working!

[nebulous]

The chi branch has been merged. This is a fairly major overhaul of the storage engine used for Infinitude and how it shares data with Carrier's webservice as well. Hopefully it will help with this issue. I was able to control the stat (for the most part with some lag) from the Carrier iOS app, OSX app, Infinitude, and the stat itself(listed in order of decreasing lag).

Incidentally, I'm still using v12 on my wall unit, so that's most likely to work right now as its the one I've tested.

[sbrown4]

I'm puzzled by this as well.
There seems to be a problem with the pass-through. If I make a change in the t-stat, the Bryant web site is updated on the next status post. If I make a change on the Bryant site, the next status post response has serverHasChanges set true. The t-stat doesn't issue a get for the changes. However, sniffing the wire shows that the wrong response is returned to the t-stat. Rather than the return from the post to the Bryant site, the content of the 200 return is the xml from the original post.

I thought that this was due to automatic rendering, so I added a $c->render_later in the before_dispatch hook. But, no joy. The $c->render() in the /systems/:system_id_status stub just seems to be ignored. However, if I remove it, I get a "time out" message and the process hangs, as expected.

Anybody have an idea what's going on?

[nebulous]

@sbrown4 is this still an issue for you with the latest code?

[sbrown4]

PR 61 fixed this.

[rcoletti116]

Do I understand correctly that this requires a v12 firmware to resolve and use infinitude for read and updates?

[nebulous]

This is a closed issue from over a year ago. At the time I was using v12 successfully, and I'm now using v14 also without incident.

[rcoletti116]

This is a closed issue from over a year ago. At the time I was using v12 successfully, and I'm now using v14 also without incident.

Yep - saw that, but noticed you commented as recently as December. Thanks for the info. I'll go through my configuration again and see if I can get it working.