I ran into a little delay due to some linting issues, but here it is:
Get it while it’s hot!
The PR is now being examined by kai, so I expect that it will be merged soon. Please join me in testing the binding to make sure it does what it needs to do :-). The update and authentication issues should be solved as well, so I hope you can run without hiccups now.
Nice! Will definitly test it after this weekend, maybe sunday evening if i got time for it.
Hi guys, unfortunately my binding still crashed after a couple of days…
I added a more robust safeguard to the update mechanism which should definitevely solve it.
And it still stops updating. Seems like the changes needed to get it merged didn’t really contribute to its stability. I’ll update here when it runs successfully for a week at my end.
Can’t we make an exec binding which restarts it through karaf or something for the time being?
Sure, a cronjob should work as well. I posted something similar in the trådfri topic a while back.
Anyway, I’m not blocking the PR by it and try to fix it in the meantime. Feels like a trivial thing, but I’m not sure what the issue is right now. It seems to only occur after a couple of days, so preproducing and validating is slow.
Edit: Link to the cronjob solution IKEA Trådfri Gateway
Come to think of it; an exec binding should be able to do the same. I’ll check if I can make it work.
That should work as exec i think, gonna try this when i get home.
@Mickroz any luck with the exec binding?
I got a little bit further with testing. Turns out the binding doesn’t crash anymore; it just sometimes seem to wait indefinitely
2018-05-15 10:03:20.077 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/location/xxxxxx/status?includeTemperatureControlSystems=True]
2018-05-15 10:03:20.274 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 200 OK - 1799 bytes]
2018-05-15 10:03:20.286 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/location/xxxxxx/status?includeTemperatureControlSystems=True]
2018-05-15 10:03:20.503 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 200 OK - 6236 bytes]
2018-05-15 10:03:20.515 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/location/xxxxxx/status?includeTemperatureControlSystems=True]
2018-05-15 10:03:20.728 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 200 OK - 1376 bytes]
2018-05-15 10:03:35.759 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/location/xxxxxx/status?includeTemperatureControlSystems=True]
That response never comes thus halting the update loop, ultimately letting the access token go stale. According to the docs of jetty this is expected behavior since the timeout of a request is bound to system settings. My system is, apparently, configured to never timeout.
I fixed this in my development system and has been running for three workdays days now. In between days, my computer goes into sleep mode, resuming the morning after; the binding still running smoothly.
In the meantime kai has reviewed my code as well - some minor remarks as a result. I’ll pick these up with the next release, which will include my fixes for a fixed timeout. I think that’ll be the last step before it will be merged. Please help me test the next release thoroughly so we will have a stable, well performing binding in the 2.3.0 release!
Yes, just had to install sshpass on my system, but it works with the exec binding:
sshpass -p habopen ssh -p 8101 openhab@localhost "bundle:restart 'Evohome Binding'"
According to my graph, i don’t see any timeouts.
Can anyone assist? While I realise this is alpha software it seems that others have it working happily.
I’ve installed the binding as an addon and I can get the Evo Home account online
evohome:account:evo_home' changed from INITIALIZING to ONLINE
but I cannot get the display or any zones to come online and get the following error
'evohome:display:evo_home:display' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Status not found, check the display id
The display id I got from my display by holding down the Display Settings button - is this correct?
How do I get the ID’s for the individual heating zones?
Would it make any difference that I am in New Zealand and use https://international.mytotalconnectcomfort.com ?
Any assistance would be greatly appreciated as I’ve been around and around in many circles.
Cheers,
Tim Welch
I am having problems getting evohome to connect to mytotalconnectcomfort.com. Does this portal work with evohome?
From the log:
09:08:27.182 [ERROR] [ohome.internal.api.EvohomeApiClientV2] - Authorization failed
@timwelch I’m not sure what you mean by “Holding down the Display Settings button”. Could you check the status of your account Thing and check if it’s online? If it is you should get your zones autodetected. Take the id you get from that e.g. evohome:display:myplace:1234567 so the id is 1234567. You can also see the id’s if you enable TRACE logging on the binding in Karaf and analyze the raw response data but that’s somewhat more involved, and not really the user interface to finding your display id.
@mjcumming Yes, this should work (I’m using the same). How are you providing your credentials: things file or PaperUI?
PaperUI is where I configured the credentials.
Mike
@jvanzuijlen - can get this binding to connect using a .things file - paperui did not work.
I am not sure what to put in the your_display_alias and your_zone_alias?
Bridge evohome:account:your_account_alias [ username=“your_user_name”, password=“your_password” ]
{
display your_display_alias [ id=“1234” ]
heatingzone your_zone_alias [ id=“5678” ]
}
It’s definitely coming online but nothing more. I’ve enabled trace logged and it appears to be showing some bad API requests…
2018-05-23 08:35:09.305 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/WebAPI/emea/api/v1/userAccount]
2018-05-23 08:35:09.579 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 400 Bad Request - 167 bytes]
2018-05-23 08:35:09.583 [TRACE] [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: Tue, 22 May 2018 20:35:08 GMT
Content-Length: 167
Set-Cookie: NSC_UDDOB-XfcBqj-TTM-WT=ffffffff090ecc1a4f4f58455a465a4a42378b;expires=Tue, 22-May-2018 20:37:09 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-05-23 08:35:09.600 [hingStatusInfoChangedEvent] - 'evohome:account:a7f92577' changed from INITIALIZING to ONLINE
I definitely don’t appear to be getting my zones autodetected after the account comes online.
Cheers, Tim
@mjcumming Ok, good that you are able to make it work. Not sure why the PaperUI does not work for you. Maybe strange characters in your password? Hard to check this since you probably wouldn’t (and shouldn’t!) share that 
May I can log the username and password before authenticating. Since I don’t feel comfortable logging plain text passwords that will probably an MD5 of SHA hashed one, but then you can still do the same hashing and see if it matches.
your_display_alias and your_zone_alias are values that you can freely choose. so maybe my_home and living_room respectively. It makes you channel names somewhat more friendly. OpenHAB generally generates a random value for these when it autodetects them.
@timwelch Looking at https://tccna.honeywell.com/WebAPI/emea/api/v1/userAccount and the fact that you are New Zealand based makes me think that it maybe is correct that you are not getting anything back. EMEA is for Europe, Middle East, and Afrika. Let me check if I can fix that. Thanks for the details!
@timwelch Could you enable TRACE logging and send me the response to the Requesting: [https://tccna.honeywell.com/Auth/OAuth/Token] call? Remove the token values but leave the rest, please. For me (based in Holland) I get this back:
Response: HttpContentResponse[HTTP/1.1 200 OK - 1454 bytes]
2018-05-23 08:57:39.287 [DEBUG] [evohome.internal.api.ApiAccess:107 ] -
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, 23 May 2018 06:57:38 GMT
Content-Length: 1454
Set-Cookie: NSC_UDDOB-TTM-WT=ffffffff090ecc1c45525d5f4f58455e445a4a42378b;expires=Wed, 23-May-2018 06:59:38 GMT;path=/;secure;httponly
{"access_token":"ACCESS","token_type":"bearer","expires_in":3599,"refresh_token":"REFRESH","scope":"EMEA-V1-Basic EMEA-V1-Anonymous"}@jvanzuijlen I get this…
2018-05-23 18:25:23.550 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Requesting: [https://tccna.honeywell.com/Auth/OAuth/Token]
2018-05-23 18:25:25.043 [DEBUG] [nding.evohome.internal.api.ApiAccess] - Response: HttpContentResponse[HTTP/1.1 200 OK - 1412 bytes]
2018-05-23 18:25:25.045 [TRACE] [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, 23 May 2018 06:25:24 GMT
Content-Length: 1412
Set-Cookie: NSC_UDDOB-TTM-WT=ffffffff090ecc1d45525d5f4f58455e445a4a42378b;expires=Wed, 23-May-2018 06:27:24 GMT;path=/;secure;httponly
{"access_token":"xxxx","token_type":"bearer","expires_in":3599,"refresh_token":"xxxx"}
Tokens replaced with xxxx
I think you snipped off the scope bit; which is the bit I was interested in
Edit: hm, I changed the Token request to request for APAC instead of EMEA, and I don’t seem to get the scope back as well. I think I need to add a region selection option to the credentials bit. I’ll try to get that in as well. Would you be willing to test this out when I release the next version with that option available?