Evohome binding 2.0

ok nice to know, haven’t checked it yet, still have some problems getting my rfxcom working :frowning:

Hi guys,

I just put up a 2.3.0 version of the merged binding here: https://github.com/Nebula83/openhab2-addons/releases/tag/2.3.0-1 Note that there a some changes in the interface (there is now only one setpoint channel). Refer to the readme or official binding docs for more info. And you can always drop a question here of course :slight_smile:

Please help me iron out any wrinkles (if any) before it is released with OH2.4

Thanks!

does this include functionality for North America locations? :wink:

Thanks for this - looking forward to testing and implementing.

Does this new 2.3.0 (2.4.0) version include Hot Water controls?

Can I just clarify how the new set point will work.

So I can send a command to a setpoint with a new temperature value and the zone will keep that set point until either the next scheduled change OR I send a 0 value to the setpoint.

Assuming a simple Boost heating switch to up the heating in a zone:

Switch   Boost         "Heating Boost"         (gHeating)  ["Switchable"]

With the 3 items in a zone:

Number   SetPoint      "Set Point [%.1f °C]"       { channel="evohome:heatingzone:abcdee:123456:SetPoint" }
String   Status        "Setpoint Status"           { channel="evohome:heatingzone:abcdee:123456:SetPointStatus" }
Number   Temperature   "Reported Temp [%.1f °C]"   { channel="evohome:heatingzone:abcdee:123456:Temperature" }

Then a simple rule could be:

when
	Item Boost changed
then
   if(Boost.state == OFF) {
      logInfo("Heating", "Boost ending")
      //Set setpoint to 0
      SetPoint.sendCommand(0)
   }
   else if (Boost.state == ON) {
      logInfo("Heating", "Boosting heating")
      //Set setpoint to desired temp
      SetPoint.sendCommand(21.0)
   }
end

N

I’m getting errors as follows after attempt to add account thing via discovery in Paper UI:

2018-12-13 00:20:48.929 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/Auth/OAuth/Token]

2018-12-13 00:20:49.904 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 200 OK - 1454 bytes]

2018-12-13 00:20:49.907 [DEBUG] [nding.evohome.internal.api.ApiAccess] - 

Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json;charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.5
Set-Cookie: thlang=en-US; expires=Wed, 12-Dec-2068 23:20:49 GMT; path=/
Server: Web1
Date: Wed, 12 Dec 2018 23:20:49 GMT
Content-Length: 1454
Set-Cookie: NSC_UDDOB-TTM-WT=<....>;expires=Wed, 12-Dec-2018 23:22:49 GMT;path=/;secure;httponly
{"access_token":"<...>","token_type":"bearer","expires_in":3599,"refresh_token":"<....>","scope":"EMEA-V1-Basic EMEA-V1-Anonymous"}

2018-12-13 00:20:49.920 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/userAccount]

2018-12-13 00:20:50.132 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 400 Bad Request - 167 bytes]

2018-12-13 00:20:50.134 [DEBUG] [nding.evohome.internal.api.ApiAccess] - 

Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.5
Server: Web1
Date: Wed, 12 Dec 2018 23:20:49 GMT
Content-Length: 167
Set-Cookie: NSC_UDDOB-XfcBqj-TTM-WT=<....>;expires=Wed, 12-Dec-2018 23:22:50 GMT;path=/;secure;httponly
[
  {
    "code": "UnsupportedClientVersion",
    "message": "Values provided by API aren't supported by client or field filled by client is not supported."
  }
]

==> /var/log/openhab2/events.log <==

2018-12-13 00:20:50.145 [hingStatusInfoChangedEvent] - 'evohome:account:26bf4f72' changed from INITIALIZING to ONLINE

and discovery of display & zones does not return any results. Any idea what i’m doing wrong?

You can track the implementation of new features on my github. If you use the link from the topic start post it’ll order them according to the number of votes it got. Currently this release only contains the scope of the first PR. No new functionality

You can track the implementation of new features on my github. If you use the link from the topic start post it’ll order them according to the number of votes it got. Currently this release only contains the scope of the first PR. No new functionality

Currently only permanent setpoint changes are implemented. The only way to cancel it is to send a zero. You can check the online documentation for more details.

Are you not in North America and is your password correct?

I’m in Poland and i think password is correct. Funny thing is that when i today restarted the binding, then without any change in the configuration, API started to respond correctly and zones and display has been discovered. Things was also switched into online state:

