Simultaneous Heating and Cooling: The Fault That Never Alarms

There is a category of fault that will never page you, never show red on a graphic, and never generate a complaint. Occupants are comfortable. Equipment runs. Every point reads normal. And the building is burning a substantial share of its energy budget heating air it just finished cooling.

Simultaneous heating and cooling is the most expensive fault most technicians never look for, precisely because nothing in the system is designed to tell you about it. Comfort is the metric the BAS was built to defend, and comfort is being delivered. The waste is invisible by design.

Why nothing alarms. An alarm fires when a value leaves a range someone defined. Nobody defines a range for “the reheat valve and the cooling valve are both open.” It isn't out of range — each valve is doing exactly what its own loop asked for. The fault only exists in the relationship between two points, and almost no standard alarm looks at relationships.

Finding it: the three-day trend

You don't need analytics software or an energy audit to find this. You need three points and a weekend.

What to trend

Heating valve command (or reheat output)
Cooling valve command
Discharge air temperature

Set the interval to five minutes and let it run for three days. Five minutes is fast enough to catch real overlap and slow enough that three days of data stays manageable. Three days gets you at least one occupied/unoccupied cycle and, if you're lucky, a weekend.

What you're looking for

Any period where both valves show open at the same time for more than about fifteen minutes. Brief overlap during a changeover is normal and expected. Sustained overlap is not — that's the building actively working against itself.

Don't skip the discharge air temperature. The two valve commands tell you what was asked for. Discharge air tells you what actually happened. If both valves read closed but discharge air is climbing with no call for heat, you're looking at a leaking valve rather than a control problem, and no amount of programming will fix it.

The four causes, in order of how often you'll find them

Valve scaling inverted

The valve reads 100% when it is actually closed, or 0% when it is actually open. The loop is behaving correctly and the feedback is lying about it. This is the most common cause and the easiest to confirm: command the valve to a known position and physically look at the stem.

Normally-open programmed as normally-closed

A normally-open valve wired and programmed as if it were normally-closed sits fully open at zero signal. Everything about the sequence looks right on screen. The valve has simply been passing hot water since commissioning.

No deadband between heating and cooling

If the heating loop's upper limit and the cooling loop's lower limit touch — or overlap — the zone will chase itself around setpoint with both outputs modulating. A small deadband between the two is what stops this, and it is very often missing or set to zero.

Valve leaking through

Mechanical, not a controls problem, but it lands on your ticket anyway. A valve commanded fully closed that still passes flow will produce exactly this signature. Discharge air temperature is what separates this from the three causes above.

Why commissioning didn't catch it

This is worth understanding, because it explains why the fault is so widespread in buildings that were properly commissioned.

Commissioning and test-and-balance typically verify a sample of units — often somewhere in the range of a third of the installed equipment, not all of it. On a building with two hundred VAV boxes, that leaves a lot of boxes nobody ever functionally tested. If a valve was scaled backwards at the factory or programmed wrong from a copied template, it goes into service that way and stays that way.

The template problem. Controls programming is copied. One box gets configured, and that configuration is duplicated across every similar box in the building. This is efficient and it is also how a single mistake becomes two hundred mistakes. When you find one inverted valve, check its siblings before you assume it was a one-off.

What to do when you find it

Evidence	Most likely cause	First action
Both valves commanded open, sustained	Missing or zero deadband	Check the loop setpoints and separation between heating and cooling
Valve command and physical position disagree	Scaling inverted or NO/NC mismatch	Command to a known position and physically verify the stem
Both commanded closed, discharge air still rising	Valve leaking through	Mechanical — the valve needs service or replacement
One box only	Individual configuration error	Fix it, then check boxes configured from the same template
Many boxes, same signature	Template copied with the error in it	Fix the template, then re-verify every box built from it

The bigger lesson

Everything about this fault is a specific case of a general problem: the front end reports what it was told, not what is happening. Both valve points are “working.” Both loops are “correct.” The graphic is green. And the actual physical reality — hot water and chilled water meeting in the same duct — appears nowhere on any screen because no single point describes it.

The habit worth building isn't memorising this one fault. It's asking, on any system you inherit, which physical realities have no point representing them — and then trending your way to an answer.

Go deeper

The method behind this, chapter by chapter

Every sensor, drive and control loop in the building — how it works, how to prove it with a meter, and how it fails. BAS Field Fundamentals is the method this article uses, with 20 field cases and a browser diagnostic simulator to practice on.

Get BAS Field Fundamentals

Found a wrong number or a broken link? Tell me and I’ll fix it.