Maybe a stupid question, but i can’t manage to change the setpoint value.
All the data is displayed. but i’m not able to control the temperatuur.
What could be wrong with my thing’s file.
or more better, what thing line do i use to controll the setpoint 
i get it, in my first try i used the wrong item name, so nothing was happening.
this is in my sitemap
Setpoint item=SetOverLiving step=0.5 minValue=15 maxValue=25
and this in my items
Number SetOverLiving “Living Over [%.1f °C]” (grHeat) { channel=“evohome:heatingzone:Evohom:xxxxxx:PermanentSetPoint” }
Change the override option. Setpoint is readonly
I see you figured it out already 
Regardless I updated the TS with a link to some documentation, including some examples. Hope it helps with future issues.
1 Like
By the way, I looked into the postUpdate vs sendCommand differences.
What happens is this: when you use postUpdate, only the value of the item is updated, but the “command” (which it really isn’t) never reaches the binding. This results in an updated value in the UI up onto the point where the next evohome update is recieved and it is set to the actual value again.
Using sendCommand the value in the UI is updated AND the command is send to the binding, which, in turn, forwards it to your evohome. If that was successful, the next evohome update which ,of course, reflect that change.
I think this is due to openHAB and it is by design. This way you can update UI values without triggering any rules or bindings. I’ve used it to update the value of an item from within a rule where that rules was triggered by that same item. Works flawlessly.
See also: sendCommand vs postUpdate, https://stackoverflow.com/questions/28981946/what-is-the-difference-between-postupdate-and-sendcommand-in-openhab
1 Like
There. I just fixed the last remark on the PR. I’ll see if I can update that tomorrow as well as creating a new release. I’ll probably have to fix some things to close the PR but I feel the end is nigh.
For now, have a nice evening!
good job, cant wait to test the new release!
Have a nice evening!
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.
1 Like
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.
1 Like
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?