https Authentication help: Honeywell Total Comfort Connect

[quote=“CudaNet, post:58, topic:185223”]Someone might want to confirm in test as I took this from the Java.Groovy. If you didn’t need this then my bad ! I’m bouncing around on different projects here at work.

“StatusCool” == 1 and “SystemSwitchPosition” == 3 then the operating state is currently cooling
“StatusHeat” == 1 and “SystemSwitchPosition” == 1 then the operating state is currently heating.[/quote]

Based on my testing that is not correct. (Seep previous post). StatusCool and StatusHeat (despite the names), indicate what the current setpoint type is (temporary, permanent, or following schedule). Does not indicate anything with respect to the system being on or off.

Thanks for the post. I pretty much completely revamped the way I do refreshing in the next version. It’s possible it still won’t recover gracefully after the 10+ hrs (haven’t let the plug-in just sit there for that long) but if not I will have a better place to start the debugging / modifications from. :slight_smile:

I plan to post the updated version soon (that includes sending the actual changes to your thermostats), but I’m still giving a college try to at least making the UI5 setup page usable…grrr… >:(

Thanks for all your hard work JoeyD!

This post needs a huge like button. Thanks JoeyD!

+1111

Alright folks,

Attached is what I consider to be a “alpha” type release. It includes:

[ol][li]Support for both UI5 and UI7.[/li]
[li]Full two - way (read and post) with your thermostats.[/li]
[li]In addition to the Setup tab, there is now a defaults tab. Only one entry right now…allows you to specify what kind of behavior your set-points will be when changed with the UI. (Either permanent hold, or temporary hold)[/li]
[li]Revamped refresh / authentication. (Thermostat refreshes still occur every 5 minutes after start-up.) I will only re-attempt to log-in with your credentials if a refresh fails.[/li]
[li]Support for ModeState “estimate”. Depending on the relationship between your current temperature and your set-point, the ModeState is set to Heating / Cooling / idle.[/li][/ol]

Bang on this one for a few days and let me know how it goes. :slight_smile: It’s not required to uninstall / remove your current device…you should be able to just upload the new files directly and reload.

rayp…thanks for allowing me access to your UI5 vera. The plug-in is all the much more better for it! (This version is currently installed on your unit.)

Seems to be working well.
Thanks JoeyD for all the effort. it was the one device that i really wanted to get integrated.

There’s only few things left to do before I request publication from the app store (aside from addressing any bugs found by those following this thread):

  1. I want to let this sit for a few days and make sure it gracefully handles re-authentication when honeywell no longer accepts log-in cookie on refreshes.

  2. Based on advice from mikee (thanks!), I will likely tweak how how I am processing / updating cookies to make it more robust.

  3. I want to create/ expose a few more actions. Baiscally support all the actions that you could normally do from the physical wall unit or thermostat view of mytotalconnectcomfort.com. The only ones left appear to be removing the holds from set-points, and creating a set-point that expires at a specific time. (These won’t be available from the device UI, but you’ll be able to create luup.call_action statements or use the advance scene editor to call them.)

  4. Edit…almost forgot…Ensure support for degrees C works as well.

  5. Make outdoor temperature, indoor humidity and outdoor humidity available for access. (This is assuming your thermostat supports this, of course.)

How about indoor and outdoor temp and humidity? Can you send that info to the Vera node for PLEG processing?

As I don’t suspect the build in Vera control supports displaying that info.

Yes, I can expose indoor / outdoor humidity and outdoor temp. I assume indoor temp is already accessible (that’s what the device displays.) I’ll include that on the to-do list for the version 1.0 release.

Although the more I think out it, there may be complications to support what you want. I haven’t used PLEG, but I assume it looks at the device service files. I don’t think the themostat devices natively support those extra variables, so if I just create new variables to store with the thermostat devices, it likely won’t be “plug and play” with PLEG.

Having said that, I believe there is a “variable container” plug-in that could work for integrating the variables directly into scenes without having to write lua script.

I haven’t used either of these plugins, so I’d have to play with them to see how things work exactly. The alternative for getting direct PLEG support would be to create a separate temperature sensordevice (for the outdoor temp) and 2 humidity devices for each thermostat. That should ensure “plug and play” type compatibility with advanced scene editors and things like PLEG. I don’t think I want to do that though since now you’ve got all kinds of devices cluttering things up. (Or maybe there is a way to create an “invisible/hidden” device?)

For version 1.0 I will plan on just creating new variables for the thermostat devices to hold outdoor temp, indoor and outdoor humidity. You’ll be able to access these with luup scripts (and I assume the “variable container” plugin), but probably not with PLEG or advance scene editor.

Not sure about all the internal details (don’t know anything about Luup) but I believe (check out the screenshot) if you add the variables and update them, PLEG can use that for triggers… ?

That’s great then…just FYI I will be adding the variables for outside temp, and inside / outside humidity to the individual thermostats rather than the parent device.

Sounds Fantastic!! Thank You!!

What’s that… Beep, beep, beeeeeeeeeeeeeeeeeeeeeeeep. Oh, that’s the sound of me pulling the plug on Smart Things support of the Honeywell device. Apologies for the mis-information, glad I prefaced it with “confirm in test” as there just seems to be no real documentation (even though a select few have been blessed with an API document from Honeywell).

I’ll start playing around with some LUUP and report if I have any issues…

[quote=“JoeyD, post:61, topic:185223”][quote=“CudaNet, post:58, topic:185223”]Someone might want to confirm in test as I took this from the Java.Groovy. If you didn’t need this then my bad ! I’m bouncing around on different projects here at work.

“StatusCool” == 1 and “SystemSwitchPosition” == 3 then the operating state is currently cooling
“StatusHeat” == 1 and “SystemSwitchPosition” == 1 then the operating state is currently heating.[/quote]

Based on my testing that is not correct. (Seep previous post). StatusCool and StatusHeat (despite the names), indicate what the current setpoint type is (temporary, permanent, or following schedule). Does not indicate anything with respect to the system being on or off.[/quote]

No worries! :slight_smile:

I do wish that Honeywell reported the actual heating / cooling on/off status (and fan on/off status for that matter). Seems to me one of the basic items you’d want to know, particularly for remote operation. They report this status on my physical wall mounted unit…but hell I can HEAR the furnace / fan running when I’m physically there :). It’s when I’m remotely operating / checking status that the information would be more useful.

