S-Plan vs Y-Plan for Evohome ?

[g6ejd]

I also think you have uncovered a firmware issue because my DHW is set to 50, but it never reads more than 49 (by the CS92), i.e. the boiler is switched off at 49 so it never stops at 50°C the set-point. It would be really easy to check the Evohome source code and see what values are being compared see if (most likely) one is being rounded and the other not.

[HenGus]

I also think you have uncovered a firmware issue because my DHW is set to 50, but it never reads more than 49 (by the CS92), i.e. the boiler is switched off at 49 so it never stops at 50°C the set-point. It would be really easy to check the Evohome source code and see what values are being compared see if (most likely) one is being rounded and the other not.

Having had Evohome installed for over 2 1/2 years now, I have never seen a HW temperature over-run above my set target temperature UNLESS I have had pump over-run set and then it was only by a couple of degrees. On the odd occasion, I have seen a temp a degree or so below the target temperature but I attribute this to someone running a hot tap when the CS92 has called a stop but before the Evohome temperature has updated. I cannot say that I am bothered provided the temperature is within the range that I have set

I appreciate that those with a technical background are keen to look deeply into the system; however, my simple view is that Evohome does what it says on the tin. That said, I rarely use the App having had a senior moment when applying a QA only to find that when I returned home the controller had frozen.

[HenGus]

@DBMandrake Might this be a CS92 transceiver issue?

[paulockenden]

I was just going to say that I've never seen any DHW overshoots of this nature. But looking at my Domoticz graphs it seems I have.

chart (5).jpg

P.

[DBMandrake]

I also think you have uncovered a firmware issue because my DHW is set to 50, but it never reads more than 49 (by the CS92), i.e. the boiler is switched off at 49 so it never stops at 50°C the set-point. It would be really easy to check the Evohome source code and see what values are being compared see if (most likely) one is being rounded and the other not.

That's interesting - you have the new 1.03 firmware don't you ? I'm still on 1.02.

Mine always waits until it reaches an indicated 50 degrees before it turns off the hot water relay. The valve does shut before the reading changes to 50 but that is just a delay of about 5-10 seconds before the display updates. I have never seen it get to 49 and switch off and then the reading stay at 49 as you describe. I wonder if there is a subtle change in the logic in 1.03 ?

Looking at the output of the V1 and V2 web API's and comparing the displayed figure on the Evotouch is interesting - it appears that both the Evotouch display and V2 API's round hot water temperature down, not to the nearest degree as you would expect.

In one instance I saw the V1 API reporting 48.87 degrees while the V2 API reported 48.0 and the Evotouch displayed 48. The figure always appears to be rounded down.

I wonder if the 1.02 firmware does something like use the rounded down figure to decide whether the temperature has hit the set point yet, so that 49.9 still would not satisfy the hot water demand, and yet at the same time the CS92 rounds 49.9 up to 50 and decides now is the right time to send a temperature update ?

In that case the CS92 believes it has sent a temperature update at the set point that will trigger the hot water demand as being satisfied, but the Evotouch is not satisfied so it keeps heating until the next (considerably delayed) temperature update by which time the temperature has overshot.

Whether the problem is hit would depend on the rate of temperature rise and how that coincided with the sampling periods of the sensor, so it might hit under only very specific semi-random circumstances, and probably only with hot water that heats very quickly. (EG a small cylinder like mine) I've noticed that when the reading hits 47 or 48 during re-heat it always successfully changes to 50 shortly thereafter and shuts off, its only when it goes to 49 that there is a problem due to the reading then staying on 49 for anywhere from another 10 to 20 minutes, which is an eternity in hot water heating time.

If we assume that the behaviour of the CS92 can't be modified (firmware updates aren't possible in the field) then it would appear the only workaround would be for the Evotouch to be a bit more lenient about the set point target - if it sees a temperature within half to one degree of the set point maybe the 1.03 firmware says "ok close enough, lets switch off hot water" to avoid the risk that the temperature sensor won't send another update for a long time. The fact that yours always stops at 49 (which is probably something like 49.8, rounded down for display) would possibly suggest that they have done exactly that.

Having had Evohome installed for over 2 1/2 years now, I have never seen a HW temperature over-run above my set target temperature UNLESS I have had pump over-run set and then it was only by a couple of degrees. On the odd occasion, I have seen a temp a degree or so below the target temperature but I attribute this to someone running a hot tap when the CS92 has called a stop but before the Evohome temperature has updated. I cannot say that I am bothered provided the temperature is within the range that I have set

