In this episode we discuss how to use the three integrations methods to integrate your building automation and audio visual 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 275. Hey folks, Phil Zito here, welcome to Episode 275. And today I'm recording a twofer episode. So I'm going to record Episode 275. And then I'm going to be recording Episode 276. After this last Wednesday was my kids first day of school, so didn't get the podcast knocked out that day. That being said, We're continuing our series on system integration. And we are going to be looking at implementing audio visual integrations. Now, if you have not already done so definitely go back and listen to episodes 272 273 and 274. Those are sorry, 271 272 and 274. Those episodes are key to you understanding what we're going to be discussing today, because of the fact that integration is much more than just the systems we're integrating. It has to do with processes and kind of procedures. And we cover those in those episodes. So let's dive in. As we already discussed, audio visual systems are a very common system for integration, especially in the corporate office environment, but you also see them being integrated in higher ed and also in healthcare situations. So let's talk through how we integrate. The first kind of integration is physical integration, right. But we don't really see physical integration or physical interfacing, happening really, in audio visual, audio visual definitely does use physical interfacing to tie into lights to tie into TVs to tie it and phones to tie in the shade control, not really to tie into building automation. And the reason why is building automation. And what we would be controlling is normally controlled by IO in the first place, right? If we think about a space, it's got a temperature sensor, and that temperature sensor goes to a VA v box which regulates air flow into the space which then cools or heats the space. Well, if we tried to interrupt the physical IO between that space temp sensor and the actual VA v box, that would be bad things would not work. And I've never really seen this on an integration design. That's not to say it's not out there. That's not to say someone is not trying to do that, that would be a horrible idea. So by and large, we're gonna skip over physical interfacing as a form of integration for audio visual systems. Now, moving on to the most common form of integration, which is going to be protocol. And when I say protocol, it's primarily back net over IP. And what will typically happen is you will either at the server or at the room level connect to the audio visual system. Now you can at the server level, connect to the audio visual system. And you can pull in your zone temperature, your zone temperature set points into the audio visual system, or rather, the audio visual system person can pull them in. And then they can use those to display on signage to display on remote control applications through the phone applications that are being controlled via, you know, like desk screen. Essentially, there's not a kiosk, basically like a little tablet that sits on the conference room desks. And you can go and pull those points in right and do discovery. And that's a very common form of integration. And in that case, your key points of performance for that integration are one to make sure you're pulling in the right points sound temps on temp setpoint excetera occupancy to making sure you're pulling them in at the correct priority. If the AV system is supposed to take precedence, then you want to have a lower number because remember in back net priority arrays, lower numbers are higher priority. So you want to have a lower number than whatever you are using for the building automation system and its graphics. Otherwise, every time you go and you change the graphics in the building automation system, you are then going to be overriding whatever's in the AV system, which is not necessarily a problem. If we switch gears here and we say we are pulling data out of the AV system in to the building automation system. Now this is less common in my experience. It is more common for us to pull data into the AV system and use That as the primary system and to use our VA s as the secondary system, at least for space control. That being said, there are scenarios where we will go and pull in data from the actual AV system into the building automation system. And this may be like if we wanted to get lightning data. If we wanted to get energy data, if we wanted to get performance data, we could pull that into the BA s system. So just be cognizant of that. The third way that we do this actually, before I go into third way, I just want to dive a little bit deeper, I don't want to assume that you all understand. So what I would do, for example, if I had to discover a Crestron system, I would go into Google Chrome like I'm doing right here and I would say Crestron, back net IP.
Phil Zito 5:54
And I would look this up and I would start to find like the SW three series BACnet 50 with Crestron electronics, and I would start to understand kind of what does this thing do? I would look at the resources. Okay, I've got a technical resource with an application diagram. What exactly does this mean? Oh, it just gives me a simple diagram of the system. Okay, so I just do discovery a back net. And I can pull in access control hv C, whatever, into this Crestron system not very descriptive, right? If I go into the spec sheet.
Phil Zito 6:32
Let's see if this thing's any better right here, give it a second to load up. It tells me that the three series and four series can support 500 BACnet objects. With the following exceptions. If I have some other stuff, I can do 2000 objects. So understanding, you know, hey, there are limitations to my objects, there are limitations to the supported control systems. And understanding that this SW, which stands for software, three series back net 50 is just a software license that enables the three or four series control system to support more than 50 BACnet objects. So basically, if I want to do more than 50 BACnet objects and I want to bring them in for discovery and control purposes, then I'm going to have to have a license. And you know, I didn't, I've messed with Crestron in the past, it's been a couple years. But I didn't know this off the top of my head until I google that. So just realize that take a little bit of time, do a little bit of research, you know, type in Crestron, BACnet IP or whatever system you're using for your audio visual system. And then once you've discovered that, then go and figure out okay, alright, this is a software license. What are the supported control systems? Oh, and AV three or an F TTS. Okay, great. Sounds good. Now I know that this system is also supported, right? AV three is a rack mountable three series controls processor, right, so this controls processor, it allows us to connect to the room control devices, this products been discontinued, find out who, okay, but you get the point. And the key point is to doing some research now, all of that's well and good. But the reality is there's plenty of AV systems out there that do not support back net. They only support API's application programming interfaces. So once we know that they support API's, the system supports an API, what we have to figure out is twofold. One, we have to figure out what is the API for the AV system? And then what API do we have for our building automation system. And depending on the building automation system, we may have the ability to write to http API's hypertext transport protocol. And we may be able to write to those API's directly from our building automation system at which time, we just simply need to make sure that we understand the functions of the audio visual system API. So this is your checklist right? Go and research the API of the audio visual system figure out its functions and the data types that those functions accept. Normally, this is done by typing in the AV system API and then SDK. SDK, also known as software development kit will typically give you a list and examples of the functions that you can call on an API. Once you understand what functions you can call on an API, then you are going to be able to understand how you actually write to that API. So I just pause the podcast, what I'm doing in the background is I'm opening up the exci Oh, cloud service from Crestron, I'm looking at its API reference, I'm starting to understand, okay, I have to have a subscription key, I have to have an API that I'm writing to. And it's going to give me like, what can I do? What can I write. And once I understand what I can write, and what properties exist, then once I understand that, I have to go and actually write up in my building automation system, how I'm transferring this now, as I mentioned, some building automation systems will have HTTP endpoints and API, drivers that make this easy, others will not some will not support it at all. And you'll have to do like a BACnet. To RESTful API gateway, you can do those through some third party hardware providers. Or you can write your own in, you know, like Python, or in JavaScript, or some sort of scripting language. And, you know, or you can even write a C sharp service or a Java service, and have it run on the background on the server.
Phil Zito 11:20
The problem with hard coding things, like the gateways, or, like I'm mentioning with those services, is that if anything breaks, if anything kind of gets out of whack, you're going to have to go and redo the service. And they're difficult to maintain and watch. But the reality is, that's just sometimes what you have to do. So what you would do, like I said, you'd look up the SDK, you'd figure out what the API supports, and then you would figure out how to write it. Kind of hard to teach you that on a podcast To be honest, because it's a very visual thing. But I will tell you that if you Google, how to write API's, or how to write to API's, or how to write scripts for API's, or how to write services to API's, specifically focusing on JSON JavaScript Object Notation, which is the most common format of writing or formatting data coming out of an API, then that would be pretty helpful in my opinion for you. Now the reality is most of you listening to this are not going to have to do anything more than BACnet IP into your AV system or out of your AV system. But there are the few of you who are going to have to work with API's and just be cognizant that this is how you go about it. Alright, folks, so that kind of brings us to the end of this shorter podcast episode. Hopefully, this gave you some ideas on audio visual, I know that there are little nuances to everything. So if you would like to dive much deeper into system integration, or in the protocols, I encourage you to check out our VA s protocol boot camp or our system integration bootcamp. And remember, you can always go into the comment section if you're listening to this on social or if you're at our website, the common set comments section at the bottom of the page, that would be at podcasts that smart buildings academy.com Ford slash 275. Once again, that's podcast at smart buildings academy.com Ford slash 275. And if you are interested in our courses, I encourage you to take advantage of our Labor Day Sale where our courses are significantly discounted. You can find more information on that at courses dot smart buildings. academy.com once again, that's courses that smart buildings academy.com Thanks a ton for being here. I look forward to talking to you in Episode 276 take care
