Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

[SteveP]

SteveP, Since it was hot yesterday, I still have one room that is shut down from last night, due to it not not dropping below the actual SP by 1'C( I think it needs to be this). That room is holding heat still so not dropped below SP so still in hot weather shutdown.. So have a look at your setpoints for the photos you taken. If room temps are 1'C below SP then I do not think the shutdown resets. 1.5'C I believe it resets..

Question about your office... I see the loop symbol which is a permanent overrule of 5'C SP, did you make this permanent overrule, or was that a manual override, because I had a random permanent overrule appear instead of the a manual override I performed.

Hi, yes the rooms are within 1C of SP so that would appear to be the answer
Re the office - I set manually as it is a BD91 controlling a relay that controls an electric rad. However, since I set that up I added an air con unit that has its own app controlled cloud service timer (oh how I would love to control that from evotouch !!) and so I set the office to min setting just in case the air con (which also heats) fails in winter. The office (posh shed) has a toilet room so I don't want the office to freeze

[SteveP]

Well spotted, yes this is new.

As the value is named "Load scaling rate of rise" when you go into it then I'd say yes it's related to load scaling

Mine are all set to 3.0C as well and the range is 0.5C to 6C. This setting will be related to how many degrees C per hour the radiators in a zone can raise the temperature going at full tilt.

When I analysed the optimal start function years ago I came to the conclusion that the controller started off with an assumption of 3C / hour rate of rise for all zones before gradually adapting to the true rate of rise of each zone, (to get the room to hit the target at the right time) with a maximal adaption range of approximately 1-6C / hour. So it's interesting to see a default of 3C here and a similar range of adjustment.

Perhaps Andy can clarify what adjusting this zone setting would do - load scaling is said to be adaptive to the characteristics of each zone (after a week or two of monitoring the zone characteristics to learn) so I'm not sure how a manual adjustment fits in here, and whether altering this value would override any automatic adaption, as there isn't an "auto" setting to return it to after you've manually made a change.

