What would you like to see in evohome? (have your say)

[DJBenson]

1: Show which HR92 is calling for heat
2: Connect locally to controller via app ( ie bluetooth to controller web interface without need for internet)
3: app for graphing zone temperatures

Many thanks

Mick

Shouldn't need bluetooth to connect to the controller, the controller (or bridge on the older models) is a device on your local network, it has an IP address and should be directly addressable internally...there must be reasons why Honeywell chose not to provide local access to the controller but I can't think why. It's a pretty big PITA if you lose your network connection and can't control your system via the app.

My wish list would be;

1. Local access to the controller
2. Web-based (HTML5) controller interface (accessible locally too)
3. Heat call indicator (which zone is calling for heat)

I had a couple more (i.e. the ability to boost the heating if the temperature drops below a certain value) but those can be done indirectly using IFTTT.

[Mickjohn]

Good point DJBenson re ip addy

[Fireblade69]

I'm a bit late to the party here but I may as well add my thoughts.

1. Web browser interface
2. Ability to add electric only heat zones
3. Save/load schedules created on a PC
4. One more which escapes me at the moment but I'll add it when I remember!

Other than that, I really like that they are bringing home security into the system as I hate multiple systems that don't integrate.

[Midori]

The only dissapointment for me is how Evohome resolves it's control logic for non HR92 systems. I mean those systems like mine which have one or more on/off zone valves. In essence; effective control of heat relies on effective control of mean water temperature at the radiator.

Whereas HR92 systems have the benefit of sensing water flow temperature as each radiator throughout the house, measurement of an effective water flow temperature at the radiators is assumed by Evohome software solely on a locally mounted room thermostat. Due to time lag of Boiler Relay calling for heat, and time taken for meaningful flow temperature to arrive at radiators (sometimes 1 to 3 minutes), stable comfortable conditions are not achieved. Evohome Boiler Relay 'minimum on time' adjustment does not securely resolve this.

In the case of zone valve heating networks where one of zone valves is used for HWS primary heating circuit the Boiler Relay should be de-coupled from HWS Service BDR91. Why? Because HWS BRD91 is controlled by a wide differential thermostat (6, 7, 8, 9, or 10 deg C) and therefore only operates HWS BDR91 when HWS Cylinder has cooled at bottom layer. Typically HWS timer setting could be 'ON the whole day' to satisfy irregular occupancy and diurnal HWS demands. Whilst present Boiler Relay is coupled to HWS Service Timer settings, when there is no heating demand or no low HWS storage, the Boiler Relay merrily continues to fire the boiler throughout the day - wasting energy and bad paractice. For this reason I cannot use Boiler Relay and min on time functions. Upgrading my system to Boiler Relay + BRD91 + wiring, for me was just a waste of money.

I see the quick solution being to de-couple Boiler Relay from HWS timer periods, allowing HWS BDR91 zone valve auxilliaries to be put in parallel with Boiler Relay output contacts.

In the long term I would like to see the recommendation for Boiler Relay abolished for Zone Valve systems and individual anti short cycling preset adjusters introduced for each individual heating zone so as to allow for differing thermal delays within the systems.

And for a bonus, I would like to see a similar function the Quick Select - "Heating Off"... Please give me an additional Quick Select to lift room temperature for a short while. (checkout MiGenie one click logic as example).

That said - I am happy to recommend Honeywell as best in class and would not wish to change mine.

[paulockenden]

My current wishlist:

