how does evohome work?

[Stevedh]

Is this how evohome works.

I expect someone will point me to a diagram which explains all this,but I haven't been able to find one,


I have probably got this totally wrong, so could someone tell me what acutally happens.

simplified..

assuming room temp is 15 degrees
current setting is 10 degrees.

I set room in phone app to 20 degrees for 30 minutes
app sets room on evohome controller to 20 degrees for 30 minutes.
evohome controller waits until HR92 next talks to it, and tells it to set room to 20 degrees.
HR92 compares wanted with actual temperature and if its higher opens the valve and tells the controller it wants heat.
controller tells boiler relay to switch on boiler.
after 30 minutes
controller waits for hr92 to next communicate, and then sets it back to 10 degrees.
hr92 closes valve and tells controller it no longer wants heat,
controller tells boiler relay to switch off boiler.

or does the controller handle all the temperature comparison etc as the above sequence wouldn't explain how open therm works.

so what actually happens, just wondering

thanks
Steve

[dty]

There's no "20 degrees for 30 minutes" concept. It's a given temperature until the next setpoint change.

The HR92 sends demand (as a percentage) to the controller. The controller aggregates demand from all the HR92s and uses that information to module the BDR92 or to set a flow temperature via OpenTherm.

[paulockenden]

The only thing I'd add to what dty says is that you might be surprised that with all this proportional stuff going on the demand on the boiler will be 100% quite a lot of the time. It only starts to ramp down once all zones are within about a degree of their setpoint. The aggregation seems to mainly be a max() function.

[edhodges1984]

Sorry to jump on this thread but how often does the HR92 communicate with the controller?
Thanks

[Stevedh]

Thanks
Ok I probably should have looked before I wrote, its 'set until' instead of set for..
so presumably If I set it to be a 'given temperature' until a 'given time' this will create a new setpoint..
however is the flow roughly as I described..
does the controller wait until the HR92 next communicates before giving it a temperature.
and does the controller then tell it when the next setpoint is reached, I'm guessing the HR92 doesn't have its own clock.. or does it?
Also is it around once every 5 minutes communication occurs, or will this vary if the temperatures HR92 is reading are changing quickly etc.

[gordonb3]

Ahem. Are we nit-picking here now? `set for` is not such a big deal, it's a simple `set until ( now() + for )`. I have that in my dzEvo project for single click operation on the children's bedrooms which are not supposed to be heated all night but should be at a comfortable temperature when it is time for them to turn in.

As for the sequence in the opening post, that seems right on the money to me. With the remark that the HR92 will not wait for the next 5-minute slot to send commands to the controller and of course when it does there is communication so it can receive new commands at that time as well.

Opentherm is actually not supported by the controller. It's a hardware module that can be paired with the controller (touch or round) to replace the normal on/off operation through a BDR92.

[DBMandrake]

Thanks
so presumably If I set it to be a 'given temperature' until a 'given time' this will create a new setpoint..

Setting an override to a specific time is essentially a dynamically created set point change yes - at the end of the override period the set point changes to whatever the schedule would normally be at that time.

however is the flow roughly as I described..
does the controller wait until the HR92 next communicates before giving it a temperature.

Both controller and HR92 can initiate communications depending on the situation.

Most of the time the HR92 is sleeping, it then wakes up and "listens" for communication from the controller about every 3 1/2 minutes. (Actually the sleep time is not hard coded, but controlled by a message sent from the controller in the previous cycle, but it always seems to use about the same length of time in current firmware versions...)

So any set point change initiated at the controller or phone apps must wait until a communications window where the HR92 wakes up before it can be sent or the message would be ignored. This is why it takes anywhere from a few seconds to nearly 4 minutes for a set point change from the controller to be recognised by an HR92.

Set point changes made at the HR92 on the other hand by turning its knob wakes it up immediately and sends the change to the controller within a few seconds, as the controller is always listening. So there is very little delay in that direction.

and does the controller then tell it when the next setpoint is reached, I'm guessing the HR92 doesn't have its own clock.. or does it?

The HR92 has no concept of an override time period - when you do a timed override the controller sends a set point change at the start of the override period and then sends another set point change at the end of the override period. So a timed override is no different to you simply cancelling it manually at the controller after a period of time.

Also is it around once every 5 minutes communication occurs, or will this vary if the temperatures HR92 is reading are changing quickly etc.

As I described above, the set point comms from controller to HR92 is on a schedule - about 3 1/2 to 4 minutes, but as the sleep time is specified in one of the controller to HR92 messages it can vary - I think it does vary a small amount on purpose to provide a few seconds of staggering in different zones to help avoid a sudden burst of messages to all HR92's in the house over a short period of time.

Temperature readings from the controller to HR92 (for example relayed from wall sensors) are also sent at the same time as set point changes. In the other direction, the HR92 seems to vary how often it sends temperature sensor readings back to the controller - when the temperature is changing rapidly it sends temperature measurements more often - I've seen as often as every 30 seconds, while if the temperature is holding steady it can be 20+ minutes between temperature sensor transmissions from HR92 to Controller.

Heat demand requests from the HR92 to controller are sent a few seconds after the motor moves the pin position, which also occurs on the same approx 3 1/2 minute schedule. So during that communication window the controller sends an updated temperature sensor reading to the HR92, a set point change (if applicable) and the HR92 then makes a decision about whether to turn the motor to move the pin, does so, then sends back a new heat demand then goes to sleep until the next cycle.

Temperature sensor readings sent back to the controller from the HR92 seem to be asynchronous to the above cycle. Temperature sensor readings are sent as unacknowledged broadcast messages, so the HR92 probably just wakes up, sends a temperature sensor reading then goes back to sleep again immediately.

[Stevedh]

Thanks DBMandrake for that detailed explanation