3150: Zone Heat Demand

WIP - Heat Demand

Each evohome zone (except for Electric Heat zones) will 'demand' heat and - broadly - the further the current temperature is below the desired setpoint, the greater that demand will be.

The exact mechanism for this is somewhat complex:

• each zone consists of a single temperature sensor, and a collection of actuators (e.g. a TRV)
• each actuator has the opportunity to see how far it is behind the setpoint - it will use it's own temp sensor if it has one
• each actuator will tell the controller their personal heat demand (a number between 0-200)
• the controller considers the heat demand of a zone to be the greatest of all demands for that zone - this is reported in the evohome UI (see NB, below)
• the controller calls-for-heat from the heat source (e.g. a combi boiler, or district heating) according to the greatest heat demand of all zones

(Question: what if the sensor temp is above the setpoint, but a actuator is still demanding heat?)

The specifics of the final step depends upon if you have OpenTherm (OTB), which uses modulation (varies the temperature of the hot water circulating around the heating system) or a Boiler relay (BDR), which uses TPI (varies how often per TPI cycle that water is heated and circulated around the system).

Note: the relationship between heat demand (the number between 0-200) is not the same as that in the evohome UI - the relationship is a non-linear function.

Heat Demand

The 3150 packet is a request for heat, sent to the controller from a sensor (e.g. TRVs, thermostats). It is used to calculate the net demand from a zone.

Compare this with a 0008 packet, which is an instruction from the controller to an actuator that can relay a 'call for heat' to a device which can provide that heat (e.g. a boiler, or an electric radiator).

The controller could ignore or moderate this 3150/request into a 0008/call for heat (e.g. evohome's 'Optimum Stop' feature).

Payload structure

Payload decode:
Zone/Device	[0:2]	zone_idx or domain_id (F9=CH, FA=DHW, FC=Boiler control)
Demand	[2:4]	Heat demand (0-200)

Analysis

Below are actual packet logs captured from a live system (any blank lines have been added for readability).

Using cat packets.log | grep ' 3150 002 FC':

10:48:42.403 057  I --- 01:145038 --:------ 01:145038 3150 002 FC7E
11:08:43.784 060  I --- 01:145038 --:------ 01:145038 3150 002 FC7E
11:28:44.768 065  I --- 01:145038 --:------ 01:145038 3150 002 FC7E

11:37:50.646 064  I --- 01:145038 --:------ 01:145038 3150 002 FC00
11:57:52.730 063  I --- 01:145038 --:------ 01:145038 3150 002 FC00
12:17:57.618 063  I --- 01:145038 --:------ 01:145038 3150 002 FC00
12:38:01.504 063  I --- 01:145038 --:------ 01:145038 3150 002 FC00

12:39:30.228 063  I --- 01:145038 --:------ 01:145038 3150 002 FC3E

This demonstrates two behaviours from the controller: a) whilst there is no change in heat demand, it will send a 3150 announcement at the end of every 'cycle', and; b) it will send a 3150 announcement immediately whenever the demand has changed (see below).

The cycle_rate is a system parameter, either 3, 6, 9, or 12 cycles per hour, corresponding to a 20, 10, 7.5 or 5 minute cycle. See code 1100 for more detail.

Using cat packets.log | grep ' 3150 ':

02:57:53.978 000  I --- 01:145038 --:------ 01:145038 3150 002 FC00

03:03:14.022 000  I --- 04:056057 --:------ 01:145038 3150 002 0300
03:04:43.242 000  I --- 04:056059 --:------ 01:145038 3150 002 0100
03:04:44.166 000  I --- 04:056053 --:------ 01:145038 3150 002 0100
03:05:25.484 000  I --- 04:189082 --:------ 01:145038 3150 002 0400
03:11:00.224 000  I --- 04:189078 --:------ 01:145038 3150 002 0600
03:11:31.304 000  I --- 04:056061 --:------ 01:145038 3150 002 0000
03:16:19.423 000  I --- 04:189080 --:------ 01:145038 3150 002 0500
03:17:24.419 000  I --- 04:189076 --:------ 01:145038 3150 002 0200
03:17:58.161 000  I --- 01:145038 --:------ 01:145038 3150 002 FC00

This is a normal (20 minute) cycle with no change in demand from any of the TRVs. Every sensor informs the controller of their demand every cycle, and in this case, there are two TRVs in zone 01.

Using cat packets.log | grep 3150 | grep -E '(056059|056053)':

18:46:25.283 042  I --- 04:056053 --:------ 01:145038 3150 002 0162
18:49:26.917 044  I --- 04:056059 --:------ 01:145038 3150 002 0154
18:54:27.530 041  I --- 04:056053 --:------ 01:145038 3150 002 0158
19:09:24.738 045  I --- 04:056059 --:------ 01:145038 3150 002 0154

Even though these devices are in the same zone, their head demand do not have to match.

Using cat packets.log | grep ' 3150 ':

19:11:58.754 061  I --- 04:189080 --:------ 01:145038 3150 002 059E
19:12:00.572 087  I --- 04:189082 --:------ 01:145038 3150 002 0486
19:12:01.912 059  I --- 01:145038 --:------ 01:145038 3150 002 FC9E

19:12:24.347 043  I --- 04:056059 --:------ 01:145038 3150 002 0148
19:12:34.696 082  I --- 04:189076 --:------ 01:145038 3150 002 0228
19:14:24.388 042  I --- 04:056053 --:------ 01:145038 3150 002 0158
19:15:26.383 061  I --- 04:189080 --:------ 01:145038 3150 002 0500
19:15:26.846 060  I --- 01:145038 --:------ 01:145038 3150 002 FC86

19:15:35.122 082  I --- 04:189076 --:------ 01:145038 3150 002 021C
19:15:54.912 086  I --- 04:189082 --:------ 01:145038 3150 002 047A
19:18:11.563 060  I --- 04:056061 --:------ 01:145038 3150 002 0000
19:21:36.656 082  I --- 04:189076 --:------ 01:145038 3150 002 0200
19:22:29.631 056  I --- 04:056057 --:------ 01:145038 3150 002 0300
19:32:04.951 081  I --- 04:189078 --:------ 01:145038 3150 002 0614
19:32:24.788 043  I --- 04:056059 --:------ 01:145038 3150 002 0148
19:33:53.773 083  I --- 04:189082 --:------ 01:145038 3150 002 0400
19:33:54.012 058  I --- 01:145038 --:------ 01:145038 3150 002 FC58

Notice that: when the demand for zone 05 drops from 9E to 00, the demand for FC immediately falls from 9E to the next highest, 86, from zone 04. Later, zone 04 falls to 7A and nothing happens (?dropped packet?). Finally, zone 04 drops to 00 and teh next highest demand used forFC is 58, from zone 01, but from one cycle previous.

UFH

Note the array (spaces added for readability).

19:44:06.176243 056  I --- 02:001107 --:------ 01:187666 3150 002 0026
19:44:06.351438 056  I --- 02:001107 --:------ 02:001107 3150 010 002A 012A 022A 0326 0426
19:44:42.593814 056  I --- 02:001107 --:------ 02:001107 3150 002 FC2A