When a Fault Code Doesn't Tell You What's Actually Wrong

A real-world no-cool call that reinforced why fault codes are clues, thermostat history matters, and measurements still have to tell a complete story.

Fault codes are useful. I like having them, especially on communicating equipment where the system can give you information that would otherwise take a while to uncover.

But a fault code still isn't a diagnosis.

I was recently on a no-cool call involving a relatively new communicating variable-speed heat pump system. When I got to the indoor equipment, the customer immediately pointed out a flashing light on the control board.

The board was displaying a Code 4, and naturally the first question was:

"What does that mean?"

Normally, with a communicating system, I would go to the thermostat first. I want to see what the system is reporting, check for any active faults, and look through the fault history before I start digging into individual components.

That wasn't how this call started.

The customer was pretty focused on that flashing board and wanted to know what the 4 meant. Since that was what had their attention, I decided to start there and see what the system was trying to tell us.

Looking back, that decision became part of what made this call worth writing about.

Starting With Code 4

I pulled up the service information instead of relying on memory.

The Code 4 indication pointed me toward a general issue involving the electronic expansion valve, or EEV.

It wasn't telling me:

"The EEV is bad."

It was telling me:

"Something related to this part of the system needs your attention."

That is an important difference.

So I started with the EEV stepper motor and checked the windings.

EEV stepper motor check

Result: All four readings were consistent. I wasn't seeing an open winding, and nothing in those resistance measurements gave me a reason to condemn the stepper motor.

That didn't mean the entire EEV system was automatically cleared. It meant I had tested one part of it, and the numbers weren't supporting an obvious electrical failure.

So I kept going.

Running the System

From there, I went to the communicating thermostat and put the system into test mode.

Once it started running, I noticed the evaporator beginning to frost.

That changed things for me.

Now I had something physically happening in front of me that needed to make sense with the fault I had just been chasing.

I checked the thermostat for active alarms.

Nothing.

Then I went into the alarm history.

That was when I found the clue I probably should have looked for first.

The system had recorded a low-pressure fault approximately a week earlier.

That caught my attention.

The low-pressure fault wasn't active when I arrived, but the customer was still dealing with the same cooling problem. The equipment may not recreate the same fault while a technician is standing there. Load, capacity, outdoor conditions, and runtime can all be different. The fault may be gone from the active screen while the underlying problem is still there.

The equipment had already seen low pressure. It had already recorded it. I just hadn't asked it for that information yet.

This Is Where I Would Change My Process

This is probably the part of the call that stuck with me the most afterward.

I don't think checking the EEV was wasted time. I got useful measurements from it, and those measurements helped me determine that I didn't have an obviously open EEV motor winding.

But if I walked into this exact call again tomorrow, I would change the order.

The customer pointing out the flashing board was still valuable information. Customers notice things, and sometimes what they tell you ends up being one of the best clues on the call.

The lesson for me wasn't to ignore what the customer says. It was to take what they give me and then use the system's own diagnostic information to decide where I go next.

The Refrigerant Readings

With the previous low-pressure fault in mind and the evaporator beginning to frost, I moved to the refrigeration side.

I connected my pressure and temperature probes and ran the system in cooling.

Refrigeration snapshot

At that point, the numbers were telling a much different story than "replace the EEV because the board flashed a 4."

Nearly 90°F of superheat is an extremely starved evaporator. At the same time, I had essentially zero subcooling.

I now had:

• a no-cool complaint,
• an evaporator beginning to frost,
• a previous low-pressure fault stored in the communicating system,
• EEV motor windings that measured consistently,
• very high superheat,
• and basically no subcooling.

Those clues were starting to line up. The operating conditions supported a system that was significantly short of refrigerant.

The Diagnostic Path

1. Code 4 pointed toward an EEV-related condition.
2. Approximately 47 Ω across all four windings showed no obvious open stepper-motor winding.
3. Evaporator frosting showed a physical condition that still needed an explanation.
4. Thermostat history revealed a previous low-pressure fault.
5. 89.2°F superheat and 0.2°F subcooling showed a severely starved system.
6. Refrigerant shortage was suspected, so a complete leak search became the next recommendation.

The Board Wasn't Necessarily Wrong

One thing I don't want this article to suggest is that the board gave me a "bad" code.

The control system saw something it didn't like and pointed toward the EEV/refrigeration side of the system. That information was useful.

What would have been wrong was taking that information and immediately turning it into a parts diagnosis.

That is where technicians can get into trouble with fault codes. We see EEV fault, and it is easy to mentally turn that into bad EEV. Those are not the same statement.

The valve, refrigerant condition, sensors, control logic, wiring, operating conditions, or something else affecting that circuit can all influence what the control is seeing.

The code is one piece of the story. The measurements still have to make sense.

Low Refrigerant Still Isn't the Final Diagnosis

Once I saw the refrigeration readings, I had good evidence that the system was significantly short of refrigerant.

But I still don't consider "low on refrigerant" to be the final answer.

If a sealed refrigeration system is missing a significant amount of refrigerant, I want to know where it went.

Simply putting refrigerant back into the system might change the pressures and get the house cooling again for a while. That doesn't mean the problem is fixed.

My recommendation was a complete refrigerant leak search:

1. Find the source of the loss.
2. Determine what needs to be repaired.
3. Complete the repair.
4. Properly evacuate and recharge the system.
5. Verify operation according to the manufacturer's requirements.

That is a very different repair than: "It was low, so I added some refrigerant."

Putting the Call Back Together

This wasn't some impossible diagnostic problem. What made it useful to me was looking back at how the information came together.

The customer gave me the first clue by pointing out the flashing board. The board gave me a Code 4. The service information pointed me toward the EEV. The resistance measurements told me the EEV motor windings were at least electrically consistent. The evaporator started frosting. The thermostat history showed that the system had experienced low pressure about a week earlier. Then the gauges and temperature probes showed 89.2°F of superheat and 0.2°F of subcooling.

Not just one of those things told the whole story.

Together, they did.

What I Took Away From It

If I see another communicating system tomorrow, I'm still going to listen to what the customer tells me. I'm still going to look at the flashing lights and fault codes.

But I'm going to make sure I use the system the way it was designed to be used.

Check the thermostat.

Check active faults.

Check the history.

Then start testing what the evidence points toward.

That is probably the biggest thing I learned from this call.

The EEV test wasn't wasted. The fault code wasn't useless. The customer wasn't wrong to point it out. I just could have put those pieces together in a better order.

And that is part of getting better at this trade.

You finish the call, think about how you approached it, and ask yourself:

If I walked into that exact same problem tomorrow, what would I do differently?

For me, the answer on this one is easy.

On a communicating system, I'm going to let the system tell me what it has already seen before I decide what the first fault code means.

The board had a clue. The thermostat history had another. The evaporator had another. My probes had another.

My job was to put them together instead of letting the first code decide the answer.