Hey folks, Phil Zito here, and welcome back! Today, we are going to be continuing our series on integrations. We are going to be talking about implementing lightning integrations, and we're also going to discuss the three primary integration types and approaches.
So, this is critical. This is going to carry through to the rest of the series. No matter how many integrations we look at, we're going to be looking at the three ways of integrating for every integration.
So that being said, everything we discuss can be found at blog.smartbuildingsacademy.com. I encourage you to go there because our System Integration Guide can be found there, and that's a really good guide that covers the entire MSI process in great detail.
Additionally, you'll find a link to our MSI in a Box course which, if you're looking for master systems integration in a box, that is the course you're going to want. It will teach you the exact process from selling the integration idea to the customer, all the way to implementing, designing, and supporting integrations post-implementation.
Alright, let’s get started. There are three approaches to integration. Technically, you could say two because I will argue that the third approach is really more interfacing, and I’ll explain more about what that means.
In my mind, integration is where you take two or more systems, and you produce a different system by integrating them together. So, for example, if I take my lighting system and my building automation system, and I integrate them together, I now have functionally a new system. I've taken a building automation system, that may not have had lighting capabilities, and now I've given it lighting capabilities, or a lighting system that may not have had building automation capabilities, which is very rare, and have given it building automation capabilities.
The nice thing about doing this, through this integration process, is we are creating functionality. Now, you know, if you've read my past blogs, I'm an advocate for micro-use cases. I think that by and large, these massive 50 plus system integration use cases are:
- Overkill for a lot of customers;
- Very difficult to support from a legacy product perspective;
- Just logically don't make a whole lot of sense.
They are done more for ego purposes than actual use case and return on investment.
Interfacing
So, when we look at integrations, we're going to be looking at three primary approaches. The first is interfacing, and that is physical interfacing. In lighting, this would be us putting a relay in between the light switch and the ballast and being able to manually override. Or, putting a relay at the lighting power panel, and turning on and off that.
We've all seen this where the Facilities person goes into the closet and turns off the light switch and all the lights go off, right? Well, that is interfacing. We are interfacing with the lighting system, usually by using some form of 277 or 120 volt relay to turn on and off lighting circuits.
I say this is interfacing and not integration, because there's no real feedback. With integration, we're taking a system and we're making it a part of our greater system. With interfacing, we are adding another method of control, but that system still kind of stands on its own.
So interfacing is probably the most common form of “integration” that you will see across the board. You'll see this with access control, you'll see this with audio visual, and with fire alarm, where we are doing secondary monitoring and/or secondary control of these systems via physical interfacing. It’s the easiest thing to do, but it gives you the least capabilities.
Protocol Integration
Next is protocol integration. This is where I see a lot of people who struggle with protocol integration. This is for three reasons:
- They don't actually get involved with the protocol integration early enough to have the proper influence so that the gateway they're integrating to, or the settings that they require for integration, or the points lists, etc, are properly set up.
- They don't really understand the protocol, they don't understand what the protocol requires, as far as connectivity and what its limitations are.
- They don't understand the capabilities and limitations of the system they're trying to integrate. You could try to integrate a lighting system via BACnet all day long, but if you're not doing proper data shaping or data adaption, like we discussed in the previous blog, where it’s zones versus spaces, and you're not accounting for this, then it's not going to matter. Things aren't going to match up no matter what you do.
So, protocol integration, like I said, is our most common form of integration. As such, it is something we're going to spend the most time on here, especially for lighting when we get to other forms of integration. Other systems, there may be a more common way of integrating, like API's, in the case of audio visual or energy data.
However, in the case of lighting, protocol integration is our primary way. It's typically going to be, at least in the United States, via BACnet usually BACnet IP from the server. In the case of Europe, you may see KNX or Dolly.
So that being said, we're going to focus in on BACnet, but not in regard to its lighting objects. We are going to be assuming that we're using regular device objects, your regular analog input, analog value, analog output, binary input, binary value, binary output, etc, and your regular read-property and write-property services. Or, is there going to be our primary things that we're going to be integrating?
So, how do we do this? Well, the first thing we need to do is understand which system is in charge. Is it the lighting system or is it the BAS? Once we've determined that, then we can determine our point of integration. Typically, it's going to be at the lighting server level, or sometimes it'll be at the lighting gateway level.
Typically, we are going to have to purchase, or the lighting manufacturer is going to have to provide, an additional integration accessory. So, if I search, and I'll use Lutron as an example, for their quantum system, is I would type in Lutron BACnet PIC (Protocol Implementation Conformance).
This tells me all the things it supports. It tells me what it does support, what it doesn't support, and the different points that it has. Once I have these points, and once I understand what points and objects are available, then I can start to discover.
Ideally, this is done before you start executing, during the submittal phase of a project. The reason you do this is so that now I could say, “The sequence of operations in the specifications says I should be able to do this, but looking at the protocol implementation conformance statement, I could tell that it doesn't support those objects. So there's no way I can do that.”
Then you can submit a request for clarification and say, “Here is the protocol implementation conformance sheet. Here is the sequence. You can see these points don't exist. So, since these points don't exist, how do you expect me to do this?” This is where a lot of people get hung up on all forms of protocol integration, whether it's a chiller, an audio-visual system, a lighting system, etc, this is where they get stuck.
So, at this point, you need to check out your implementation conformance sheet for BACnet. If it's long, go check out your snippet list and all of your property lists there to understand what points are available to you.
Once you have that information, then you have to figure out, “I have the points list, I know the sequence, I've done some data adaption, so I know which zones match to which spaces.” Now, I can figure out the physical integration.
So many folks try to figure out the physical integration, but they get the data side of the protocol integration wrong. You know, like the BACnet, IP setting up the BBMD, the BDTs, device IDs, all that stuff, but then they don't account for protocol or for the data types.
So that being said, that's what I want you to focus on. Now, once you've got that information, then you can lay out your physical layout for the network. You can say it needs to be on this subnet, this switch, this IP address, this range, etc. You do the basic IP network stuff. Then once you've done that, it's just a matter of mapping the points in and writing your program according to the sequence of operations.
Programmatic Integration
This brings us to our third type of integration, which is programmatic integration. This is typically an API, or CoAP, or MQTT. There's a variety of different programmatic integrations. And when I say programmatic integration, what do I mean? I use that term very purposely. And here's why.
I have an API, an application programming interface, which is an interface that allows me to connect to the programming of an application and run functionality, or I have an MQTT feed, or I have a CoAP, and the CoAP and MQTT are usually JSON or stream. I have those outputs coming out. Now I have to decide what do I do with them, and this is where a lot of MSI’s (Master System Integrators) get hung up.
So basically, long story short, there's data that comes out of systems, in this case, lighting systems. It comes out of the data in a computer stream like ones and zeros that ultimately get formatted into streams of data. Your building automation system, most of them have no way to consume this data, because it's computer speak and our building automation systems speak protocols.
So, we have to use some form of scripting, to basically write a function, write a service, that is going to take the data from those data streams and convert it into protocol data, or some form of data that our building automation system can consume. This is why when folks ask me, “What should I learn in IT,” I say, “Basic networking and basic scripting.” Scripting is really important because with that information, with that knowledge, then we're able to do programmatic integration.
So, in the case of lighting, I would look to see if there's an API and I would look for what is known as a software development kit for the API. That SDK should provide a library of all the functionality and calls that the API supports. Then I can write some sample applications to consume that API data, parse through it, and then take that data and type it, using data adaption, into whatever protocol I'm using, typically BACnet, for consumption into my building automation system.
Now, there are some building automation systems that support native API consumption, built into them. Those are becoming more and more common every day. I will tell you that it is still the exception to the rule, and the average controls person does not know how to do this.
So, in a nutshell, how do we implement lightning? Majority of it is going to be protocol implementation. We need to understand our data types, make sure they're matched up. We need to make sure that we're doing proper data adaption. We need to understand what points are exposed by looking at our protocol conformance sheets, and then we need to make sure that we have the right data for the sequence so that way we can implement it. Then, and only then, do we implement the physical integration.
You will run into and retrofits as there a lot of legacy buildings that have physical interfacing for lighting control, but do not have the capability of doing protocol integration, because the systems are too legacy. Programmatic is the future and we are getting closer to it every day. There are systems that are API based, and you're going to see this more commonly as we continue to grow in our industry.
So, if you have any questions about lighting integration or you'd like to provide some feedback, go to blog.smartbuildingsacademy.com. I'd love to answer your questions or to discuss that with you. This is kind of my world I used to live in. I know quite a bit about it and would love to share that experience with you. So, ask away!
I will see you in our next blog where we talk about selling lighting integrations. Alright folks, thanks a ton. Take care.
