evohome Wi-Fi

[benc]

I just used the Contact Us page to raise a request using the subject suggested and got this response:
Dear Mr Cook,

Thank you for contacting Honeywell Consumer Support. Your reference is XXXXXXX.

Unfortunately it is not possible for us to specifically grant access to anyone to have
update that have not gone on general release. Once any updates are available you
will be notified with the relevant instructions.

Sorry I don't have a more positive response for you.
Kind regards
Honeywell Consumer Support

[DBMandrake]

Interesting. I've had an email back to say that half of the upgrade process has completed on mine...

Apparently there are two different files that have to be uploaded and they leave an hour between uploading each file. (I guess one is the "Application Software" and the other is the "Wifi Software", as there are two different version numbers on the version screen for the two software components)

So by the time I get home tonight it will probably be complete. I'll let people know how I get on.

I just used the original email address and suggested subject line and for good measure I linked to this forum thread as well. Maybe it depends on who you get ?

PS, probably not kosher to post a support persons full name provided in a private reply on a public forum thread...

[benc]

Ah didn't spot that. I've removed their name. Thanks for the heads up.

Did your update complete ok?

[rotor]

I wasn't able to see my firmware version. Holding the Device Settings button in the User settings menu doesn't yield anything.

[DBMandrake]

Did your update complete ok?

Yes it did. I got another email from Consumer support before I got home to say that the upgrade was complete. The quick response time and very helpful email exchange was very impressive actually.

When I got home there were no notices or alerts of any kind on the controller to indicate that an upgrade had occurred, however when checking the firmware versions by long pressing the devices button, sure enough it now has the newer firmware version described by Rameses. So it looks like minor firmware updates are more or less "silent", unless you specifically checked the version before and after.

I'm pleased to report that the HR92 local override now works, and pretty much in the way that I hoped it would.

Making a local adjustment on the HR92 is now reflected on the Evotouch controller, and very quickly - typically within 5-10 seconds the new setpoint appears on the screen and within the iPhone app.

It appears as a timed override - eg with the little stop watch icon that you get from a timed override of a zone entered directly on the evotouch, and contrary to some confusing discussion about this earlier it does in fact show the new set point as well not just an icon, at least in my single HR92 zones. The only room I have with more than one radiator currently doesn't have any HR92's so I have no idea how this might behave in a multi radiator zone whether in single room or multi-room.

When making the adjustment on the HR92 it initially shows as a local override on the HR92's display, but after the periodic 4 minute communication update from the evotouch to the HR92 passes, the local override icon goes away and the set point remains at the new manually adjusted temperature.

After a bit of tinkering and observation it seems to work like this:

Making a local override on the HR92 immediately changes its local setpoint (the motor starts adjusting the valve) and displays the local override icon as before. It sends the new setpoint to the evotouch more or less immediately, so quickly in fact that if you pause for a moment at the wrong temperature while making the adjustment then turn the knob again it sometimes shows the first temperature on the evotouch then updates to the correct one a few seconds later.

The evotouch then displays the new set point as a timed zone override valid until the next set point. At some point in the next 4 minutes during its periodic communication with the actuator in the HR92 it sends a zone set point update for the new temperature back to the HR92 - at this point even though the new set point sent to the HR92 is the same as the current local override temperature the HR92 switches out of local override mode (the override icon goes out) and continues to maintain the same temperature.

At this point it seems that the override is now a zone override instead of just a local override, which means that after a few minutes a local override made on an HR92 is completely equivalent to a timed override for the zone made from the evotouch or phone app. (At least for a single radiator zone - again, no idea how it behaves for multiple radiator zones)

This is great IMO because previously I deliberately avoided using the HR92 manual override and walked further to the main controller in the hallway (or used the phone app) because I didn't like the way that the controller was unaware of the actual set point in a room with a local override - far too easy to accidentally leave a zone turned up all night, or think that your heating is off when you're away from the house but wonder why the temperature isn't falling like it should be...

Now I'm quite happy to make a local adjustment on an HR92 instead of going to the evotouch because I know it will (*usually) be reflected correctly on the evotouch, so this is now my preferred adjustment point if my phone is not handy.

* In my testing I was able to catch it out in a couple of ways though. Not sure if these are bugs that might still get fixed or inherent limitations/restrictions in the wireless protocol:

1) The local override made on the HR92 was not always sent to the evotouch properly. I would say maybe 1 in 10 times it did not seem to go through, even if left for 10+ minutes, leaving the HR92 and Evotouch in disagreement about the set point for the zone. Making a second adjustment to another temperature did seem to go through. I doubt this is signal related as all signals are very strong and even the hall way HR92 experienced this issue - and it is only 1 metre from the evotouch...