Glad its working well for you but that's twice now that it's done this in the first week that I've had the hot water kit, and the issue is not related to pump overrun - it's definitely a lack of temperature updates being sent to the evotouch during the critical time when the target temperature is being reached that is the issue.

@DBMandrake Might this be a CS92 transceiver issue?

What kind of issue are you suggesting ?

Faulty from new ?

A wireless signal issue ?

Firmware bug ?

[DBMandrake]

I was just going to say that I've never seen any DHW overshoots of this nature. But looking at my Domoticz graphs it seems I have.

[ATTACH=CONFIG]844[/ATTACH]

P.

Can you zoom in on a period where it appears there is an overshoot and see whether your reading stuck at 1 degree below the target for a long time, and also see what the temperature peaked up to after the reading started updating again to see if you see what I posted in my graph ?

Are you graphing from an HCI80 or via the Web API, if the former do you get at least one decimal place in your hot water temperature out of interest ? I use the Web API but it looks like it should be easy to update the hot water reading in the Domoticz script to use the V1 API for fine resolution like I did with the heating zones. It's just a matter of getting a few quiet minutes to sit down and work on the code...

[paulockenden]

I'm using an hgi80.

Can't zoom in on past events because Domoticz seems to only save averaged data in the past.

IMG_0257.jpg

[DBMandrake]

Can't zoom in on past events because Domoticz seems to only save averaged data in the past.

Ah that's a pity. Munin does this by default too but in my Munin config I have set it to keep all data at full 5 minute resolution for up to a year - it turns out that it only takes about 10MB per zone to do this so I'm happy to do that.

Not sure whether there is a way to configure Domoticz to do the same or not, I haven't looked.

I run both Munin with the evohome-munin plugin and Domoticz in parallel on the same Raspberry Pi - to be honest at the moment I mainly run Domoticz so I can easily look at raw un-rounded un-biased temperature readings on a nice web based dashboard.

I've updated my domoticz evo-update.sh patch to also provide hot water temperature to two decimal place resolution so we'll see what the prior reading is next time there is an overshoot.

My guess is it will be between 49.5 and 49.99, as I suspect the basis of the problem is a difference in rounding behaviour between CS92 and Evotouch.

Although they both have access to the raw high resolution temperature reading, I suspect that nearest neighbour rounding is done in the CS92 before the test that says "has the set point just been crossed, if so send an immediate temperature update", but the code in the Evotouch rounds down before deciding whether the set point has been reached or not.

Thus if the temperature is sampled at 49.75 the CS92 rounds up to 50 and decides yes, now is the right time to send an update, the Evotouch receives 49.75, rounds it down to 49 and decides that more heating still has to be done to reach 50, so the CS92 now doesn't seen another update for a long time...

If the temperature is never between 49.5 and 49.99 during a sampling period the problem doesn't occur. That's my working theory anyway!

[paulockenden]

I'll try to keep an eye on the Domoticz graphs/logs over the next few days, to see if I can capture for a DHW overshoot.

At first sight though, it does look like a bug. Those with particularly high flow rates and temps from their boiler (basically those with high kw boilers) are likely to see quite a large overshoot, I'd have thought.

[DBMandrake]

