Potential for total load vs component load discrepancies

[shorowit]

In some less common situations, it is possible for there to be moderate discrepancies between the total heating (or cooling) load and the sum of its components loads after A) changing the component load methodology and B) using a temperature capacitance multiplier (TCM) of 7.

For example, with this HPXML, you get a situation like so:

(The first option in the list is cases with a TCM=1, second is TCM=7.)

Note that the cooling setpoint is equal to the heating setpoint (other than during setbacks) for this home. During the 5F heating setback, the indoor temperature remains closer to the cooling setpoint for a period of time w/ TCM=7 and thus the component energy transfers are assigned to cooling instead of heating. (If the cooling setpoint was even just 1 degree higher, it would prevent the issue -- for this home anyway.)

Perhaps some additional sophisticated component load logic could prevent this, but need to be careful that it is robust and works for many different situations.

cc @jmaguire1 @aspeake

[shorowit]

Maybe something like.... if the heating setpoint decreased in the past hour (?) and indoor temperature is trending downward, assign to heating (because there would have been a heating load if not for the heating setback). And vice versa for cooling.

We should probably avoid using e.g. outdoor temperature in the logic. (For example, it could be 40F outside, but if you have a high performance home with lots of solar gains, you could easily be cooling.)

[jmaguire1]

Mild temperatures are also a problem if we just use OAT. That was my first inclination, but Scott talked me out of it. Too many potential issues.

The actual EMS program here might get tricky, I think you'd need trend variables to know that the setpoint changed 30 minutes ago if you want to want to use this approach with subhourly timesteps, and that could get to be kinda onerous with say 1 minute timesteps.

Still the best idea I can think of now, but when we revisit this I'll do some more brainstorming on how we might approach this.

[shorowit]

You could probably use a global EMS variable that stores the time of the year when the setpoint last changed, and then compare the current time of the year to that to see if more than e.g. an hour has elapsed. That should allow one to avoid using a trend variable.

[aspeake]

Maybe something like.... if the heating setpoint decreased in the past hour (?) and indoor temperature is trending downward, assign to heating (because there would have been a heating load if not for the heating setback). And vice versa for cooling.

We should probably avoid using e.g. outdoor temperature in the logic. (For example, it could be 40F outside, but if you have a high performance home with lots of solar gains, you could easily be cooling.)

This sounds like the most robust approach to me. Instead of relying on the trend of the indoor temperature, maybe we just maintain the original setpoint average (70F in your example) as the threshold for 1 or 2 hours after the setback, so if it is trending downward then it is a heating load, since it is < the original TSP average.