Yes I thought it may be the zone adjustment factor used by the optimiser /load scaler, the bit that foxed me was that it could be manually adjusted !
Before the days of evohome I was seriously in to optimiser based thermostat controllers (we're talking the early 90s now) and one of them had an optimiser adjuster value that could be viewed. Problem was basically it set a start number and then missed the target temp and simply adjusted the number. The next day rinse and repeat. All fine if the temp gradually changes outside but when there were big o/s temp jumps the system couldn't cater. I am hoping that the "fuzzy logic" in evotouch will be smarter but am concerned that all zones show the same temp rise value of 3c and I could manually set the values better as I know from experience that there are serious variations between zones. This is one of the primary reasons why I first invested in evotouch MK I due to its zone based capability rather than a blanket central based thermostat (My hall is always lovely and toasty whilst my north facing ensuite freezes !!)

[guyank]

I'm seeing some strange behaviour for Optimisation. When we're off work, using a combination of Google Calendar, IFTTT and SmartThings I have Evohome setup to start the Day Off quick action at 0200. For some reason, Optimisation doesn't seem to work for this now. It either doesn't start or starts and then almost immediately stops with the set point altered to 5C. The first graph shows this working correctly in Jan:

Screenshot 2020-04-09 at 10.32.31.jpg

The second shows optimisation working correctly on Tuesday when I went to work so didn't use Day Off like this:

Screenshot 2020-04-09 at 11.10.06.jpg

And the next 2 show this behaviour over the last 2 days. You can also see there are a couple of the 35C setpoints occurring:

Screenshot 2020-04-09 at 11.09.43.jpg
Screenshot 2020-04-09 at 11.09.22.jpg

[PJB]

Believe it or not that isn't hocus pocus, but a workaround to a different issue (phantom override) that has been there for a long time. (Not related to the current beta firmware) Quite a bit of discussion about that particular issue on old threads here. It's an issue I've had myself and yes, randomising the boot up time of the HR92's does work around it. I don't think it will help this particular issue though.

Update: Needless to say, the 'battery swap at 5 past the hour' trick hasn't solved my optimum start 35degC CH demand problem. I made sure all battery connections were solid too, as recommended in the 'phantom override' thread. But the 35degC spike happened again this morning. I think it's too much of a coincidence to say that this is a separate issue, not caused by the Beta firmware.

So what now? @Andy_the_Minion .. is this a recognized problem which will be ironed out in future Betas? It's spring here & the CH will be in lockdown too for the next few months. Should I sit tight?

[Andy the Minion]

I've had the Beta firmware installed since 3Apr2020. Yesterday morning & evening and again this morning I noticed the 35degC CH demand in one of my zones. Other zones are unaffected. I have optimum start enabled. The zone in question has just an HR92UK rad controller. I'm afraid that I didn't investigate too much - I just manually decreased the zone setpoint via my HomeAssistant setup.

I put a call into Honeywell/Resideo support. They were aware of the firmware Beta trial. Their suggestion is

"At any hour and 5 minutes (f.ex. 12:05, 1:05) please remove the batteries from the HR92UK for couple of seconds and plug them back.
Make sure to follow that procedure exactly at some hour and 5 minutes, to be able to reset the unit properly."

Which sounds like hocus-pocus to me. However, I'll try it & let you know.

Hummm, a very poor response to the call. I will ask about this.

[Andy the Minion]

Update: Needless to say, the 'battery swap at 5 past the hour' trick hasn't solved my optimum start 35degC CH demand problem. I made sure all battery connections were solid too, as recommended in the 'phantom override' thread. But the 35degC spike happened again this morning. I think it's too much of a coincidence to say that this is a separate issue, not caused by the Beta firmware.

So what now? @Andy_the_Minion .. is this a recognized problem which will be ironed out in future Betas? It's spring here & the CH will be in lockdown too for the next few months. Should I sit tight?

Yes it is a known bug and has been covered back in the early days of the thread. It should not cause the room to overheat but is fixed for the release version.
Regards
AtM

[PJB]

Yes it is a known bug and has been covered back in the early days of the thread. It should not cause the room to overheat but is fixed for the release version.
Regards
AtM

Excellent. Thanks for the confirmation.

Thanks but don't sweat about the response from Resideo Customer Support team. Thread item #235. Best you spend your time with the firmware bugs

[DBMandrake]

Yes it is a known bug and has been covered back in the early days of the thread. It should not cause the room to overheat but is fixed for the release version.
Regards
AtM

Will those testing here see another beta more representative of the final version before it goes out to the masses so that the various fixes can be independently verified ?

[petep]

All zones now OFF except that first one with the constant 15C setpoint. Current temp from HR92 is 21.4C

Definitely not expected behaviour.

Same today.
9pm
Outside temp 20C
All rooms but one off at 5C except one.
Rooms were either at 5C overnight or switched to 5C about noon.

Current room temp 22.9C, setpoint 15C
This room has never switched to 5C

@andy_the_minion why is this zone not being set off?

[Andy the Minion]

Yes I thought it may be the zone adjustment factor used by the optimiser /load scaler, the bit that foxed me was that it could be manually adjusted !
Before the days of evohome I was seriously in to optimiser based thermostat controllers (we're talking the early 90s now) and one of them had an optimiser adjuster value that could be viewed. Problem was basically it set a start number and then missed the target temp and simply adjusted the number. The next day rinse and repeat. All fine if the temp gradually changes outside but when there were big o/s temp jumps the system couldn't cater. I am hoping that the "fuzzy logic" in evotouch will be smarter but am concerned that all zones show the same temp rise value of 3c and I could manually set the values better as I know from experience that there are serious variations between zones. This is one of the primary reasons why I first invested in evotouch MK I due to its zone based capability rather than a blanket central based thermostat (My hall is always lovely and toasty whilst my north facing ensuite freezes !!)

The setting you can see is the first stage in the load scaling implimentation the value it is initially preset by the type of emitters the zone has. Underfloor heating generally has a much slower response than radiators so to optimise it needed an expectation to work to. However it's not quite as simple in practice, firstly not all underfloor systems are slow (or very slow perhaps) and radiator systems with external sensors in weird places work completely different to radiator heads. We have now removed the need to set this again by learning the response but we left it in place for the trial..... just in case