A few years ago (maybe less) I created a Honeywell Home API binding to access the thermostat and sensor information for my home. It has been running for a year at least and working fine. To update it to 4.2.x I got back into working on it. I am hoping to put in a PR if I can get it cleaned up. But (big but) I am not a JAVA programmer and I find myself a little shell shocked over OpenHAB/JAVA/Honeywell etc. I started this thread to ask for a little information as I clean up my code and make it more thread safe, etc.
The communication with Honeywell is http get/put/post so I tried using the http binding but I got lost in how to take the respounses from initial “things” and feed them back through “items” into the configuration of the new “things” to get the eventual data from Honeywell. So I created the binding.
I designed the binding to create a bridge handler which does the Honeywell authentication and caches the respounses from the Honeywell API. There is a limited bandwidth Honeywell allows so a cache helps ensure Honeywell doesn’t start refusing requests. The sensor and thermostat thing handlers then register a url and data consumer with the bridge handler.
My first problem is that the bridge configuration can contain a onetime authorization code that can be used to generate a refresh token (never expires) which is needed to get an access token (which expires often) which is needed to access the Honeywell API. If an authorization code is to be used it NEEDS to be used only once and the refresh token needs to be written into the config. Is that allowed? When I started to write the .things documentation I started to wonder how does OpenHAB deal with a onetime configuration parameter in a file.
If I use the refreshToken which never expires there is no problem the bridge will always be created with and empty authorizationCode and a usable refreshToken.
My bridge will take this and get the refreshToken and will update the bridge configuration to authorizationCode="", refreshToken="newlygeneratedtoken". The next time the bridge is created, say after a system restart won’t the newly generated token be lost? What is the best practice to deal with this?
I didn’t have the answers to your questions. but are you familiar with Honeywell home thermostat Binding? It’s that the same API or a different one?
And this is very unlikely to be the first binding that needs to save a token like that so surely there’s an add-on that can be referenced for an example.
Oauth2 is pretty standard so I’m certain dealing with the refresh token has been done before. Unfortunately I’ve not coded a binding line this so can’t help any more than this
It’s the same API. I am familiar with it. I had already written mine when I saw that one and it focuses more on the thermostat and doesn’t do anything about sensors and it makes the user do the authorization manually. I will look at it again.
I am reading about Spotify and it’s oauth in OpenHAB I might be able to do it the way they do. I didn’t know about Oauth2 client service in OpenHAB maybe I can learn about that and it will get rid of my needing to store the tokens in the config.
I wasn’t able to solve the problem but I got rid of it, by getting rid of the need. My binding now allows for the full OAuth2 authentication flow. It is SO easy for the user to authenticate there is just no need to futz with refresh tokens and authorization codes. I used the functionality from the Spotify binding and OAuth2 Factory. Now I need to clean up that code before I can post it .
One thing to be careful of though is to ensure that the refresh token does not expire. In my experimentation in the past (Honeywell Home API with openHAB using just rules) and my experience with the binding posted to the marketplace is that over a relatively short period of time (days) my refresh token stops working and I have to go through the whole authorization process again. That’s the main reason I use Amazon Control to access my thermostat, but that’s pretty much limited to just the setpoint and HVAC mode and nothing more.
I’ll happily be a beta tester for this when it’s ready.
Thanks for the tip. I was past that. I had my binding running for over a year, no problems at all constantly reconnecting. Now that I migrated to the OAuth2 I’m working through a few features. The authentication hiccups but it then gets back on track no problem, no need to re-auth but I had to pause/start the binding, I have it take the bridge OFFLINE when it had a problem (which it gets over at the next refresh) and the bridge goes back ONLINE but the Thermostat and Sensor things stay offline with the bridge error. They never seem to recover through the bridge status change routine.
I’ll let you know when I’ve up loaded my changes.
I’m trying to streamline the exceptions so the important ones bubble up and the not so important don’t shutdown the binding.
Here is the one I am working on. I use it for reading data not controlling the thermostat. I had the control working to do simple controls but I just reworked that code and haven’t test it yet. I’d be curious on your thoughts of the authentication. Especially since it has never run on your machine.
.