2018-12-13 18:43:43.603 [hingStatusInfoChangedEvent] - 'evohome:heatingzone:26bf4f72:4475230' changed from INITIALIZING to ONLINE
2018-12-13 18:43:43.615 [hingStatusInfoChangedEvent] - 'evohome:display:26bf4f72:4475231' changed from INITIALIZING to ONLINE
...
2018-12-13 18:43:58.914 [hingStatusInfoChangedEvent] - 'evohome:heatingzone:26bf4f72:4475430' changed from INITIALIZING to ONLINE

However, shortly after it again switched back to:

  {
    "code": "UnsupportedClientVersion",
    "message": "Values provided by API aren't supported by client or field filled by client is not supported."
  }

Also discovered things were throwing errors:

2018-12-13 18:44:53.016 [hingStatusInfoChangedEvent] - 'evohome:heatingzone:26bf4f72:4475428' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Status not found, check the zone id
2018-12-13 18:44:53.019 [hingStatusInfoChangedEvent] - 'evohome:heatingzone:26bf4f72:4475230' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Status not found, check the zone id
2018-12-13 18:44:53.026 [hingStatusInfoChangedEvent] - 'evohome:display:26bf4f72:4475231' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Status not found, check the display id
2018-12-13 18:44:53.031 [hingStatusInfoChangedEvent] - 'evohome:heatingzone:26bf4f72:4475430' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Status not found, check the zone id

:frowning:

Is there any specification to the API used by this binding? I found https://developer.honeywell.com/api-methods
But requests looks different than what is used by the binding.

I can successful login to https://international.mytotalconnectcomfort.com, which seems to be using requests as https://international.mytotalconnectcomfort.com/Api/LocationsApi/GetLocationSystem?id=3326582 to fetch update of device status. So looks like different API as well.

No there is none. It was reverse engineered by someone else whom I based my work off. You could check if https://github.com/watchforstock/evohome-client works better (it’s python). If it does, then I have some work to do since that is my reference. On what platform are you using openhab?

I use “Raspberry Pi 3 Model B Rev 1.2” & openHABian.

It seems to be working at least regarding login and fetching temperatures from zones:

Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57:15) [MSC v.1915 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from evohomeclient import EvohomeClient
>>> client = EvohomeClient(<my_user_name>, <my_pass>)
>>> for device in client.temperatures():
...     print(device)
...
{'thermostat': 'EMEA_ZONE', 'id': 4475428, 'name': 'Lazienka', 'temp': 23.6, 'setpoint': 20.0}
{'thermostat': 'EMEA_ZONE', 'id': 4475230, 'name': 'Salon', 'temp': 21.36, 'setpoint': 20.5}
{'thermostat': 'EMEA_ZONE', 'id': 4475430, 'name': 'Sypialnia', 'temp': 18.91, 'setpoint': 18.5}

OK, I have a raspi lying around somewhere. Let me see if I can reproduce the issue. Maybe it sends some headers the api doesn’t like.

Just to gather some info: who is using the latest release and with what OH version? I’m curious as to how it performs.

I’m using 2.4.0.M8 for both binding and OH. Result as described above.

Im on M7, still have the restart binding exec line, so dunnow if its stable without it.

For issue with ‘UnsupportedClientVersion’ error returned by API, looks like basic authentication string used by binding is rejected by Honeywell API. If i use this from https://developer.honeywell.com/api-methods, then API responds correctly for me:

diff --git a/addons/binding/org.openhab.binding.evohome/src/main/java/org/openhab/binding/evohome/internal/api/EvohomeApiClient.java b/addons/binding/org.openhab.binding.evohome/src/main/java/org/openhab/binding/evohome/internal/api/EvohomeApiClient.java
index 6837eddbb..6f5978fd8 100644
--- a/addons/binding/org.openhab.binding.evohome/src/main/java/org/openhab/binding/evohome/internal/api/EvohomeApiClient.java
+++ b/addons/binding/org.openhab.binding.evohome/src/main/java/org/openhab/binding/evohome/internal/api/EvohomeApiClient.java
@@ -191,7 +191,8 @@ public class EvohomeApiClient {
                 + "Connection=Keep-Alive";

         Map<String, String> headers = new HashMap<>();
-        String basicAuth = Base64.getEncoder().encodeToString((APPLICATION_ID + ":test").getBytes());
+        String basicAuth = "NGEyMzEwODktZDJiNi00MWJkLWE1ZWItMTZhMGE0MjJiOTk5OjFhMTVjZGI4LTQyZGUtNDA3Yi1hZGQwLTA1OWY5MmM1MzBjYg==";
         headers.put("Authorization", "Basic " + basicAuth);
         headers.put("Accept", "application/json, application/xml, text/json, text/x-json, text/javascript, text/xml");