Client Portal

FAQ – Communication Protocols

If you cannot find the answer to your question within this FAQ, feel free to contact us via technical support, or give us a call at 504-529-1413.

Communication Protocols

How do I add SNMP Functions to CBAS?

SNMP is a network based protocol that allows communication with and control of various network devices. Battery backups, switches, and servers are likely candidates to support SNMP. CBAS has the capability to talk to SNMP devices and provide you valuable information about your system and device. This feature will require a CBAS and license upgrade if you are using CBAS 8.X.XX or lower.

The basic steps are as follows:

  • Get the IP address of the device
  • Get a copy of your products MIB file from the manufacturer
  • Make sure you have software to read an MIB file (we recommend ServersCheck MIB Browser )
  • Create an SNMP channel in CBAS
  • Create an SNMP controller in CBAS
  • Add points and configure them

In this example, we will be using a standard UPS device with an add-on Ethernet card.

Once installed and your network connected to the UPS, you will need the IP address of the device. In our case, software was provided to locate the UPS on the network and manually assign an IP. Next, you will need a copy of the MIB file for the device. The MIB was provided on the software disk for our device as well as being available as a free download from the manufacturer’s site. (Most MIB’s will be free downloads from the manufacturer) Next, install and start the MIB browser software and open your MIB file. This will list all of the functions that can be passed between the devices using the SNMP protocol.

Note: CBAS only supports the GET command at this time meaning CBAS only monitors or receives data. We do not currently support TRAPS or WRITING of the SNMP protocol.

Once you have located the point you would like to monitor, you will need to make note of the OID number from the MIB browser.

In editor mode of CBAS, go to Hardware View and Add A Channel – Name your channel and configure as SNMP.  Next, select the newly created SNMP channel and select Controllers and Add a SNMP Controller – name your controller and Configure as SNMP and lastly, enter the IP address obtained at the beginning.

Note: If you do not know the IP address at the time of programming, you can add it later by going to the SNMP controller in the hardware view, select Program and enter the address.

Now we are ready to add points to our controller. Select your SNMP device through the Hardware menu and click on Points – Add A SNMP Point sand name your point and select the point type and add. Now select the point to bring up the Point Program Screen and click the SNMP box in the lower left hand corner. This will bring up an SNMP Description box and click Edit Address box in the lower right corner. The Community in most cases will be Public unless you have manually configured the device you are trying to talk to. The OID number should match the point you selected through the MIB browser and adjust the update interval accordingly. Now you are ready to exit CBAS Editor Mode and enter into CBAS Real Mode to check your additions.

How do I program BACnet devices in CBAS?


  • Programming a 3rd Party BACnet MS/TP Channel and Controller is much like programming a BASNet channel of VAVs. You need an 8X or other Host controller first. (8X, 16X, 32X, or 64X)
  • It is suggested that the Host controller have recent or newest firmware, as many changes have been made to BACnet over the years.
  • You will also need to set the 3rd party device’s address and verify the Baud Rate that it will use to communicate. CBAS can communicate with the following Baud Rates: 4800, 9600, 19.2K, and 38.4K.
  • BACnet is a token passing protocol, so all devices should be set to Master.
  • Some Bacnet controllers must have a unique “instance” number. So, you may have to set an instance in CBAS to correspond to the instance you find when you “Probe” the controller.
  • Communication wiring should use 18-2 shielded twisted pair.
  • Multiple controllers can be “daisy chained” like any other RS485 bus.
  • BACnet TCP/IP is also covered later in this document.