1 - An 'expert' mode on the controller, not as pretty but with more info available. Such as (but not exclusively):
1a - Which zone is calling for heat, not just on-off, but expose the 0-200 parameter used internally. And even better, show this at device level rather than just zone level.
1b - In expert mode don't round temps to 0.5 degrees, or bias them towards the setpoint. Show TRUE temperatures.
1c - Expose the heat demand parameter via the API too.
1d - An ability to tweak the various internal parameters / variables to to with optimisation, etc.
2 - Make the three degree change in Eco mode configurable, either + or -. So it could be used for a whole-house boost as well.
3 - Expose the boiler cycle and minimum on time parameters in S and Y plan mode (i.e. when there's no boiler relay present)
4 - Multiple configurable schedules. Accept that, for example, summer and winter months need different setpoints to maintain comfort. Allow users to switch between them.
4a - Which of course needs a much better schedule control interface. Maybe even via a dedicated app.
5 - With the apps, don't just replicate what's available on the controller - try to extend the functionality, and make use of the more flexible GUI available.
6 - A web interface, with graphing. It's amazing how much info you can glean from Evohome graphs. I've completely re-vamped my scheduled temps because of the patterns I've seen.
7 - A way to see (and graph in the web interface) ALL of the devices assigned to a zone, both temperature sensors and actuators. Not just the one temperature sensor used for zone control.
8 - More that one custom Quick Action, and with more flexibility.
9 - The ability to set zones so that they don't fire the boiler when there's a heat demand (making it easier to use other heat sources).
10 - Less 'oh, it's magic', and 'wait two minutes' etc. Be more open about how things work, algorithms used, etc., and any engineering limitations.

OK, that's a start! But I do realise it's probably a 'power user' request list.

Although none of these would be useful for more "set and forget" users, I feel that the learnings that would come from giving 'people like us' such facilities would feed back things which would enhance the product for non-power users. And like I said in my first point, all of the extra stuff can be hidden within an expert mode.

[paulockenden]

And having said all of that, I still love Evohome!

[DanD]

Great list Paul! I particularly like items 6&7:

6 - A web interface, with graphing. It's amazing how much info you can glean from Evohome graphs. I've completely re-vamped my scheduled temps because of the patterns I've seen.
7 - A way to see (and graph in the web interface) ALL of the devices assigned to a zone, both temperature sensors and actuators. Not just the one temperature sensor used for zone control.

I've been using Domoticz for item 6 and I agree that having historic data really helps to understand and optimise the settings. Item 7 has been bugging me too and I'm messing with the Domoticz code at the moment to see if I can work out a way to surface all unique devices to at least allow temperature monitoring of all individual sensors. I think this would really help in understanding how zones of grouped devices are behaving together.

I also agree with your thoughts on Evohome. I think it's a great system.

Dan

[DBMandrake]

The only dissapointment for me is how Evohome resolves it's control logic for non HR92 systems. I mean those systems like mine which have one or more on/off zone valves. In essence; effective control of heat relies on effective control of mean water temperature at the radiator.

Whereas HR92 systems have the benefit of sensing water flow temperature as each radiator throughout the house, measurement of an effective water flow temperature at the radiators is assumed by Evohome software solely on a locally mounted room thermostat.

Can you show a reference that says that the HR92 measures the water flow temperature at the radiator ? As far as I'm aware, the HR92 does not, and can not do this. To do so it would have to have a temperature probe in solid contact with the metal of the radiator valve body, but if you examine the screw on attachment that goes on the valve and the inside of the base of the HR92 you'll see that its pretty much all plastic and there is no such sensor and nowhere it could really go.

On the contrary, measuring the temperature of the room beside the radiator is a big disadvantage as the reading is elevated when the radiator is hot due to the direct heat from the radiator, and the ability to "sample" the real room temperature is highly dependent on how well the radiator convects the air around the room. There can be an error of several degrees between the reading taken at an HR92 and taken at a wall stat under some circumstances.

A remotely mounted wall stat is always going to be more accurate and representative of the room than measuring beside the radiator.

Interestingly I have read somewhere (can't remember where, I think it was a spec sheet) that the HR92 has two air temperature sensors. It's not clear what it would do with two sensors but my guess is there is one on each side of the HR92 body that allows it to cancel out the proximity effect of the radiator heat to some degree.

The way that would work is if the radiator is cold both temperature sensors would give the same reading, which it could use directly, however when the radiator is hot the sensor on the radiator side of the HR92 would read higher than the one on the other side - it would then know to use whichever sensor gave the lower reading, or perhaps even extrapolate a reading that was lower than lower reading based on the temperature slope between the two sensors...(eg if the near side sensor says 21 and the far side sensor measures 20 it might be reasonable that the room temperature is really 19)

I have no idea if it does this or not but it seems possible. Can anyone from Honeywell confirm the "two" temperature sensors in the HR92 and comment on the purpose of having two if it does have two ?

Due to time lag of Boiler Relay calling for heat, and time taken for meaningful flow temperature to arrive at radiators (sometimes 1 to 3 minutes), stable comfortable conditions are not achieved. Evohome Boiler Relay 'minimum on time' adjustment does not securely resolve this.

I assume you mean you're getting cyclical overshoot ? I very much doubt this will be due to remote temperature sensing - remember the sensors work to a 0.1 degree resolution (even though the displayed figures are rounded up) and TPI should in theory give reasonably fine control of heat from an on/off control like a boiler relay or zone valve, however a zone valve giving hard on/off cycling is never going to give as fine a control of the heat as an HR92 which can make small continuously variable adjustments to the flow through the valve instead of just full on or off.

[WiteWulf]

Nothing new to add, but I'd like to echo the following requests:
- see which zone is calling for heat and when (not essential on the controller or app, but definitely through the API)
- see when boiler is on or off via BDR91 (again, more useful through the API than controller or app) if we can't have per zone indication

[jdp80]

As others have said
- Show when a zone is calling for heat, both in the controller and on the API
- More accurate current temperatures - don't round toward the setpoint! (Why is this?)
- A cheaper, subtler alternative to the DT92/Y87 which just reports temperature
- Power supply for the CS92 (most cylinders will have power nearby, one less set of batteries)
- an event log listing all the main events throughout the day

[DBMandrake]

This is a UI consistency glitch I think, but when HR92/UK units are set to display measured temperature, they actually seem to display the temperature of the master unit, not the temperature of the actual unit.

This is correct and normal behaviour if the zone is configured in "single room" mode, which is the default. The way it works in single room mode is that there is only ever one temperature sensor used - whichever sensor is nominated during binding or configuration. This could be one of the HR92's or it could be a wall sensor like a DTS92.

That temperature sensor periodically sends its reading to the controller, which then relays it back out to all actuators. So for example if you have a DTS92 and two HR92's in a single room mode zone, the DTS92 will show a change in temperature first, shortly followed by the controller screen, (and phone app) and then some time later (quite a few minutes later) any HR92's in that zone that are configured to show measured room temperature will update their displayed temperature. So the HR92's are actually showing the temperature measured by the DTS92, (albeit with considerable delay) not measured by themselves.

Since there is only one temperature sensor in use in a zone in single room mode this makes perfect sense to me - the HR92 is telling you the temperature of the room, just not measured from it's own sensor, it's telling you the temperature measured at the nominated temperature sensor - which is the temperature reading that is used to regulate the room temperature, and is almost always more accurate than the temperature measured at the HR92.

An interesting little factoid is if an HR92 is the temperature sensor in a single room zone, it seems that its temperature readout does not use that temperature reading directly - it still displays the temperature sent to it by the controller. So it measures the temperature, sends that to the controller, a few minutes later the controller sends the temperature reading back to the HR92 which then displays it. This is why the temperature reading on HR92's is so slow to change when there is a sudden change in room temperature, yet the controller reports the change much quicker. You'd assume because it was the temperature sensor for the zone that it would use that information directly, but the protocol does not seem to work that way. (It only uses it directly in unbound mode)

While this is not much of an issue where the units are in the same room, when a zone is spread across multiple rooms, it is downright weird to display a completely false temperature in a room.

If the HR92's in a single zone are in different rooms, you should configure the zone to be a "multi-room zone", otherwise the room that is not currently the nominated temperature sensor will not get its temperature regulated properly at all, and could end up very hot or cold depending on the difference in rooms. In multi-room mode every HR92 measures its temperature directly and uses this to control its own radiator valve only, so that they can independently regulate their own rooms to the same temperature. Only the temperature of the first room is reported back to the controller, the 2nd room's temperature will only display on that HR92.

Maybe I have misunderstood how the system works, but I assumed that the master sensor was only for display on the controller, while each HR92 would still use locally measured temperature for valve operation and heat demand.

Nope - that's the way it works in multi-room zone mode, but that is not the default unless you choose that. Generally unless you were spreading a zone across multiple rooms or if the zone had widely different conditions at different radiators (a large open plan room for example) then you would use single room mode where all radiators in the zone work in unison from a single temperature measurement.

[paulockenden]

I think that in many respects an HR92 is actually two separate devices. A sensor and an actuator. That's why you are seeing the round trip to the controller on temperature changes.

[DBMandrake]

I think that in many respects an HR92 is actually two separate devices. A sensor and an actuator. That's why you are seeing the round trip to the controller on temperature changes.

Indeed. When an HR92 is the nominated temperate sensor for the zone, when there is a change in temperature it's always reported on the controller screen well before the reading on the HR92 itself updates, which seems counter intuitive at first but makes sense when you realise that the HR92 display is always reporting the temperature measurement sent to it by the controller, even if the same HR92 happened to be the original source of the temperature reading. (For temperature display it doesn't care where the reading originally came from in single room mode)

This is also apparent when you bind a different temperature sensor to the zone - like going from an HR92 to a DT92 as the sensor - after a few minutes the HR92 will start reporting the DT92's reading even though you have not changed the binding to the HR92.

Actually I think an HR92 is three devices in one, not two. It's an actuator, its a set point controller, and its (optionally) a temperature sensor. If you choose a different temperature sensor on an already configured zone an existing HR92 still continues to function as both an actuator and a set point controller. (At least in single room mode, for the latter)

Likewise I've also noticed that a DT92 is really two devices not one - its a temperature sensor and a set point controller. When you bind it it automatically becomes both however if later on you change the temperature sensor for the zone back to an HR92 an interesting thing happens - as expected the HR92 now becomes the temperature sensor for the zone, and its measurement is now reported on the controller and used to regulate the temperature instead of the DT92, however the DT92 continues to measure and display its own temperature rather than display the temperature measured by the HR92 and displayed by the controller. (This local measurement of the DT92 in this state doesn't actually do anything though other than display on its own display)

