Evohome binding 2.0

To all, I’m anticipating on the PR to be merged soon. Please leave your vote on my github issue list my means of a :+1: on the issue. I’ll be looking at the highest votes first. You can check the order by sorting on that icon to see where your issue is in terms of priority. So vote, and get your friends and family to weigh in you want your item to be investigated first :blush:

Great news! As of last night, the PR got merged! This means that as of OH2.4 evohome is officially supported! I’ll post an updated 2.3 on github soon so that we can all test it well. I have a system again as well so that eases my continued development considerably.

Thanks in advance for testing!

1 Like

You can buy relatively inexpensive arduino based equivalents (about £25 on eBay for pre-built if I recall correctly, or make your own for about £5 to £7!), which for the most part, work well as an alternative to the HGI80. I have been using such a system for the last 6 months or so - GitHub - smar000/evoGateway: Python script for listening in and responding to evohome heating control radio messages, and get live data for temperatures, heat demands, window open status etc etc.

thats great news on both!! :smiley:

Do you have some links to products and build instructions? Might be great to integrate that stuff in the binding at some point.

Unfortunately I don’t have any specific links other than my previous github repo and the corresponding credits section in the Readme there. However, the build was pretty straightforward if I recall correctly. Here’s a photo of my setup (I use a small electrical junction box to hold it all in). Not the neatest of jobs as I had intended to put it all onto a breadboard at some stage, but it has been working fine for about 6 months as is and so no impetus to change it! FYI, I have put together 3 of these now including for family members, all in the same way, and all working well.

Parts:

  • 1 x Arduino nano (clone should be fine), preferably with FTDI usb chipset, though the cheaper CH341 chipset also worked. The only issue I had with the CH341 was that the USB port was not always cleanly released when my python script exited. My FTDI based build is much more reliable in this respect.

  • 1 x CC1101 radio, 868MHz, e.g. something like CC1101 868MHz Wireless Transciever Pinout | QuadMeUp. I think I paid about £2 for this. Also note that the image on that link does not show the antenna - this is just a small coil on mine (I’ve seen others with high gain antennaes but haven’t tried them as I wasn’t sure whether power directly from the arduino pins would be enough, and didn’t want to spend too much time on experimenting)

  • 8 x Dupont fly leads or equivalent, making sure that you get the correct male/female combination for your arduino and CC1101 card

Wiring Up:
Connect each pin of the CC1101 radio to the corresponding pin on the arduino, e.g. from my photo, it looks as if I’m using the following connections:

WIRE COLOUR			CC1101 Pin 	Nano Pin

Red 				Vcc		3.3V pin
Black 				GND 		GND
Orange 				MOSI		15
Yellow 				SCLK		17
Blue				MISO		16
Dark Red 			GDO2		32
Grey				GDO0 		1
White 				CSN 		14

ANT 				Antenna coil

(Using the Nano pinout numbering from the following link https://components101.com/sites/default/files/component_pin/Arduino-Nano-Pinout.png [pin numbers are the ones in the grey boxes])

Arduino firmware
The firmware that does the heavy lifting on my setup is by ghoti57 and can be downloaded from GitHub - ghoti57/evofw2: Firmware for interfacing an RPi with SCC board to Domoticz in order to receive Evohome data. On Ubuntu, you can use avrdude to flash the arduino.

And that’s it for the hardware side.

Software

For testing, you can use the python script on my github, which will show you what the arduino is receiving, and post to mqtt server if required.

Would be great if you could do that! This is the only reason I’m not using the binding at the moment but have resorted to mqtt.

1 Like

Wow, awesome, thanks! And not that hard to build at all. Would be easy to make a PCB for that as well. I think your python script will show the way to communicate with it? Or is it read-only?

Yes, it took me about 15 minutes each time. And the hardest part was soldering the pins on to the radio card. A tip in case you also use the dupont jumper cables - I soldered alternate cable pins through the bottom of the card so as to give sufficient space between the cable pin holder blocks.

Very easy, and in fact I recall seeing some on Ebay afterwards. By that time, mine were working fine, tucked away in their boxes and no need to change anything. In fact, yesterday was the first time I’ve opened the box in months, to take the photograph to post here.

Yes, at the moment it is read only. You can get examples of the write functions from the Domiticz HGI80 sources . That is what I used to build the python script.

so, i updated my openhab to 2.4.0.M7 from a 2.4.0-NIGHTLY, and now the evohome binding does not work, i get authentication failed.
My things file did not change, nor did my auth creds, what did change, is that i went from jdk1.8.0_181 to zulu8.33.0.134-jdk1.8.0_192.

any ideas?

Seems my system time had changed, so the ssl cert failed!
Works again!

Ha! What do you know? Turns out that’s MY firmware that’s been forked!

Notice that the setpoint channels changed. There is now only one for reading, writing and resetting.

(wow, the docs are already officially available :smile:)

It’s a small world!! :slight_smile:

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