still going strong here, no restart needed anymore, gj @jvanzuijlen
1 Like
Hello, I know that Outh information was it. I removed. I will delete it next time. I left it in there that you can check. I havt this build installed: openHAB 2.5.0 Build #1472. But I moved from 2.4 of course. I did a clean install from 2.3 to 2.4. That was the time that I started to make config file system to keep my config, But I don’t know how to do it with Zwave, This is hard and my system is based on zwave network. When I isntalled 2.5 evohome binding I had the same result. I make a log again about this verision and upload without sevisitve info.binding_evohome_2.5_log.txt (3.8 KB)
I’m not expert about openhab building system schedule and processes, but “openHAB 2.5.0 Build #1472” seems to be prepared on 2018-12-23 03:31:56, where fix landed on master on 23.12.2018, 21:26 CET.
I guess build used by you may not include the fix yet and you need to check with newer build.
ok, thanks. There is a newer one: Build #1480 (28-Dec-2018 11:08:22)
I try it tomorrow morning and let you know the result.
Hello, I can confirm that the change rolled out in Build #1480 (28-Dec-2018 11:08:22) and works.
Many Thanks!
1 Like
Great! I still need to make a 2.4 somewhere soon for others, but at least everyone interested seems to be able to use the binding for now 
1 Like
Only interesting thing is, that when I configure the things through config files the zones still stay visible in the inbox. I tried it many ways but no success. It does not effect the operation. When I change something after a few seconds it rolles out to the thermostat or backwards to OpenHAB server. So it is perfect.
I’ve just updated my OH installation to the latest snapshot (openHAB 2.5.0~S1484-1 (Build #1484)) and suddenly my Evohome account initialised and automatically found my heating zones.
I’ve previously never managed to get any of this working at all on previous versions of the binding so whatever you’re doing @jvanzuijlen keep it up!
Thanks guys, this really makes my day 
Thank you for testing and helping me to make this a great quality binding!
Hey, thanks for this. I am running a fresh install of OpenHab 2 on a Raspberry Pi with a fresh install of Max2Play. The version of evohome I am using is binding-evohome - 2.4.0 through the official plugins list. The Binding picked up my zones perfectly and I have been able to make permanent changes to the temperatures on the fly using rules very easily.
I just wanted to check one thing:
When my Snug is at 17.5 degrees I can set the temperature with:
SnugHeating_SetPoint.sendCommand(16)
The log says:
Item 'SnugHeating_SetPoint' received command 16
SnugHeating_SetPoint predicted to become 16
SnugHeating_SetPoint changed from 17.5 to 16
By design, and as stated in the documentation, this makes a permanent change to the temperature.
I then cancel the 16 degrees with:
SnugHeating_SetPoint.sendCommand(0)
The log says:
Item 'SnugHeating_SetPoint' received command 0
SnugHeating_SetPoint predicted to become 0
SnugHeating_SetPoint changed from 16.0 to 0
SnugHeating_SetPoint changed from 0 to 16.0
This behaviour was unexpected for me. Is this by design? I thought it would cancel the permanent change and the zone would pop back on to its scheduled temperature. Instead, the permanent temperature has become the temperature in the room until the next set point.
Now, I am delighted that I can change the temperature until the next set point, but I would also like to be able to pop the room back on its schedule at the right temperature.
Is this possible? (Do I have to start playing with Persistence to achieve it?)
Thank you for all your work on this.
Have you tried waiting for a bit? For me it tends to snap back in a minute or two? If that really doesn’t work it should be possible to restore the set point from the schedule, when I implement that.
In response to my own post above.
I was a bit previous. The evoHome initially reverts to the temperature that was set as the PERMANENT SetPoint, but after a minute or two it returns to schedule.
(Sorry, just found this in drafts from a few days ago. I thought I’d pressed send. Thanks for replying.)
No problem, glad it seems to work consistently 
I once had the same impression
Thanks for this wonderful binding @jvanzuijlen. Great to be able to set my heating temperature in openHAB.
There was a small annoyance. When a new temperature is set, the temperature is permanently set. I prefer the behavior of my Honeywell Round module which sets the new temperature till the next switch point in the schedule. As this is open source software I downloaded the source code and changed this behavior in the binding and it work really well for me.
Is there an interest to share this feature and merge this into the codebase? If so, how and where do I start?
Regards, Jeroen
Yes please!
Worked around this to let openhab schedule my evohome, instead of the evotouch, but this would be better.
Yes there is definitely an interest: https://github.com/Nebula83/openhab2-addons/issues/17. Its the first thing on my todo list actually. Please fork my github repo and create a pull request. I’d like to have it configurable, but that is something I can easily add. Big thanks for the contribution in advance!
I forgot to mention: I made a 2.4.0 version including the new authentication. You can find it here: https://github.com/Nebula83/openhab2-addons/releases/tag/2.4.0-1.
Thanks Jasper, I will have a go next week and if I have questions I will let you know.
Hi Jasper,
I just created a PR to add support for temporary set point override based on schedule. Please let me know what you think.
Regards, Jeroen