At first it would appear that it has been unbound, however only the temperature sensor half of its functionality has been unbound. You'll find that if you make a temperature adjustment from the DT92 it still overrides the zone set point and a single press of the up/down button still queries the controller for the current set point. So the set point controller function remains bound even though it is no longer bound as a temperature sensor.

To clear it properly for re-use in another zone the CLR function in the DT92 menu must be used to fully clear any remaining bindings.

[DBMandrake]

Another point:

The HR92UK thermostat knob goes the wrong way. I have just installed my first HR92UK, as well as my first HR92, to go with a load of HR80UK and a few HR80 units which appeared on ebay.

The instructions say "By turning the adjustment dial anti-clockwise until OFF is displayed, the valve will be closed permanently." But this is not the case. Some clever clogs has reversed it in the unit design. Probably because we drive on the left hand side of the road, or something.

There are two main design points about UK models going the opposite way: (1) they should all behave consistently, and (2) clockwise motion to tun the temperature down is astonishingly bad UI.

I thought it was fairly obvious why the knob is configured this way ? In the UK conventional TRV valves have standard right hand threads so that when you turn the knob clockwise (looking down on it) this will push the pin down, closing the valve thus reducing the temperature, eg 3, 2, 1 etc. The HR92UK follows the same convention with turning the knob clockwise reducing the temperature. It might be inconsistent with other types of controls people use (such as volume knobs on radios) but it is 100% consistent with the manual TRV's that the HR92UK is replacing.

