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 =)
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
I was so free as to create an issue for the binding here: https://github.com/openhab/openhab2-addons/issues/2268. 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.
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 (https://www.eneco.nl/toon-thermostaat/ 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 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.
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
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.
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.