Oh well, maybe there is a separate API call that can be made to get that info…which brings us back to the API that Honeywell seems reluctant to actually publish…

We are now what I would consider to be a beta. No new additional “features” are planned. Just perhaps some code optimization and bug fixes. So please respond if you find any issues!

Attached is a zip with the latest installation files. The following additions have been made:

  1. Support for both temperature units (degrees F and degrees C). Technically, this support is only needed if your thermostat is set in one type of unit, and your vera is set to display a different unit. Bottom line is…it now does not matter what units any of your thermostats are, or what units your Vera is set to display…things should “just work.”

  2. Added support for two new actions for the parent device (Details will be below)

[ul][li] HoldSetpoint: Enables you to set a permanent or temporary set-point. If temporary, allows you to set the expiration time as an option.[/li]
[li] CancelSetpointHold: Removes the permanent or temporary set-point hold, and reverts the thermostat to “follow schedule”[/li][/ul]

  1. Added support for including new variables to the child thermostat devices. The service for all of these is “urn:honeywell-com:serviceId:ThermostatData1”

[ul][li]ThermostatUnits - “F” or “C”[/li]
[li]OutdoorHumidityAvailable - true / false[/li]
[li]IndoorHumiditySensorAvailable - true / false[/li]
[li]IndoorHumiditySensorNotFault - true / false[/li]
[li]HeatSetpointHoldType -“Temporary”, “Permanent”, or “Following Schedule”[/li]
[li]CoolSetpointHoldType -“Temporary”, “Permanent”, or “Following Schedule”[/li]
[li]HeatSetpointUntilTime - (h:mm AM/PM format) - indicates the time the next heat set-point change is scheduled to occur[/li]
[li]CoolSetpointUntilTime - (h:mm AM/PM format) - indicates the time the next cool set-point change is scheduled to occur[/li]
[li]OutdoorTemperature - provided in the DISPLAY units of vera[/li]
[li]OutdoorHumidity- as a percent (ex: 45)[/li]
[li]IndoorHumidity - as a percent (ex: 45)[/li][/ul]