If it worked the other way around (the "right" way according to you) then there would a long retraining process for end users whose muscle memory would keep turning the knob the "wrong" way after years of being used to manual TRV's. It's all about being consistent with what you're used to and what your muscle memory is programmed to do.

If the documentation claims that you should turn the knob the other way (I haven't noticed) then its the documentation that's in error not the functioning of the knob.

I'm curious as to why you have a mixture of HR92UK and HR92 on the same system ? That doesn't make any sense to me...

PLEASE, let's have a common model with software orientation switching. I am sure the only reason you have different models is so that the logo is always the right way up, but that is a terrible reason in product design terms (if not in branding theory). You can fix this either with a reversible logo panel, or by printing the logo on the dial so it rotates.

In the latter approach, despite the fact that the logo will almost never be oriented correctly as your branding people would normally want, the fact that it moves makes it more prominent. Conversely, sitting in the same place all the time, the logo becomes all but invisible to a householder.

I doubt that it is related to branding, it will simply be a limitation of the LCD screen. It's not a bitmap screen it is a conventional LCD screen with predefined symbols, a screen like this cannot be flipped upside down electronically. The different models of HR92 will either have the screen installed upside down (if it has two sets of contacts) or it will be a different LCD screen altogether which has the symbol layout inverted. Either way you can't switch it in software.

Am inclined to agree. It always frustrates me that when I got to turn up a stat I immediately and instinctively turn it clockwise and then realise I am going the wrong way. Surely it is normal to turn something clockwise to increase?

Except for every manual TRV ever sold in the UK that you turn clockwise to reduce the temperature ?

[DBMandrake]

After about 10 months of use of the Evohome Wifi model I'd like to add a list of bugs I've found, a wishlist of changes/features, many of which echo previous respondants, and a few comments. Items are listed roughly in order of perceived importance. This will be really long as I have been collecting and thinking about many of these points for months, so I appologise in advance.

Bugs:

1) Overriding a temperature locally at an HR92 then cancelling the override at the controller before the next regular 4 minute update has been sent back to the HR92 causes the override to be cancelled on the controller but not on the HR92. For example if the initial set point is 5 degrees and the HR92 is overriden locally to 20 degrees this will be reported back to the controller in a few seconds, however if you then cancel the override at the controller before the local override icon has gone out on the HR92 display, the HR92 will remain at 20 degrees even though the controller now reports 5 degrees. They will remain out of step with each other until the next set point change occurs.

