Honeywell Lyric thermostat

Tags: #<Tag:0x00007f18675ca950>

Hi!

The Lyric is a smart thermostat, that use a smartphone app, to automate the home/away status and adjust temperature. The problem was that there is no public API… But guess what! The public beta API was recently release! HoneywellDev

It’s look nice, but with some limitations.

First, it use the online lyric cloud service to access your local thermostat.

Also, honeywell said “Our limit is designed to allow you to poll device status every 5 minutes for up to 20 devices per hour, with a little cushion to make changes.”

After I had installed a Lyric at home for testing, and connect it to my local network, I’ve try to find it using “nmap” and was stunned to not finding it. :open_mouth:

I’ve also try to access my thermostat using the API and “curl” in linux command line, without success. :confused:

Is anybody found out a way to interact with it?

Is there a binding planed for this thermostat?

Cheer!
Tom

1 Like

If I had the hardware, I’d write the binding. :smile:

Not sure if it uses the same API, but there was a lot of work done on decoding the Honeywell EvoHome API. Personally I use Python scripts triggered via the exec binding to run them and control our heating.

Might be worth going through some of the automatedhome.co.uk forums and see the discussions over there. I think Andrew Stock did most of the initial work.

Try Here

I also know work was done on the Domoticz forums to integrate Honeywell stuff - try here

I’ve created an EvoHome binding - not sure if it will work with the Lyric but you are welcome to try:

Nice work, Neil! It looks like the EvoHome uses a different API from the Lyric, based on the URLs that your binding calls https://tccna.honeywell.com/WebAPI/api. The Lyric uses an API at https://api.honeywell.com/.... I hope to be writing a binding for that API soon.

Thanks - I’ve given up on my Nest + Lightwave TRVs in trying to get zonal heating and took the Evo Home plunge.

Hello all,

I own now also a Lyric T6 and I like to have a binding for openhab. I am running now openhab 1.8 and probably will soon go to 2.0. Does anybody already have a binding working or is working on it. I like to help in any way. I saw also the other honeywell development but they are target on the evohome and not the Lyric.

Greetings Paul

The Honeywell Lyric API uses a form of OAuth2 authorization that depends on a “redirect URL” which is problematic for integration to openHAB (assumes public-facing web page on the openHAB side). I’ve communicated with the API people there and they promised a usable PIN-based auth flow in V2 of the API, but I don’t think that’s materialized. If they update their API with a usable auth flow, then a binding for Honeywell Lyric is possible and even fairly straightforward. If you could ping them to add this improvement, it might help make it possible!

Thanks for the info. I will send them also a message. Is there a address on the development portal to ask for improvement?

There is a nice fellow named Joe who replied to me from the email address HoneywellAPISupport [AT] honeywell.com.

Hello John,

I have mailed Honeywell but no answer from them yet.
I was looking at the netatmo binding. I was thinking to rebuild this so it can be used for the Lyric. Whath are your thoughts about this? Is this the reight way to go?
http://docs.openhab.org/addons/bindings/netatmo/readme.html

Sorry I just now noticed your reply from two weeks ago.

Until the people who maintain and evolve the Lyric API add an authorization flow other than the last I knew about, redirect_url, then I don’t see how openHAB can authorize against it. So regardless of which binding you would consider using as a model for a Honeywell Lyric binding, I think you would hit this problem as a blocking issue. I would love to hear about how one could solve this in a way that makes sense for openHAB users.

No problem. In the netatmo binding they have for this a manual workaround to handle the redirect URL. Could this not be implemented in the paper UI when adding a binding?

I haven’t looked at the Netatmo workaround; perhaps it could be made to work for the Lyric? My understanding of how the Lyric uses the redirect URL is that it has to be a public URL that their servers can reach. But perhaps you’ve dug deeper than I have! :slight_smile:

It will be the same procedure as the netatmo. create a app and use these settings in the binding. I don’t know if it is easy to rewrite the netatmo binding.
Is it just rewrite it to honeywell and done?

Creat a app at honeywell
https://developer.honeywell.com/user/me/apps
STEP 1: REGISTER FOR AN ACCOUNT AND A KEY