Again, those variables are accessed via the individual child thermostat devices.

A note about Heat/CoolSetpopintUntilTime: even if your thermostat is in a permanent hold, you will see a time indicated here. This is the time that the thermostat would change the set-point if it were not in a permanent hold.

Here’s the details on the new actions. These actions are tied to the PARENT device:


Action Name: CancelSetpointHold
Parameters:{ThermostatID=XXXXXX}

Sample luup call to remove the setpoint holds, for a thermostat with id 123456 and your plugin parent device ID of 10. After the execution of this command, yout thermostat number 123456 will revert to “following schedule” for the set-points:

local lul_arguments = {} lul_arguments["ThermostatID"] = 123456 luup.call_action("urn:joeyd-com:serviceId:HoneywellTCC1","CancelSetpointHold",lul_arguments,10)


The following action allows you to set types of Honeywell thermostat set-points that you cannot do with the standard thermostat device actions and device UI.

Action Name: HoldSetpoint
Parameters: {
ThermostatID=XXXXXX,
newSetpointValue=[Temperature in the DISPLAY UNITS of vera],
SetpointMode = [“COOL” or “HEAT”]
SetpointType = [“TEMPORARY” or “PERMANENT”]
SetpointEndtime = [Time in 24 hr format, eg: “15:25”]
}

You must supply the ThermostatID and the NewSetpointValue. All other arguments are optional. If you omit the SetpointMode, the action will determine which mode your thermostat is currently in (heating or cooling) and apply the setpoint accordingly. If you omit SetpointType, the action will look to your default setting for the type, and apply that.

The SetpointEndtime parameter only applies as an option for the TEMPORARY SetpointType. This is equivalent to going to your unit and selecting “hold until 5:30 PM.” After that time is reached, your thermostat reverts to “following schedule.” Note that the Honeywell thermostats support 15 minute increments only. You can supply any time in the parameter, but the action will in effect round that to the nearest 15 minutes. Example, if you enter in “15:50”, your temporary set-point will be held until 4:00 PM.

Sample luup to set the heat-point to hold at 70 degrees until 11:00 PM:

local lul_arguments = {}
lul_arguments["ThermostatID"] = 123456
lul_arguments["newSetpointValue"] = 70
lul_arguments["SetpointMode"] = "HEAT"
lul_arguments["SetpointType"] = "TEMPORARY"
lul_arguments["SetpointEndtime"] = "23:00"

luup.call_action("urn:joeyd-com:serviceId:HoneywellTCC1","HoldSetpoint",lul_arguments,10)

Again, the plug-in is pretty much feature complete at this time. ServiceXp, please see if the exposed variables allows you to do via PLEG what you want to do. At this point, I’ll be cleaning up some code and tweaking the cookie authorization scheme, and that should do it for the version 1.0 release that I will submit to the app store.

Fantastic Job!

Sooo glad you implemented ‘PERMANENT’ as I had some odd behavior just before I dozed off last night. I loaded and let the code run all day (7am to 7pm) then decided to reduce the temps to 62 (was previously 66 and not on hold) and put it on on hold for the night. Around 11, I heard the ductless system ramping up to heat - the vanes dropped down and sure enough, it started to heat the room. I grabbed my iPad and used the TCC app to put the unit back ‘on-hold’ as it was set to 66 degrees. I did that, and the unit went into circulate mode (no heat).

5 minutes later, sure enough - the thing attempted to heat the room to 66. I then just turned the unit off (and verified that the plug-in indicated ‘off’) and decided that today I’d just write a quick script to data mine all the behavior through the day as I didn’t really have any data to present IF it were a bug-a-boo…

I’ll load the beta and put my unit on hold and monitor it for the next 24 hours.