Honeywell T10 via HomeKit Controller missing climate.set_preset_mode?

I have 3x Honeywell T10 Pro’s installed in my house in a zoned system (not really my choice, the builder did this by default!). Based on reading here, I may eventually swap them for Venstar, but for now I’m just trying to get some basic home/away-mode automations going.

I initially integrated them via HomeKit Controller, as this was auto-discovered and is responsive/local, and supports reading the remote (Honeywell) temp/hum/occ sensors I’ve placed in some rooms. However, there’s no climate.set_preset_mode available for them through this integration. This is the main thing I’m puzzling about right now: is this normal? does it vary by model, or is this a generic HKC thermostat limitation?

I ended up also trying out the (cloud-based, ewww) Honeywell Lyric integration and I was able to get it configured successfully as well. It does expose climate.set_preset_mode as well as a few other nifty extras (like humidity setpoints). It doesn’t expose the remote sensors, but that’s ok, I can always keep those feeding in via HKC.

Now that I’m trying to really set up automations, I’ve found that both (a) I really need climate.set_preset_mode to be able to operate on them sanely (the idea being to configure the in-thermostat schedules on the assumption people are home, and then flip to PermanentHold and a wider pair of setpoints when everyone leaves the house, then do a NoHold to flip back to normal scheduling when people get home), but also (b) the Lyric integration is very laggy and/or buggy (probably mostly on Honeywell’s end!), so it’s kind of hard to reliably automate with it. It works reliably maybe a third of the time. Sometimes thermostat ends up in the wrong hvac_mode, or only 1/2 setpoints gets set correctly. I’ve also seen commands sent via Lyric arrive at the thermostat several minutes late and that gets really confusing while trying to debug the scripts.

What I’m doing for now that kinda “Works For Me”, is I’ve kept both integrations alive, and I’m having my automations use the Lyric integration just to set the PermanentHold or NoHold state, then doing a 5s wait, and then from the same script setting the temperatures reliably via the HomeKit integration. This seems to work better than anything else I’ve tried in my limited testing today, but I imagine I’m just begging for some odd race condition at the thermostat end by using these two disparate command paths together.

Anyone else mucked around with this same hardware and the same issues? Any advice other than “throw away the Honeywells?” (I’m about ready to, because their cloud services are terrible anyways, even when using their own apps).

Did you ever find a solution? I’m mucking around with a T9 and would like to be able to have a tad more local control.

I also need this! In my situation I specifically need two things (1. is basically a repeat of above request):

1.Ability to set the thermostat mode to “Permanent” in HA. This should be something that can be done via the automations/scenes and also manually. I am currently controlling the thermostats totally via HA using the calendar/automations/scenes functions. If someone changes the temperature and sets it to a temporary hold, my control gets “hijacked” by the (“unused”) built-in schedule in the thermostat. This is very frustrating. Please add this and the below controls to HA!

  1. Ability to set the “priority” mode. This is applicable when you have a one or more remote temperature sensors. Using the Resideo software or directly configuring the thermostat by hand, you can choose which sensors are used by the thermostat to determine if the requested temperature has been reached. You can select one or more of the sensors to be used in the determination. This is useful if you have a situation where you want to control temperature in a specific room for a specific period of time.

I guess the question is - are these even exposed by the device to HomeKit?

Is there anyone who is using “official” HomeKit gear that can control hold modes, fan modes, or sensor priority, or is that unfortunately strictly limited to Honeywell’s cloud garbage, or is there evidence of these existing in the underlying protocols but merely hidden by HA? I am guessing that these interfaces are simply missing from Honeywell’s HK implementation.

I’m starting to really regret the T9, and I’m thinking of returning the damn thing before my Amazon return period expires and getting a Nest or Ecobee - sadly neither of those offer local control, but at least their cloud integrations suck less AND they are eligible for my power company’s demand response program. Turns out that while the power company’s e-shop implies Honeywell thermostats can be enrolled, in reallty, they cannot be and you must buy either Nest or Ecobee.

Alright, this drove me absolutely nuts because I’m trying to zone my house with home assistant.

EDIT 11/22/2023: Coming back I’m now using this post to fix my own installation after working for several months. It looks like due to messing with my network my thermostat lost connectivity long enough that the refresh token went stale again. All I had to do was go here (Honeywell Home Developer Site | Create a Token from an Authorization Code) and use my existing information but I’m redoing the whole thing with a new app so that this makes more sense next time I break it and until I figure out how to bypass resideo.

I need to be able to change priority with automation and while this isn’t my perfect solution it does work.

We’re going to use the resideo api to make the commands that weren’t included with homekit. Unfortunately this solution does depend on the cloud. I’m hopeful to change this later but at least it works for now.

  1. Make a honeywell/resideo developer account (Honeywell Home Developer Site | APIs)
  2. Create a new app with any name and this URL as the “callback URL” which will later be referred to as the “redirect uri”

  1. Under the API menu in the resideo/honeywell website you’re going to select the “authentication” submenu which should have 4 commands (we need to do them all)

