Hey folks, Phil Zito here and welcome back! Today, we're going to be kind of stepping a little bit out of where we have been in the past, which has been sales, retrofits, and technology. Now we're going to be diving deep, for at least the next nine sessions, into integration.
For a lot of you, integration is something that is challenging. I was in our live office hours for our students last Friday, and I said something to them, and I hope this doesn't come across as offensive:
I am surprised as an industry how much we still struggle with integration. How much it seems like, every time I talk to someone, and I bring up the word integration, I get groans and I get eye rolls. It's doesn't have to be that way. Integration, in and of itself, really isn't that difficult, but I find that people don't have a process and, I was guilty of this, where you just kind of change settings until it works, and then you're like, “Hey, don't touch it, it's working now. Leave it alone.” There has to be a better way!
That is what we're going to look at over the next several, probably like 9 to 12, blogs. As always, everything can be found at blog.smartbuildingsacademy.com. If you find my process interesting, if you find the integration process interesting, then I encourage you to check out our MSI in a Box course.
So today, we are going to take up, arguably, the most common integration outside of HVAC equipment. Obviously, the most common integration would be integrating other building automation controllers, followed by integrating HVAC systems. Outside of that, the most common, in my experience, has been lighting, and there's a lot to lighting integrations.
So, the first thing I want to do is talk about the structure of a control system. It's my belief that if you understand the structure of a control system and how the structure and frameworks are universal, despite the different types of systems, that you'll find integrating systems a little bit easier.
So, lighting, audio-visual, access control, parking management, work order management, all of these systems are fairly similar in their architecture. When I say architecture, I'm talking about their physical architecture, meaning that majority of them have a server. They have a supervisory device, they have field controllers, and IO.
You may be saying, “Okay, what does this look like in lighting?” Well, in lighting, we have a lighting server, and then from that lighting server, we go to lighting control panels. Now, these may be control panels, these may be little controllers on the ballasts themselves. It's kind of like a three-tier IP architecture without the IP in some cases.
Then, from there, we have our IO. Our input would be our light switch, that turns things on and off, and our output would be our light, and those are controlled by the lighting controllers. Now the lighting controllers themselves could be very simple on/off lighting controllers. They could be everything from multiple dim levels, lighting zones, etc.
So, when I look at any system, lighting, audio-visual, or access control, I know access control has card readers that are an input. It has locks that are the output. It has the card controller, that has the supervisory device, that has the server side. With audio visual, it has touchscreens, projectors, room controllers, the main supervisory controller, and the server. These are all tied together.
The first thing I want to think of whenever I am working with any kind of integration, and specifically lighting integration, is, what is my point of integration? This is going to be key. When we are integrating with other controllers, we're often just consuming data and adding them under the purview of our existing control system.
So, when we are integrating existing BAS controllers, we are basically integrating them and making them part of our BAS system, and so they're controlled by our BAS system. When we're doing these third tier, like lighting control, audio-visual control, access control, etc, we're actually deciding at what point do we integrate, and we have to decide what system takes control.
I'm not going to repeat this every time we go through a new type of integration. But this is kind of core knowledge. So if you don't get this, you're not going to understand basically anything else throughout the entire series.
So, for example, the lighting server, that's most likely going to have zone control, different levels of control, lighting, and the warmth of the light. Based on that, you can control that, possibly through integration. Or, you can have the lighting system control that. So, we have to figure out what system is taking charge.
This is where I see a lot of integrations go wrong when we get outside of HVAC & BAS. We never firmly sit down. We get a plan and spec job, maybe a design build job if we're lucky.
We get a spec, and it says to integrate the lighting system. It says to, “look at the related section,” which is lighting control. The lighting control section has a sequence and then the control section has a sequence that maybe says “integrate lights, turn on lights based on occupancy.” But then it doesn't declare who controls the lights. Do we control them through the UI? Which system takes priority? If something is scheduled in the lighting system, does that take priority? If something scheduled in the BAS system does that take priority?
So, the process, which we'll cover in the next blog of actually implementing these lighting integrations, becomes very dependent on, what are we doing from a “who's on first” perspective. What system is in control? So that's our first primary question, “what system is in control,” then once we know what system needs to be in control, then we can decide at which point we want to integrate.
If we know the BAS system is going to be taking full control of the lighting system, then we can integrate to the ballasts themselves, if possible, or maybe through the server. However, we will be writing if the lighting system supports BACnet at a higher priority. So that way, we overwrite whatever the lighting system is doing, because we are taking primary control. Now flip that, if the lighting system has primary control, we'll be writing at a lower priority so that the lighting system can reflect that.
Now, the challenge becomes when this isn't properly communicated to the customer, and the customer has a lighting server with a control screen in a closet. Then they have the lighting control on the BAS graphics, and they're trying to change the lighting control and the BAS graphics, but it's instantly being overwritten by the lighting control from the server because the lighting system has primary control.
So, if you're not able to communicate this, and identify this, you're going to get a lot of warranty calls and a lot of issues. I mean, this is true of access control, audio-visual, lighting, parking management, etc. So, we just need to be cognizant. First off, what system is in charge? Then, we have to find a way to communicate that information to the end user, so they understand what system is in charge.
So much of integration is balancing out “what system is in charge?” How do we communicate that to the customer? But then there's this third thing, and it I find it to be not so true for access control, but definitely true for lighting and audio-visual control. It's the mismatch of data types and data structures.
So, for example, you have an HVAC system, and that HVAC system has a thermostat, and that thermostat is serving temperature data to multiple VAV boxes. So, you have multiple VAV boxes, or maybe you have a single VAV box with multiple diffusers going into multiple spaces. What happens is, you have this space concept. I am in HVAC controlling spaces, Space 101 Space 102, whereas in lighting, and somewhat in audio visual, you are taking a zone approach.
You may have a lighting zone that stretches across multiple spaces. This is where we start to get into more advanced control. I see people begin to mess up the integration. As an integrator, it's not only your responsibility to understand the sequence, it's not only your responsibility to understand what system is going to be in charge, but it's also your responsibility to understand how do I align up objects and how do I align up devices? This is so that when I am controlling Lighting Zone 101, which actually overlaps spaces 101, 102, and 103, that I am reflecting that in the graphics, tying to systems properly, properly executing sequences, etc.
Common examples of this would be having an open area with a lighting zone that stretches across that entire open area and maybe even covers some interior office space. Then you have HVAC systems where that open area is a space, and then the internal spaces are spaces as well. So, you have to do some data mapping and some data matchup, and this is something I don't see a lot of people do. Then they are wondering, “Hey, the lights are on, but the HVAC isn't on, or the HVAC is on but the lights aren't on.” And things get a little messy.
Alright, so those three key concepts:
- Understanding the sequence
- Understanding the structure
- Mapping data
Now let's get into the basics of lighting integration. Lighting integration is pretty simple, right? We have three primary ways in which we integrate:
- Direct hardwire integration, where we actually implement our own relays and we can make and break power relays to entire lighting circuits or to an individual fixture.
- Protocol integration, which may be Dolly, may be KNX, may be BACnet, may be LON, but it's some sort of protocol integration. With protocol integration, it becomes very important that we understand the data types, and we understand what priority these data types have. So, if we’re integrating ballasts and zone controls and lighting levels, are we getting full control over that, or is it being controlled at the server, and we're getting read and temporary overrides capabilities?
- API integrations which are becoming more common, but just realize that this is one of the more difficult ways to integrate for most BAS contractors, because they don't know how to write scripting. A lot of them don't have the capability to consume API's natively into their BAS yet, and so because of this, you have that issue.
You also have the issue of API deprecation and version management. So, you will upgrade your API version, and then suddenly, the functionality that's in that version gets deprecated which means it gets removed. Then you have to re-initiate your integration.
So, from a lighting perspective, the majority of the systems are going to be BACnet integrations here in the United States, overseas, it's going to be a little different based on where you are.
You are going to typically integrate directly to the server. That's the most common way when you are doing protocol integration. Typically, you are going to be dependent on whatever priority level is exposed to you from an integration perspective, BACnet’s a little more forgiving than others. That being said, the KNX and Dolly tend to have more capabilities because they are more total room control or lighting focused protocols, whereas BACnet is kind of a more general-purpose control protocol with read property, right property.
BACnet definitely has lighting objects, and I will tell you, in my experience at the time I last worked with lighting integrations, there weren't a lot of vendors who were supporting the lighting objects that come with BACnet. That may have changed, and I’m not professing to know every lighting system out there and every possible way to integrate every lighting system via BACnet. I will tell you that in my experience, it's been typically read and write property that you discovered and maybe device objects that you discovered, and this would typically be BACnet IP via the lighting server.
Now, we'll get more into actually implementing step-by-step as it's important to have a step-by-step process when it comes to integration. We'll see in the next blog how I talk about implementing lighting integrations, we'll look through three scenarios, a physical integration, a protocol integration and an API integration.
I encourage you, as we go through this series, we're going to be talking about a lot of integration. We're going to be talking about a lot of different systems. If you have a question, reach out using the form at the bottom of the page. Let me know if you think I should cover things differently.
There you have it, folks, the basics of lighting integration and the basic fundamentals of integration, in and of itself. If you found this fascinating and you'd like to know more, I encourage you to check out our MSI in a Box course, which is a full turnkey course on master systems integration work.
Thank you so much for being here. Take care!