Note: Instructions below assume that you have read the CBAS Programming Manual and understand how to program controllers, channels and points.

  • Program a Bacnet 485 over TCP/IP channel on the Host Controller.
  • Set the Baud Rate by going to the Program screen of the channel. (Match the Baud Rate of the device. Some are set to auto-negotiate by default. Example: Viconics thermostats)
  • Program a Bacnet Generic controller on the channel at the address that the device is set to. (0 is NOT a valid address)
  • When you are asked if you want to import the points, answer No. (First time only)
  • Using the manufacturer’s documentation, program one point that you are sure about on the controller. If you do not program a point on the controller, it will never communicate. This is because CBAS has nothing to poll, to you will get no response.
  • Once you add the point, you have to go to the program screen on the point, then click the BACnet button (bottom left), and set the address. Also make sure the point type is correct.
  • Go into Real Mode and make sure the new database downloads to the Host controller, so that it knows it is hosting the channel.
  • Do this by clicking the Host Controller, then Erase Database and wait about 5 seconds for the controller to reboot.
  • Take the controller OFF SCAN, then back ON SCAN, and it should download within a few seconds.
  • The Generic Bacnet controller and its points should turn Normal (Blue) if it is correct.
  • To interrogate the controller, go to the Program screen of the BACnet Generic Controller. Click the Probe button. If it is successful, it will save a text file to C:\CBAS\Data. If it fails, then either the device is configured with a wrong address/baud rate, or the point is programmed wrong in CBAS.

At the end of the text file, there will be a list of the points on the Bacnet controller. You can program the rest of the points from this list.

At the beginning of the text file, there is an instance number. Some manufacturers require that communications include the instance number. If you are having trouble communicating, try adding the instance number to the program screen of the Generic BACnet controller. If you cannot Probe the controller, you may need to get the Instance from the device’s configuration utility.

Note: Sometimes the Probe file point list will differ from the manufacturers’ documentation because of recent firmware or model changes, but the Probe file will show the correct points. Also, not all devices will respond to the Probe, but most will.

*While editing points in Real Mode: if you change point addresses, change point types, add points, change the controller address or the baud rate, CBAS MUST BE RESTARTED.

It should also be noted that Bacnet MS/TP devices generally take a few minutes to start communicating after the Host controller has Normal communications. To watch this process, go to the Program screen of the BACnet Channel. Click the Show Traffic button. You will see messages that are being sent. The first one should be “WHO IS”. You may see 2 of these before a response from the controller. Once you have seen at least 3 of these messages without a response, you can conclude that something is configured wrong, most probably in the configuration of the device itself. It could also be that the polarity of the communication wires is reversed. In this case, the Port 1 or Port 2 Activity light on the controller should be solid. Consult the manufacturer’s documentation for help.

Once the 3rd party device responds, you will begin to see COMPLEX ACK messages:

Add:1 Sz:17 COMPLEX ACK (3) READ AV 7 (3)

Add:1 means the address of the device is 1. Sz:17 is the size of the packet. (3) means this is the 3rd packet received. The next line means the packet contains address 1’s reading of Analog Value 7.

If you have a wrong address or point type, you will see errors:

Add:1 Sz:7 ERROR OBJ UnkObj (36) READ AI 0 (36)

In this case, Add:1 is the address of the controller/device. AI 0 is analog input position 0, which is an invalid point because 0 cannot be used. UnkObj means the point is not in the database of the device as configured by the manufacturer.

Duplicating controllers

  • Additional controllers can be added easily once the first one is programmed and working. Once you have verified that all points are correct on the first controller, you can click the controller, and then click Export Database. (In older versions, Export to OPTO/BACnet)
  • NOTE: If you get error messages when you export and the export file saves as 0 bytes size, then you need to scale the General Purpose Table of the Host controller. See the last section of this manual for instructions on scaling.
  • Follow onscreen prompts to complete the export.
  • The export file will be saved to C:\CBAS\Bin\BACNET as BacnetGeneric.txt.
  • If you will be saving multiple point configurations, you will want to rename that file to reflect the configuration, or it will be overwritten.
  • When you add subsequent Generic BACnet controllers, you will be asked if you want to import the points.
  • Answer YES and you will be taken to the same folder to select the proper file.
  • When adding the points, you will be prompted to add a prefix to the point names.
  • If the point names don’t turn out the way you want them, they can be changed one at a time through the Point Program screen, or through Global Name Change at System\Database Maintenance.