2) Changing quick action or cancelling an override before a set point change but after the point at which it would have changed due to optimal start results in optimisation not occuring for that zone and the set point not changing until the normal scheduled time. For example: during a week day the Living room is scheduled for 5 degrees while people are at work during the day and is scheduled to 20 degrees at 6pm. Depending on current conditions (room temperature etc) optimal start may decide to turn this zone on at 4:30pm to reach the set point in time. However if the heating is manually turned off until say 4:40pm and then turned back on, optimal start "missed its chance" and the zone will remain at 5 degrees until 6pm with no optimisation. Meanwhile a zone whose planned optimal start would have had it come on at 4:50pm - after the heating was turned back on, will start early.

Changing between normal and day off quick action, cancelling away mode, cancelling a manual override will all result in optimal start for that zone failing to occur if the time at which the change occured is after the time at which optimal start would have triggered based on conditions. Personally I find this bug really annoying because I end up having to manually override many zones to compensate for the fact that the zone will now not start heating until the time it is supposed to be up to temperature. Because optimal start will tend to pre-start different zones at different times its common to end up in a situation where some zones will optimal start (those due to start a bit later) and some will not, which is a very inconsistent user experience. Apparently this same issue can affect those using things like IFTTT and it has been reported in other threads on the forum before.

3) Local HR92 overrides are not communicated 100% reliably to the controller. It doesn't happen often, but from time to time a local override made at an HR92 simply does not propogate back to the controller. This can interact with bug #1 above and cause a zone to call for heat when the controller indicates this should not be happening. Turning the knob again a few seconds later results in the set point update going through to the controller. I do not see this issue with the DT92, only HR92.

4) Eco mode (according to built in help and documentation) is supposed to drop the temperature of all zones by 3 degrees. However it will not drop any zone below 15 degrees, also any zone set to 16 or 17 degrees will remain at their set temperature instead of dropping to 15 or lower. EG enabling Eco mode would currently make the following set point changes: 14->14, 15->15, 16->16, 17->17, 18->15, 19->16, 20->17, 21->18. If it is intended to not drop a zone below 15 degrees the built in help and external documentation should be updated to reflect this, however the behaviour of 16 and 17 degrees not being dropped would still remain a bug that needs fixing.

5) Set point changes made from the controller (or phone app) via schedule or manually are occasionally clobbered/reverted by the HR92 sending a periodic hourly report - this is a known bug since the firmware update that enabled HR92 local override display and has been discussed in other threads on the forum, and acknowledged by Honeywell. Hopefully a fix for this will be forthcoming as although it happens to me very rarely it does reduce my confidence in the system reliably actioning overrides that I set.

6) The low voltage fault warning is far too sensitive. Even though the device always has batteries fitted and well charged, I find that lifting the unit from the dock sometimes causes a low mains voltage warning to be erroneously written to the log at the moment the unit is lifted. Obviously "mains voltage" (in reality the 5 volts provided by the dock) will drop when it is lifted, however it should wait a moment and check the voltage again before logging a fault - if the input voltage is zero on the second check it should be smart enough to realise that this is because it has been removed from the dock and that the previous low voltage reading (somewhere inbetween 0 and 5 volts) occured as it was being removed from the dock and isn't an actual low voltage situation.

Continued..