If you already have an account and a key, great! If not, go here, then create yourself an app on the My Apps page to get an API Key.

STEP 2: USE THE API!

To start using the API you have two options:

Using the interactive documentation which gets you past the step of setting up an OAuth redirect URL for tokens
Registering an OAuth Redirect URL to your application and using your own code
Requirements:

A Honeywell Lyric account with a connected/installed device
An API Key from Step 1
EXAMPLE API CALL FLOW:

First: Get an OAuth Bearer Token. We use the Authorization Code flow (commonly called 3-legged OAuth). This will be used with your API key for all other API calls. You can also use our interactive documentation, which will get and handle the token for you.

Second: Get a user’s locations and devices. Here you’ll want to store the locationIDs and deviceIDs for later use in changing settings.

Request:

curl -H “Authorization: Bearer accessTokenHere” api.honeywell.com/v1/locations
Response Snippet:

[
{
“locationID”: 29769,
“name”: “home”,
“streetAddress”: “1985 Douglas drive”,
“city”: “Golden valley”,
“state”: “MN”,
“country”: “Usa”,
“zipcode”: “55422”,
“devices”: [
{
“deviceID”: “TCC-1105359”,
“name”: “Desk Test”,
“userDefinedDeviceName”: “Desk Test”…

Third: You can use the locationId to get all the devices for a particular location

Request:

curl -H “Authorization: Bearer accessTokenHere” api.honeywell.com/v1/devices?apikey=apiKeyHere&locationId=29769
Response Snippet:

[
{
“deviceID”: “TCC-1105359”,
“name”: “Desk Test”,
“userDefinedDeviceName”: “Desk Test”,
“thermostat”: {
“units”: “Fahrenheit”,
“indoorTemperature”: 73.0000,
“outdoorTemperature”: 57.0000,
“allowedModes”: [
“Cool”,
“Heat”,
“Off”
],
“deadband”: 0.0000,
“hasDualSetpointStatus”: false,
“minHeatSetpoint”: 40.0000,
“maxHeatSetpoint”: 90.0000,
“minCoolSetpoint”: 50.0000,
“maxCoolSetpoint”: 99.0000,
“changeableValues”: {
“mode”: “Heat”,
“autoChangeoverActive”: true,
“heatSetpoint”: 73.0000,
“coolSetpoint”: 78.0000
}…
]
Fourth: The part we are should focus on is the “changeableValues” array. I’m too cold, so I’d appreciate if you change the setpoint up a couple degrees.

curl -X POST -H “Authorization: Bearer accessTokenHere” -H “Content-Type: application/json” -d ‘{ “mode”: “Heat”, “autoChangeoverActive”: true, “heatSetpoint”: 74,“coolSetpoint”: 78 }’ https://api.honeywell.com/v1/devices/thermostats/TCC-1105359?apikey=apiKeyHere&locationId=29769
You should recieve a 200 response, and the setpoint on your device should change pretty quickly after that.

Hi guys, just to let you know, I have spent the last 3 days trying to get this API to work. I got the keys set up, I got through to the auth and got the user code but the next step just wouldn’t work, always failing with an invalid user credential.

I figured I must be doing something wrong even though I was closely following the spec so emailed Honeywell support with a fairly detailed report of what I had tried. No response.

I decided a closer look at what was going on under the covers was in order. I figured that I would intercept the lyric app communications and compare them against my own in case I was missing a base 64 encode somewhere or something. Well folks, the lyric app uses a totally (mostly) different API with a totally different endpoint, calling https://lyric.alarmnet.com/CHAPI/api/v2/session/ with username and password to login and https://lyric.alarmnet.com/CHAPI/api/v3/locations (similar to the documented locations from the published API, I believe) to get the actual info.

Yay, it was me. I was generating the base64 encode by echoing into the base64 command on a linux system. Echo includes the \n, of course so it was a bad base64 value.

Good that you find the problem. Did you get any further with developing a plug-in for openhab?

Not currently. I moved on to another project but hope to get back to it
soon.

Richy anyluck with the binding anything I could do to help? I have one too that I can help test let me know