Hey folks, Phil Zito here and welcome back. Okay, so I've gotten a lot of questions and my team's gotten a lot of questions about how do I make this transition from HVAC to building automation? This is a really cool question because it is, in my humble opinion, a logical transition. You know, especially if you do residential HVAC, it takes a toll on the body. It starts to, you know, kind of break the body down, wear the body out, and I find that while building automation still gives you that physical experience, and you still get to work with your hands, you also can kind of reduce that wear and tear on your body.
In my opinion, it has a lot of areas you can branch out into. So, what we're going to be looking at today is why building automation? What are the core skills required for building automation? And then I'm going to put together three transition plans, because there is something that you have to factor in, which is this little thing known as money. For some people, that's important, most people it is. If you're going from a 20-year HVAC mechanic on the commercial side, even on the residential side, and you're transitioning into building automation, how can you do that with the least bit of monetary impact possible? I mean, the reality is, you're going to face some monetary impact, but how can you reduce that as much as possible?
So, we're going to look at three different transition plans. Some are going to have a bigger financial gap, others are going to have a very narrow financial gap but may take more time. So, it's kind of like which one do you want? Do you want to get there right away or do you want to kind of stretch this transition out and reduce the financial impact? We’ll look at three different models for that.
Before we dive in, I do want to point out that one of the key areas I would focus in on if I were you and you're an HVAC mechanic, or you employ HVAC mechanics and want to transition them into building automation, I recommend checking out our completely free Skills Assessment. When having these conversations, I usually direct most people to begin here. If they want to know how to transition from HVAC to BAS, the first thing I tell them is we need to identify what they know and what they don’t know. That right there is what’s going to affect your transition plan.
Okay, so why BAS? In my opinion, there are a lot of options for building automation. Let's say you're someone who is a mechanic, but on the side, you like to work with computers. Well, there are integrator options, there's programmer, there are developer options. Let's say you're someone who's artistic, and maybe a side hobby of yours is doing some form of art tattoos or drawing. You could be a designer. You could be a hardware designer or a graphics designer. There's a lot of things you can do.
The nice thing, in my experience, about building automation design, unlike mechanical design, a lot of mechanical design requires you to have a professional engineer license, whereas a lot of controls design still requires some technical skill. I'm not diminishing that, but you're interpreting engineered designs and then creating your submittals from that.
Then just on the physical side of things, let's be honest, controls work is physical. I mean, I remember being in Texas on roofs when it was 140 degrees, sweating, and coming home and just laying on the couch like I was dead. So, it is physical, but you're not hauling compressors on your back, you're not cutting your hands open trying to clean chiller tubes, and stuff like that. So, there is a different type of physical impact on your body.
Quite frankly, in my opinion, building automation, it's future proof. I will agree that HVAC is, in my opinion, future proof as well. It's very hard to outsource. The same thing with building automation, it's very hard to outsource. I will tell you, unless you've been under a rock, all of this discussion of sustainability, of energy efficiency, what directly impacts efficiency and sustainability? Building automation, right? Turning the temperatures down, reducing BTU consumption, reducing temperature loss, dealing with more efficient sequences, that's all building automation.
HVAC
So, what are these core skills for building automation? There are four core skills. The one that I really want to hammer here, because it often gets missed or assumed, is HVAC theory. People will say, I've been a mechanic for 5 years, I've been a mechanic for 10 years, and I’ll ask them, “Okay, do you know, HVAC theory?” They’ll say, Of course I know HVAC.” Then I’ll say, “Okay, tell me about how psychometrics works, tell me about heat transfer, tell me about ASHRAE 62.1, ASHRAE 90.1, ASHRAE 55, tell me about how a central utility plant can be used in a trim and response sequence. What is that HVAC theory?”
Sometimes I'll get great answers. I will say a good chunk of the time, I don't get great answers though because while folks understand, that this is a fan that blows air, this is a compressor, this is a coil, this is an actuator, this is damper, etc. What I find is, the system's thinking of how all of these things interact, that tends to not be as well understood.
When it comes to building automation, I've never changed a fan belt in my life, never changed a compressor, never changed a coil, and I haven't had to. Could I figure that stuff out if I had to? Yeah, I’m mechanically inclined, but I understand HVAC theory. I can look at a psychrometric chart and I can understand why mixing two air streams may actually result in a higher relative humidity than a lower. It's understanding this HVAC theory that is incredibly important for building automation. At the end of the day, the mechanicals are going to install the air handler, they’re going to install the chiller, and they're going to perform startup. They're going to make sure the compressors fire up, they're going to make sure that the refrigerant goes where it's supposed to go, and that air flows. Hopefully they check that the air flows in the right direction. But actually controlling it and implementing a sequence, that is often done by the building automation system.
So, understanding that theory is going to be very important for you to make that transition from HVAC to building automation. It's a different type of thinking. Now, your HVAC background will definitely help, but you have to understand that we're not as much concerned about the fact that you've changed belts or filters or done all sorts of things. We are more so, and I'm not meaning to simplify what HVAC mechanics do so I hope you don't take it as that, but we are looking for a different type of thinking in regards to HVAC.
Electrical
Next up is electrical. So electrical, a lot of mechanics understand electrical, they're good with it. But what I'm talking about is more so the electrical thinking in regards to low voltage, in regards to relay logic, in regards to safety circuits, etc. I'm not talking about, do you understand what three-phase is versus single phase? Do you understand what a capacitor is? Do you understand what a fuse is?
I mean, yeah, that's important, but we're more concerned about, why does the VA drop on a transformer when your controllers are activating a piece of equipment, and they're activating all these load devices? Why does that happen, but when they're not active, it doesn't happen? Those kinds of things. Why are certain safety circuits not working? What happens if you put your safety circuit on the automatic side of an HOA, and you don't put it on the common side of an HOA? So, all of a sudden, you put things in hand and no longer do your safety circuits work. So, that kind of electrical thinking.
IT
The big one I see for a lot of mechanics is IT. That's where I see a lot of folks get tripped up. I believe it's because if you go on LinkedIn, you see all these people talking about digital twins, analytics, prop tech, all this advanced technology. If you're a mechanic, and you look around, you could be pretty intimidated. You'd probably be saying to yourself, I'm not a programmer, I don't understand analytics. I don't get this IT virtual server, cloud, SAS stuff. I'm so freakin' confused.
But the reality is, is that you don't have to be this IT expert. There are specific things in regards to IT that you need to understand. First off, you need to understand how to turn on your computer. I know that sounds simplistic, but you need to understand, turn on your computer, your computer has physical ports, things like that. You need to understand basic networking, and you need to understand basic network troubleshooting and basic computer troubleshooting.
Once you understand that baseline, you should be able to do enough in building automation to succeed. Now, would it be beneficial to understand certificating, API's, firewalls, servers, virtualization, databases, etc? Yes, do you need to know that immediately? No.
BAS
Then obviously, our core skills for BAS, if you can understand BAS, that's great. That will really help when it comes to understanding BAS. Understand the parts and pieces, understand where to find the manufacturer documentation, understand the common architectures, and understand the control modes that you're going to be implementing. Understand basic inputs and outputs and basic point to point configuration.
Alright, so those are our core skills, right? HVAC theory, low voltage electrical, specifically around safeties and relay logic, IT specifically around computer use and networking, and then building automation around parts and pieces, around understanding different control modes, like sequence control, versus floating control, versus PID control, etc.
Transition Plan #1: Intercompany
Let's talk about transition plan. Transition Plan #1 is low salary impact, long time period, and I call it the intercompany transition plan. If you are a mechanical contractor, and you're not in some way, shape, or form, doing controls, I feel like that is a miss. There is a huge opportunity of unexecuted construction and service work due to companies not having enough people. If you find yourself in a situation with your mechanics where a job kind of finished up and they don't have the backlog, or a project hasn't spun up yet for them to do mechanical work, there should be a plan in place to do some form of either continuing service of your existing customers, or some form of controls, in my opinion.
Now, granted, I'm not saying you have a mechanical company, and you start taking on million-dollar controls jobs, that would be a bad idea. But to take on maybe a medical office building where they want someone to help service some basic control service, maybe that would be a good opportunity for you to have some potential load that you can place on your employees, so you keep them fully burdened, and from charging overhead.
So, this brings us to transition plan #1 which is intercompany. Now, what this looks like is, and I'll usually point to something like a Niagara or a Distech, something like that, where you have a large installed base, but it's not specific to an OEM branch. You can learn that and there should be a strong service base of opportunities that you can then go to. So, I do want you to be conscious of what is your service base? I tend to find service being the strongest place to initially do controls, because you can control what you respond to. You can say, there's no way we can troubleshoot a central plant that's not performing, but we could definitely help you to deal with alarms, trends and basic graphic stuff like that.
So, what this transition plan would look like, is looking at your existing install base, talking with your service manager or your construction manager, and saying, “Hey, I'm really passionate about controls. I think that this would be a revenue opportunity for us. I'm strong in HVAC, I'm strong in electrical, I'm strong in IT, and I want to find a way to work with you to potentially do work on these control systems.”
Now, if your mechanical staff or company already has a controls group, that makes it even easier. You just work with your manager to coordinate the labor shift. You'd say, if you're only 80% utilized, can you utilize me doing point to point checkout, something basic. So, you would initially start with point to point checkout, maybe controller mapping, maybe doing some basic graphics. And I know I'm saying basic, but that stuff is relatively basic in the scheme of things.
As you start to learn more and more about controls, one, you're going to see if you like the stuff and if you enjoy it. Two, you can gradually transition your labor shift. So, you can move from maybe 80% mechanical, 10% controls, and you gradually shift that to 15% controls, 20% controls, etc. Until you transition.
Now there are some things we have to factor in. Are you a union shop and is your controls team non-union? These are things that need to be thought about and we'd be remiss if we didn't address them.
So, transition plan #1 is intercompany. Now, it will take a much longer time period, because you're gradually taking on more and more controls work. But the nice thing about it is, there shouldn't be a significant pay drop. You know, if your company really needs some controls work done, they should be willing to tolerate a higher burdened rate individual, initially, and as you become more efficient, they possibly will consider transitioning you into controls, but keeping you at the same pay level. So, this is a way to avoid a pay drop off.
Obviously, as you can imagine, this would take a much longer period, because this is non-structured, this isn't something where you have a clear plan where you will learn this, this, and this. You're literally just taking on whatever they'll give to you, and you have to be very, very disciplined. You have to be very honest with yourself to evaluate what you know and what you do not know. How I like to do that is to get a job description of the controls person at your company, or at a similar company. Then I like to check off what I'm learning. So, I've done point to point and I feel comfortable with that, so I'm going to check that off. I've done controller mapping, BACnet/MSTP, trunk setup, I feel comfortable with them, check it off. And you just keep going down the list.
Transition Plan #2: Train While You Work
Transition plan #2 is train while you work. This is a mix of the two. It can possibly take less time, but it is going to cost you because you're going to use a training organization, maybe a company like our own, or maybe you go to some trade school that has a multi-year building automation program. You're going to work full-time and then you're going to train in your off hours. So, there's an opportunity cost here. In that, you're losing that time with your family, you're using that time to just do whatever.
Once again though, you're avoiding that cost impact, because you're going to train yourself, and then you're going to be better positioned to come to another company and say, “Look, I have an N4 cert,” or “I have this degree in controls,” or in the case of our company, “I have a certificate in Programming.” You're going to be able to then transition with less cost impact on the back end. You're going to have cost impact on the front end because you have to pay for training, but you should be able to transition at a similar pace structure.
Okay, so if you're a manager, and you're reading this, you're probably wondering, how do I implement this? Transition Plan #1 is typically what a lot of mechanical firms will do. Transition Plan #2 if you have a defined building automation role, or you're trying to grow a building automation business. It’s also another one that I see mechanical firms do.
Transition Plan #3: Right to Controls
Alright, Transition Plan #3 to jump ship and go right to controls. Now you are going to take a pay impact. I've seen very few people do Transition Plan #3 and take a not take a pay impact. I'll be honest with you, you're talking typically a 10-to-20% reduction in pay. I'm just being straight with you.
You have to weigh the pros and cons. These are the questions I would ask if you're going to do this:
- What kind of work am I going to be doing?
- What vertical markets am I going to be exposed to?
If you find out, you're leaving your company to go work somewhere and all they do is office building work where it’s packaged rooftop with VAVs, I wouldn't really consider that a good transition. The reason why is that what you're going to be exposed to is very simplistic. You're not going to be exposed to complex systems and complex integrations and complex projects, on average. Because of that, your value as a building automation employee is going to be in my opinion, low.
Now, if they said they do hospitals, data centers, things like that, I would say that is interesting to me. Those are both critical environments where you're going to be exposed to legacy and existing systems as well as new systems, very complex sequences. You're going to learn a lot really fast, which in my experience, and some folks will disagree with me, it is less important how long you've been doing controls and more important the level of diversity of projects that you've been doing.
If you tell me you've been doing 20 years at the same office building working on a single rooftop unit with VAV boxes, that is less impressive to me than working 2 years doing construction and service at hospitals and data centers, where you're going to get exposure to a lot of different systems. So really, you need to consider that because the name of the game is, going in there and understanding I'm picking a pay reduction for a year or two, but I'm going to make that up on the back end. Once I have experience with the data center, experience with the hospital, I'm going to be able to then market myself for darn near close to six figures. I mean, having an HVAC background as a mechanic with controls experience at hospitals and data centers, I mean, that's like golden ticket, especially if you can mix in programming and some integration. In today's market, you're talking about a high profit individual.
So how do we do this? I've given you three transition plans. What does this look like? Regardless of the transition plan, what I would really want to do if I were you is I would think logically from a controls architecture. Inputs and outputs are going to be your first logical point of experience. So, understanding different inputs and output types. Fortunately, there's usually four input types and four output types, right? We have binary inputs, resistive inputs, voltage and milliamp on the inputs. On the output side, we have voltage, milliamp output, volts DC, and then your internal/externally sourced outputs.
Once you understand those outputs, how to wire them up, when you use each one, how to configure, how to do point to point, you're looking pretty good. You have the input and output side, good to go. Now you've figured out, how do I set this up inside my software, you have the controller, good to go.
Now we move up to trunks. So, we've done inputs and outputs, we've done controller hardware, we move up to trunks, we start focusing on our MSTP and our IP trunks. How do you set them up? How do you configure them? What are their device properties? How do you then map them into a supervisory device, discover the controllers, and call it good?
So, now you have your inputs and outputs set up. You have your your controllers. You have your supervisory device and you're good to go. Now, we go from there and we talk about doing point extensions, we talk about graphics, inputs, we talk about program upload and download, and by that point, you should have a pretty solid foundation of BAS and you should be good to go on most BAS work as a contributor. Can't write programs yet, can't do designs, can't do much troubleshooting, but you should be a solid performer at least from a, “Hey, I can put this person on job and they're not just going to carry tools around all day” perspective.
Ok, with that being said, please reach out if you have any questions about this topic. I can’t always go into great detail about these topics, but I’m always willing to create another blog to help get that information out to you. I appreciate you being here.
Thanks a ton, and take care.
