oh, yeah, I forgot about that one! However, when you have full control over all traffic, what benefit would you have from the binding? You could just as well use MQTT or likewise so set up everything, or am I missing something?
The main benefit would be the auto-discovery of things, unless the MQTT HA/Homie discovery is implemented. Another (small) benefit would be that users have the option to switch between the two methods, in case one is down, from a single solution.
But you’re right - it can all be done in MQTT.
Ok, then I understand what you are saying. For me it would make more sense if the 'home-brew HCI-80" would actually implement the full features from the HCI-80. Then one could choose the “easy-way-out” of buying one, or the more fun way of rolling your own.
Thanks for this it works really well.
When I have used the integration on SmartThings any set point is set until the next switchpoint, rather than it being permanent.
Is there anyway of achieving this functionality with this binding?
It is a useful failsafe, if for any reason EvoHome does not receive the command from HA to cancel any setpoint override at some point the schedule will cut in and restore it at some point in the schedule.
For example in my house the setpoints all revert at 23:00 on the EvoHome controller itself.
Yes, that’s a fair point. My understanding is that they are functionally equivalent, except that the HCI-80 has improved radio reception and picks up some messages that don’t get through to the home-brew.
Anyway, your current binding is working well with the web api, and as you say, it is not that much of an issue to use the hardware solution via mqtt, and so may be not worth the effort in integrating.
The web app doesn’t support it, but the, in my case, the android app returns the next setpoint time, and you can set the temp till next set point, but not implemented yet in the binding.
You can thumb up my issue here: https://github.com/Nebula83/openhab2-addons/issues/22
or here https://github.com/Nebula83/openhab2-addons/issues/17
to get things speeded up.
Done 
Actually @VibroAxe has a PR open for the last issue: https://github.com/openhab/openhab-addons/pull/6479/files#r381743945. Implementing the first issue will be trivial after that.
Yeah, I doing that now. I expect to be done soon. I totally lost track of that one, sorry 
No worries! Ity to me long enough to do my bit, I can hardly complain 
I’m having something strange with my connection in openHAB. Password, screen and 2 of the 6 heatzones are displaying and working as expected, 4 of the 6 heatzones give a connection error. After reinstallation of the binding and things it’s exactly the same, also the same heatzones. Anybody any idees how to solve that?
I’m using openHAB2.5 with all the updates.
Hi, I’m not quit sure how to do that, i’m new to this. I’m able to login in karaf but then . . . .
For starters attached evohome-part of the event.log.
events.log (4.4 KB)
Hey Gyus, any advice why my zone setpoint changes get reverted to the value (originally) set via the Honeywell native controller / tablet or mobile app ?
Below log file - last line is actually not triggered by my actions in OpenHab, but all time appears upon setting a new setpoint in for a zone.
All seem to be working otherwise, I get the zones, correct temperatures etc. Binding version is 2.5.2
The things and items I configured via PaperUI.
2020-03-12 11:50:31.427 [ome.event.ItemCommandEvent] - Item 'wc_temperature_setpoint' received command 23 °C
2020-03-12 11:50:31.450 [nt.ItemStatePredictedEvent] - wc_temperature_setpoint predicted to become 23 °C
2020-03-12 11:50:31.607 [vent.ItemStateChangedEvent] - wc_temperature_setpoint changed from 21.5 °C to 23 °C
2020-03-12 11:50:40.371 [vent.ItemStateChangedEvent] - wc_temperature_setpoint changed from 23 °C to 21.5 °C
I have been using this binding for quite a while now, it’s fab, thank you for the hard work that goes into creating and maintaining.
I do have an issue which I see more and more of and am wondering whether others have the same.
When sending setpoint 0 (to cancel an active override) it makes it to the controller, i.e. it reverts back to the schedule for that room. However, in OpenHAB it seems to be a 50/50 chance whether it then updates with the new setpoint value. Sometimes it works, sometimes it doesn’t.
Example. Schedule for a room at 18deg, overridden to 23. App shows 23. I send setpoint 0 through OpenHAB. Controller reverts back to 18. App continues to show 23.
As I said, it doesn’t always happen which makes this frustrating.
I’m using binding version 2.4.0 on OpenHAB 2.50M1.
Any pointers greatly appreciated
Thank you
Martin
Hello, I see an open PR here: https://github.com/openhab/openhab-addons/pull/6479
Can I ask when it will be avaiable? It would be really benefitial if we can have temporary ovveride function. Thanks Istvan
exact same here. Just reinstalled entire openhab raspbian setup: openHAB 2.5.5-1, evohome binding 2.5.5 and when issuing a setpoint change to any zone, log shows Item changing briefly to new setpoint and then immediately reverting to previous state. In previous versions it used to work perfectly. Can anyone help with this? It makes the entire binding useless to me and I used to rely on it a lot to automate evohome setpoints.
2020-07-04 14:43:03.394 [vent.ItemStateChangedEvent] - FenetreSebSensorDoor changed from CLOSED to OPEN
2020-07-04 14:43:03.425 [ome.event.ItemCommandEvent] - Item 'ChbrSeb_SetPoint' received command 5
2020-07-04 14:43:03.428 [nt.ItemStatePredictedEvent] - ChbrSeb_SetPoint predicted to become 5
2020-07-04 14:43:03.448 [GroupItemStateChangedEvent] - EvoHome_SetPoint_Group changed from 15.8 to 14.6 through ChbrSeb_SetPoint
2020-07-04 14:43:03.452 [vent.ItemStateChangedEvent] - ChbrSeb_SetPoint changed from 14.0 °C to 5.0 °C
2020-07-04 14:43:14.402 [vent.ItemStateChangedEvent] - ChbrSeb_SetPoint changed from 5.0 °C to 14.0 °C
1 Like
Just for Information.
After a few months I started and updated openHab again and that solved this issue.
Today I added a 2nd Evohome display to my house. As I have an Intergas boiler with 2 separate circuits (one for high temperature with radiators and one for low temparature for floor heating) the only working option was to have 2 Evohome systems.
So in the HoneyWell TTC I now have 2 locations (LT and HT). Unfortunately I can’t find a setting within the binding to get devices from this 2nd location. Is that correct?