NOTE: To avoid problems when naming points and adding prefixes, make the point names generic on the controller that you are exporting from. Example: instead of naming points like RM 1 SPACE TEMP, add them as SPACE TEMP. You can add the RM 1 part using the prefix feature when adding from the export file.

BACnet on Controller
In the preceding configuration (BACnet 485 over TCP/IP), commands to a BACnet device may be head-end dependent, because you cannot download programming, like logic or schedules, to the 3rd party controller. Software points containing logic etc. exist on the Host controller or other needed points may exist on other controllers. In situations where a loss of communication occurs, which can happen when CBAS is not in Real Mode, you will lose functionality. It may be necessary to program the channel as “BACnet on Controller”, or to convert the channel to that type. Since this channel type is fairly new to CBAS, the latest firmware is necessary on the Host controller.

When programmed on a BACnet on Controller Channel, the database of the Generic Bacnet Controller is contained in the database of the Host controller. The BACnet points communicate directly with software and hardware points on the Host, eliminating the need to communicate with the head-end computer. Statuses and changes of state are then relayed to the head end.

NOTE: An “on Controller” channel is not seen in the main screen of Hardware View. You can find the channel by going to where you programmed it originally: Click the Host controller, then Channels. Click either the Host or Secondary channel, then controllers. Of course, the points can also be found in Text View\All Points, and can be added to Logical Groups or Graphics View. Otherwise, programming controllers and points on this type of channel is exactly the same as described in the first section.

The tool for converting a channel to an “on Controller” channel can be found in Utility Mode on the System Menu under Controller and Channel Maintenance. For information on Utility Mode, see the final section of this manual.

The instructions for this type are almost exactly the same as BACnet MS/TP, except that you don’t need a Host controller. The BACnet TCP/IP channel is added on the first screen of Hardware View.

  • In Editor Mode, go to Hardware View and click Add a Channel. The configuration will be BACnet TCP/IP.
  • Once the Channel is added, click the Channel then Controllers.
  • Add a BACnet Generic controller.
  • Everything else is the same, except that each Generic BACnet Controller will need a unique IP address within the subnet that the CBAS Server and other controllers are in.
  • Logic and schedules etc. can be programmed on the points, but they really reside on the head-end.

For more information on TCP/IP networking, refer to the Networking section of the CBAS Programming Manual.

The installer of the BACnet device is usually responsible for setting the IP address, as well as any other necessary settings, through its local interface.

Utility Mode and Scaling Databases
To start CBAS in utility mode, copy the CBAS icon on your desktop, then paste it so that you now have a new one. Right-click the icon and go to its properties, and add the following to the end of the target: [space]mode=utility

This will start CBAS in a special utility mode that you should not allow the end user access to. From here we can scale the controller database and other items unavailable in Editor mode.

  • To scale the database on a controller, start the system in utility mode, go to the System then Scale Database.
  • When asked if you want to scale the DPU database, click NO.
  • When asked if you want to scale a controller database, click YES.
  • Click the TCP/IP for Controllers channel.
  • Pick a controller from the list.
  • A screen with database items will open and display the number of items used and available.
  • Make sure the number available is more than the number used.


Logic 32 used and 32 available, change the available to 60

PIDS 12 used and 12 available, change the available to 30

Make sure that the Total Available Memory at the bottom of the window is a positive number. If not, then lower the numbers you scaled previously.

Click Save Changes and Exit.

You will have to acknowledge a message to erase SRAM. This means you have to delete the database from the controller and let it download again.

A convenient way to delete several databases at once is to change to Real Mode, go to the System > BASNet controller information screen, select a controller or more than one, and hit the delete database button.

The General Purpose Tables are at the bottom of the list. Scale all 3 of them to more than the number of points. If you have 19 points, scale them to 30 to be safe. Save changes. You do not have to go to Real Mode and back to Editor Mode in order to Export from the Generic BACnet controller now.

