New EvoHome Binding

in my implementation I can’t see any variable displayed in the interface
neither any variable moves in the event log
the binding code gets login with Honeywell server, and I see all the data received with all details of my devices

also I tried to reinstall openhab on a scratch raspberry, so I feel I can exclude openhab installation

I have some doubts for the item configuration string, but I played several combination of quotes/names/capital letters… but no way to run

can you share your configuration for items and what you set in openhab.cfg (masking your account of course)?

Does anyone know what the status is of this binding? It’s been more than a year since the original version and afaik no updates have been made since.

I think it could be converted into an Openhab2 binding to make configuration a lot easier (since the JSON response contains all info needed to make Things)

The one thing I’m really missing is to be able to set quick actions; viewing temps is a nice feature, but I’m looking to integrate it to at the level where IFTTT is. The IFTTT interface is a nice idea, but it way to slow to be of value to me… Does anyone know how setting quick actions works or how to reverse engineer it from the app?

Lastly, I’m happy to pick up some of the coding and get thing moving =)


Well I’m on the cusp of moving to Openhab2 so I’m about to start moving this and my other bindings across to OH2. You are right the xml would make config really easy in OH2.

I never really used quick actions hence they weren’t implemented and even more setting temperature is tough without a proper scheduling ability in Openhab.

That being said I used this library “” to find out the API calls to make and it has the quick action details.

I will start to convert this but it will be by doing it an hour at time in my lunch break - as I have a young family and a wedding to plan this year…

Hi Neil, thanks for the swift reply! I just made the transfer to OH2 myself and I’ve got to say I’m pretty impressed with the whole Things concept.

I see where you are coming from time wise; I’ve got a little one of the age of yours as well, I see, and a second on the way :open_mouth:

I was so free as to create an issue for the binding here: What do you say we’ll make it a joint effort? I already spent some time diving into the OH2 bindings and have a plan to start the implementation. Let me know if you’re interested and I’ll share with you my train of thought.


The second little one is here now - and not so little…already 14 months! So up and walking!

I’ve created a fork and the skeleton binding (and that is all!) here:

I’ve been looking to learn about the “Thing” coding have you come across is this mythical yahooweather binding that is in all the examples? I can’t find it anywhere!

Yeah, our first is just about doing that as well :slight_smile: Magical times!

I created a fork as well, but haven’t committed anything yet. I’ll let you know when I have, probably somewhere today.

I stumbled upon this set of documentation: (maybe you already found it) and it’s serving me quite well! I already have implemented a Bridge Thing along with the username, password and applicationId settings. It’s showing up OH2 as a binding and as a thing: awesome!

The sources you are looking for are here:, since these bindings are oriented broader than Openhab. That choice is described here in the “Choosing a namespace” section. I chose to aim for OH right now because I’m new to all this (the smarthome namespace has more restrictions which I don’t know I’ll run into or not).

I’ve been basing my work on the org.openhab.binding.toon and org.eclipse.smarthome.binding.yahooweather bindings. The first because it very much resembles the Evohome system ( it’s a dutch product, sorry ;-))

I was just about to port your API classes where a question arose: you used the org.codehaus.jackson package for json manipulation I think. Is there a particular reason to use that library? Or can we convert to the GSON package as @Kai would like to see (openHAB JSON library (not JSONPATH))?

Edit: reading the previously mentioned post I see that for HTTP the “Jetty HTTP client library” is preferred so I propose changing to that as well

I just pushed my initial commit:

I’ve managed to find the yahooweather binding code.

No reason not to use the standard HTTP and JSON library - I can’t remember why I chose one over the other but what we need it for isn’t exactly rocket science so I think either will work.

I think you have to use the openhab namespace otherwise it causes all sorts of problems. Go with the lowest barrier to entry and at a later date it can always be changed and ported if it is needed.

I’ll take a look at your commit.

Exactly my reasoning; great.

I Just pushed an additional commit which implements the login and that works! Next step would probably be to implement the request for and create a discovery service for generating Things off the response data.

This is way easier than I thought :smiley:


I had a quick look through the first commit - you will need to rename your sample channel at some point. I spent my lunchtime getting my laptop setup to code for OH2. That being said I might wait before doing too much so we don’t end up both doing the same work.


Indeed, I need to. I left it there because it doesn’t allow me to leave the file like that without any channels defined. Channels, however, are not yet on my todo list in the near future :slight_smile:

I pushed all my work up and probably won’t have time the upcoming days to work on it so feel free to fiddle around with it.

Shall we use this topic to align our work? Or shall we do that in the github issue?

Not sure to be honest - but if I get some time (might on Thur evening) I’ll push in small increments to your repo.

Hi Neil,

Yesterday evening I looked at the python code you sent a link to earlier. It looks like that one is using OAUTH and is able to get more data via a different set of endpoints I cannot access with just the sessionID header. I think I want to implement that one instead, since that gives me access to the quick actions.

Could you check if that python code works for you as well? I don’t know if it is region based, for me in the Netherlands it works at least.

I think my main focus would be the gateway channels and setting quick actions. That leaves open the Things connected to the gateway i.e. the radiator controls. That and Thing discovery might be something you could pick up if that’s okay?

Jasper and Neil,
very nice to hear you are working on this binding
my problems with evohome legacy binding are still pending, but I haven’t enoth competence to develop any code by myself
so great you are working for the community, thank you a lot!
should you need any help for testing, I’m here

Hi Alberto,

Thanks! That is definitely welcome! I’ll let you know when something testable is available.


I’ve ported your code locally and login works. Going to see if I can get some data now im logged in. The work split certainly works as the valves are more interesting to me.

Great, let’s do it like that then.

I was able to get a working login with the new API. Unfortunately that means that the old API as was used in your OH1 binding can no longer be used. I’ll push my changes in a moment, please check if the login still works for you then.

Let’s get coding!

Yeah I had noticed you’d not used OAuth as long as you’ve created a method to make calls that deals with the OAuth it should be fairly easy to port. Although I might make EvoHomeApi into an interface so we have options.

Out of interest what do you see on the OAuth API that isn’t on the other one that you need?

I’ve just made EvoHomeApi an interface in my repo. Can you take that change as well? Then at least we have options. Plan would be to use OAuth but at least an interface gives us the option to have both if we need to.

The v1 api doesn’t seem to have a way to request the current applied quick action (that I could see). Also, the other API seems to provide more detailed info in general. More is better :wink:

I’ll check if I can merge with your changes, should be doable. Lets then use something like models.v1 and models.v2 and ApiClientV1 and ApiClientV2.

I just finished the implementation of OAUTH and the querying of the user account. The rest of the calls should be fairly tedious :stuck_out_tongue: