Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

Quote:

---

Originally Posted by SteveP

Ally153, could we have a pseudocode or structured english (or other code view) of exactly what the o/s temp logic is as whilst it is "entertaining" myself and others such as DerekWilliamsUK reporting the inaccuracy of the evohome o/s temp value compared to what you are saying is the authoritative source (Accuweather) , my readings this morning show that it is no longer a simple polling issue as when evohome did update it used a value that Accuweather was not reporting for my area and was several degrees out.

---

I completely agree with SteveP.

My latest check at just after 11AM shows EVO now reporting 12*c (a BIG jump from previous 7*c) HOWEVER Accuweather APP is now reporting 16*c, so no match with EVO. Because of this slow/low reporting Evo still has Cold Weather Compensation ACTIVE (it is only set for the downstairs rooms), when it should have backed-off ages ago !!

As for maintaining my requested Setpoints, EVO is doing a great job. My daytime default is 22*c across all zones (that's how my wife likes it). The Lounge Window area/zone (LoungeW) is lightly over due to the morning Solar effect.

See attached for latest readings.
Attachment 1591 Attachment 1592

This has been known since the initial release. I was reporting temperature variations back in April. Andy the Minion replied as detailed below. Unfortunately he never came back with the explanation.

Originally Posted by CT1 In April
Yesterday morning EvoHome was reporting a temperature 3 degrees below the actual outside temperature and 1 degree below that reported by my Alexa. At lunch time today they all agree. I do not see how this can be the basis of an acurate control system.


Reply from Andy the Minion
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

Quote:

---

Originally Posted by CT1

This has been known since the initial release. I was reporting temperature variations back in April. Andy the Minion replied as detailed below. Unfortunately he never came back with the explanation.

Originally Posted by CT1 In April
Yesterday morning EvoHome was reporting a temperature 3 degrees below the actual outside temperature and 1 degree below that reported by my Alexa. At lunch time today they all agree. I do not see how this can be the basis of an acurate control system.


Reply from Andy the Minion
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

---

I've been trying to refrain responding too deeply into the outside temperature issues until I got a more complete picture from the connected team, but don't want you all to think I'm ignoring this discussion!

Evo polls for the outside temperature every 10 minutes, I assume the issues many of you are facing are from the API's response, which I'm still waiting some analysis on. I have seen in the past that certain locations will at times return an error value when we ask for weather data from our API. I believe this is an error code from accuweather when our collective devices trying to make too many weather requests in a set period of time (accuweather licences limit the number of calls you can make to their APIs). This is pure speculation at the moment however and until I get more feedback from the team should be taken with a pinch of salt.

The outside temperature is displayed when we get valid weather data from the weather API, the API should return an error code when there is no valid data for your location. The data is processed by the Wi-Fi micro application, which is then passed to the main micro application. I develop the main micro application, so the handling from the Wi-Fi micro is a black box to me handled by a separate team. Until I can get more detail on what's happening to our API requests and how the Wi-Fi application handles the data, I don't think trying to cobble together a more detailed answer will be helpful to this discussion.

What I will say is that as long as you see an outside temperature on the Evo display, this temperature will be used for any feature that relies on outside temperature data. I don't do additional staleness checks as I'm being told by the black box function I call "this is valid temperature data". If I made a staleness check the end result is the feature would come and go throughout the day, which doesn't lead to a desirable user experience, so once I get more information it would make sense to see what options we have to consider the source more trusted.

I'm afraid it will take time to get answers from the separate teams involved, so unfortunately we'll need to be patient, but the feedback on this beta from the forum has been great, so please keep it coming!

Just a thought. I am not running the beta version but if the Evohome app would only sync with HomeKit, it is high time it did like many others now do, then HomeKit can be used to pull in the outside temperature from an actual sensor. I have a Philips Hue motion sensor mounted outside that feeds the actual temperature all the time as opposed to relying on a “foreign” source that can never be accurate for such do not report the actual temperature at your home which is far more important, not one for some place that may or any not be nearby.

Quote:

---

Originally Posted by G4RHL

Just a thought. I am not running the beta version but if the Evohome app would only sync with HomeKit, it is high time it did like many others now do, then HomeKit can be used to pull in the outside temperature from an actual sensor. I have a Philips Hue motion sensor mounted outside that feeds the actual temperature all the time as opposed to relying on a “foreign” source that can never be accurate for such do not report the actual temperature at your home which is far more important, not one for some place that may or any not be nearby.

---

I don’t think it is a good idea to tell people they need a 3rd party sensor to make their system work properly. Also if I installed a Hew motion sensor it would not be in the best position for a temperature sensor.

Another thought. Get the local Evohome controllers to poll Accuweather directly. Cut out the middle-man and the problems should go away.

You can still control this centrally by pushing out the URL for each controller to poll via the Resideo API. Doing it this way you could even switch to a different weather provider without any firmware changes.

And because it's an outbound call from the controller there's no security issues.

Still have doubts about this feature usefulness because of solar gain etc, but I think the only real alternative to using an out of sync weather service is for EvoHome to go back to offering their own external sensor for those who want extra precision. Whether theire would be enough takers to make it viable, at a sensible price is another question.

As there will be no new firmware changes until at least next year, I think we will just have to wait and hear peoples experiences over autumn, winter and spring, then see what if anything needs changing.

Quote:

---

Originally Posted by paulockenden

Another thought. Get the local Evohome controllers to poll Accuweather directly. Cut out the middle-man and the problems should go away.

---

But potentially exceed the rate limit of their Accuweather API key, as mentioned earlier ?

Quote:

---

You can still control this centrally by pushing out the URL for each controller to poll via the Resideo API. Doing it this way you could even switch to a different weather provider without any firmware changes.

---

I'm not so sure about that. If the device is polling the weather service directly, the API's between one service an another will very likely be quite different. Just changing URL's wouldn't be sufficient, it would likely require coding changes in the Evotouch's firmware.

However using a Honeywell server as a "middle man" means the weather service can be switched at any time without limitation and without any coding or configuration changes on the individual Evotouch controllers...

Done properly a middle man server shouldn't add any significant additional latency.

Quote:

---

Originally Posted by DBMandrake

I'm not so sure about that. If the device is polling the weather service directly, the API's between one service an another will very likely be quite different. Just changing URL's wouldn't be sufficient, it would likely require coding changes in the Evotouch's firmware.

---

Not if the API pushed a URL and a grep string.

P.

If the API is being rate limited, it doesn't particularly matter whether it's the cloud or the end device that is doing the polling. If the rate is still above the committed rate limit, then the API will decline the request.

Roy.