Convert Database to “On Controller”

  • To convert the database, open CBAS in Utility Mode, go to the System Menu, then Controller and Channel Maintenance.
  • In the bottom left click the button labeled “Convert Interface Channel to On Board 8X Channel”.
  • It will remind you to do a Backup first. Click Yes, then choose the channel and it will convert.
  • Once again, you will have to delete the database from the Host controller so that the changes are downloaded.
What are some of the advantages of using Internet protocols (TCP/IP) instead of BAS-specific protocols such as BACnet, LonWorks?

TCP/IP Internet Protocols are…

  • well defined.
  • widely accepted.
  • free. No single company controls them.

Anyone can look up the standards and can choose from a long list of component manufacturers.

Internet protocols are continually improved and benefit from research and development from thousands of companies across hundreds of industries. The amount of money in R&D for the Internet and Internet-related technologies dwarfs that in the building automation industry.

Internet protocols allow building automation systems to cross industry boundaries and interface with a wide variety of other systems.

Internet protocols allow separate systems and groups of components to share the same set of wires. This reduces the overall cost of installing and maintaining several systems.

Internet technology is not limited to desktop computers. The term Internet Appliance is applied to embedded electronic devices that use standard Internet protocols. Internet appliances are small devices (like building automation system components) that have this type of Internet protocol capabilities built in them. There is a tremendous amount of research in this area. The vision is to have all of the electronic devices in the home and office communicating with each other and sharing information. Devices from different manufacturers will instantly connect and exchange meaningful data with each other.

One of the advantages of BACnet was that BACnet was developed by what was supposed to be an unbiased committee. This is in direct contrast to standards like LonWorks® that are essentially dictated by a single corporation. In addition, BACnect covers the specific needs of the building automation industry.

One of the disadvantages of BACnet has been that cooperation among the players has been half-hearted. There have been many releases of BACnet products that were not 100% compliant. True interoperability between these products and compliant products could not be achieved. This left consumers somewhat disillusioned. To address this problem the BACnet Testing Laboratories® (BTL) was formed. But this was not launched until the year 2000—13 years after the conception of BACnet!

Another problem is that, in general, the technology behind BACnet is not comparable to the state-of-the-art networking technology found in other industries and standards. Part of this is due to the sluggish pace of the standards committee. To address this major shortcoming, BACnet/IP was quickly introduced after the initial release. The idea of BACnet/IP is to place BACnet packets over the Internet. But this was more of an afterthought than a primary design goal. And it only further muddied the already murky waters of BAS interoperability.

LonWorks® is a standard that was developed by the Echelon Corporation. From its’ conception, LonWorks® has revolved around the LonTalk® protocol and the company’s Neuron® chips. Unlike BACnet, LonWorks® was developed by and is primarily controlled by a single company. Until recently, any product that was LonWorks® compatible contained one of Echelon’s Neuron chips. This of course raises the question of whether or not LonWorks® is truly open. To have the entire standard placed at the mercy of a single company is not an ideal situation for many manufacturers.

One benefit of the single-company philosophy is controlled interoperability. By having Echelon enforce strict implementation of the LonTalk protocol, LonWorks® products achieve a higher degree of interoperability between multiple manufacturers than does BACnet. But this is at the cost of soul-source components and licenses.

Even though Echelon is the sole source for LonWorks, it has managed to get the LonWorks standard accepted as part of several other open standards. For example, LonWorks is an accepted part of the BACnet standard. But in practice, these two standards are rarely used together. Ira Goldscmidt1 had the following to say about the inclusion of the LonTalk protocol into the BACnet standard:

“The issue of including LonTalk as a LAN technology within BACnet was passed prior to the third public review of the standard in 1995. The alternative appeared to be a deadlock and potential appeal of BACnet by Echelon, which led to an observer’s remark that some committee members held their noses while voting ‘yes.’”

1 Ira Goldschmidt, “Development of BACnet”, Association of Energy Engineers “Strategic Planning for Energy and the Environment”, November 1998.