From design to setup to reporting, bad habits and bad thinking may loom at every turn.

More and more projects are involving the integration of even more systems and/or equipment, many whose function is not for HVAC. This is a good trend, as long as there is value from the integration. Of course, with this trend comes the challenges of learning about new systems, but more importantly, there is usually a need to educate the system/equipment representatives about the part they need to play in integration (you may even be helping them learn about the integration solution that they didn’t even know existed). And then there are the many myths, lies, and misconceptions that seem to sprout forth whenever the scope of our integration goals grows.

Some of these myths, lies, and misconceptions may be seen by some as debatable truths, some seem to be rooted in a lack of education, and others are driven by marketing hype. So in no particular order:

• Always Use BACnet® – It almost never fails: the first sentence out of a system/equipment provider’s mouth when asked about their product’s integration capabilities is often, “We support BACnet.” Unfortunately, other than most BAS products and commercial HVAC equipment, BACnet is usually not the protocol of choice, even if it is supposedly “supported.” Hopefully, this will change, but for now most industrial-based products (electrical equipment, CRACs, boilers, anything with a PLC, etc.) generally support Modbus as the native protocol (and rarely BACnet or LonTalk). When BACnet is offered up, it is usually via a Modbus-to-BACnet gateway, which is not a preferred approach (have the BAS perform the Modbus conversion rather than installing gateways scattered all around the facility). Other systems (mostly at the enterprise level) will probably support web services, share information via a database server (e.g., SQL), or possibly some other semi-custom approach. Communicate All Data – Some systems/equipment have hundreds of data items available for communication. Communicating all of this data not only leads to the question of how it can be presented to the user in a useful manner, but, more importantly, if the system architecture is not properly designed (e.g., with many BAS data routers), then communications in some or all of the BAS could grind to a halt.
  
• The BAS Contractor Will Take Care Of It – BAS integration with another system/equipment is a client/server relationship, so both parties must take part in providing matching interfaces and setting them up for the integration. This means that the system/equipment spec must list only one protocol and transport technology (e.g., 485 vs. IP). Listing a choice does not permit the BAS contractor to properly bid or design their side of the relationship. Furthermore, some system/equipment interfaces are mounted outboard, and therefore the spec needs to clearly define who installs and powers the interface. We’ll Communicate Any Data You Want – Be careful if a system/equipment supplier says this. What it really means is that the interface probably is “vaporware” or, as a minimum, that it may require extensive set-up efforts in the field (which, as Murphy’s Law dictates, may lead to problems).
  
• Always Use a Digital Communications Interface – Let’s face it, not all systems/equipment have much of use to say (we’ve seen some equipment with data lists totaling four items). If so, why not just pick up the product’s alarm and/or run status via a contact and some other important analog parameter or two via sensors, both wired to BAS inputs?
  
• Only Use the Digital Communications Interface – Unfortunately, digital communications is not as reliable a form of integration as that via the old-fashioned way – BAS points. Therefore, on major and/or critical equipment (chillers, VFDs on critical motors, etc.), use of hard-wired points for start/stop and other important control items (e.g., a VFD’s speed signal) is probably a more failure-proof design.