Integrating systems is not difficult.
I know, as I write this there are hundreds of people out in the field right now struggling to get two systems to talk. Maybe that is why you're here reading this article.
If so, welcome! In this article we are going to cover how to integrate systems. By the end of this article you will be able to integrate any two open systems together. I know that seems like a bold statement but my experience has shown me that everything can be integrated short of a few proprietary protocols.
Step 1: Identify the Use Case
The first step to any integration is identifying the use case. It is a massive waste of time to spend hours researching how to integrate a system if it cannot achieve your use case. For example, if you are trying to integrate a chiller (without a chilled water setpoint) via BACnet into your building automation system so that you can control it's chilled water setpoint then you are practicing an act of futility.
Nothing you do will change the fact that the chiller does not have a chilled water setpoint. I've seen too many new technicians spend hours trying to integrate systems that did not have the capabilities to achieve the use case.
To summarize your goal here is to identify the use case of the integration, what data points are required, and what data points are available.
Step 2: Find the Integration Solution
Oh schnap! We just jumped from doing some data analysis to identifying the solution for our integration. That seems a little quick doesn't it?
But the reality is, in the world of integration there really is nothing new under the sun. Sure the systems may be different but I guarantee you someone has worked with your protocol(s) before. And that is the part of creating the integration.
Identify the Protocols in Play
What protocols are you working with? Does system A have BACnet/IP and system B have Modbus/RTU?
If so you now know that you have disparate protocols and you need to do perform data adaption. This is the part that I also see a lot of new and experienced building automation professionals get tripped up.
Why?
You would think this would be relatively easy. There's a very obvious reason why people get tripped up and I will tell you at the end of this article.
Now let's say you're working on a BACnet/IP to Modbus/RTU integration.
The easiest way to achieve this is to search for a BACnet/IP to Modbus/RTU protocol gateway. Once you have found one then you can implement your integration.
There are so many options. Let's look at the Intesis one, they are another company I like with a broad selection of integrations.
Once we have identified the product we just need to dig into how to configure it which we can find in the technical documentation.
But what if the protocols are more complex? One of the most common integrations that I see people struggle with is BACnet/IP to Restful/API or Restful/API to BACnet/IP. How do you handle this?
Once again it is quite simple if you follow the common approach. First you need to find a protocol gateway.
To do this I performed a simple Google Search
From here I went to the first result (I really have had good success with Chipkin's stuff).
Oh looky here, we've got ourselves a REST to BACnet Gateway but damn, it's a passive gateway so that means we can't actively push data to an API endpoint... Or can we?
That's why you always need to read the complete product notes.
As I dig deeper I see that I can actually use the Push Driver to enable me to write to a 3rd party web service. Schweet!
Now I need to dig into my BACnet capabilities.
The BACnet/IP driver can support WHO-IS, WHO-HAS, Subscribe COV, and Read/Write Property. This enables me to perform the majority of my BACnet services. I've just solved my problem!
Step 3: Implement the Integration
Ok, you ready?
The reason why most technicians struggle with integration is because they don't understand protocols on a deep level.
Time for a virtual show of hands, how many of you reading this have read the whole Modbus Standard? What about the BACnet Standard? How many of you have read the HTTP standard?
I don't see a whole lot of hands raised anymore. Look, I'm not here to judge, but let's be real. If you are just relying on the vendors to tell you what settings to change while not knowing what those settings mean then you are one step away from a integration fiasco.
The overwhelming majority of the time that I've seen people hung up on integrations was due to someone not understanding the configuration parameters and functionality of protocols.
Here's the deal, it sucks to read all 1200+ pages of ASHRAE 135 (if you don't know what I mean by ASHRAE 135 then it's time to study young grasshopper). But, if you want to be an integrator then you need to do what is necessary you need to spend time studying protocols.
We've put a ton of information together around protocols, most of it is completely free. For example you can read our protocols guide by clicking here.
But, if you'd like to save a MASSIVE amount of time, and learn exactly what you need to know in order to deeply understand protocols then you need to enroll in our BAS Protocol Bootcamp. Click here to learn more.
My hope is that this article gave you some ideas on how to approach integration differently. Let me know your thoughts in the comments below.
