[RELEASE] Beta 1 - version of Honeywell Home Thermostats (Lyric etc...)

This is strange. I just noticed from the logs that you have Geofencing turned on. Correct? Try turning it off from the Honeywell app and try the same test again. It may be that the setpoint change is being ignored because Geofencing is on or there is a bug in the app that related to Geofencing being on. I don't have schedules enabled on my thermostats and they work fine.

Turned off geofencing, no effect.

I see in the logs in the very beginning the call going out to API has the setpoint listed as 74 even though I typed in 76 on the device page ... I think this is the disconnect

Check this - I added this feature so that in the winter those of us that have to winterize AC units can be assured they won't get activated and vice/versa in the summer.

I tend to agree. Can you post the latest log from when you changed the setpoint to 76? I want to look at the payload sent in the web service call. Look for this string "debugsetThermosat-params" which is where the payload is logged.

Something is really fishy here.

I have all 4 selections enabled under preferences, including "Allow Cool Mode"

@taylor Yes, I wonder if @maximus8907 is running into that old bug where the preference is not initialized. I thought that was fixed.

There you go .... coolSetpoint is clearly listed as 74 even though on the device page i typed 76

app:1172021-02-14 02:56:25.368 pm debugsetThermosat-params [uri:xttps://api.honeywell.com/v2/devices/thermostats/TCC-617911?apikey=nd6mFw4Z1jvtVhvaLs3p9hNECgKAA5UW&locationId=27482, headers:[Authorization:Bearer 2sdaUX9zU6yTCTtjw5zucZISPu0Z, Content-Type:application/json], body:[mode:Cool, heatSetpoint:68, coolSetpoint:74, autoChangeoverActive:false]]

speaking of, i know i typed 76 because later on i see this as well:

dev:1472021-02-14 02:56:30.629 pm infoLyric Cooling setpoint changed to 76

You should see the driver log of the setpoint change at a time before the app tries to make the change. 02:56:30.629 is after the app payload you posted.

The log from the device "Cooling setpoint changed to 76" at least indicates the driver called the app. I suspect that someplace in the app a setting got transposed and cooling point is null so it's getting the current value. Doing some more code review.

I think I see the bug...

emergency heat is being passed twice - I'll code up a quick fix
!parent.setThermosatSetPoint(device, null, device.currentValue("autoChangeoverActive"), device.currentValue("emergencyHeatActive"), device.currentValue("emergencyHeatActive"), null, temperature)

ok, went through another attempt...

this is the first debug output:

dev:1472021-02-14 03:04:38.459 pm debugLyric setCoolingSetpoint() - autoChangeoverActive: false

then i see the app make the call to the API:

app:1172021-02-14 03:04:39.677 pm infoSetThermostate() Mode: Cool; Heatsetpoint: 68; CoolPoint: 74 API Response: 200
app:1172021-02-14 03:04:38.479 pm debugsetThermosat-params [uri:xttps://api.honeywell.com/v2/devices/thermostats/TCC-617911?apikey=nd6mFw4Z1jvtVhvaLs3p9hNECgKAA5UW&locationId=27482, headers:[Authorization:Bearer AZeoLCkzEjda7NcKWczPGB3nGUdc, Content-Type:application/json], body:[mode:Cool, heatSetpoint:68, coolSetpoint:74, autoChangeoverActive:false]]

then i see the driver state that it made the call:

dev:1472021-02-14 03:04:40.669 pm infoLyric Cooling setpoint changed to 76

On separate note, i just poked around with some of the other controls. I was able to successfully change the mode from Cool to OFF and then back to Cool.

Here is what that looks like on the log:
dev:1472021-02-14 03:07:34.231 pm debugLyric setThermostatMode() - autoChangeoverActive: false
dev:1472021-02-14 03:07:34.226 pm debugLyric off called

......

app:1172021-02-14 03:07:35.657 pm infoSetThermostate() Mode: Off; Heatsetpoint: 68; CoolPoint: 74 API Response: 200
app:1172021-02-14 03:07:34.245 pm debugsetThermosat-params [uri:xttps://api.honeywell.com/v2/devices/thermostats/TCC-617911?apikey=nd6mFw4Z1jvtVhvaLs3p9hNECgKAA5UW&locationId=27482, headers:[Authorization:Bearer AZeoLCkzEjda7NcKWczPGB3nGUdc, Content-Type:application/json], body:[mode:Off, heatSetpoint:68, coolSetpoint:74, autoChangeoverActive:false]]

.......

dev:1472021-02-14 03:07:36.622 pm infoLyric mode changed to off

Can you try updating the driver code with https://raw.githubusercontent.com/thecloudtaylor/hubitat-honeywell/thecloudtaylor-coolingsetpoint/honeywellhomedriver.groovy

If that works I'll update the release.

1 Like

@taylor I just got a reply from @maximus8907 on email. He's locked out of posting anything more today because he's a new user. Your fix did the trick. He also thanked you and I for our help.

Awesome - I'll create a release.

1 Like

I was going to try this out but then I discovered this...


Perhaps system maintenance?

I just checked my logs from last night and there was one error that happened at 8:40 pm EST, a hostname resolution error.
app:5532021-02-14 08:40:10.120 pm [error] (http://192.168.1.178/installedapp/configure/553)java.net.UnknownHostException: api.honeywell.com: Temporary failure in name resolution on line 679 (RefreshAllDevices)

Token refresh was normal before and after that error. When I have seen errors from the Honeywell side, it is usually in the middle of the night. Probably system maintenance on their side.

Well when I woke up this morning I checked again and it's still offline. I checked my client list and the thermostat was actually showing a 169.xxx.xx.xx ip address. Super strange so I'm checking into it now.

Well I'm not sure what the issue was but I restored from a backup file (of my unifi controller not HE) and all is well now. I also tested the update and EVERYTHING is working great!

That is really weird, but I'm glad to hear you are back up and running.

1 Like

I had a similar issue last week, in my case it was Honeywell's server being down as api.honeywell.com was not resolving. About 2 hours later it was back.