In this episode we explore how to implement lighting integrations.
We go step-by-step through the process of implementing lighting integrations and discuss the three most common approaches to integrating systems into our building automation systems.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Transcript
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 272. Hey folks, Phil Zito here, welcome to Episode 272 of the smart buildings Academy podcast. In this episode, we are going to be continuing our series on integrations. And in this episode, we are going to be talking about implementing lightning integrations, we're also going to be discussing the three primary integration types and approaches. So this is critical. This is going to carry through to the entire 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 pretty much. So that being said, Everything we discussed can be found at podcast at smart buildings Academy comm forward slash 272. Once again, that is podcast, that's Mart buildings academy.com Ford slash 272, I encourage you to go there because our system integration guide is going to be there. And that's a really good guide that goes through the entire MSI process in great detail. Additionally, you'll find a link to our systems integration bootcamp course, which if you're looking for master systems integration in a box, that is the course you're going to want to go through that course 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, so let's dive in. So there's three approaches to integration. And technically, you could say two, because I will argue that the third approach is really more interfacing. And I'll talk 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. And this is very rare. And given it building automation capabilities. And the nice thing about doing this, through this integration process is we are creating functionality. Now, you know, if you've listened to any of these podcast episodes in the past, you know, I'm an advocate for micro use cases, I think that by and large, these massive 50 plus system integration, use cases are one, they're overkill for a lot of customers too, they're very difficult to support from a legacy product perspective. And three, just logically, they don't make a whole lot of sense. There's often they're done more for ego purposes than actual use case and return on investment. Alright, so when we look at integrations, we're going to be looking at three primary approaches. The first, as I said, is more interfacing. And that is physical interfacing. So in lighting, and I'll give you an example of this from a lighting perspective for each one. So lighting, let's talk through what would this look like this would look like us putting a relay in between maybe the light switch and the ballast, and being able to manually override or putting a relay at the master lighting panel, 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 go and turn on and off lighting circuits. I say this is interfacing and not integration. Because there's no real feedback, right? With integration. We're taking a system and we're making it a part of our greater system. With interfacing we are we're really we're going and adding another method of control but that system still kind of stands on its own. So interfacing is our is probably the most common form of quote quote integration that you will see across the board. You'll see this with access control, you'll see this with audio visual, you'll see this with fire alarm, where we are doing secondary monitoring and or secondary control of these systems via physical interfacing is the easiest thing to do, but it gives you the least capabilities.
Phil Zito 4:52
Next up comes protocol integration. This is the bread and butter is where everyone tends to screw. I don't wanna say everyone. Anytime you Hear me, say everyone. And anytime you hear anyone say everyone or everything are always or never, that should be a red flag, where you're like, hmm, I'm gonna really question when that person says, so I give you permission, if you ever hear me say, everything, or always, and I try not to, I try to catch myself. But if you hear me say that, then challenge what I'm about to tell you. So I see a lot of people who struggle with protocol integration. And this is for three reasons. Reason number one, they don't go and actually get involved with the protocol integration early enough to have the proper influence so that that gateway that they're integrating to, or the settings that they require for integration, or the points, lists etc, are properly set up to they don't really understand the protocol, they don't understand what the protocol requires, as far as connectivity and what its limitations are. And three, they don't understand the capabilities and limitations of the system they're trying to integrate, you could try to integrate a BACnet or 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 podcast, where it 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. And 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 like audio, visual or energy data. But in the case of lighting protocol, integration is our primary way. And it's typically going to be at least in the United States, going to be via BACnet, I usually BACnet IP from the server. And in the case of Europe, you may see Cayenne ax or Dolly. Alright, so that being said, we're going to focus in on back net, we are not going to focus in on back net. In regards to its lighting objects, we are going to be assuming that we're going to be 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, as I mentioned, we need to understand which system is in charge. Is it the lighting system? Or is it the VA s, once we've determined that then we can determine our point of integration. Typically, it's going to be at the lighting server level, 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 go here, and I'm just using Lutron, as an example, don't start emailing me saying, you know, my system is better. Bla bla bla bla bla bla bla, all I'm doing is using them as an example because they've got pretty good market share. And so the first thing I go like for their quantum system is I would type in Lutron Lutron. Back net pick. So protocol protocol, implementation conformance statement, right? We remember that. Actually, we may not remember that because I covered that in our live office hours, I get the two mixed up. Last week's live office hours, I spent, basically a masterclass on back net, testing laboratories and ptl compliance. But essentially what I do here, and you can't see it on my screen, because I'm doing a podcast, but I went and I looked up the quantum for,
Phil Zito 8:51
for back net or back net, p IC, the back net protocol implementation conformance sheet for the quantum gateway for Lutron. Right, and it tells me all the things that supports it tells me what it does support what it doesn't support, it tells me the different points that it has. And once I have these points, and once I understand what points and objects are available, then I am able to go and start to understand Alright, this is what I can discover this is what I cannot discover. And ideally, this is done before you start executing. Ideally, this is done during the submittal phase of a project. And the reason you do this is now I could say Oh, 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. And you can go and submit a request for clarification and say, hey, look, 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 and this is where a lot of people get hung up. On all forms of protocol integration, whether it's a chiller, whether it's audio visual system, whether it's lighting system, etc, this is where they get stuck. So this is what you need to do, right, you need to go check out your implementation performance sheet for back net. If it's long, go check out your snippet list and all of your property lists there. If it's you know, Dolly can get the point, right, you know, your protocols know what you need to look for, know how to go and look up points, lists, and understand what points are available to you. Once you have that information, then you've got to figure out okay, I've got the points list. I know the sequence, I've done some data adaption. So I know which zones match to which spaces, I've accounted for that. Now, I can go and figure out the physical, so many folks try to figure out the physical integration. And I would argue that a lot of people get the physical integration, right. But they get the protocol data, the the data side of the protocol integration wrong, they get the physical side of the protocol integration, right? You know, like the BACnet, IP setting up the BBM, D, the bdts, device IDs, all that stuff. But then they don't account for protocol. And they don't account 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, right? You can say, okay, it needs to be on this sub net, this switch this IP address, this range, blah, blah, blah, blah, blah, blah, blah, right? 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. It's pretty straightforward at that point. Which brings us up to our third type of integration, which is going to be a programmatic integration. This is a typically an API, or co app, or message queue. There's mq, TT. 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. When I have an API, an application programming interface, so that's an interface that allows me to connect to the programming of an application and run functionality. Or I have an mq, MQ tt field feed, or I have a co op, right, and Co Op and mq TT are usually JSON or stream. And I've got those outputs coming out. Now I've got to decide what do I do with them. And this is where a lot of MSI is making air quotes. Master system integrators get hung up, because they can do the protocol integration. But when it comes to actually integrating the ERP systems that are data feeds programmatically, which is where I think our industry is going, by the way as programmatic data feeds and things like node read j s, stuff like that, which basically allows you to graphically do JavaScript to consume.
Phil Zito 13:19
products are Oh, sorry about that. programmatic feeds. So that being said, since that's where I think the industry is going, what, actually my backup because I think I probably just lost half the audience. So basically, long story short, there's data that comes out of systems, in this case, lighting systems, sometimes it's like a weather station system, sometimes it's audio visual system 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 what we have to do is 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 converted into protocol data or some form of data that our building automation system can consume. This is why when folks asked me what should they learn in it, I say basic networking, and basic scripting scripting is really important. So 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, I would go and 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 that API supports. And then I can go and write some sample applications to consume that API data parse through it. And then take that data and type it using data adaption in to whatever protocol I'm using, typically back net for consumption into my building automation system. Now there are some building automation systems that support native API consumption built into them. And those are becoming more and more common every day. But 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's going to be protocol implementation, our big gotchas, 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've got the right data for the sequence. So that way we can implement it. And then and only then do we implement the physical integration, you will run into and retrofits a lot of legacy buildings that have physical interfaces for lighting control, but do not have the capability of doing protocol integration, because the systems are too legacy. programmatic is the future we are getting closer to it every day. And 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 that being said, if you have any questions about lighting integration, you'd like to provide some feedback, go to podcast at smart buildings. academy.com forward slash 270. Once again, that's podcast at smart buildings Academy comm Ford slash 272. I'd love to answer those questions for you love 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 and I will see you in our next podcast where we talk about selling lighting integrations. Alright folks, Thanks a ton. Take care.
