It’s Always A Controls Issue.

I spent five years in my apprenticeship hearing that phrase from the HVAC techs at least twice a week. It was the running joke — that, and the idea that our only tool was a pocket screwdriver. Even the instructors would pile on. The boiler’s not running? Controls issue. The air handler can’t make static? Controls issue. Your fantasy football team is losing? Ok, that one might not actually be a controls issue.

By this point in time, the joke has been repeated often enough that a lot of HVAC techs have internalized the “controls issue” line as truth. If you haven’t noticed it yet in your career, you will.

The Curious Case of the ‘Broken’ Controller

When I was working as a service technician, one of the most common calls I got was, “Communication to this controller is down.” And most of the time… it was. I’d stroll into the building with my eight-foot ladder, awkwardly sidestep someone half-holding the door for me, then head off to pop a ceiling tile and investigate this “broken” controller.

Nine times out of ten, you know what I found? No power. Of course it wasn’t communicating with the system — it wasn’t even on. My oven doesn’t cook mozzarella sticks when it’s off either.

Being the thoughtful tech I am, I’d pull out my meter, do some digging, and usually come back to the mechanical contractor with the news: they had a blown fuse or a tripped breaker somewhere in their system. I was just the messenger who happened to own a multimeter — all because the first sign of trouble showed up in the controls system.

Why Controls Gets Blamed

So why does it always play out this way? Why is it that, even though half the time all we do as a controls contractor is provide visibility into a system — or we’re just one part of its overall operation — we’re still the first ones in the hot seat?

1) We Touch Everything

If you’ve been in this trade for more than a week, you’ve probably figured out that being the controls contractor means having a baseline understanding of almost every system in the building. HVAC, lighting, power monitoring, plumbing, process systems, un-process systems — we do it all. That wide reach makes the building automation system’s role look bigger than it actually is, which means when something goes wrong, we’re suddenly “part of the problem.”

2) We’re the Most Visible

When something goes wrong, the building engineer doesn’t grab a wrench — they check the BAS first.

• Alarm? Comes from the BAS.

• Service request? Investigated through the BAS graphics.

• Need trend data to see if the system has capacity for a project? Call the controls contractor.

We provide the window into the system, so the perception quickly becomes that we are the system.

3) Sometimes, Yeah… It’s Us

No one’s perfect. Well, maybe you are, but the rest of us mere mortals make mistakes. Sometimes we have to go back and fix programming, replace a dead controller, swap out a bad sensor, or troubleshoot an actual logic issue. Things break — it’s part of the job. And when that happens, we’re usually the most qualified (and fastest) to fix it.

Fine then. The council has convened and, with or without our input, it’s our fault. What does that mean for you?

Building Automation or Flex Tape(Bandaid Approach & Problems)

Picture this: your latest project is a boat. It’s cruising along just fine until water starts pooling at your feet. The boat’s got a leak! Luckily, you’ve still got that can of Flex Tape from that night you stayed up watching late-night infomercials, and you slap some of that magic tape on the hole. Problem solved… for now.

That’s controls in a nutshell. We’re often not the ones driving the boat, we’re the Flex Tape. Something’s broken? “Just slap some controls on it!”

I’ve been there. You’ve been there. We didn’t make the hole in the boat.

Here’s a recent example: a mechanical contractor’s drawings showed the isolation valve for some boilers on the outlet instead of the inlet. During startup, the boilers kept tripping on low-water cutout alarms. Why? Because the pumps were pulling water out of the boilers. The obvious fix? Move the valves. The actual fix? Program around it in the BAS.

So what’s the problem?

You’re not fixing the problem — you’re covering it up. The hole in the boat is still there, you’ve just put a bandaid on it. Sure, it keeps things running for now, but it builds long-term risk:

• The bandaid becomes “the solution” and the root cause is forgotten.

• The bandaid solution can lead to system inefficiencies, increasing long-term costs.

• The bandaid often adds system complexity, making future troubleshooting slower and more expensive.

Sometimes the right answer is the hard one: drain the system, move the valves, and do it right. And no, I’m not still bitter about it. Probably.

You, the Bandaid

You may have noticed that even though I’m preaching about providing the “right” solution for the customer, I still ended up re-programming that hot water system. The reality is, as much as we should aim for the permanent fix, we’re not always the ones calling the shots. Sometimes, you are the bandaid. It’s a part of the job—there’s no avoiding it entirely.

The difference between a good bandaid and a bad one? A good bandaid doesn’t just cover the problem; it leaves a trail for the next person to follow. Make it clear that programming around a problem isn’t the proper fix. Be vocal. Document it. Leave notes on your as-builts, your graphics interface, the inside of the port-o-potty—anywhere it will be seen.

Because a bandaid might keep things running for now, but the story you leave behind can be the difference between a quick, informed repair… and an expensive game of guess-and-check.

Your Turn

So, what about you? What’s the most ridiculous “controls fix” you’ve ever had to pull off for a problem that wasn’t really controls at all?

Join the mailing list and share your wildest bandaid stories with me — I’d love to swap war stories and lessons learned. Who knows? Your experience might help someone else avoid the same pitfalls!