The directions on them aren’t clear and terminlogy changes so we’ll keep an inventory:

One of the things we’ll need is an “Authorization”. We get this by taking the “Consumer Key” and “Consumer Secret” which you can get by expanding your app on the “My Apps” tab in the resideo developer site. Once you’ve expanded the app by clicking on it’s name it should look like this:

The "Authorization is a base 64 combination of these two keys with a “:” (colon) in the middle. Go to this website and paste the api key (Consumer Key) and secret (Consumer Secret) for the app you created with a “:” between them The base64 version is what you’ll use for “Authorization”.

Using my example keys, that step looks like this:

Now take the base64 converted string and test it using the link below to make sure your authorization works:
Obtain OAuth2 Client CredentialsToken

Get an Authorization Code [information only, you dont need to go here]

Please don’t confuse this with “Authorization” … This is an “Authorization Code”. It’s an 8 character alphanumeric string you’ll pull out of your browser URL on the landing page when it asks for your home assistant URL. You do not need to go past that page.

Take the link below and replace the "xxxxx"s with your api key (Consumer key on the honeywell page for the app you created in step 1. You do not need to click on the link above, you only need to modify the one below and go to that link. It will ask you to login to your resideo account and you should link your account to the device before doing this step. This is different from your honeywell developer account.
Login, select your thermostat, authorize and when it asks to continue to home assistant: Look in the url after “code=” and copy those 8 characters.

Let’s take an inventory of what we’ve got now:

Go to this link: Create a refresh token
Fill out: Authorization / code (aka authoriation code) / and redirect URI using the information we’ve collect and hit send. The only line we care about is the “Refresh token”. This is the only step you need to repeat if your refresh token ever goes stale and you cant make requests anymore.

Requests to the API are made with an access token. While we get one from the previous step, we need to refresh it regularly so dont worry about it until you setup a sensor in home assistant to refresh it automatically using the refresh token.

Refresh a Token
We’ll do this as a sensor because this api key goes stale all the time and we need a new one to keep making requests. There is almost certainly a better way to do this im just going for the duct tape approach.

  - platform: command_line
    name: T10_Refresh_Token
    command: "/usr/bin/curl -s -X POST \
    -H 'Content-Type: application/x-www-form-urlencoded'
    -d 'grant_type=refresh_token&refresh_token=<REPLACE WITH YOUR REFRESH TOKEN>' | cut -d '\"' -f4"
    scan_interval: 1000
    set_thermostat_priority: "/usr/bin/curl -X PUT \
    '<INSERT LCC-########>/priority?apikey=<INSERT YOUR API KEY HERE>&locationId=<INSERT YOUR LOCATION HERE>'
    -H 'Authorization: Bearer {{api_key}}'
    -H 'Content-Type: application/json'
    -d '{{input}}'"

Please note the “LCC-#######” refers to the T10 and you’ll need to change this for your thermostat. You’ll need to do this anyway because you’ll want the location identifier as well. You can get this from the api website: https ://

refresh token goes stale if it stops getting updated for a while so even if you are getting api keys back they won’t work. You’ll have to go get another “code” through the web auth and then get another refresh token.

This is very much a work in progress and I’ve not even finished working the kinks out … there is a solution though.

sorry about the link formatting, I made this account just to toss what I had up and it wont let me have more than 2 links. EDIT: came back and fixed formatting now that my account can.

very cool approach. i can’t control the fan modes (auto, off, circulate) for my T10 via the homekit integration and might try this. i saw some people mention you can edit the device state via dev tools, adjust the supported_features, etc, but i couldn’t get that to work.

i’ll report back if i get something together.

The final text box outlining a shell command is the basis for how you would add your fan control. You’ll probably want to record the current state of the fan as well, you should make a helper list for this and then update it via an api get.

In a script or automation you’ll call this service and have an input that will be sent to the api such as:

input: >-
  "{ 'currentPriority': { 'priorityType': 'PickARoom', 'selectedRooms': [0,1,2] }}"

In your case this shell command in your config.yaml:

    set_fan_mode: "/usr/bin/curl -X PUT \
    '<INSERT LCC-########>/fan?apikey=<INSERT YOUR API KEY HERE>&locationId=<INSERT YOUR LOCATION HERE>'
    -H 'Authorization: Bearer {{api_key}}'
    -H 'Content-Type: application/json'
    -d '{{input}}'"

And then use the below service call in a script or automation:

- service: shell_command.set_fan_mode
     input: >-
       "{ 'mode': 'On'  }"

Just to be clear you’ll need the follow the above guide for getting connected to the api and this is still going over the internet and not local only. I’m working on how I can access these methods via the homekit api and if I figure it out ill post.

Make sure you modify the URL in the shell command to fit your needs … in mine after the LCC its /priority/ you would have /fan/ as outlined on the honeywell api website:

A full list of commands you could run are here: