<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

Hey folks, Phil Zito here and welcome back! In this post, we are going to continue our discussion on implementing access control integrations and ultimately, on access control integrations as a whole. Now, as I discussed in the last post, this is going to be a bit shorter just simply due to the fact that with access control integrations, the reality is, you are at the mercy of a driver or an API, for most access control integrations.  

Alright, so access control integrations, like I said, they are primarily going to be integrated via API's, drivers, or utilizing a product that already has those capabilities built into the product. So, with most of our solutions, with most of what we're doing, we are going to be taking a driver and adding it to our building automation system, if we can. We will then pull in the access control system points via the driver, and we will use those points typically to determine occupancy, to detect if someone's in a room and then to turn on or off HVAC systems.  

So, what does this look like? Well, depending on the building automation system, start off by figuring out what driver works with your building automation system. Sometimes that's contacting that building automation system system’s integration group, sometimes that is just activating the driver from a list of drivers and maybe paying a licensing fee. It just depends, you know, it varies.  

Once you've done that, once you have that driver activated and pulled into your building automation system, then you just follow the driver configuration rules, set up the communication bus. Sometimes it's physical, sometimes it's IP, most of the time, it's IP with access control, and you then pull the points into the building automation system and set them up accordingly. Pretty straightforward.  

API is a bit more complex. We've discussed APIs in great detail throughout this series on integration, and I will say that with access control, it's no different. You have to understand the API, you have to typically get yourself a token, or some sort of key in order to utilize the API, you have to be able to then understand the SDK, the software development kit related to that API, so that you can look at that API, understand it, and understand how to do calls against it.  

Sometimes, that's as simple as going into your building automation system, setting that up, and just setting up the HTTP or whatever reference to the API endpoint, pulling those data points in, and just adding them to your building automation system. Other times, it's a bit more complex. Maybe you have to do some data type conversion in your building automation system, maybe take string data and convert it to integer data or numeric data.  

Other times, it's very complex, and you actually have to pull in the API via a script, you actually have to write a script, and you maybe have to run that script as a service, and it consistently runs. That way, you can do some API to protocol conversion, maybe you're converting that API to BACnet, or taking that API and converting it to some sort of informational format, some sort of protocol format, that your building automation system can work with.  

That's why, quite honestly, I wouldn't really work a lot with access control integrations. There are easier ways to detect occupancy in a space. There are easier ways to people count without integrating access control.  

I know that, especially over in Europe, they're really big on the total room control model, which is lighting, access control, HVAC, etc. all into a single controller, and that can work for them. Here in the United States, while that is a model that is being utilized by some OEMs, most of the OEMs like the Johnson, Siemens, Schneider, etc., are still keeping their access control BAS solutions separate.  

So just be cognizant of that as you approach integration. Just think through like, “Why am I doing this? What am I trying to do? What am I trying to achieve? What do I need to know in order to do this integration?”  

What we need to know is the access control manufacturer, the model, and the use case. Once we know the use case, we need to know what points support that use case, then we need to take that information and figure out how we get the points out of that model from that manufacturer. That's when we start to dig into drivers, start to dig into API's, maybe protocol integrations, but in most cases, no protocol integration exists.  

So, there you have it, folks. That's implementing access control integrations. Like I said, pretty short post, a lot of the fundamental key concepts I've covered in pretty short posts.   

Be sure to check out the previous posts on Basics of Lighting Integrations, Implementing Lighting Integrations, Basics of Audio-Visual Integrations, and Implementing Audio-Visual Integrations. Definitely check those out because I dive deep into a lot of the things that I mentioned here, but I didn't give a lot of description around because I am assuming you're following this series.  

Our next blog will be about selling access control, then we'll get into energy, then we're going to start diving into IAQ, and finally we're going to do a little bit on an educational side of things. That's the plan, may change, but we'll see.  

Alright, thanks so much for being here. I hope you're enjoying these blogs. Hope you're enjoying the shorter format. Definitely engage in the comments Smart Buildings Academy Blog. Thanks a ton and take care! 

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?

 

BE A GUEST