This might not be a bug however, because during my testing I was making multiple set point changes per minute (since it responds so quickly) and this is not a normal use case. From my reading a while ago I'm aware that not only is communication from evotouch -> HR92 restricted to once every 4 minutes for battery saving, devices using this wireless protocol also have a "message quota" per unit time that they are not allowed to exceed. I don't recall what it is, but it's something like no more than 10 messages per 4 minute period, even for mains powered devices like a BDR91 let alone battery powered devices.

So it could be that making many adjustments to the HR92 in the space of a couple of minutes was exceeding its allowable message quota until the next time interval. I would have thought that it would wait until it was allowed to send messages again and then belatedly send the local override message, but apparently not - the message just doesn't get sent at all leaving them out of sync and in disagreement until the next manual override or set point change.

The way to test this theory would be to make lots of manual override adjustments on the HR92 but leave at least 5-10 minutes between each one - if that works without any lost messages then it would confirm the message quota theory, IE, not a bug. I will give this a try over the weekend.

2) If I made a manual override on an HR92, which is reflected almost immediately on the evotouch display, and I then tried to cancel the override on the evotouch within the up to 4 minute period before the evotouch sent a new setpoint update back to the HR92, eg before the local override icon went out on the HR92, then the evotouch would cancel the override from its perspective, but the HR92 would stay in local override mode and thus not revert to the non-overridden temperature.

However if I made sure to wait until the 4 minute period was up and/or the local override icon on the HR92 had gone out (showing that the set point update had gone through) then I could successfully cancel the override on the evotouch and it would revert the HR92 back to the non-overridden temperature. I can see how this could potentially happen if the HR92 was adjusted less than 4 minutes before a scheduled setpoint change as well.

I think what is happening here is that the evotouch will not send a message to cancel an override to an HR92 if it had not previously sent a message to set the override in the first place. EG say that the scheduled temperature was 20 and you overrode to 22 degrees on the HR92.

The set point on the evotouch is now 22 degrees thanks to this new software update, but it has not yet sent any message to the HR92 to tell it to switch to 22 degrees as it is waiting for the next 4 minute interval. (It is seemingly unaware that the HR92 has been manually set to 22 even though it just received a message from it)

If I now cancel the override at the evotouch, it doesn't send any message to the HR92 to set it back to 20 degrees, because it never sent it a message telling it to change to 22 degrees in the first place. Therefore the HR92 stays in local override mode at 22 degrees. This seems like it should be trivially fixable in the evotouch software by just always sending a set point message when cancelling a zone override even if the original override message never got a chance to be sent to the HR92. (What harm does it do to re-send the same set point just to make sure ?)

This same sort of issue actually existed on the old firmware when trying to reset a manual override remotely - For example say that the zone was scheduled to 20 degrees and you override to 22 at the HR92. This was not reflected on the evotouch or phone app, however if you were aware that you had made a manual override you might try to for example turn off the heating then turn it back on via phone app to refresh the set point of all zones.

This didn't work if you did it too quickly - for example if you only set heating off for 30 seconds then turned it back on, the HR92 would remain at 22 degrees. You had to wait at least 5 minutes to be sure that the evotouch sent a set point of 5 degrees to the HR92 and then it would send a set point of 20 when you turned it back on.

Hopefully this is something that can be addressed in a revision to the new firmware, but other than this minor niggle I'm really liking the proper handling of HR92 local override.

I can't say I have noticed any other changes since the firmware update except perhaps a slightly darker/bolder font in the user interface, but that could be my imagination.

[DBMandrake]

I wasn't able to see my firmware version. Holding the Device Settings button in the User settings menu doesn't yield anything.

You have to hold it a long time - about 30 seconds.

[rotor]

Ah OK, thanks. Will try again tonight.

[DBMandrake]

I can't say I have noticed any other changes since the firmware update except perhaps a slightly darker/bolder font in the user interface, but that could be my imagination.

I didn't want to say anything right away because with only one day of operation I couldn't be sure, but after a few more days I think that the firmware update has also improved/fixed "optimum start".

Since a week before the firmware update I have been graphing set points and temperature and had noticed that optimum start just didn't seem to be "learning", despite two weeks of use since the initial install. (I had also noticed it anecdotally before getting hard facts through graphing)

I only have two zones at the moment - the Living room and the hall way. The living room cools quickly but also heats quickly, and the hallway cools very slowly but also heats very slowly even when the doors are closed. (Not sure why! It has quite a large radiator and the slow cooling suggests that excessive heat loss is not the cause of the slow warming)

Warm up time for either room is typically between 1 1/2 to 2 hours but I left the optimum start limit at the default 3 hours deliberately to watch the learning process.

During the week the living room is set to 5 degrees from 8am to 6pm and 22 degrees from 6pm. In the colder recent weather it was falling to a low of about 13 degrees during the day. Despite it only taking about 1 hour 40 minutes to warm up from 13 degrees to 22 degrees it was turning this room on at about 3:15 in the afternoon - eg a full 2 hours and 45 minutes early, causing the room to be up to temperature more than an hour early every day.

