New EvoHome Binding

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:

I just merged your stuff into my code and starting to work on implementing the interface.

One remark:

private void update() {
    DataModelResponse[] data = getData();
    // TODO trigger update requests on the client here and delegate them to the Things
}

public DataModelResponse[] getData() {
    return apiClient.getData();
}

I take it that this is test code? getData is a bit generic :wink:

Also bear in mind that for v2 you need a different application id. I changed the binding default settings to use v2 (OAUTH).

I just pushed the moving of the namespaces, please sync with that to prevent conflicts later on.

Also we’d have to use some reponse-data neutral data model as return values of the interface. I reserver the models namespace for that.

By the way, I aligned all the EvoHome spellings to Evohome. Maybe the easiest for you is to create a new fork off mine and port your changes there. Otherwise I’m afraid we are going to have a lot of conflicts.

My latest push also includes the processing of the “Locations”, this includes a list of Zones, which, I think, are of interest to you. They are in Locations->Location->Gateways->TemperatureControlSystems->Zones. The requesting of actuals I haven’t implemented yet. I think you can get them via URL_V2_HEAT_SETPOINT

Edit: Actuals are there too now

Hi all!

I just made a quick pre-release of the current status of the binding to see if I get the process and if the API work for you. It’s published here: https://github.com/Nebula83/openhab2-addons/releases/tag/echohome-pre-release-2.10

If you download the .jar and throw it in your addons folder you should be good to go. In the bindings you will find an Evohome entry and the ability to add a Thing where you can enter your credentials. Check to see if that one goes ONLINE. If it does, you should be able to scan for a new Thing that has a Mode channel which enables you to change the Quick Settings mode.

The mapping is as follows:

   "Auto"="Normal",
   "AutoWithEco"="Eco",
   "Away"="Away",
   "DayOff"="Day off/Working at home",
   "HeatingOff"="Off",
   "Custom"="Custom"

Please let me know if it works!

Get a HTTP 500 when trying to save user/pass details as a thing, from the openhab.log:

2017-05-22 21:21:28.271 [WARN ] [org.eclipse.jetty.server.HttpChannel] - Could not send response error 500: javax.servlet.ServletException: javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: org/openhab/binding/evohome/EvohomeBindingConstants

Haven’t seen that myself. I’ll set up a clean install of openhab in a bit.

Have you tried to remove and re-add the thing? (Evohome Account?)

Edit: I just made a clean openhab2 install (download zip file, unzip in a new location, start from there) and copied the jar file into addons and that worked. I’m running on Ubuntu Linux.

Could you do the same and tell me your results as well as your OS and java version and type?

I see nice news
but i’m out of home now for all the week, I can’t make any test until Sunday evening

No rush =) I’m running into an issue anyway that make it run for a couple of hours before running into “Too many open files”. Please do check if the authentication and Display control work for you.

My java/OS versions:

java version “1.8.0_121”

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

Linux openhabpi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

Currently failing to install a fresh copy due to issues with downloads from bintray.com…will try again later

Great thanks! And what does update-alternatives --display java yield for you?

i’ve just got it to add as a thing on my original install. Restarted openhab a couple of times and used firefox instead of chrome but that’s it. I’ll check a bit more later on as had to go back onto my work vpn for the afternoon.

It did come online, and discovered an “EvoTouch” thing and has pulled down the current setting of HeatingOff, so looks good so far.

I can also confirm changing the mode does correctly update the mode on the actual device

Just noticed this in the openhab.log every minute - is there still a limitation of only being about to poll the api 6 times an hour?

2017-05-23 14:55:49.807 [ERROR] [ome.internal.api.models.v2.ApiAccess] - Error in handling request
java.util.concurrent.ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:653)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.openhab.binding.evohome.internal.api.models.v2.ApiAccess.doRequest(ApiAccess.java:58)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.internal.api.models.v2.ApiAccess.doAuthenticatedRequest(ApiAccess.java:89)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.internal.api.EvohomeApiClientV2.requestLocationsStatus(EvohomeApiClientV2.java:83)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.internal.api.EvohomeApiClientV2.update(EvohomeApiClientV2.java:149)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler.update(EvohomeGatewayHandler.java:129)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler.access$0(EvohomeGatewayHandler.java:122)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler$1.run(EvohomeGatewayHandler.java:116)[215:org.openhab.binding.evohome:2.1.0.201705221349]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
at org.eclipse.jetty.client.AuthenticationProtocolHandler$AuthenticationListener.onComplete(AuthenticationProtocolHandler.java:113)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:453)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:400)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:266)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1403)[72:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1245)[72:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:156)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:117)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:123)[70:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[73:org.eclipse.jetty.io:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[84:org.eclipse.jetty.util:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[84:org.eclipse.jetty.util:9.2.19.v20160908]

Hey, great news! I’m happy that it works for you. I wouldn’t know about that poll rate? The evohome app seems to be pretty snappy to refresh so I guess it should be possible to update faster than that. If you would like to experiment, you can change the poll rate in the advanced setting of the Account Thing.

Thanks for testing so far!

Hi @smighall, I found the source of your problem. Nothing to do with too many requests. The auth token expires after an hour. I created an issue in github and will post updates on the issue there. Expect an update soon!

Hi @neil_renaud, I just merged your changes in. Awesome job, I see my zones popping up, no problem. The actuals aren’t there yet, indeed, but that should be easy to add.

I added you as collaborator to my github repo so that you can do code reviews on my work as well. I opened a review to re-integrate my fixes back into the master branch. I should then be in a state when it will be testable for others as well.

My next focus will be getting the access token to update using the refresh token just before the access token expires. I already got that to work in postman, I just need to implement it in java.

So I have been trying to get the current status of the binding into the openhab main repo, but with no luck. I have no experience with git and that is keeping me from getting anything to pass the prerequistes of a PR (no other authors commits, everything “squashed”). Coming from mercurial this is the world upside down for me.

I have created a second preview on github for those interested. Let me know if it works for you.

You can find it here

Also, if someone is willing to teach me how to get my commits in order, I’d be very grateful.