My boiler is somewhere between 18kW and 23kW - depending on how it was adjusted when it was provisioned. (which I don't know)

The cylinder is only 95 litres and I have the flow temperature boost for hot water demand set to about 78 degrees. I could set it lower as it does heat a lot faster than I expected but with my current thermostat wiring (internal and external flow temp stats wired in series) that would also reduce the maximum configurable flow temperature for heating, so I can't really set it lower than about 75 in case I need 75 for heating in the winter.

I could get another (or different) external flow temperature controller and be able to set hot water flow temperature lower than maximum heating flow temperature if necessary with the internal stat retained as a safety over temperature cutout but I was hoping to avoid that.

Reheat from 45 to 50 is only about 6 minutes, a further 10-15 minutes will take it to well over 60, so 10 - 20 minutes delay between readings if the set point is "missed" is quite a big overshoot.

Maybe people with larger or slower heating cylinders wouldn't notice much of an issue.

[DBMandrake]

While I'm at it, does anyone know how to change the seemingly hard wired 60 degrees Domoticz reports for the hot water set point when the hot water is ON ?

It doesn't look like the hot water set point can be retrieved through the Web API, and I expected to see 60 hard wired in one of the domoticz evohome scripts but I don't see it anywhere. Domoticz treats the device as an ON/OFF device, so I'm not sure where 60 is obtained from for the purposes of graphing.

[g6ejd]

Re: Boiler Output

Most boilers have a graph of gas consumption v output, that's how I adjusted ours, it's output can be varied from 18-25KW and BGas have this (annoying) habit of always turning the output to maximum every time they service the boiler. So, having determined by rough trial-and-error that the load for this property is nearer 20KW without creating a cycling boiler when it reaches flow temperature, I used the graph and gas rate on the meter by adjusting the burner gas rate (it's just a small screw) to the desired output. When BGas leave I adjust it back again - works for me.

[DBMandrake]

I know where the kW output adjust screw is on my boiler, (beneath a cap nut) but I'm not touching it. I would have thought any gas adjustment like this is illegal for anyone not gas safe registered ?

It seems to be set about right though, with all radiators on and hot water at the same time during initial warm up the temperature rise is steady but fairly slow, and it doesn't short cycle. With a lighter load it does cycle but as it is a non-modulating boiler any load less than full load will cause it to cycle on and off once it reaches the set flow temperature. I have a differential of about 5 degrees set on the external flow temperature controller.

[DBMandrake]

I'll try to keep an eye on the Domoticz graphs/logs over the next few days, to see if I can capture for a DHW overshoot.

At first sight though, it does look like a bug. Those with particularly high flow rates and temps from their boiler (basically those with high kw boilers) are likely to see quite a large overshoot, I'd have thought.

How ironic.

The following morning after I updated my domoticz patch to give full resolution hot water readings the problem kindly exhibited itself for me, and seemingly disproved my rounding theory!

Here is the graph from this morning. Again ignore the 60 degree set point, my hot water set point is really 50:



I hadn't previously noticed that Domoticz can also provide a CSV output of the readings, this provides much better clarity of the problem:

DateTime	Set Point	DateTime	Temperature
31/10/2016 04:20	0	31/10/2016 04:20	39.48
31/10/2016 04:25	0	31/10/2016 04:25	39.48
31/10/2016 04:30	0	31/10/2016 04:30	39.48
31/10/2016 04:35	60	31/10/2016 04:35	39.48
31/10/2016 04:40	60	31/10/2016 04:40	45.34
31/10/2016 04:45	60	31/10/2016 04:45	48.83
31/10/2016 04:50	60	31/10/2016 04:50	48.83
31/10/2016 04:55	60	31/10/2016 04:55	48.83
31/10/2016 05:00	60	31/10/2016 05:00	48.83
31/10/2016 05:05	60	31/10/2016 05:05	48.83
31/10/2016 05:10	60	31/10/2016 05:10	62.29
31/10/2016 05:15	60	31/10/2016 05:15	62.29
31/10/2016 05:20	60	31/10/2016 05:20	62.29
31/10/2016 05:25	60	31/10/2016 05:25	62.29
31/10/2016 05:30	60	31/10/2016 05:30	62.29

Hot water was scheduled to come on at 4:30 at 50 degrees, and Domoticz only samples once every 5 minutes. At 4:45 the temperature had already reached 48.83 degrees and would have been due to hit the set point before 4:50, however the temperature reading remained stuck at 48.83 right up until 5:10 - a full 20 minute delay in the reading updating, same as the previous two times this happened. The result of this is an overshoot to 62.29 degrees.

My rounding theory is blown out of the water so to speak because the prior reading was actually less than 49 and would have been displayed as 48 on the controller as I've already established the displayed hot water temperature is rounded down from the true figure.

So I'm left with the conclusion that either the sensor failed to send any temperature updates during the critical period from 4:45 to 5:05, or they were not received by or processed by the Evotouch for some reason.

I double checked again - a full 5 flashes signal strength from the CS92, "Excellent" reported by the Evotouch for the hot water sensor, it's not within 300mm of anything metal or any BDR91's or other electronic devices, the signal is literally travelling about 7 metres through one wall (one side light density fire brick in the boiler cupboard, and plaster on the other side in the kitchen) and then a wooden door that is mostly glass to reach the Evotouch which is wall mounted in the hallway. You couldn't ask for an easier RF path in any normal house, and I have never seen less than a 5/5 signal test to any device around the house. I don't believe it is a signal strength issue.

Maybe it's time to contact Honeywell ? The CS92 just isn't reliable enough for an £80 piece of kit.

[paulockenden]

Didn't someone (it might have been you!) establish that the CS92 sends the data three times?