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?
I solved it, just disabled the Account Thing en reenabled it, now it found the new hardware. 
When setting a SetPoint via the Evohome binding, it always becomes a permanent override isn’t it?
And by setting it to 0 it return to FollowSchedule.
Is it also possible to set a (temporary) override until the next time block according to the schedule?
Hi Peter,
Good to see that you fixed the issue.
On the override topic: this was proposed and made it as a PR by another, but then got closed. I don’t have the time right now to implement it, so it’s still in limbo. All it really needs is a someone to restructure some of the code. The function on it’s own is already working.
I had this issue again recently with only one of my HR92 thermostats. I decided to unlink all, delete items and thing for that device and re discovered it and and created same items as before and all worked again fine. I’ll keep this as the repair procedure should this issue happen again.
1 Like
Have you tried restarting the binding from the Karaf console?
Hi,
Maybe its the open window mode and it has nothing to do with openHAB
I will testing this tonight I will het them on. but I saw that one of the 3 radiators was sending een off command to the evohome. so i checked up the forums of honywell. because i had the same problem like you.
you have the open window mode if a cold wind reach your hr92 it will turn automatic off.
you can disable it on hr92 setting hold the button go to parameter 11 and set it to 0
I let you guys know.
Update: it was the openwindow mode in my case, no problems after turn off the open window setting
I have one heating zone that always changing to the offline status with
COMMUNICATION_ERROR
TempZoneActuatorCommunicationLost
in the TTC it is working fine.
I’m living in Belgirum, using OH3 at the moment, but 1 week ago I had the same issue when running on OH2.
Any Idea why for one zone this can be the situation?
It would be nice that in the future can be added that you can change from a time to a time the temperature. Then I can specify the use of a location in my google calendar and when connected via iCalendar also update the planning in my EvoHome system. And when doing it in this way you can use the optimizer off the EvoHome system in place of trying to provide an own one to program in the OH environment.
Does this Binding work for North American TCC accounts? I checked the notes and issues log and it says it was solved by “Home Assistant”, but the link no longer works.
Hi @jvanzuijlen
Thanks for the work in developing this binding. I’ve just today loaded OH3 and 3.0.1 version of the evohome binding. I know the Documentation refers to this supporting heating zones, but I was wondering if you have any plans to extend it to include the stored hot water that my evohome system also controls?
Many thanks
Any responses?
No it does not.
I wrote this to interface with OH via MQTT