Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

[guyank]

@guyank Thanks for the MAC id. We had a look at the system and as best we can tell the 5°C are all being caused by system off quick actions with reversions to Eco or Day off a few minutes later. The changes appear to be from the App.
As a general point, the ‘big’ quick actions in a large system do generate a lot of Rf traffic and especially when they come in quick succession there will be sp messages sent in all directions to all zones, with repeats and answers with demand messages from all the zones. This is prime territory for Rf comms classes and missed messages. The system will recover but if you are paying close attention you may notice zones that stay in a previous state until things quieten down the regular message repeats allow it to catch up again

Andy,

Thanks for the response. I don't see how this could be happening only to one zone if it's coming from the app. You can't apply a quick action to a a single zone. I'll look at my SmartThings logs to see if anything's trying implement a quick action, but I don't see what would at that time of day, especially as it appears to coincide with when optimisation would start.

Thanks

Guyan

[G4RHL]

Question for those running the beta version. Is the clock on the Control Panel more accurate? Mine always runs a couple of minutes fast. I can reset it but it eventually defaults again. I assume it is where it connects to but other devices in the house getting their time from the internet are all fine. Well they all read the same time. Some are bound to as they will pick it up through the same router.

[bruce_miranda]

This is a known issue even with previous versions.

[Andy the Minion]

Question for those running the beta version. Is the clock on the Control Panel more accurate? Mine always runs a couple of minutes fast. I can reset it but it eventually defaults again. I assume it is where it connects to but other devices in the house getting their time from the internet are all fine. Well they all read the same time. Some are bound to as they will pick it up through the same router.

@G4RHL This ‘error’ is intentional and was a TCC thing. There are a lot of devices connected to TCC around the world and schedules tend to be based on the hour and half hour intervals The cloud team impose a random 2-3 minute deliberate offset on device real time that prevents ‘the world‘ all sending commands at exactly the same instance. It would be possible to offset this on the display but then there would be a difference between actions and the display so I guess they went with a time error but true operation at the device. I would expect your device restart when the firmware was pushed gave you a lower offset when the device reconnected and updated the rtc.
AtM

[roydonaldson]

@G4RHL This ‘error’ is intentional and was a TCC thing. There are a lot of devices connected to TCC around the world and schedules tend to be based on the hour and half hour intervals The cloud team impose a random 2-3 minute deliberate offset on device real time that prevents ‘the world‘ all sending commands at exactly the same instance. It would be possible to offset this on the display but then there would be a difference between actions and the display so I guess they went with a time error but true operation at the device. I would expect your device restart when the firmware was pushed gave you a lower offset when the device reconnected and updated the rtc.
AtM

A good idea, but definately a lazy implementation. The time on the device should be accurate, but the offset should then be being applied to the sending api. I do understand the challenge, having worked on projects before where we see hundred thousand odd devices hitting server farms simultaneously. Random based requests and backoff windows work well.

[CT1]

@G4RHL This ‘error’ is intentional and was a TCC thing. There are a lot of devices connected to TCC around the world and schedules tend to be based on the hour and half hour intervals The cloud team impose a random 2-3 minute deliberate offset on device real time that prevents ‘the world‘ all sending commands at exactly the same instance. It would be possible to offset this on the display but then there would be a difference between actions and the display so I guess they went with a time error but true operation at the device. I would expect your device restart when the firmware was pushed gave you a lower offset when the device reconnected and updated the rtc.
AtM

Good to have an explanation at last, thanks for that. However, I agree with roydonaldson. This is another oddity that is potentially confusing for the non geek and makes EvoHome appear unsophisticated, especially for a product at this price point.

[CT1]

Hey, what goes on here, I spent 20 minutes yesterday replying to this and explaining the operation.
But it's late and it's been a very long day, so for now... no we dont base temperature control on this weather data. I will explain more when I'm less fed up.
AtM

My sympathies, I have always found that my login expires before I can finish any but a short post. I now copy the text before posting, that way if it gets lost, I can Log in again and paste it back. The auto save does not always work for me.

[G4RHL]

Good to have an explanation at last, thanks for that. However, I agree with roydonaldson. This is another oddity that is potentially confusing for the non geek and makes EvoHome appear unsophisticated, especially for a product at this price point.

It is nice to have an admission and an explanation but, whilst it is a minor issue, my heating always starts up nearly two minutes before it should. But then with that, who needs optimisation?!

[sminkypinky155]

Here's a strange one for Andy the Minion.

We have a room (our room) in our setup that whenever the cold weather boost kicks in without fail receives a new set point 2 degrees higher than its actual set point. When the new software was sent to us I changed the setting to boost up to 1 degree, as I felt the maximum of 1.5 was too high. Now this room is going into new territory

Could you have a look at this for me please?

[jb80]

I am interested to know whether the "Adaptive Load Scaling" modulation feature increases wear and tear on the boiler because of the frequent stop/start behaviour. I was thinking about this whilst watching this Vaillant video about their modulating thermostat which I gather is varying the power rather than switching the boiler on/off. My thoughts are whether the reduced energy costs using "Adaptive Load Scaling" modulation is offset by the increased wear and tear on the boiler. As a home owner I'd prefer to spend a few extra quid on energy to avoid replacing/servicing the boiler sooner than planned. Thoughts?