Day to day the startup time would vary maybe 15 minute either way but that may have been due to a slightly different starting point, eg 14 degrees instead of 13 degrees. My expectation was that there would be a steady daily trend to start later and later each day until it hit the target at the right time but after 2 weeks of a regular schedule it was still getting the living room up to temperature more than an hour too soon with no real improvement.

Meanwhile the slow warming hallway had the opposite problem - it was starting much later, about 4:30, and only had to warm from about 16 to its 20 degrees 6pm set point, but it was not actually making it in time, and was typically only up to 19 degrees by 6pm. Again, day after day it was missing its target and not managing to get to 20 degrees until half an hour or more after the target, and was not showing any significant trend to start earlier to compensate as it should have.

After the firmware update both zones are now pretty much hitting it on the button after only one or two days - in fact the living room which was an hour too early the previous day was pretty close to correct even the same day that the firmware update was done - which was completed only about an hour before optimum start would have been due to turn the living room zone on.

I had to clear my graphs due to a configuration change to increase the resolution of old graph data so unfortunately I don't still have those evening examples, but here is this morning (Saturday) for both zones, with Hallway set to 20 degrees at 9am and Living room to 21 degrees at 9am:





The hall came on 1 hour 15 minutes before the set point and got to the correct temperature about 15 minutes early - previously it was always at least half an hour late.

The Living room came on 1 hour 20 minutes before the set point and got to the correct temperature 5 minutes early - last weekend it was coming on about 6:15 in the morning instead of 7:40.

I don't know for sure of course, but I have a theory of what might have changed, based on having both a very slow and very quick warming zone to observe.

It seems that even if it was monitoring the warmup characteristics of the room to learn how soon it should have been turning on, for some reason (perhaps a bug) this information was not actually being factored into the calculation. It was as if it was using a "nominal" figure of about 3 degrees rise per hour in its calculation regardless of what it had previously observed.

My living room can manage about 6 degrees rise per hour, while my hallway can only manage about 2 degrees rise per hour. Thus the living room consistently came on way too early while the hallway consistently came on too late and never made the target in time. The startup time did seem to vary correctly in response variations in the starting temperature - eg if the room was colder it did come on earlier. But for the same starting temperature it started at about the same time within 15 minutes every day and never learned that it was getting there far to early or late.

It did seem to learn the thermal response time of the room in other regards - for example the first day after a complete reset of everything the living room will overshoot by about 1.5 - 2 degrees, again possibly because the room heats so quickly and there is significant thermal mass of the large radiator area, yet the very next day there would be no overshoot and it would hit the target temperature on the button without under or overshoot as in the graphs above. (Albeit an hour too early before the update)

Then when we put a Christmas tree in front of those radiators (arranged in a bay window) the following day it overshot again (presumably the tree adds thermal lag for the transfer of heat from some of the radiators to the HR92's sensor) and once again the following day there was no overshoot because it had learnt the change in thermal characteristics - the graph above shows it hitting 21 degrees perfectly, with the obstruction of the tree. (Two of the three radiator panels are obstructed by the tree, but the one with the HR92 on it is exposed to the room)

Anyway I will continue to keep an eye the performance of optimum start, as I have certainly seen a few people complain that it comes on too early and never seems to learn - from what I have seen it might be a bug that is due to be fixed when this firmware is released!

[Fursty Ferret]

Thanks Rameses - emailed yesterday and had a reply within 10 minutes telling me the firmware was on its way. :-)

That's the sort of customer service to be proud of.

[Caesium]

Huh. Still waiting for my reply, can you see if it got missed please Rameses? Sent it again just in case. This is the [email protected] address right?

[Caesium]

And now I got fobbed off with a generic reply, "there is no update available"

[top brake]

Huh. Still waiting for my reply, can you see if it got missed please Rameses? Sent it again just in case. This is the [email protected] address right?

http://getconnected.honeywell.com/en/contact-us

and put a link to this thread please

[Caesium]

thanks top brake, done.

[londonbairn]

Bought this last month and having problems now. Randomly turns on heat with no reason why and the battery won't last beyond five minutes. Spoke to retailer who have said a few people have had the battery issue. Will be getting swapped out I think

[DBMandrake]

Bought this last month and having problems now. Randomly turns on heat with no reason why and the battery won't last beyond five minutes. Spoke to retailer who have said a few people have had the battery issue. Will be getting swapped out I think

Assuming you still have the same problem after a replacement unit it might pay to start your own thread with a description of the problem.

Chances are that "for no reason" is not the case and it's more a case of understanding how the system works. (Or possibly a comms fault causing failsafe mode to activate, if you have failsafe enabled - I had that happen when I had an incorrect binding causing the boiler to run at 20% duty cycle over night warming up the rooms with manual TRV's)

One example of "coming on for no reason" would be turning the heating "off" and then seeing the boiler relay come on a couple of minutes later for a couple of minutes - due to the way communications work this can and does happen.