Bacne T Integration Ref

Technical Publications
BACnet Integration Reference
Niagara Release 2.3.5 Published: April 26, 2004
Tridium, Inc. 3951 Westerre Parkway Suite 350 Richmond, Virginia 23233 USA http://www.tridium.com Phone 804.747.4771 Fax 804.747.5204
Copyright Notice: The software described herein is furnished under a license agreement and may be used only in accordance with the terms of the agreement. Copyright 2004 Tridium, Inc. All rights reserved. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior written consent from Tridium, Inc., 3951 Westerre Parkway, Suite 350, Richmond, Virginia 23233. The confidential information contained in this document is provided solely for use by Tridium employees, licensees, and system owners; and is not to be released to, or reproduced for, anyone else; neither is it to be used for reproduction of this Control System or any of its components. All rights to revise designs described herein are reserved. While every effort has been made to assure the accuracy of this document, Tridium shall not be held responsible for damages, including consequential damages, arising from the application of the information given herein. The information in this document is subject to change without notice. The release described in this document may be protected by one of more U.S. patents, foreign patents, or pending applications. Trademark Notices: BACnet and ASHRAE are registered trademarks of American Society of Heating, Refrigerating and Air-Conditioning Engineers. Microsoft and Windows are registered trademarks, and Windows 95, Windows NT, Windows 2000, Windows XP Professional, and Internet Explorer are trademarks of Microsoft Corporation. Java and other Java-based names are trademarks of Sun Microsystems Inc. and refer to Sun's family of Java-branded technologies. Communicator and Navigator are registered trademarks of Netscape Communications Corporation. Echelon, LON, LonMark, LonTalk, and LonWorks are registered trademarks of Echelon Corporation. Tridium, Niagara, the Niagara Framework, Vykon, Java Desktop Environment, WorkPlace Pro, Web Supervisor, JACE-4, JACE-5, JACE-NP, and JACE-NX are trademarks of Tridium Inc. All other product names and services mentioned in this publication that are known to be trademarks, registered trademarks, or service marks have been appropriately capitalized and are the property of their respective owners. BACnet Integration Reference Copyright 2004, Tridium, Inc. All rights reserved.
C O N T E N T S
About This Document Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisite Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important Information Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commonly Used Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix ix x x xi xi xii xiv xiv
CHAPTER
Getting Started Supported BACnet Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Support (Shadow Objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exposing Objects (Server Support) . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Alarming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Link Layer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COV (Change Of Value) Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . BBMD Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Integrations vs. Other Integrations . . . . . . . . . . . . . . . . . . . . . . . . Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing and Configuring the BACnet Service . . . . . . . . . . . . . . . . . . . . . Licensing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing BACnet Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the BACnetService in a JACE station . . . . . . . . . . . . . . . . . . Configuring Essential Station Properties . . . . . . . . . . . . . . . . . . . . . . Verifying Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WhoIs Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning a BACnet Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Station Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important General Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1 1-1 1-2 1-3 1-4 1-4 1-5 1-6 1-6 1-7 1-7 1-7 1-8 1-8 1-9 1-10 1-11 1-13 1-15 1-15 1-19 1-20
Niagara Release 2.3.5 BACnet Integration Reference
Published: April 26, 2004
iii
Contents
CHAPTER
Using the BACnet Utility Opening the BACnetUtility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Action Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status Line History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Network Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . whoIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . whoHas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . learnNetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Device Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . learnDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . getAlarmSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually Adding BACnet Shadow Objects . . . . . . . . . . . . . . . . . . . . . . . Adding a Device Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Child Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-1 2-1 2-2 2-2 2-3 2-3 2-5 2-6 2-9 2-9 2-13 2-14 2-15 2-16
CHAPTER
BACnet Client Operation About BACnet Shadow Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Property Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Lite BACnet Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Writable Input Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Integration Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet objects (children) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogValuePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryOutput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryValuePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateValuePriority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-1 3-1 3-2 3-3 3-3 3-5 3-5 3-15 3-26 3-30 3-33 3-35 3-38 3-40 3-43 3-45 3-48 3-51 3-54 3-56
iv
Contents
CHAPTER
BACnet Server Operation Device Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Name Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Allowing BACnet Write Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using BACnet Log Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Log Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding BACnet Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Log Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collection Time Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-1 4-1 4-2 4-3 4-7 4-8 4-9 4-9 4-10 4-11 4-11
CHAPTER
Configuring BACnet Alarming Generating BACnet Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet Alarm Generation . . . . . . . . . . . . . . . . . . . . . BACnetRecipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving BACnet Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet Alarm Reception. . . . . . . . . . . . . . . . . . . . . .
5-1 5-1 5-2 5-3 5-5 5-7 5-8 5-8
CHAPTER
Configuring BACnetService Properties BACnetService Property Sheet Overview. . . . . . . . . . . . . . . . . . . . . . . . . . General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BACnet Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the Poll Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Poll Scheduler Properties . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Device Status/Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Device Status Monitor Properties . . . . . . . . . . . . . . . . . . . Configuring BACnet/IP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BACnet/Ethernet Properties . . . . . . . . . . . . . . . . . . . . . . . . . Commands to the BACnet Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-1 6-2 6-3 6-3 6-4 6-7 6-9 6-9 6-12 6-15 6-16 6-18 6-18 6-20 6-22 6-22
Contents
Using Debug Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard BACnet Debug Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug Option Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjunct Configuration: bacnet.properties File. . . . . . . . . . . . . . . . . . . . . . Editing bacnet.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-24 6-24 6-25 6-28 6-29
APPENDIX
Troubleshooting
Go/No-Go Communications Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . Objects Not Polling Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Color and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug and Standard Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1 A-1 A-2 A-2 A-6 A-7
APPENDIX
BACnet PICS
BACnet Protocol Implementation Conformance Statement . . . . . . . .
B-1 B-1
APPENDIX
BACnet PC Notes
Installing the BACnet Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Over Ethernet Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . Using setAdapter.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually Editing driver.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . Edit drivers.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C-1 C-1 C-2 C-2 C-3 C-5
APPENDIX
Niagara bacnetx Modules

About bacnetx Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ndio (bacxNdio) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the bacxNdio Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . notifier (bacxNotifier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the bacxNotifier Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NotifierBinaryValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-1 D-1 D-2 D-2 D-3 D-3 D-4
APPENDIX
Internetworks and BACnet/IP

BACnet Network Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internetwork = BACnet Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internetwork Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Router Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet/IP and BBMDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E-1 E-1 E-2 E-2 E-3 E-3
vi
Contents
About BBMDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niagara BBMD Configuration Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Internetwork Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E-3 E-5 E-7
APPENDIX
Niagara MS/TP Support

Niagara MS/TP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS/TP Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Station Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prepare the JACE Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Essential MS/TP Link-Layer Properties . . . . . . . . . . . . . . . Engineering Considerations for MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . Token Passing and Related Operation . . . . . . . . . . . . . . . . . . . . . . . . MS/TP Network Configuration Guidelines . . . . . . . . . . . . . . . . . . . . Recommended MS/TP Learn Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Slave Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F-1 F-1 F-2 F-3 F-3 F-3 F-7 F-13 F-13 F-14 F-17 F-18
INDEX
vii
Contents
viii
P R E F A C E
About This Document

This document is intended to help you use the BACnet service for a Niagara station. Included are getting started procedures, station engineering considerations, reference information on integration objects, and troubleshooting tips. This preface includes the following sections:
Note
Intended Audience Prerequisite Knowledge Document Summary Formatting Conventions Commonly Used Terms Related Documentation Document Updates
The Niagara BACnet Supervisor Reference is very similar to this document, and contains all equivalent information. If you have a BACnet Supervisor job, you may simply refer to the Niagara BACnet Supervisor Reference instead of this manual.
Intended Audience
The following people should use this document: Vykon systems integrators and installers responsible for initial setup and ongoing configuration of JACE controllers that are part of a BACnet integration. Vykon application programmers.
ix
Preface Prerequisite Knowledge
About This Document
Prerequisite Knowledge
Readers of this document should know or have experience with the following: Basic Niagara concepts, such as stations, nodes, objects, properties and links. Niagaras Java Desktop Environment (JDE, formerly called WorkPlace Pro), including the necessary tasks to provide system control and user interface. Ideally, you should be Niagara-certified, that is, have successfully passed Tridiums formal Niagara Technical Certification Program. Familiarity with the specific foreign BACnet devices included in the Niagara integration, which vary by vendor in levels of BACnet conformance. Access to the native programming tools of the foreign BACnet devices is typically necessary to verify integration methods.
Document Summary
This document contains six chapters and six appendixes, summarized below. Chapter 1, Getting Started,Provides an overview of the Niagara BACnet implementation. Procedures cover installation, start up, initial checkout of BACnet communications, and learning external BACnet devices. Chapter 2, Using the BACnet Utility,Provides an explanation of the BACnetUtility View provided by the BACnet service, and procedures to use its various commands. Also covered is how to manually add BACnet shadow objects. Chapter 3, BACnet Client Operation,Provides detailed information on each of the BACnet shadow object types. Included are the device object and lite objects. Chapter 4, BACnet Server Operation,Explains the configuration required to expose standard Niagara objects as BACnet objects, including allowing write access. Information on special BACnet log objects is also provided. Chapter 5, Configuring BACnet Alarming,Provides an explanation of how BACnet alarming is performed by the BACnet service. Procedures for configuration and testing are provided. Chapter 6, Configuring BACnetService Properties.Provides explanations and procedures to configure various BACnet service properties that affect polling, device status, various link-layer options, as well as debug operations. Appendix A, Troubleshooting,Provides troubleshooting information specific to the BACnet service. Appendix B, BACnet PICS,The PICS (Protocol Implementation Conformance Statement) for the BACnet Supervisor and also JACE controllers, 2.3.4 and later. Appendix C, BACnet PC Notes,Provides configuration details for running the Niagara BACnet service on a PC platform. Appendix D, Niagara bacnetx Modules,Information on BACnet extension modules, used for exposing Ndio objects or for integrating Notifier panels.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004
Preface
About This Document Formatting Conventions
Appendix E, Internetworks and BACnet/IP,Explains how multiple BACnet networks are combined to form an internetwork, and related issues and rules. Also covers BBMD operation (specific to a BACnet/IP network). Appendix F, Niagara MS/TP Support,Explains the MS/TP support provided by JACE-4/5 controllers, a specially-licensed option. An Index provides alphabetical reference to important topics in this manual.
Formatting Conventions
This document uses the following text-formatting conventions: Bold text indicates an important keyword, a keyboard key name, or an interface object name. For example, the ENTER key, or the File menu. CAPITAL letters are used for acronyms, such as WPP (WorkPlace Pro). They are also used to identify keyboard keys in instructions. For example, Press ENTER. or Press CTRL+C. Italic text is used for emphasis. It is also used to refer to the titles of other publications and document filenames. For example, The Microsoft Manual of Style or Niagara Web Solutions Guide. Italic text is also used for non-literal text that represents a variable. For example, station_name or DONOFF_n. Quotation marks are used to refer to the names of sections within the current document. For example, see Paragraph Styles for additional information. <Text between brackets> is used as a placeholder for user-supplied values. For example, <password>. <Text between brackets> is also used to indicate a variable in contexts where italic text is not appropriate or is not easily discernible from other text. For example, D:\niagara\<release number>\stations.
Important Information Indicators

In addition to text formatting, this document uses important information indicators, as listed below: Notes typically contain significant details related to the topic in the nearby text. They alert you to important information that might otherwise be overlooked.
Note
Caution
Cautions remind you to be careful. There is a chance that you could perform an action that cannot be undone, might produce unexpected results, or might cause lost data. Cautions typically explain why the action is potentially problematic.
xi
Preface Commonly Used Terms
About This Document
Tip
Means a best practice or other helpful instruction. Tips typically contain recommendations that will help you use the product more effectively.
Timesaver
Means a shortcut. Timesavers typically tell you a quicker or shorter way to perform a task. They might include keyboard combinations or buttons that can be used instead of menu selections to perform the same action.
Commonly Used Terms

Throughout this document, references are made to acronyms and terms encountered with a BACnet integration. This section provides definitions for these terms and is intended to ensure their consistent use.
ASHRAE BACnet
American Society of Heating, Refrigerating and Air-Conditioning Engineers. Building Automation Controls network. An ASHRAE-developed open communications protocol designed for the HVAC controls industry, where data is modeled using a common set of objects and a standard set of services. Operation mode for a BACnet system or device, where it makes use of a BACnet device for some particular purpose via a service request instance. Operation mode for a BACnet system or device, where it provides a service to a requesting client. Refers to either/both the Niagara BACnetService, which runs in a JACE station, or the nearly identical Niagara BACnetWSService, an option for a Web Supervisor. BACnet/IP Broadcast Management Device. A device that receives and redistributes broadcast-type BACnet messages (Who-Is, I-Am, etc.) to other BACnet/IP devices on its own subnet, and sends broadcast-type messages to BBMDs on other subnets. By having one BBMD on each subnet, a BACnet/IP network can span subnets (between IP routers, which otherwise typically block broadcast-type messages). Starting in Niagara r2.3.4, the BACnet service (if configured for BACnet IP) supports operation as a BBMD.
BACnet client
BACnet server
BACnet service (Niagara) BBMD
BACnet/Ethernet or B/Eth BACnet/IP or B/IP
Native BACnet over Ethernet, one of the original BACnet link-layer types, and the first BACnet protocol supported in Niagara. BACnet over Ethernet IP, sometimes called BACnet/TCP or BACnet TCP/IP. Introduced in Annex J of the BACnet standard, it has become the most popular BACnet link-layer protocol (except in lowest-cost devices, where MS/TP is used). Niagara support for the BACnet/IP protocol was extended in r2.3.4 and later with many new features, including capability of BBMD operation.
BACnet MS/TP
The BACnet link-layer protocol used for lower-cost devices. See MS/TP.
xii
Preface
About This Document Commonly Used Terms
child object
In general Niagara terms, any object contained in another objects Workspace. Specific to BACnet shadow objects, a child object refers to any of the full or lite shadow objects contained under a BACnetDevice (parent) object. The shadow objects represent BACnet control objects in the parent device. Change-of-Value. In general Niagara terms, any object representing an external device. Specific to a BACnet integration, a BACnetDevice object is a container (parent) object that shadows a particular external BACnet device (specifically, its Device object). The BACnetDevice may contain other child shadow objects. External to a Niagara host, the station appears as a BACnet device with a BACnet Device object. This Device object has the stations name, and uses Config properties in the BACnet service.
COV device object, Device object
foreign device
A BACnet/IP term for a BACnet device that exists on an IP subnet without a BBMD, where the device can register with a BBMD on another (remote) subnet as a foreign device to explicitly receive BACnet broadcast messages. (In no way does it imply any reduced functionality.) A Niagara term for a (child) BACnet shadow object that has both BACnet required and optional properties (for that object type). Full objects are intended for use when external BACnet devices are implemented with objects having both required and optional properties. See also Lite object. A term used in learnDevice or learnNetwork that narrows the scope of shadow objects created for a device, by range(s) of instance numbers. Two or more BACnet networks connected by a BACnet router. Java Desktop Environment. The graphical engineering tool for creating Niagara station databases (formerly WorkPlace Pro). A Niagara term for a (child) BACnet shadow object that has only BACnet required object properties (for that object type), and none of the BACnet optional properties. Lite objects are useful when external BACnet devices are implemented with objects having only required properties. See also full object. Master Slave / Token Passing. A BACnet link-layer type for lower cost devices that are networked using RS-485 multidrop networks. Niagara r2.3.4 and later provides direct support for MS/TP networks with JACE-4/5 series controllers. A BACnet method to identify a particular object within a device, using a combination of its object type and a unique instance number. In general Niagara terms, any object in the station database that represents some externally-programmed device or data point (object, value, data store, etc.). Specific to a BACnet integration, there are two specific classes of shadow objects: a device object (BACnetDevice) and the various child objects.
full object
instance limits
internetwork JDE
Lite object
MS/TP
object identifier, (object ID) shadow object
xiii
Preface Related Documentation
About This Document
Related Documentation
For additional information related to Niagara and BACnet, please refer to the following other Niagara Technical Publications: Niagara BACnet Supervisor Reference, r2.3.5 Niagara Standard Programming Reference, r2.3.5 For general BACnet information, the definitive BACnet reference is the comprehensive ASHRAE specification developed and maintained by the ASHRAE Standing Standard Project Committee (SSPC) 135, entitled: BACnet, A Data Communication Protocol for Building Automation and Control Networks. Visit the official BACnet website, www.bacnet.org, for information on obtaining a copy of this specification, and for other BACnet-related information.
Document Updates
Updates to this document are listed below.
Table 1 Updates to the BACnet Integration Reference, Niagara Release 2.3.5.
Date
04/12/04
Update
Initial document published for Niagara Release 2.3.5. For information on changes made in the tridiumx/bacnet module, please refer to the Niagara 2.3.5 Release Notes document.
xiv
CHAPTER
Getting Started
Of the many integrations provided by the Niagara Framework, BACnet is the most tightly-coupled. In fact, the standard Niagara object set builds from the collection of BACnet objects, including most BACnet object properties and definitions. Core object functionality such as status flags, priority arrays and levels, event notification, and so on, have direct BACnet heritage. This chapter provides the following main topics:

Supported BACnet Features BACnet Integrations vs. Other Integrations Installing and Configuring the BACnet Service Verifying Communications Learning a BACnet Network Station Engineering Considerations Important General Facts
Supported BACnet Features

Niagara support for various BACnet features are described in the following sections:

Client Support (Shadow Objects) Exposing Objects (Server Support) BACnet Alarming Data Link Layer Support COV (Change Of Value) Subscriptions BBMD Functionality Time Synchronization
11
Chapter 1 Supported BACnet Features
Getting Started
Client Support (Shadow Objects)

Operating primarily as a BACnet client, the JACE station requests object data from other devices using BACnet services ReadProperty (and if remotely supported) ReadPropertyMultiple. For most BACnet object types, the continuously requested properties are Present_Value and Status_Flags. This data from other BACnet devices is continuously updated in either of two ways: COV (Change Of Value) Subscriptions (if the device supports SubscribeCOV) A communications polling routine
In the station, BACnet client information is represented by BACnet shadow objects. These objects exist at the BACnet device (parent) level and at the control object (child) level. The collection of a stations BACnet shadow objects define the data items for COV subscriptions/polling. BACnet shadow objects provide various right-click commands, and can be linked into other logic in the station database for control, data archiving, and presentation on web-accessible graphics. All properties of a shadowed BACnet object are available for upload, review, and if so enabled in the target (server) device, most are modifiable from the Niagara property sheet. BACnet services WriteProperty and WritePropertyMultiple (if supported) are used. Using the JDE, a BACnet Utility provides methods to automatically learn (and create) BACnet shadow objects. An option is provided to create lite versions of objects, which include only BACnet-required properties, or standard objects, which include all required properties plus BACnet-defined optional properties. Shadow objects of both types (standard or lite) are available for the following types of BACnet objects in remote devices:

AnalogInput1 AnalogOutput AnalogValue AnalogValue (priority)
BinaryInput1 BinaryOutput BinaryValue BinaryValue (priority)
MultistateInput1 MultistateOutput MultistateValue MultistateValue (priority)
1.
Special writable versions of input shadow objects are also available. Writable versions allow the present value to be set by a (Niagara) input value, providing that it is out_of_service. Use of these objects is expected to be rare.
The JDEs BACnet Utility also provides client support at the network-level for BACnet services Who-I and Who-Has, and at the device-level for the BACnet service GetAlarmSummary. For more information, refer to Chapter 2, Using the BACnet Utility, and Chapter 3, BACnet Client Operation.
12
Chapter 1
Getting Started Supported BACnet Features
Exposing Objects (Server Support)

The station running on the JACE appears to the BACnet network as a BACnet Device object, using the stations name. Its numerical object ID is assigned as a config property in its BACnet service, along with other Device-type properties. Because many standard Niagara objects are closely modeled after BACnet objects, other station data can be easily exported to BACnet. Specifically, for any Niagara station is running the BACnet service, there are currently 8 types of standard Niagara objects that can be exposed directly as BACnet objects. A single property in each object, foreignAddress, activates this feature. When making this data available, the Niagara station operates as a BACnet server. The standard Niagara objects that provide external BACnet server visibility are:

AnalogInput (AI) AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)
Calendar Schedule MultistateInput (MSI) MultistateOutput (MSO)
Exposing Niagara Logs
By using special server objects available in the tridiumx\bacnet jar in the Local Library, you can also expose Niagara logs as BACnet Trend_Log objects. For any log you wish to expose to BACnet, you use one of these log objects instead of the standard Niagara equivalent (which they otherwise closely resemble). Server log objects include:

BACnetAnalogLog BACnetBinaryLog BACnetIntegerLog BACnetMultistateLog BACnetStringLog
For more information, refer to Using BACnet Log Objects, page 4-8.
Server Support for BACnet Services
The Niagara station also provides server support to client requests for various BACnet application services, including:
ReadProperty ReadPropertyMultiple Who-Has Who-Is
WriteProperty WritePropertyMultiple I-Have I-Am
For more information, refer to Chapter 4, BACnet Server Operation.
13
Getting Started
BACnet Alarming
The JACE station supports BACnet alarming, both as a client and server. The station can route Niagara alarms to BACnet recipients, using special notification objects. These alarms appear as BACnet alarms to the targeted BACnet devices (which can also provide alarm acknowledgement). A JACE station can also receive incoming BACnet alarms, convert them to the Niagara alarm format, and route them through a Niagara system as any other alarm (including the numerous recipient options). These BACnet alarms appear in the JDE Alarm Console (and remote Vykon Alarm Service clients), and can be acknowledged like native alarms. Device objects shadowing BACnet devices also provide a Get Alarm Summary command, which returns a list of objects currently in alarm. The station can also be configured to continuously ping shadowed BACnet devices. This confirms communication status and generates Niagara device down alarms when offline status is detected. For more information, refer to Chapter 5, Configuring BACnet Alarming.
Data Link Layer Support

The JACE station can be configured to use link-layer types BACnet/IP (BACnet over TCP/IP over Ethernet) or BACnet/Ethernet, or both simultaneously. If a JACE-41 or JACE-5, additional simultaneous MS/TP (master-slave/token-passing) support is also available, with up to four separate RS-485 MS/TP networks. Unique BACnet network numbers are used for each of the link-layer tabs enabled in the JACE station. BACnet/IP is becoming more typical and is often used for newer installations. If BACnet/IP is enabled, the JACE station is configurable as either a BACnet Foreign Device or as a BBMD (BACnet/IP Broadcast Management Device) host, either of which allows BACnet/IP operation though IP routers. For more information, see BACnet/IP Considerations, page 1-11.
BACnet Router Operation
If the JACE station is configured to have more than one link-layer tab enabled, say BACnet/IP and BACnet/Ethernet, or BACnet/IP and BACnet-MS/TP, it automatically operates as a BACnet router between the different BACnet networks. Router operation is independent of other station operation (no particular station configuration is required). Upon startup, the station broadcasts the BACnet I-Am-Router-To-Network message to inform other BACnet routers that may exist on the internetwork.
Remote BACnet Router Detection
The property sheet for the Niagara BACnet service provides a router table listing any other identified BACnet routers. Typically, routers are automatically detected and stored as a result of various Who-Is and I-Am BACnet broadcast messages. In addition, you can manually enter known BACnet routers.
1. MS/TP support for JACE-NX and -NP platforms to be available at some future date.
14
Chapter 1
Getting Started Supported BACnet Features
COV (Change Of Value) Subscriptions

The JACE station can receive COV (change of value) updates from BACnet objects, via client-side support for the BACnet SubscribeCOV service. This mechanism results in quicker data updates for shadow objects than polling requests, as well as more efficient network utilization. Essentially, a BACnet shadow (client) object enabled for COV registers a subscription in the remote device, whereby it is sent data updates (notifications) upon changes in Present_Value and/or Status_Flags. For any binary or multistate-type object, this means each value change. For any analog-type object, the value change must be equal or greater than the objects COV_increment value.
COV Configuration Overview
Niagara support for SubscribeCOV is available for any remote BACnet (server) device that supports itand for as many objects that the device allows subscribed to a single client. For any BACnet device that does not support the SubscribeCOV service, polling request/response messages are used to get all data values. In the Niagara station, each BACnetDevice object has a useCOV property. If the device was learned by Niagara, and it supports SubscribeCOV, its useCOV property is initially set to True. You can then select specific child objects to useCOV, such that COV updates are used instead of polling. If, for some reason COV subscriptions are unsuccessful, polling is automatically substituted. Starting in r2.3.5, a progressive backoff scheme was implemented for COV re-subscription attempts. This provides automatic re-usage of SubscribeCOV for object updates, in cases where fallback polling of objects temporarily occurred. At the device-level, a maxCOVSubscriptions property limits the number of attempted COV subscriptions, with a default value of 50 objects. Depending on the capabilities of the target device, you may wish to adjust this up or down. A useConfirmedCOV property is also available, plus a status value showing the number of currently COV-subscribed (or confirmed-COV-subscribed) objects.
Notes
Niagara support for SubscribeCOV is client-side only. This means that Niagara objects exposed as BACnet do not generate COV notifications. However, most Niagara stations operate primarily as BACnet clients, and so server-side support for Read Property Multiple is typically used. Often, a device may state support for SubcribeCOV, but then in operation limit the number of actual COV subscriptions to only a few objects. Adjust the device property maxCOVSubscriptions within this value, and select objects carefully before enabling useCOV. Polling is automatically used for any COV-enabled shadow object that has met with unsuccessful attempts at COV subscription. This may occur for a variety of reasons, one of which is the device has run out of subscriptions. For any BACnet device that supports Confirmed COV Notification, you can choose this at the device-level (useConfirmedCOV) instead of just useCOV. It applies to all client (child) objects enabled for useCOV. However, note that this service requires extra messaging by both the station and the remote device.
15
Getting Started
Note
The similar (but different) BACnet SubscribeCOVProperty service is not currently supported in Niagara. In that service, the subscriber can specify a particular property, for example, High_Limit. However, because Niagara always requests Present_Value and Status_Flags, the overhead of this service would outweigh any benefits.
COV, Polling, and Poll On Demand

Shadow objects under a device supporting SubscribeCOV are still added to the stations BACnet polling queue, as a means of tracking subscriptions. However, polling messages (requests) are not sent for these objects. When shadow objects are in PollOnDemand containers, those that are inactive (not viewed or in the view cache) are dynamically removed from the BACnet poll queue, as before. They are unsubscribed from the BACnet device at that point. When activated, they are resubscribed and added back to the queue.
BBMD Functionality
If using BACnet/IP, the JACE station can be configured to operate as a BBMD (BACnet Broadcast Management Device). In this way, the JACE can provide support for BACnet broadcast messages to its local IP subnet. Included is the ability to register other BACnet devices as BACnet foreign devices, and to review the broadcast distribution table common to all BBMDs on the same BACnet/IP network. If no other BACnet devices exist on the same IP subnet as the JACE, its station can be configured instead to register as a foreign device with a BBMD on another IP subnet. If a BBMD already exists on the JACEs local IP subnet, the station can be simply left at the default configuration (neither a BBMD or a foreign device). Broadcast message operation relies on the existing device.
Time Synchronization
The JACE station can be configured to accept time-synchronization messages from a designated BACnet time-synchronization master. Either regular or UTC (universal time coordinated) messages, or both, can be accepted. UTC synch messages allow synchronization across time zones. This configuration is done on the BACnetServices property sheet, General, Engineering tab. Use of this feature requires configuration of the BACnet time master device, specifically, to name the JACE station as a time-synchronization recipient. This configuration is a local matter to that remote BACnet device.
16
Chapter 1
Getting Started BACnet Integrations vs. Other Integrations
BACnet Integrations vs. Other Integrations

A BACnet integration has both differences and similarities to other Niagara integrations (LonWorks, Modbus, proprietary types such as Andover Infinity, etc.).
Differences
A BACnet integration is not required to be organized under a specific container in a Niagara station (for example, lonTrunk, AcInfinityNetwork, so forth). The only requirement is that client shadow objects reside under their appropriate parent (device) shadow object. These (BACnet) device objects can be located as needed in the station database. By convention, however, you may wish to group client BACnetDevices together into containers by BACnet network, especially when multiple networks exist (BACnet internetwork). Note that on the server side, standard Niagara objects can be exposed as BACnet objects while located anywhere in the station database.
A remote BACnet device may be a BACnet workstation, typically a PC running an operator interface implemented with the BACnet protocol. In this scenario, a stations BACnet server operations may used more than client operationsfor example, to export information originating in another Niagara integration (LonWorks, Modbus, or other proprietary). The BACnet application service Who-Has, provided by the BACnetUtility View of the Niagara BACnet service, offers unique network-level search functionality. Using this command, you can search all networked BACnet devices for instances of objects by name, type, instance number, or combinations of type and instance number range. Devices report back with their objects deviceIds, objectIds, and objectNames. This data can be useful when selecting which devices and BACnet objects are of interest.

Client-side support for the BACnet SubscribeCOV service provides for better network utilization than in most other integrations, which are poll-only.
Similarities
In the JDE, the BACnet service provides a BACnetUtility View that provides learnNetwork and learnDevice commands. These commands automate the stations creation of the available BACnet shadow objects, from which you can keep those needed (and delete those that are not). These commands are similar to others in network- and device-level manager views in other integrations. For more information, refer to Chapter 2, Using the BACnet Utility. Real-time values in BACnet shadow objects are updated using a polling mechanism (if the source BACnet device does not support the SubscribeCOV service). The same polling model is used in other integrations (for example,
17
Chapter 1 Installing and Configuring the BACnet Service
Getting Started
AcInfinity, Modbus, others). In addition, a device-status mechanism is also available. Refer to Chapter 6, Configuring BACnetService Properties, for more information. As with most other integrations, shadow objects can be placed in PollOnDemand containers to further increase overall data updates.
Installing and Configuring the BACnet Service

These main topics explain initial BACnet module installation and configuration: Licensing Considerations Installing BACnet Modules Adding the BACnetService in a JACE station Configuring Essential Station Properties
Licensing Considerations
JACE Controllers Web Supervisor
JACE Controllers
JACE controllers are typically licensed to run the BACnetService. Verify this by using the Admin Tool to open the JACE, and then select the Installation tab, View License. The features line will contain bacnet. Contact Tridium if it does not. Starting in Niagara r2.3.5 (or r2.301.432 or later), a new line in the license.properties file, if present, defines the maximum number of client BACnet devices that can be shadowed in the station database. This line is:
numberOfBACnetDevices=n
Note
Note that after reaching this device limit, BACnet device learns will stop, or if BACnet device objects are manually added, will fail to properly initialize. This device limit applies across all BACnet link-layer types (BACnet/IP, MS/TP, and BACnet/Ethernet). Depending on the JACE model or licensed purchased, this limit value may vary. If this line is absent, there is no explicit device limit. In addition, the BACnet MS/TP option for a JACE-4/5 has additional license considerations. Refer to Licensing for BACnet MS/TP, page F-4.
Caution
Do not attempt to edit the license file. If you make any changes to the license file, your JACE station will not operate! Contact Tridium if you need any changes made to your license, so that you may be sent a proper license.
18
Chapter 1
Getting Started Installing and Configuring the BACnet Service
Web Supervisor
A special Web Supervisor product, the BACnet Supervisor, is available for use on a BACnet network without requiring JACE controllers. For the equivalent Niagara document on this product, refer to the Niagara BACnet Supervisor Reference. A typical Web Supervisor PC is not licensed to run the BACnetService. However, the engineering PC used by a Vykon systems integrator may be licensed that way. In this case, use the Admin Tool to open the engineering PC host, and then select the Installation tab, View License. Verify that the features line contains bacnet. A Niagara host PC may require some additional driver configuration to use the Niagara BACnet service. Refer to Appendix C, BACnet PC Notes.
Note
Installing BACnet Modules

Any Web Supervisor requires a bacnet module in its modules directory. The Niagara bacnet module is typically installed on a JACE-NX or -NP at the factory, prior to shipment. For any JACE-4 or JACE-5, you must install all needed modules. You may receive updated BACnet module files as: (for JACE-4 and JACE-5) bacnet-<release>.jar.nt (for JACE-NX, JACE-NP and Web Supervisor) where <release> is 2.305.508, or whatever the current build number is.
bacnet-<release>.jar.jace
You can follow this procedure to install all BACnet modules.

Procedure 1 Installing the necessary Niagara modules.
Step 1
Make station backups of any existing stations running BACnet services, saving databases to XML. For procedures, see the Niagara JDE Users Guide. On your Niagara engineering PC/Web Supervisor, copy the nt jar file to the Niagara modules subdirectory, for example, D:\niagara\<release>\nre\modules Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes BACnet components available to the Web Supervisor and Local Library.
Step 2
Step 3 Step 4
Close and restart the JDE to load updated module(s) on your PC. On your Niagara engineering PC/Web Supervisor, copy the nt jar file (again) to the Niagara subdirectory you use to store JACE-NX/NP modules, for example,
D:\niagara\<release>\nt
Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-NX or JACE-NP.
Step 5
On your Niagara engineering PC/Web Supervisor, copy the jace jar file to the Niagara subdirectory you use to store JACE-4/5 modules, for example,
D:\niagara\<release>\emb
Remove the .jace portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-4 or JACE-5.
19
Getting Started
Step 6
Using the Admin Tool, open the JACE host and select Installation tab, Installation Wizard. In the Select Distribution Directory dialog box: a. If you are installing modules on a JACE-4/5 controller, select emb. b. If you are installing modules on a JACE-NX/NP controller, select nt. Click Install. In the Niagara Remote Installation dialog box, click the radio button for Configure Modules Only. Click Next. In the Configure Modules dialog box, scroll down to find the row for the bacnet module and click in the Upgrade/Add column beside it. A red check mark appears besides bacnet module in Upgrade/Add. If installing in a JACE-4, also select (upgrade/add) the bacxNdio module. This allows Ndio objects in the JACE-4 to be exposed as BACnet objects.
Step 7
Step 8 Step 9
Step 10
Note
Step 11 Step 12 Step 13 Step 14 Step 15
Click Next. In the Database Backup dialog box, select the database to be backed up. Enter an administrative-level station user name and password. Click Next. Click Finish. In the summary dialog box, click OK to continue. A dialog box displays each task as it is performed. Typically, this process takes a couple of minutes. When the installation is complete, click OK.
Step 16
Adding the BACnetService in a JACE station

Procedure 1-1 Adding the BACnetService in a JACE station.
Step 1
Using the JDE, open the station and expand the stations services folder (to verify the BACnetService is missing). Open the Local Library. In the tridiumx folder, expand the bacnet jar to tridiumx/bacnet/services. Right-click the BACnetService and select Copy. Right-click the stations services container and select Paste. The service is not effective until the station is restarted. However, you should first specify the BACnet device ID for the station, as well its link-layer options. See the next section, Configuring Essential Station Properties.
Step 2 Step 3 Step 4 Step 5
110
Chapter 1
Configuring Essential Station Properties

Before starting a Niagara station with the BACnet service, it is recommended that you configure essential properties such as its numerical BACnet Device object ID, the link-layer type(s) to use, and perhaps other items.
Procedure 1-2 Specifying essential BACnetService properties.
Step 1
Under the stations services folder, right-click the BACnetService and select Go > Properties. On the General, Config tab, set the deviceID, Instance Number from the default -1 (disabled) to a unique device number for the BACnet network. Click Apply. This is the BACnet object indentifier for the Device object that externally represents the Niagara station. Valid range is from 0 to 4194302.
Step 2
Note
Step 3
Click the appropriate link-layer tab, for example BACnetIP or BACnetEthernet, and then its Config subtab. (BACnet/IP requires review of several properties.) Each of the link-layer type tabs has a network number, used to specify the BACnet network associated with that link layer. Defaults values are BACnet/IP as network 1, and BACnet/Ethernet as network 2. For any existing job that already has one or more BACnet routers, you need to edit these network numbers to match others in use. The valid range for a BACnet network is a unique number from 1 to 65535. Link-layer tabs BACnetMSTP(n) currently apply only to a station in a JACE-4 or JACE-5, and are not supported on a JACE-NP or JACE-NX. For more information, see Appendix F, Niagara MS/TP Support.
a.
Note
For BACnetIP, also see BACnet/IP Considerations, page 1-11. If not using BACnet/IP, simply set ipEnable as False, and click Apply. For BACnetEthernet, enter a value in the ethernetNetworkNumber for the BACnet network number in use. Set ethernetEnable to True. Click Apply. If not using BACnet/Ethernet, set ethernetEnable as False, and click Apply.
b.
Step 4 Step 5
After reviewing the appropriate changes on all tabs, click Apply. Save the station database and restart the station.
BACnet/IP Considerations
The address of a BACnet/IP device is determined by the combination of two things: IP address of the device UDP port number (the default is the hexadecimal number BAC0).
111
Getting Started
Depending on the configuration of other BACnet/IP devices on the BACnet network, address issues may be encountered. These issues are divided into two broad areas: Network, Subnet and UDP Port BBMD Support
Network, Subnet and UDP Port
You should know the BACnet network number used by other BACnet/IP devices on the network. The default network number (1) may be used in a new installation. Typically, the JACEs IP address, the default UDP port (BAC0), and default subnet mask (255.255.255.0) are the appropriate values. However, if part of a custom subnet, or another UDP port is being used in a BACnet/IP configuration, you might need to edit the appropriate subnet and UDP port properties.
Procedure 1-3 BACnet/IP configuration for BACnet network, subnet mask and UDP port.
Step 1 Step 2
On the BACnetIP, Config tab, set ipEnable to True. In the ipNetworkNumber property, enter the BACnet network number in use for other BACnet/IP devices. Set the needed values in the subnetMaskString and udpPortString properties. Note that subnetMaskString uses the conventional dotted decimal format. The udpPortString property requires an 0x prefix on the hexadecimal value, for example: 0xBAC1 Click Apply after changing.
Step 3
Step 4 Step 5
A station restart is needed to become effective. However, you should review other BACnet/IP properties first. See the next section, BBMD Support.
BBMD Support
In BACnet/IP networks, BBMDs (BACnet broadcast management devices) are commonly used. Using BBMDs, a BACnet network using BACnet/IP can span multiple IP subnets. Otherwise, BACnet broadcast-type messages from services like Who_Is, I_Am, (and others) are typically blocked at standard TCP/IP routers. One (and only one) BBMD is typically required on each IP subnet. If a subnet has only one or a few BACnet devices, they may each alternately register as a foreign device with a BBMD on another (remote) subnet. The BACnetService offers a number of BBMD-related options, based on the selection in the bacnetIPDeviceType property. Configuration is as either:
noneThe Niagara station does not act as a BBMD, nor is it registered with a BBMD on a different (remote) IP subnetthe default setting. This none setting is acceptable if the JACE resides on an IP subnet that currently has a device operating as a BBMD. foreignDeviceThe Niagara station registers with a BBMD on a remote subnet. You must know the IP address of the remote BBMD. In this scenario, other BACnet devices on the same (local) IP subnet (if any) are also likely to be registered as a foreign device with a remote BBMD.
112
Chapter 1
bbmdThe Niagara station acts as a BBMD on its local subnet. No other BBMD should reside on that subnet. Here again, you need to know the IP address of any other (remote) BBMD. The station will automatically copy its BBMD distribution table and update it again among all BBMDs.
Note
If the JACE is on the same subnet as a BBMD, leave these properties at defaults. The local BBMD will distribute all broadcast messages to/from the remote BBMDs.
Procedure 1-4 BACnet/IP configuration for BBMD operation.
Step 1 Step 2
Open the services property sheet to the BACnetIP, Config tab. Make the selection for bacnetIPDeviceType, based on the previous information. If selecting none, you have finished configuration. Click Apply. If selecting foreignDevice or bbmd, enter the known address of the remote BBMD in the remoteBBMDAddress property, default value is null). Entry format requires all hexadecimal with colons: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. For example, if the BBMD has an IP address of 192.168.1.21 and is using the default UDP port (BAC0), its MAC Address is: C0:A8:01:15:BA:C0 You can use the Windows Calculator to convert the IP octets from decimal.
Step 3
Note
If selecting bbmd, configuration is finished. Click Apply.

Step 4
If selecting foreignDevice, you can specify the length of time that the station registers with a BBMD in its foreign device table with the registrationLifetime property (default value is 900 seconds). The station periodically re-registers with the BBMD to maintain its table entry. Either accept this default, or enter another registrationLifetime value.
Step 5
Click Apply after changing. A station restart is needed to become effective.
Note
BACnet/IP properties are covered in Chapter 6, Configuring BACnetService Properties. Refer to Configuring BACnet/IP Properties, page 6-18.
Verifying Communications
With the JACE connected on the network with other BACnet devices, use the BACnet servicess BACnetUtility to verify communications.
113
Getting Started
Procedure 1-5
Verifying BACnet communications.
Step 1
Expand the stations services folder, and double-click the BACnetService. This opens the BACnetUtility view. Select Category: network, Command: whoIs, and then click Execute. A WhoIs dialog appears (Figure 1-1).
Figure 1-1 WhoIs dialog box.
Step 2
You can run the WhoIs command with the default options as shown above, or change them as follows: Use device instance limits?Check if you want to limit the device ID address range for the Who-Is message. Only those BACnet devices within the low limit or high limit should reply (limits are inclusive). The default device instance range is the entire BACnet device ID range (0 to 4194302). Wait time for I-Am responses (sec)The time waited after issuing the command to receive all I-am responses from all devices. Default value is 5 seconds. Typically, you would adjust this up (say, 60 seconds) if a large network with many devices, or an internetwork with BACnet routers. After issuing the command, the WhoIs dialog remains visible for this time period.
Step 3
With options either at defaults or at different values, click OK. After the I-am wait time, the utility window shows the message from each BACnet device (Figure 1-2). Each message contains five pieces of data about that device: Device Identifier(Device object Id number), unique among all devices. Maximum APDU Length Acceptedmaximum APDU length (min. = 50). Segmentation SupportedMessage segmentation, where both is best. Vendor Identifierunique number assigned to the vendor for the device. Currently, vendors by number are listed at the BACnet org website at URL:
http://www.bacnet.org/VendorID/BACnet%20Vendor%20IDs.html
Source Addresslists network number, then devices BACnet MAC address.
114
Chapter 1
Getting Started Learning a BACnet Network
Figure 1-2
BACnetUtility view, whoIs command results.
last field, sourceAddr, shows: n m:m:m:m:m:m where n = BACnet network number m: = BACnet MAC address
Issue a whoIs as often as you likeit does not write data to remote devices. Refer to Chapter 2, Using the BACnet Utility, for more details on whoIs. Refer to the Go/No-Go Communications Checklist section on page A-1 if communications cannot be verified.
WhoIs Notes
When performing a whoIs command, the BACnet service will not only learn about devices, but possibly also about BACnet routers. If you examine the whoIs results carefully, and notice a device that has responded with sourceAddr data that includes a network number that does not match the network number on the BACnetServices link-layer tabs (either BACnet/IP or BACnet/Ethernet), chances are that device is on a remote network. This means that a BACnet router forwarded your Who-Is message and the devices I-am response. To check, open the property sheet for the BACnetService. Click the tabs General, Config. At the bottom of the property sheet is a router table, listing any known BACnet routers (apart from itself). Often, a BACnet device may perform router functions in addition to other application duties. This is true for any Niagara station running the BACnet service with multiple link-layer tabs (networks) enabled.
Learning a BACnet Network

After verifying BACnet communications, you can read Chapter 2, Using the BACnet Utility, to understand the different BACnetUtility commands and how they operate, or simply choose to follow this procedure. This procedure globally makes BACnet shadow objects in the station for all devices found by the whoIs command. You can rerun this procedure (learnNetwork command) whenever needed, and/or delete any or all shadow objects that it creates.
Procedure 1-6 Learning a BACnet network (and creating shadow objects).
Step 1
Using the JDE, in the stations services folder, double-click the BACnetService. This opens the BACnetUtility View.
115
Chapter 1 Learning a BACnet Network
Getting Started
Step 2
Select Category: network, Command: learnNetwork, and then click Execute. The LearnNetwork dialog box appears, with options to Learn device contents (create child objects under device objects) and Use lite objects (Figure 1-3). You can also specify device ID instance limits, and modify the collective wait time for receiving I-am messages. In general, option defaults are recommended (see Tip).
Figure 1-3 LearnNetwork dialog determines whether child objects are created.
Learn commands from the BACnetUtility place created shadow objects in a BACnetTemp container in the stations root, also automatically created (if not already existing).
Tip
Unless you are learning a BACnet network with very few devices, or you have restricted the device ID range to include only a few devices, and all devices contain only important objects, it is recommended that you leave the Learn device contents option cleared, as shown here. Otherwise, the Learn Network command will attempt to create a shadow object for every BACnet object in every BACnet device within the device ID range, and you may easily create more objects than you intended. Also, if BACnet MS/TP is enabled, be aware that only the first 31 devices can be learned on any MS/TP trunk (network)the learn will skip to another link-layer (network), or stop at this point. And if a JACE-403, the learn automatically stops whenever the maximum 27 BACnet devices have been learned. If you clear Learn device contents, the learn still creates a BACnetDevice shadow object for each discovered device. You can then individually learn each device, applying instance limits for the various BACnet object types, as needed, and select lite objects if wanted. See the learnDevice section on page 2-9 for more details.
116
Chapter 1
Getting Started Learning a BACnet Network
Device instance limits are inclusive. For example, if you check device limits and enter a low limit of 99 and high limit of 102, a maximum of four devices can be learnedthose with device IDs 99, 100, 101, and 102. Note the default I-am wait time is 5 seconds. You may need to adjust this upwards, especially if you found that some devices did not reply previously to a whoIs command unless this value was set higher (Verifying Communications, page 1-13).
Step 3
Usually (as noted above), you go with default settings, and click Apply. The BACnetUtility window updates with progress messages as it creates a BACnetTemp container (Figure 1-3), and a BACnetDevice object for each discovered device. If Learn device contents was selected, shadow objects are also created for all BACnet objects in every device. Lite objects are similar to standard BACnet shadow objects, but contain only required BACnet properties, whereas normal BACnet shadow objects contain both required and optional properties. For example, lite shadow objects for Analog_Inputs do not have alarm limit properties, and so forth. They are best for devices that contain objects mostly with required properties only, as they consume less station resources. However, note that a lite object counts towards the licensed limit the same as a standard object.
Note
Depending on the number of networked BACnet devices and their contained objects, this may take from several minutes to over an hour. During this time, the status bar at the windows bottom continues to periodically flash. When the learnNetwork command is done, the status bar displays Network learn complete (Figure 1-4). An Abort button (Figure 1-4) is available. You may wish to abort a learn in progress for these reasons:

Note
It is taking longer than expected. The learn is creating more shadow objects that originally estimated. This might occur if you are not familiar with the object contents of some BACnet devices.
When you abort a learn, any BACnet objects created (up to the point of the abort) remain in the station database. See Step 4.
Figure 1-4 Status bar updates during operation and ends with Network learn complete.
Abort button. Status bar.
Step 4
When the learnNetwork command has finished, expand the BACnetTemp folder in the Tree View (Figure 1-5, left). A BACnetDevice object will exist for each BACnet device learned by the utility.
117
Chapter 1 Learning a BACnet Network
Getting Started
Figure 1-5
BACnetDevice objects are created in a BACnetTemp container.
Step 5
In the Tree View, double-click on BACnetDevice to see the child objects created (Figure 1-5, right). This applies if you selected the Learn device contents option. Refer to the the learnNetwork section on page 2-6 for more details. For information on the individual shadow objects created by the BACnetUtility, refer to Chapter 3, BACnet Client Operation.
Notes
Once a BACnet device is learned, it is not polled until you right-click on its associated device object in the JDE Workspace and select enablePolling. This clears the outOfService status for that device object.
Right-click device, set enablePolling Object shape changes from cyan to gray.
On the Config tab of the property sheet for any BACnetDevice, the writePropertyEnabled property must be set to True in order for any input links, object commands, or writes to properties for any of the BACnetDevice objects child objects to become effective (write to the BACnet device). In addition, the remote BACnet device may require local configuration to authorize these writes. Refer to the Properties That Do Not Write to the Device section on page 3-13, for related information on BACnetDevice configuration.
118
Chapter 1
Getting Started Station Engineering Considerations
Station Engineering Considerations

BACnet networks are often big, and may easily contain 100 or more devices. In addition, a single BACnet device may contain hundreds, or even thousands, of BACnet objects. A complete learn (of all BACnet devices and objects) in such a system is typically not desirable. Usually, only some of the objects in any device are of any interest in the station. Also, some BACnet devices have been known to contain many objects that are actually unused. Shadowing these unused objects is actually detrimentalstation resources, processing, and network traffic is increased, but without any payback. For these reasons, it is recommended that a learnNetwork for most BACnet networks is given without the Learn device contents option enabled (cleared). This will make one BACnetDevice container object for each device, with all the device objects residing in the BACnetTemp folder. You can then individually learn each BACnetDevice, using the learnDevice command, along with its instance limits feature (if necessary). For more details, refer to the learnDevice section on page 2-9.
Important General Facts

Although the following topics are explained in full context in various parts of this document, they are important enough to be assembled here for your convenience.
1.
Polling is not automatic for any new BACnetDevice object, whether learned (typical) or if copied from the Local Library (with edited objectIndentifier). Child objects typically appear with a value that was uploaded when the device was learned, but that value will remain frozen unless polling is enabled. To enable polling, find the BACnetDevice in its workspace, right-click it, and select enablePolling. For a related graphic, see the Notes on page 1-19. In order to command remote BACnet objects, or to successfully have Niagara write to object inputs, the writePropertyEnabled property of the parent BACnetDevice object (Config tab) must be set to True. Refer to Properties That Do Not Write to the Device, page 3-13.
Note
2.
In Niagara BACnet releases prior to r2.3.4, the writePropertyEnabled property default value was False, even for learned devices. Note this since changed for learned devices, such that the default value is True. This is a convenience change, because it is typically needed as True.
Also, the remote device (itself) must also permit BACnet writes. This is typically a local configuration matter, and varies from device to device. Please note that if you have any learned device that you wish to remain read-only from Niagara, you should set its devices writePropertyEnabled property value from True to False.
119
Chapter 1 Important General Facts
Getting Started
3.
In order to allow remote BACnet devices to command or write properties to objects exposed in the station as BACnet objects, you need to define a station user account named BACnet (with proper permissions). Refer to Allowing BACnet Write Access, page 4-6. If exposing Niagara Multistate objects (MultistateInput, MultistateOutput) as BACnet objects, you need to remove the zero (0) field from the stateText property (Visual tab) first. Otherwise, the object will not be exposed. For more details, refer to Multistate Object Considerations, page 4-5. Per the BACnet specification, the outOfService flag for any client object, (BACnetDevice included), actually sets that object to be Out_Of_Service in the remote device. To send alarms, a BACnet device receiving the alarm must be shadowed in the station (as a BACnetDevice), plus the recipientDeviceId must be specified in the BACnetRecipient notification object. Also, Niagara does not add notification classes of a remote BACnet device; our address will need to be added on the third-partys side manually.
4.
5.
6.
7.
BBMD is for IP where a Who-Is or learn operation is required over/through routers. The MAC address is the IP + UDP of the BBMD. See BBMD Support on page 1-12. For more detailed explanations, refer to Configuring BACnet/IP Properties, page 6-18, and BACnet/IP and BBMDs, page E-3.
8.
Niagara supports subscribeCOV for client objects, providing the device supports it on the server side. You must individually enable COV usage for each objectand it is recommended that you do this in some order of importance, as devices often limit the number of COV subscriptions. For more information, refer to Using COV in Shadow Objects, page 3-18. Niagara automatically uses the readPropertyMultiple service for any learned device that supports this service. This increases polling efficiency.
9.
120
CHAPTER
Using the BACnet Utility

The Niagara BACnet service provides a BACnetUtility View for use in the JDE. This view provides learn commands to automate the creation of BACnet shadow objects in the station, including a complete set of the child objects within each device. The BACnetUtility also provides standard BACnet application services, such as Who-Is, Who-Has, and Get Alarm Summary. The following main sections are contained: Opening the BACnetUtility Using Network Commands whoIs whoHas learnNetwork Using Device Commands learnDevice getAlarmSummary Manually Adding BACnet Shadow Objects Adding a Device Object Adding a Child Object
Opening the BACnetUtility

The BACnetUtility is the default JDE view for the BACnet service. To open the BACnetUtility in the JDE, expand the services folder in the Tree View and double-click the BACnet service. The utility appears in the Workspace (Figure 2-1).
21
Chapter 2 Opening the BACnetUtility
Figure 2-1
BACnetUtility is default view for BACnetService.
Command selections
Action Buttons (see next section)
Status Line History (expand control)
The BACnetUtility provides two categories of commands you can execute: networksee Using Network Commands devicesee Using Device Commands
Action Buttons
Action buttons appear near the bottom of the BACnetUtility view, described below: ExecuteExecutes the currently selected utility command. After executing any BACnetUtility command, output results appear in the main window. A right-side scroll bar appears whenever results exceed the main area. SaveProduces a dialog box for you to save the last command results to file, including controls to specify any target drive or directory on your PC. Use MS Word, Wordpad, or a similar programs to work with saved files.

AbortApplies to learn type commands only. Stops any learn in progress.
Status Line History

At the bottom of the BACnetUtility view is the status line, showing the last line of output results from the last command. To see all command results (since first opening the utility), click the expand control. A Status Line History window appears, showing the results of the first command through the most recent. As needed, use the scroll bar to view items of interest.
22
Chapter 2
Using the BACnet Utility Using Network Commands
Using Network Commands

Under the network category, there are three commands available: whoIsDiscovers possible BACnet devices on the network. whoHasSearches for a specific BACnet object by name or object ID. learnNetworkCreates shadow objects for devices and optionally, children.
The whoIs and whoHas commands work with complimentary I-Am and I-Have services offered by networked BACnet devices. All of these BACnet services are unconfirmed types.
whoIs
This command is for the BACnet Who-Is service. By default, the station issues a globally broadcast Who-Is, sent to all possible BACnet devices (Figure 2-2). Sections ahead describe WhoIs options and results.
Figure 2-2 WhoIs dialog box, showing default settings.
Options
The WhoIs dialog provides two types of options: Device Instance Limits Wait Time for I-Am
Device Instance Limits

By default, the device instance limits option is clearedthe entire possible BACnet device ID range receives the Who-Is broadcast. If you check this option, you can enter a low limit and high limit for BACnet devices to respond to the Who-Is. Low and high limits are inclusive. For example, if you specify a low limit of 50 and a high limit of 60, you should receive no more than 11 total responses, namely for devices with device IDs of 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, and 60. If only a single device is wanted, simply enter the same number for low limit and high limit. In the case of misconfiguration, multiple devices may be assigned the same numerical device ID, and you may see duplicates using the same number.
Note
23
Chapter 2 Using Network Commands
Wait Time for I-Am

The wait time applies after you click OK (to issue the Who-Is command) before the received I-Am results are posted in the BACnetUtility window. The default value of 5 seconds may be sufficient where there are relatively few devices, or perhaps where they are all BACnet/Ethernet or perhaps BACnet/IP. In general, however, a longer wait time is recommendedperhaps 60 seconds or higher, especially if MS/TP devices exist or if there are many BACnet routers.
Results
Results from the whoIs command display in the utility window, in order of being received. Each I-Am message contains five pieces of information about that device: Device IdentifierThe object identifier of the Device object in the device. Maximum APDU Length AcceptedThe largest PDU, in bytes, handled by the devices BACnet application layer. The Niagara max APDU is 1500 bytes. Segmentation SupportedWhether message segmentation is supported by the device: either no, transmit, receive, or both, where both is best. Vendor IdentifierUnique number assigned to the vendor for the device. Currently, vendors by number are listed at the BACnet org website at URL:
http://www.bacnet.org/VendorID/BACnet%20Vendor%20IDs.html
Source Addresslists network number1, devices BACnet MAC address.

The whoIs command can find all BACnet devices on the network.
Figure 2-3
On the server-side, a Niagara station sends an I-Am message to respond to Who-Is service requests from other networked BACnet devices. In addition, the station sends an I-Am message upon each station startup (power up, reboot, or restart).
1. Network number matches that configured on the corresponding link-layer tab in the Niagara BACnet service. BACnet devices that are connected to a single network may not actually know their network number.
24
Chapter 2
whoHas
This command launches a dialog box to set parameters for the BACnet Who-Has service (Figure 2-4). Using this command, you can search networked BACnet devices for specific objects by name or by object ID (combination of object type and instance number). Devices respond using the I-Have service. You can further request that only devices within a certain device ID-range respond to the Who-Has request.
Figure 2-4 WhoHas dialog allows search by object name or object ID.
Select search either by object name or object ID. If by name, the exact name is needed. See Note below. If by object ID, you must select an object type and a specific instance number. Check device instance limits only if you want to limit the Who-Has search to a range of devices, for example, 5 to 15.
Note
If searching by object name, note the name is case-sensitive and must be complete (no wildcard characters). In addition, the I-Have service in a Niagara station responds to a Who-Has-by-name search request only if the objects swid is given. When the service executes, it returns an I-Have message from any networked BACnet device that meets the search parameters. Each I-Have message returns three pieces of information from that device: Device IdentifierThe device objects identifier. For example, device: 14. Object IdentifierThe object identifier of the target object in that device. Includes object type and instance number. For example, analog_inpuput: 1. Object NameThe objects BACnet name. For example, ExhDamper1.
Figure 2-5 Example WhoHas results.
25
learnNetwork
The learnNetwork command provides a single-click method to create BACnet shadow objects in the station for all currently communicating BACnet devices. For step-by-step instructions, refer to Learning a BACnet Network, page 1-15. You can select LearnNetwork to create shadow objects for: Only BACnet devices, which is the default and recommended setting. Both devices and all their contained (child) objects (Learn device contents). If creating child objects, to create only Lite objects. These objects expose only BACnet-required properties, and omit all optional properties. Variations of the above for any range of devices, by device instance number. This works as in the whoIs command, see Device Instance Limits, page 2-3
Note
The default LearnNetwork dialog is shown in Figure 2-6.

Figure 2-6 User dialog for LearnNetwork command.
Learn device contents creates all objects under every device. Recommendation is to leave this cleared. Then use Use lite objects applies only if learning device contents. Device Instance Limits narrows range of devices to learn. Default is all possible devices (up to 4194302 devices). Wait time to receive all I-Am messages, before shadow object creation process starts. Default is 5 secondsadjust upwards if many devices, BACnet routers, etc.
Notes
Once a BACnet device is learned, it is not polled until you right-click on its associated device object in the JDE Workspace and select enablePolling. This clears the outOfService status for that device object. Typically, you should also configure each BACnetDevice object. Refer to the BACnetDevice Notes section on page 3-11 for more information. If you move a BACnet device object from the BACnetTemp folder, the learn device contents option of LearnNetwork has no further effect on it. However, you can still use the learnDevice command from the device Category.
26
Chapter 2
How it Works
The learnNetwork command performs a number of actions, executed in this manner:

1. 2. 3. 4.
A Who-Is request looks for all BACnet devices within the specified range. Each unique I-Am response received represents a single BACnet device. If BACnet devices are discovered that do not already have a corresponding shadow object, a folder called BACnetTemp is created (if not already existing). A device object for each newly-discovered device is created in BACnetTemp. Properties for each BACnetDevice object are uploaded. If LearnDevices was selected, BACnet shadow objects for all AI, AO, AV, BI, BO, BV, MSI, MSO, and MSV objects are created under each BACnet device object, where: a. If Use lite objects was selected, lite versions are created. b. If Use lite objects was cleared, full versions are created. Object properties are uploaded, along with a value and status (at time of shadow object creation). However, values remain static until you give the parent BACnetDevice object an enablePolling command.
Note
If the learnDevice encounters a device limit, which may occur after 31 devices are learned for an MS/TP trunk, or for 27 total BACnet devices if a JACE-403, a message similar to the following is displayed: Unable to create shadow object for device <deviceName> [deviceId], addr <address> due to device count limitations When doing a learnNetwork command but not learning devices, you would get a return similar to the following.
Figure 2-7 Example learnNetwork with options cleared (not learning devices).
Examples
As shown in the example above, no device child objects were created. In this particular case, a BACnet device object for device 14 already existed. If instead you ran learnNetwork and included learning device options, you would get a return similar to one shown in Figure 2-8.
27
Figure 2-8
Example learnNetwork with Learn device contents option selected.
Note
If you click Abort during a learnNetwork, all BACnet objects created up to that point remain in the station database. The object shape (glyph) for each BACnetDevice shows both the associated BACnet network number as well as the devices instance number, as shown in Figure 2-9.
Figure 2-9 BACnetDevice shape in JDE shows network and Device instance numbers.
This BACnetDevice object shadows BACnet device 501 named Btest19, located on network 85.
BACnetDevice Shape Information
This BACnetDevice object shadows BACnet device 103 named device_103, located on network 11.
In the case of a BACnet internetwork (multiple networks) you may find this information useful. For example, you can cut and paste devices from the BACnetTemp container to a new container you have created for a particular BACnet network, where you can perform the learnDevice command on each device. For more information on the learn device utility, see learnDevice, page 2-9. For information about shape information for child shadow objects, refer to Shape Information, page 3-16.
28
Chapter 2
Using the BACnet Utility Using Device Commands
Using Device Commands

Under the Category device, there are two commands available: learnDeviceCreates child shadow objects for the selected BACnet device. getAlarmSummaryReturns a list of object identifiers in the device that are currently in an alarm state. This is a standard BACnet application service. You can run the learnDevice command even if the device was previously learned.
learnDevice
As with the learnNetwork commands Learn Device option, you can select BACnet shadow objects to be either full or Lite types. In addition, you can specify whether or not: Existing shadow objects should be re-uploaded (overwritten in the station). Instance number limits should be used, available for each object type.
Procedure 2-1 Using the learnDevice command.
Step 1 Step 2 Step 3
Start the BACnetUtility by double-clicking on the BACnet service. From the Category drop-down list, select device. From the Device drop-down list, click the target device. Only devices with BACnet device shadow objects created with learnNetwork (or that were manually added from the Local Library) will appear in the list. Verify the Command drop-down list shows learnDevice, and click Execute. The LearnDevice popup dialog appears (Figure 2-10).
Figure 2-10 LearnDevice popup dialog to set Learn Device options.
Step 4
29
Chapter 2 Using Device Commands
Step 5
As needed, select or clear the LearnDevice options: Upload existing objectsIf checked, existing shadow objects in the station are recreated (in addition to any new objects). If cleared, only new shadow objects are created. Use lite objectsIf checked, Lite shadow objects are created. If cleared, full versions of shadow objects are created. Wait time for device I-Am response (sec)Default is 5 seconds. You may wish to adjust this upwards if the device is reached through a router. Use instance limitsBy default, this option is cleared. If checked, these other fields in the dialog become active: Object type Instance Number Range Configured Types (read-only) If left cleared, skip ahead to Step 7.
Note
The need for instance limits depends on a number of factors. Instance limits are useful when a device contains an extraordinarily large number of BACnet objects. For example, a device may contain 1000 Analog_Value and 1000 Binary_Value objects, although only a small portion are actually used. If you do not define instance limits for that portion, learnDevice will create shadow objects for all object instances, needlessly consuming both station resources and your time. For the example device with 2000 objects, learn time without instance limits could easily take from 3 to 4 minutes to much longer, depending on a number of factors. You would also see only a small portion of the objects in the workspace of the BACnetDevice, although they would be visible in the Tree View. When engineering a station, you typically wish to limit the creation of shadow objects among devices. For example, you may know that for a particular device, the only objects of interest are Analog_Inputs in the instance range from 5 to 20, Analog_Values under instance 10, and Binary_Outputs instances 1 and 2. By specifying these instance limits (and none for other object types) before executing the learn, only objects of interest are learned. Without instance limits, a learn would probably create objects you would then have to delete, in order to have adequate allocation of client objects among devices. Furthermore, for any device you can rerun learnDevice with different instance limits as many times as needed. This is one strategy to avoid having objects unavailable in the device container workspace. Here, you could create sub-containers under the BACnetDevice, and cut and paste groups of learned objects (as needed) into them.
Step 6
As needed, set the instance limits needed for each object type in the device, following these substeps.
a. b.
From the Object type drop-down list, select an object type. In the Instance Number Range field, type a number range or ranges. Use a hyphen (-) in a range and a comma (,) between numbers or ranges.
210
Chapter 2
For example: 1-5,12-16,19,205-207 specifies object instances 1, 2, 3, 4, 5, 12, 13, 14, 15, 16, 19, 205, 206, and 207.
c.
Press ENTER to configure this instance range for the selected object type. The object types abbreviation will appear in the Configured Types field, as shown in Figure 2-11. You must press ENTER to enter the instance range for any object typenote that this does not trigger the learn, but only enters the range.
Note
d.
Repeat, as necessary, starting again at step a for each object type requiring instance number limitations. The default instance range for any object type is all. You can re-enter all, if needed, for any object typethis removes instance limits for that type. You can also enter none, if needed, to prevent the learning of that particular object type. You see a final summary of instance ranges when you click OK.
Use the ENTER key after setting instance limit range(s) for each object type.
Note
Figure 2-11
Use the drop-down control to select each object type that requires instance limits. Type the instance limits needed for the selected object type, hitting ENTER when done.
Abbreviations for all object types that have been assigned instance limits appear in Configured Types.
Step 7
When options are set as needed, click OK. The LearnDeviceContinue popup displays, showing instance limits (Figure 2-12). If you are not using instance limits, all object types will show all.
211
Chapter 2 Using Device Commands
Figure 2-12
LearnDeviceContinue popup lets you review what objects can be learned.

If instance limits are not used, all possible object types show all, as shown here.
Finish launches the LearnDevice routine, creating shadow objects as defined.
Back returns you to the LearnDevice dialog, where you can adjust instance limits as needed.
To start LearnDevice, click Finish, or To set or change any instance limits, click Back. (You may need to check Use Instance Limits, if not previously checked.) Follow Step 6 to apply instance limits by object type. As LearnDevice operates, results display in the utility window (Figure 2-13).
Figure 2-13 LearnDevice results display in the BACnetUtility window.
212
Chapter 2
Notes
The learnDevice command works regardless of where the device shadow object is located in the station database (does not need to be in BACnetTemp). Existing lite shadow objects in a device, if any, are not converted to full objects even if Upload existing objects is selected and Use lite objects is not. If you need full versions, select and cut the existing lite ones from the station database, and then rerun the learnDevice command. When existing shadow objects are uploaded, device-resident properties are relearned, but Niagara-related properties such as description and executionParameters remain unchanged. Object links also remain unaffected. If you want to exclude any object type(s), select Use instance limits and enter none for the Instance Number Range, as needed, for each object type. Instance limits does not affect any existing shadow objects that do not fall into the entered number range.
getAlarmSummary
The getAlarmSummary command returns a list of object indentifiers in a device that are currently in alarm. You can use this command on any BACnet device on the network that has a device shadow object (regardless if it has child shadow objects).
Procedure 2-2 Using the getAlarmSummary command.
Start the BACnetUtility by double-clicking on the BACnet service. From the Category drop-down list, select device. From the Device drop-down list, click the target device. Only devices with BACnet device shadow objects created with learnNetwork (or that were manually added from the Local Library) will appear in the list. From the Command drop-down list, click getAlarmSummary, and click Execute. The device is queried and the results appear in the utility window (Figure 2-14).
Step 4
213
Chapter 2 Manually Adding BACnet Shadow Objects
Figure 2-14
The getAlarmSummary command queries the device for active alarms.
Results show three pieces of data for any object currently in an alarm condition: Object IdentifierThe object type and instance number. Alarm StateThe current value of the objects Event_State property. Acknowledged TransitionsThe value of the objects Acked_Transitions property. A missing transition means an acknowledgement is still pending.
Notes
Object names are not returned by the BACnet GetAlarmSummary service. However, you can use the network command whoHas, and search on the appropriate object Id, limiting the device instance high and low to the target device, in order to see the object name. A Niagara station can also generate and receive (and reformat) BACnet alarms. Refer to Chapter 5, Configuring BACnet Alarming, for more information.
Manually Adding BACnet Shadow Objects

As an alternative to using the BACnetUtility learn commands, you can manually add BACnet shadow objects (Device and various child objects) to the station. To do this, you need to copy the objects to the station database from the Local Library. However, you will need specific details about the BACnet objects for correct communications and operation. These details are automated by the learn commands. For this reason, manual addition of shadow objects is not typically done, except for the writable types of input objectsthese objects must be added manually. Writable input objects provide a linkable input that allow you to simultaneously override the objects present value and set it to out_of_service. Adding a Device Object Adding a Child Object
214
Chapter 2
Using the BACnet Utility Manually Adding BACnet Shadow Objects
Adding a Device Object

To manually add a BACnet device shadow object, you must know the instance number of its Device object. Essentially, this is the unique logical address for the device on the BACnet network (or if multiple networks, across the entire BACnet internetwork).
Procedure 2-3 Adding a BACnetDevice object.
Working in the Tree View of the JDE, open the Local Library. Expand the /niagara/<release>/tridiumx folder to reveal the bacnet jar file. Expand the objects folder, right-click on BACnetDevice, and select Copy. In the station database, expand the database to select the target container. You can put the device object wherever it logically makes sense. Right-click and select Paste. Right-click the object and select Go > Properties to open its property sheet. Edit the Config property objectIdentifier, Instance Number, to the correct value. This automatically causes a network command whoIs, which should populate the objects address property value with the correct MAC Address. Select upload from the Commands menu, then Yes (you wish to upload). The status bar (at the bottom of the window) updates with upload progress data. You can verify the upload by looking at various Config properties of the object, for example, objectName and vendorId, which should have values.
Step 8
Notes
Typically, you would rename a manually created BACnetDevice object. You can use its objectName (or some portion), and combine it with instance number, if neededfor example, Alerton3_AHU1. A newly-added BACnetDevice object is outOfService, by default. You can give the enablePolling command to clear this status. This also causes any child objects created for the device to be immediately polled.

After you add a BACnetDevice, it appears in the BACnetUtility under the drop-down list of Devices, and the LearnDevice command is available. If adding a BACnetDevice object that represents an MS/TP slave device, you must also enter its network number and MAC address (in hexadecimal). For more details, refer to Working with Slave Devices, page F-18. Be aware that if attempting to add a device object where the allowed limit of BACnetDevices already exist, you will receive an error message and the object will not be created. This scenario might come up if adding more devices on the same BACnet MS/TP trunk than allowed in the license, or whenever 27 total BACnet devices already exist in a JACE-403 station database.
215
Chapter 2 Manually Adding BACnet Shadow Objects
Adding a Child Object

To manually add a BACnet shadow object for a device, you first need to determine:
1.
The type of BACnet object to be shadowed. Available shadow object types in the Local Library include both lite and full versions of these types: AnalogInput AnalogOutput AnalogValue BinaryInput BinaryOutput BinaryValue MultistateInput MultistateOutput MultistateValue MultistateValuePriority
AnalogInputWritable BinaryInputWritable MultistateInputWritable
AnalogValuePriority BinaryValuePriority
2.
The numeric instance number (Object_Identifier) for that object.

Adding a child object.
Procedure 2-4
Working in the Tree View of the JDE, open the Local Library. Expand the /niagara/<release>/tridiumx folder to reveal the bacnet jar file. Expand the objects folder, right-click on the object needed, and select Copy. In the target container in (or under) the appropriate BACnetDevice, or in the WorkPlaceEditor view of this container, right-click and select Paste. Open the objects property sheet and edit the Config property: objectIdentifier, Instance Number. Select upload from the Commands menu, then Yes (you wish to upload). The status bar (at the bottom of the window) updates with upload progress data. You can verify communications by looking at the objects Status property presentValue, which should have a value. After uploading the object, you should rename it to match the BACnet object being shadowed in the device (this is automatically done when adding objects using learn device commands in the BACnetUtility). To rename the object: On the Config tab of the objects property sheet, highlight the objectName. b. Press CNTRL-C to copy the name to the Windows clipboard. c. Highlight the object in the Tree View (or select it in the WorkspaceEditor of the BACnetDevice container), right-click, and select Rename. d. With the current name highlighted, press CNTRL-V (this pastes the copied objectName into the Rename dialog). Press OK.
a.
Step 5
Step 6
Step 7
Note
In general, it is recommended that you use the BACnetUtility learn device commands rather than manually adding shadow objects. When adding objects manually, there is a risk of mismatched types and/or instance numbers.
216
CHAPTER
BACnet Client Operation

As previously mentioned, remote BACnet objects are modeled locally within a Niagara station as shadow objects. Essentially, these objects act as the interface to a stations BACnet client operation. The following main topics are explained ahead: About BACnet Shadow Objects About Lite BACnet Objects About Writable Input Objects BACnet Integration Objects
BACnetDevice BACnetAnalogInput BACnetAnalogOutput BACnetAnalogValue BACnetBinaryInput BACnetBinaryOutput BACnetBinaryValue BACnetMultistateInput BACnetMultistateOutput BACnetMultistateValue

BACnetAnalogInputWritable BACnetAnalogValuePriority BACnetBinaryInputWritable BACnetBinaryValuePriority BACnetMultistateInputWritable BACnetMultistateValuePriority
About BACnet Shadow Objects

BACnet shadow objects provide station access to BACnet objects in networked devices, including input and output link access. BACnet shadow objects have common characteristics, explained below. The entire collection of BACnet shadow objects can be divided in 2 classes: BACnetDevice objectA container that can reside anywhere in the station database. Each represents an individual BACnet device. BACnet objects (children)Can reside only under a BACnetDevice object. There are 15 types available, with 2 versions of each type (full or lite).
31
Chapter 3 About BACnet Shadow Objects
Property Types
Each BACnet child (data) object has a polled property, statusOutput, that appears on the objects shape, as shown in Figure 3-1. This ouput represents current values polled1 from the source objects properties statusFlags and presentValue.
Figure 3-1 Each statusOutput (sOut) property is a polled ({P}) property.
statusOutput reflects statusFlags by color in Niagara, both for object shape and statusOutput. See Object Color and Status, page A-2.
Provided that polling is enabled (at the parent BACnetDevice level), statusOutputs of child objects continuously update. If the object is a type with a priorityArray input (AO, AVP, BO, BVP, MSO, MSVP), the source objects priorityArray property is also updated through polling.
On Demand Transient
Apart from statusOutput and priorityArray, most other properties of BACnet shadow objects are considered on_demand_transient types in Niagara. These property values are captured in any upload (from the device to Niagara), but are not stored in the station database. An upload occurs automatically whenever a device is learned, that is, when each object was initially created in the station. Following this initial upload, a fetch command (or upload command) is necessary to refresh these values. These commands are available at the individual object-level, either as right-click or JDE menu bar commands. An uploadAll command is also available at the device-level.
Notes
After a station restart, the on_demand_transient properties will show default values (0.0 or false). For any BACnet object of interest, a fetch command will be necessary. An uploadAll command (at the device level) can also be used. Many of these properties are persistently-stored by the BACnet (foreign) device. They are indicated on property sheets by an {F} in the property label:
covIncrement {F} <value>
A few of these {F} properties are also persistently stored in a Niagara station. These properties are description, objectName, units (for analog types) and stateText (for multistate types). These properties are the principle difference between a fetch and an upload. A fetch does not replace these values in the station, whereas an upload does.
1. Child objects using COV have statusOutput updates from COV notifications.
32
Chapter 3
About Lite BACnet Objects

Lite shadow objects include only required properties for that BACnet object type. Starting in Niagara r2.3.4, each Lite object appears in the JDE Workspace with extra -Lt text in the object shape to differentiate it from a full object.
Figure 3-2 Lite object shapes include the text -Lt after the object type abbreviation.
Lite objects have -Lt after type abbreviation inside object shape. For example: AVP-Lt MSI-Lt and AO-Lt.
Full objects show the type abbreviation, but without -Lt.
Lite objects are the best choice for a device that contains objects with only required properties, and few (if any) optional properties. Usually, optional properties relate to event (alarm) detection, and occasionally an isolated configuration property (for example, resolution).
Tip
If in doubt, use the BACnetUtility to learnDevice, clearing the option Use lite objects. This creates full BACnet shadow objects. Then open the property sheet for a representative shadow object, and click the Fetch button. The status bar at the bottom of the window shows updates, including errors. Click the pointer in the lower-right corner to open the Status Line History. Any read failed for property <propertyName>:unknown-property entries indicate that these optional properties are not implemented in that device.
Notes
Object descriptions given in sections ahead (for the different types of BACnet shadow objects) do not include separate sections for the Lite objects. Instead, those properties not included in Lite objects are noted as not Lite objects. There is no Lite version of a BACnetDevice object. For any type of shadow object, there is no difference in inputs and outputs (or object shape) between its full version and its Lite version.
About Writable Input Objects

Starting in Niagara r2.3.4, writable versions of BACnet AnalogInput, BinaryInput, and MultistateInput objects are available for manual copy and paste from the Local Library (Figure 3-3). Both full and lite versions of these objects are available. You can use these writable objects in place of the standard equivalent input objects.
33
Chapter 3
Figure 3-3
Writable input objects must be copied from the bacnet JAR in the Local Library.
Writable input types operate exactly like normal input objects. However, writable objects have one important addition: a linkable statusInput that allows you to force the target object to a Niagara value with an out_of_service status. Whenever this input value returns from an out_of_service state, the input value is ignored and the source object is under local device control. See Figure 3-4 for an example.
Figure 3-4 Writable input objects respond to an out_of_service statusInput.
Writable input object, linked to another object.
Here, the linked AO is first commanded to a value (in this case 123 ). Then the AOs outOfService property is set to True, as shown below.
Input value is ignored if input is not out_of_service.
While its statusInput is out_of_service, the writable input BACnet object uses the input value as present value, and its own statusFlag is set to out_of_service.
Use of this feature is expected to be atypical, perhaps for early commissioning or application testing. For more information on manually adding objects, see Manually Adding BACnet Shadow Objects, page 2-14.
34
Chapter 3
BACnet Client Operation BACnetDevice
BACnet Integration Objects

This section provides descriptions of all the BACnet shadow objects. Covered first are details on the BACnetDevice object, then properties common among all (child) BACnet shadow objects. Right-click commands for these objects are also explained. BACnetDevice BACnet objects (children)
BACnetDevice
abbrev: Device n The BACnetDevice object is the Niagara shadow object representing a remote BACnet device. Specifically, it shadows the BACnet Device object in that device. This is a container object, under which BACnet (child) shadow objects can exist (either directly, or in other containers such as PollAlways and PollOnDemand). The BACnetDevice can be pinged by the BACnet service to determine if the device is still communicating.
Default Resource Count: 78 to 107, plus the sum of all child object resource counts.
Inputs
Default Object Shape

Outputs
All Used Inputs / Outputs

Inputs
(not shown): executeTrigger
Outputs
systemStatus deviceDown
Input/Output Property Reference for BACnet Device Object

(only input and output types, see Table 3-1 for all properties)
Type
input output
Label
exe system down
Property Name
executeTrigger systemStatus deviceDown
Data Species
TriggerType BACnetDeviceStatusEnum BooleanStatusType
Shape Information
Numbers (n) inside the BACnetDevice object shape (Figure 3-5) reflect as follows: Net nBACnet network number. Matches network number1 on the services link-layer tab if a local network, or is a different number if a remote network. Dev nUnique instance number of that devices Device object.
In addition (if the object was created by the learnNetwork command), the name of the object is the Device objects name.
Figure 3-5 BACnetDevice shape in JDE shows network and Device instance numbers.
This BACnetDevice object shadows BACnet device 501 named Btest19, located on network 85.
This BACnetDevice object shadows BACnet device 103 named device_103, located on network 11.
1. BACnet devices do not typically know their BACnet network, unless they have router functionality (such as Niagara station). However, devices do know their device instance number, which must be unique across all possible interconnected BACnet networks.
35
Chapter 3 BACnetDevice
BACnetDevice Links
The BACnetDevice object has three linkable properties: executeTriggerAn input that is rarely (if ever) used. systemStatusAn output, using data species BACnetDeviceStatusEnum. This output reflects the value of the BACnet Device objects System_Status property, as one of the following: operational operational_read_only download_required download_in_progress non_operational deviceDownAn output, using data species BooleanStatusType. Remains active (true) while the BACnet device status/ping mechanism detects the device is down. (All child objects and their outputs are down in this state.) Can be connected to control logic for fallback schemes, if desired.
Notes
Updates to systemStatus and deviceDown outputs require device status/ping to be enabled. Refer to Configuring Device Status/Ping, page 6-15. The device status ping automatically marks a BACnetDevice as down whenever the received response is non-operational.
Typically, the systemStatus output is linked to a StringLog object (set to log on change-of-value) and/or a GxText object to display current device status. If the devices systemStatus is needed as part of a control scheme, a Program object can be used to convert the BACnetDeviceStatusEnum input and produce an output using another Niagara data species. See Figure 3-6 for an example.
Figure 3-6
Program object
Program object linked to the systemStatus output of a BACnetDevice object.
(TRIPL program code used for this Program object): //Example for systemStatus to IntegerStatusType input BACnetDeviceStatusEnum deviceStatusIn output BACnetDeviceStatusEnum deviceStatusOut output IntegerStatusType devStatOut deviceStatusOut = deviceStatusIn if deviceStatusIn == "operational" devStatOut.value = 0 devStatOut.status.inAlarm = false elseif deviceStatusIn == "operational_read_only" devStatOut.value = 1 devStatOut.status.inAlarm = false elseif deviceStatusIn == "download_required" devStatOut.value = 2 devStatOut.status.inAlarm = false elseif deviceStatusIn == "download_in_progress" devStatOut.value = 3 devStatOut.status.inAlarm = false elseif deviceStatusIn == "non_operational" devStatOut.value = 4 devStatOut.status.inAlarm = true endif
BACnetDevice object
Note: The BACnetDevice object must be enabled for polling (gray), as shown here. A device object set to pollingDisabled (cyan) or that is down (yellow) will not have an accurately reflected systemStatus.
36
Chapter 3
BACnetDevice Commands
The BACnetDevice object provides numerous right-click commands in the JDE Workspace (or when accessed using a Web browser through a linked Gx object). The following right-click commands are available: These commands require user security privileges of Command, Std. fetchQueries the device and updates all on_demand_transient-type object properties for this device object. disablePollingStops the periodic polling of all contained BACnet shadow objects. The device objects statusFlags property is set to outOfService and the Engineering property pollingEnabled is set to False. However, all contained BACnet objects continue processing. enablePollingStarts the periodic polling of all contained BACnet shadow objects. The outOfService flag is cleared from the objects statusFlag property and the pollingEnabled property is set to True. uploadUploads on_demand_transient and foreign_persistent-type object properties from the Device object, and updates them in this shadow object. uploadAllUploads on_demand_transient and foreign_persistent-type object properties from the Device object and all of the devices (child) BACnet objects, and updates them in the stations shadow objects. downloadAllDownloads on_demand_transient and foreign_persistent-type object properties from the stations shadow objects (device and all child objects) to the devices BACnet objects. getAlarmSummaryEquivalent to the same command in the BACnetUtility. Results are sent to the stations Standard Output.
Note
When using the JDE, the following additional right-click commands are available for the BACnetDevice object: readPropertyUploads only the specified property entered in the Command Arguments dialog box (default is presentValue, not applicable for a device). The property is updated in the objects property sheet. Requires the Niagara property name, for example, apduTimeout. readPropertyMulitpleUploads only the specified properties (default is presentValue, again not applicable) entered in the Command Arguments dialog box. Uploaded properties are updated in the objects property sheet. The device must support the ReadPropertyMultiple service. Requires use of Niagara property names, using a comma (,) for a delimiter between properties. For example: apduTimeout,systemStatus,location.
BACnetDevice Properties
Table 3-1 lists important properties for the BACnetDevice object. These properties are in addition to the standard Niagara properties common among all object types, such as executionParameters, position, and securityGroups.
37
Table 3-1
BACnetDevice object, important properties.
Tab Property Name

objectType statusFlags
Description
Read Only: The BACnet object type. Read Only: Current Niagara state of the shadow device object, as one of these:
Valid Values
BACnetDevice (appears in braces { }) ok, outOfService, down
Default
see Notes
Notes
The default for a newly learned (created) BACnetDevice object is {outOfService}. Not a BACnet property for a Device object.
Always BACnetDevice
okPolling is enabled. outOfServicePolling is disabled. downThe device status ping mechanism

cannot detect the device, or a response non_operational was received. description Read/Write: User-defined text descriptor for the device. Any printable characters, including spaces and mixed case characters. Read Only: Current BACnet device physical and/or logical state, as one of the following:
See descrip.
systemStatus
See descrip.
See descrip.
operational (the default) operational_read_only download_required download_in_progress non_operational
Status
Available as a linkable output, using the BACnetDeviceStatusEnum data species. See Figure 3-6 for an example. As stated in the BACnet spec, the exact meaning of these states (and how they affect the BACnet services of the device) are left as local matters.
Note: Property updates require device status pings from the BACnet service. Ensure that the deviceStatusDisabled property of the BACnet service is set to False, and that the device object is set to pollingEnabled (object is gray). A device object set to pollingDisabled (cyan) or that is down (yellow) will not have an accurately reflected systemStatus or deviceDown state.
deviceDown Read Only: Remains true (Down) while device status pings go unanswered, or if the systemStatus response is non_operational. Same note as above applies. objectIdentifier, Object Type Instance Number objectName Read Only and Read/Write: Object Type field is read-only, and is device. Instance Number is read/write (integer) and defines the Device object instance number. Read Only: The Device objects name. device <integer>, 1 to 4194302
(BACnet max)
false: {ok}, Down
false (ok) Available as a linkable output, using BooleanStatusType data species. device -1 Instance Number must be unique across the internetwork of BACnet devices. Uploaded from device.
Note: If another r2.3.5 or later Niagara host, is <stationName>_<instanceNumber>

Config. address, Network Number, MAC Address Read/Write: (Values typically are defined automatically in the learnNetwork utility). Network Number defines the network connection to a BACnet router. MAC Address depends on the link-layer used by the BACnet service (Ethernet, IP, MS/TP), and is either: 0 to 65534, valid MAC address 0, null Typically, Network Number matches one on one of the enabled link-layer tabs in the BACnet service (local network). If on a remote network, that is, on the far side of a BACnet router, the network number will be a different number.
Ethernet adapter MAC address, in hex IP address and UDP port, in hex If MS/TP device, a number from 1 to 253.
38
Chapter 3
Table 3-1
BACnetDevice object, important properties. (continued)
Tab Property Name

vendorName vendorId
Description
Read Only: Text descriptor for the manufacturer of the device. Read Only: The numeric identifier unique to the vendor. Read Only: Text descriptor assigned by the vendor to define the model of the device. Read Only: Text descriptor for device firmware revision, assigned by the vendor. Read Only: Text descriptor for the application version, typically assigned by the devices application programmer. Read Only: Text descriptor that can be used to describe the devices physical location. Read Only: Defines the version of BACnet protocol supported by the device. Read Only: Defines the minimum set of services, objects, and properties supported, by conformance class number. Read Only: Defines which standardized BACnet services the device supports. A drop-down list shows supported services.
Valid Values
Default
Notes
Refer to the BACnet vendor ID information at www.bacnet.org.
modelName firmwareRevision application SoftwareVersion location protocolVersion protocol ConformanceClass Config, cont protocolServices Supported
1 1 to 6
0 0 See the BACnet spec for more details. A station running the BACnet service (currently) is class 3. Use this information to set the 2 supported config properties (Figure 3-9) accordingly.
Many types possible. See Figure 3-7.
protocolObjectTypes Supported maxApduLength Accepted segmentation Supported
Read Only: Defines which standardized BACnet objects the device supports. A drop-down list shows the supported types. Read Only: Defines the maximum number of octets that can be contained in a single, indivisible APDU. Read Only: Determines if message segmentation is supported, and if so, for transmit and receive. Possible values are:
Many types possible. See Figure 3-8. Minimum of 50
See the BACnet spec for more details. Niagara supports message segmentation.
See Descrip.
See Notes

utcOffset
segmented_both segmented_transmit segmented_receive no_segmentation -780 to 780, integer False, True 0 See the BACnet spec for additional details.
Read/Write: Defines the number of minutes between local standard time and Universal Time Coordinated Read/Write: Defines whether daylight savings time is in effect at the devices location.
daylightSavings Status
False
39
Table 3-1
Tab Property Name

apduSegment Timeout apduTimeout
Description
Read/Write: Defines the time period, in milliseconds, between APDU segment retransmissions. Read/Write: Defines the time period, in milliseconds, between APDU retransmissions when an APDU requiring acknowledgement was not acknowledged. Read/Write: Defines the maximum number of times an APDU can be transmitted. Read/Write: Specifies whether Niagara can use the BACnet ReadPropertyMultiple service for client access to the device. This service reduces communications load.
Valid Values
Default
2000
Notes
Default values (as shown) are typically used. In the case of a Niagara station, these values are defined in the BACnet service. In general, BACnet recommends all devices use the same values. Any learned device (that supports this) automatically has this property as True. Automatically set to True if device was learned (learnNetwork). If set False, acts as an interlock to prevent unintended writes (if needed). See Figure 3-9.
3000
numberOfApdu Retries Config, cont. readProperty MultipleSupported
False, True
False
writePropertyEnabled Read/Write: Determines if a property write to a devices Niagara shadow object results in a write to the devices BACnet object (providing the server device authorizes this). Set this to True if linking child objects, issuing commands, or writing properties.
False, True
False
userData
Engineering
Read-Write: String-type property common to Any string most Niagara objects. Usually left blank, value for unless special servlet or API access is used. servlet/API use, Note: In Niagara r2.301.429 and later, you or can use this property to specify a poll delay to throttle back the poll rate, as applied to pollDelay=n each child object. This is done with a poll where n is delay value, defined in milliseconds, using number of ms this specific entry: delay for the pollDelay=n BACnet poll For example, service before pollDelay=80 polling each child object.
Poll delay feature does not apply to MS/TP devices or objects. Delay feature is useful only if target device cannot keep up with normal poll rate. Delays added this way append to the overall poll cycle time, (does not help slow polling). Delay is in addition to any imparted by services interNodeDelay.
localTime
Read-Only: The time as local in the device, reflecting any UTC offset and daylight savings status (if receiving a UTCTimeSynchronization message). Read-Only: The date as local in the device, to the best of the devices knowledge. Read/Write: (Applies to MS/TP device only) If a master node, specifies highest possible address for master nodes. A value of 127 indicates it is not writable.
hh:mm
12:00PM
localDate maxMaster
dd mm yyyy -1, 0 to 127
1 Jan 1970 -1
These property values can be fetched or uploaded from the device.
310
Chapter 3
Table 3-1
Tab Property Name

maxInfoFrames
Description
Read/Write: (Applies to MS/TP device only) Specifies highest number of information frames the device may send before it must pass the token. A value of 1 indicates it is not writable or otherwise user configurable. Read-Only: A logical revision number for the devices database. Read-Only: Determines if polling of the devices child shadow objects should occur. This property is automatically set to True whenever an enablePolling command is issued, and set to False on a disablePolling command. In the case of the latter, the objects outOfService statusFlag is set.
Valid Values
-1, 1 to ?
Default
-1
Notes
These property values can be fetched or uploaded from the device.
databaseRevision pollingEnabled
-1, 1 to ? True, False
-1 False
Engineering, cont.
useCOV
Read/Write: Specifies if the device is capable of server-side support for SubscribeCOV using either type of COV notifications. Read/Write: Specifies whether confirmed COV notifications are to be used. This property matters only if useCOV is also True. If True, all child objects set to useCOV use confirmed COV notifications. If False, unconfirmed COV notifications are used.
True, False
False
useConfirmedCOV
True, False
False
For any learned device that supports SubscribeCOV, useCOV property is automatically True. In each child object you want as COV, you need to set its useCOV property to True.
covSubscriptionCount Read-Only: Current number of COV subscriptions from device to Niagara. maxCOVSubscriptions Read/Write: Maximum number of COV subscriptions attempted by Niagara.
0 to ? 1 to ?
0 50
Confirmed COV is an option, however, it does add some additional messaging overhead.
BACnetDevice Notes
The following main subsections apply to a BACnetDevice: Supported Services and Objects Properties That Do Not Write to the Device
Note
In r2.3.5, you can define a poll delay for BACnet devices that cannot keep up with Niagara polling, either at the parent (device) or child shadow object level. Due to token-passing timing constraints, this option does not apply to BACnet MS/TP devices. For more details, see descriptions for the BACnetDevice property userData, page 3-10, and common child objects property userData, page 3-22. Need for this configuration is expected to be rare. Please note that it adds to the overall poll cycle time, but may be necessary under certain circumstances.
Supported Services and Objects

After learning (or creating and uploading) a BACnet device, you can see which BACnet services and objects it supports. Find this information on the Config tab of the BACnetDevice objects property sheet. Figure 3-7 lists all possible protocol services, and Figure 3-8 lists all possible object types.
311
After you determine the devices supported services, it is recommended that you set and review some important properties accordingly. See the Properties That Do Not Write to the Device section on page 3-13.
Figure 3-7 Supported BACnet services are listed in the protocolServicesSupported property.
protocolServicesSupported Click the drop-down control to expand and contract the list.
Possible Protocol Services include: ackowledgeAlarm confirmedEventNotification getEnrollmentSummary atomicReadFile addListElement createObject readProperty readPropertyMultiple writePropertyMultiple confirmedPrivateTransfer reinitializeDevice vtClose authenticate iAm unconfirmedCOVNotification unconfirmedPrivateTransfer timeSynchronization whoIs utcTimeSynchonization subscribeCOVProperty confirmedCOVNotification getAlarmSummary subscribeCOV atomicWriteFile removeListElement deleteObject readPropertyConditional writeProperty deviceCommunicationControl confirmedTextMessage vtOpen vtData requestKey iHave unconfirmedEventNotification unconfirmedText Message whoHas readRange lifeSafetyOperation getEventInformation
Notes
An especially important protocol service is subscribeCOV, which allows the Niagara station to receive updates from child objects using COV notifications from subscriptions (either unconfirmed or confirmed), rather than polling request/response messages. For each child object you wish to use COV, you must set its config property useCOV to Truenote also that some devices limit the number of COV subscriptions. For more details, Using COV in Shadow Objects, page 3-18. See the section ahead, Properties That Do Not Write to the Device, for more details on special BACnetDevice properties.
312
Chapter 3
Figure 3-8
Supported BACnet objects are listed in the protocolObjectServicesSupported property.
protocolObjectServicesSupported Click the drop-down control to expand and contract the list.
Possible BACnet objects supported: analog_input analog_value binary_output calendar device file loop multi_state_output program averaging trend_log life_safety_zone analog_output binary_input binary_value command event_enrollment group multi_state_input notification_class schedule multi_state_value life_safety_point
Properties That Do Not Write to the Device

Each BACnetDevice has Niagara-only properties, specifying how Niagara reads and writes and values. These properties are found on tabs: Config and Engineering. ConfigOn the bottom of the Config tab of the property sheet for a BACnetDevice are two important properties (Figure 3-9), each with a default value of False: readPropertyMultipleSupportedWill show True if device was learned, providing that it supports the BACnet readPropertyMultiple service. writePropertyEnabledShows True if device was learned. This must set this to True before any object commands, links, or property changes will work from Niagara. If you wish to protect against Niagara writing to this device, set this property to False.
If you add a BACnetDevice manually, that is copy it from the Local Library, both of these properties will be False (by default). You need to set them according to the capabilities of the device and how Niagara should interact.
313
Figure 3-9
Two important BACnetDevice properties at the bottom of Config tab.
Note: The first property, readPropertyMultipleSupported, is automatically set to True if the device was learned (BACnetUtility), and the device supports this BACnet service. Also (if learned), the writePropertyEnabled property will be set to True, as a convenience. If you want read-only access from Niagara, set this to False.
Note
The property writePropertyEnabled must be True in order for any input links, object commands, or writes to properties for any of the BACnetDevice objects child objects to become effective (write to the BACnet device). In addition, the foreign BACnet device may require configuration to authorize these writes (a local matter). Editing these properties will not write or send anything to the device (query for permission to write, as one example). Put another way, if the device does not support a service (for example, the ReadPropertyMultiple service), setting this property to True will not make it support that service. To determine which of the multiple services is supported by the device, you can expand the read-only Config property protocolServicesSupported (Figure 3-7) and look at the corresponding services. EngineeringOn the bottom of the Engineering tab of the property sheet for a BACnetDevice are five properties (Figure 3-10), the last four of which are important only if the device supports the BACnet SubscribeCOV service.
pollingEnabledReflects the current polling status: enabled or disabled. (Note that COV usage requires polling enabled, but if polling is set from enabled to disabled, COV updates may continue for a bit before stopping.) useCOVDetermines whether any child object can use COV. If the device supports SubscribeCOV and was learned, this is automatically set to True. useConfirmedCOVMakes all COV usage confirmed COV. covSubscriptionCountReflects the number of child objects currently subscribed with the device to receive COV notifications. maxCOVSubscriptionsThe maximum number of COV subscriptions that the station will attempt with this BACnet device (default is 50).
314
Chapter 3
BACnet Client Operation BACnet objects (children)
Figure 3-10
Important BACnetDevice properties at the bottom of Engineering tab.
Note: The useCOV property is automatically set to True if the device was learned (BACnetUtility), and the device supports this SubscribeCOV service. If SubscribeCOV is supported, it is usually best to use unconfirmed COV, (leave useConfirmedCOV property as False). You must individually set each child object to useCOV (Config tab), and because the device may limit the number of COV subscriptions, you should do this in a most important object-first order.
BACnet objects (children)

BACnet child objects shadow standard BACnet objects in networked BACnet devices. Depending on whether a device implements optional properties for its objects, you can use lite versions or full versions of shadow objects (Table 3-2).
Table 3-2 BAcnet (child) shadow object types.
Full versions:
BACnetAnalogInput and BACnetAnalogInputWritable1 BACnetAnalogOutput BACnetAnalogValue BACnetAnalogValuePriority BACnetBinaryInput and BACnetBinaryInputWritable1 BACnetBinaryOutput BACnetBinaryValue BACnetBinaryValuePriority BACnetMultistateInput and BACnetMultistateInputWritable1 BACnetMultistateOutput BACnetMultistateValue BACnetMultistateValuePriority
1.
Lite versions:
BACnetAnalogInputLite and BACnetAnalogInputWritableLite1 BACnetAnalogOutputLite BACnetAnalogValueLite BACnetAnalogValuePriorityLite BACnetBinaryInputLite and BACnetBinaryInputWritableLite1 BACnetBinaryOutputLite BACnetBinaryValueLite BACnetBinaryValuePriorityLite BACnetMultistateInputLite and BACnetMultistateInputWritableLite1 BACnetMultistateOutputLite BACnetMultistateValueLite BACnetMultistateValuePriorityLite
For an explanation of how the Writable input-type shadow objects differ from regular input-type objects, see About Writable Input Objects, page 3-3.
315
Chapter 3 BACnet objects (children)
Shape Information
Inside the object shape for every BACnet shadow object is an object type abbreviation and an instance number (Figure 3-11). Additional text may also be included, namely -Lt if a Lite object, plus COV indicating COV usage. Finally, if the shadow object was created by the learn device command, the name of the object is the BACnet objects name.
Figure 3-11
BACnet shadow object shape in JDE WorkPlace shows type and instance number.
Default shapes for all types of BACnet shadow objects, as copied from the Local Library. Full objects Lite objects
Object for BACnet Analog Input object, instance number 7.
Object for BACnet Binary Output object, instance number 1, with object name AHU1Sfan.
Object for BACnet Binary Value object, instance number 3. The BV source object has the optional priority input, and so a BVP shadow object is used (input not linked in Niagara). This shadow object uses COV subscription for data updates.
Type: Shape type abbreviations are:

1.
AI is Analog Input AO is Analog Output AV is Analog Value AVP1 is Analog Value Priority BI is Binary Input BO is Binary Output BV is Binary Value BVP1 is Binary Value Priority
MSI is Multistate Input MSO is Multistate Output MSV is Multistate Value MSVP1 is Multistate Value Priority For all types, if a Lite object: -Lt follows type, for example: AI-Lt, AVP-Lt, BO-Lt, etc.
Priority value objects have an optional priority input, and are considered the same BACnet type as the corresponding value object. For example, AV and AVP objects are both Analog_Value objects.
Instance Number: The unique instance number within that device among other objects of the same type. COV: Any object with shape text ending in COV indicates it is currently subscribed for COV notificationsthe objects covSubscribed property is True. You must individually configure each object that you wish to use COV. See Using COV in Shadow Objects, page 3-18, for additional information.
316
Chapter 3
Inputs and Outputs
Each BACnet (child) shadow object has at least one linkable output property: statusOutput. If the object is a commandable type (AO, BO, MSO, AVP, BVP, MSVP), it also has a linkable input property, priorityArray. These properties are individually described in sections ahead on each BACnet object type. Any BACnet (child) object must reside under the appropriate BACnetDevice object (either directly, or in other containers under the BACnetDevice, such as PollOnDemand or PollAlways). A BACnet (child) object provides numerous right-click commands in the JDE Workspace (or when accessed using a Web browser through a linked Gx object). These right-click commands are included for any BACnet shadow object. Commands listed below require user security privileges of Command, Std. Commandable-type objects (for example AO and BO) include additional right-click commands, in addition to these common commands. A fetch or upload updates the polled properties (presentValue and statusFlags), in addition to working as described below.
Parent Dependencies Common Commands
Notes
fetchQueries the device and updates all on_demand_transient-type object properties for the shadow object. On the objects property sheet, this includes most properties marked with an {F} (not description and objectName). pollRenewForces an immediate poll of a shadow object in a PollOnDemand container, to update presentValue and statusFlags properties. uploadUploads on_demand_transient and foreign_persistent-type object properties and updates them in this shadow object. On the objects property sheet, this includes all properties marked with an {F}. downloadDownloads on_demand_transient and foreign_persistent-type object properties from the shadow object to the associated BACnet object. When using the JDE, the following additional right-click commands are available for any BACnet child object:
readPropertyUploads only the specified property (default is presentValue) entered in the Command Arguments dialog box. The property is updated in the objects property sheet. Requires the Niagara property name. readPropertyMultipleUploads only the properties entered in the Command Arguments dialog box (default is presentValue). Uploaded properties update in the objects property sheet. The device must support the ReadPropertyMultiple service. You must use Niagara property names, and a comma (,) delimiter between properties. For example: lowLimit,highLimit.
317
Using COV in Shadow Objects
If a device supports the BACnet SubscribeCOV service, you can select some (or perhaps all) of its child shadow objects to update using received COV notifications. COV notifications are more efficient than polling updates, especially for binary or multistate-type objects, which may infrequently change. For any analog-type object using COV notification, its value must change greater than its COV increment before any notifications are sent to the station. Any learned device that is SubscribeCOV-capable will be created with a True for useCOV, as shown on its Engineering tab (Figure 3-10 on page 3-15). If a learned device shows this as False, the following subsections do not apply. Subscribing COV Strategy Notes
Subscribing
You must individually subscribe each child shadow object you wish to use COV, by setting its useCOV property (Config tab) from False to True (Figure 3-12). This causes the station to immediately request a COV subscription. If the subscription attempt succeeds, the read-only covSubscribed property below also becomes True.
Figure 3-12 useCOV property (Config tab) for any child object is used to subscribe COV.
Note
The parent BACnetDevice must be enabled for polling (status ok) for this to work. If the COV subscription attempt does not succeed, covSubscribed remains False, the object is placed in the polling queue. Starting in Niagara r2.3.5, a progressive backoff scheme was implemented for COV re-subscriptions, as described below. If a COV-configured object attempts COV and fails, its useCOV property remains True, and it attempts again after 1 poll cycle, then 2, then 4, and so on. This allows the object eventually to get fully re-subscribed without manual intervention (albeit taking longer in cases where a network disruption lasts for a long period). Note this difference from the earlier (r2.3.4) COV subscription process, whereby any failed COV subscription attempt reset the useCOV property to False. Thus, objects needed manual intervention for them to use COV again (after fallback polling).
318
Chapter 3
To unsubscribe any currently COV-subscribed object, that is one showing covSubscribed as True (COV inside its shape), simply set its useCOV property (Config tab) from True to False. The station immediately requests to unsubscribe COV for that object, and the covSubscribed property goes to False.
COV Strategy Notes

Limited Subscriptions = Order of ImportanceThe number of COV subscriptions allowed can vary greatly from BACnet device to device. By default, you can attempt up to 50 COV subscriptions per device. However, sometimes a device may only allow a few COV subscriptions. Therefore, it is recommended that you configure objects for useCOV in some order of importance, by subscribing the most important objects first. If you can successfully subscribe 50 objects in a device for COV, you may wish to continue to subscribe even more. Do this by changing the maxCOVSubscriptions property of the parent BACnetDevice (Engineering tab) to a higher number. Best Candidates for COVIn general, the best usage of COV is for objects that have values that change infrequentlytypically binary and multistate input objects or binary and multistate value objects. These are represented by BACnet shadow object types BI, BV, MSI, and MSV. You can also use COV for analog input and value objects (AI and AV). However, to reduce notifications you would have to increase each objects covIncrement value, which would also reduce sensitivity to changesconsider that only changes larger than the covIncrement value will be reported. Poor Candidates for COVStarting in Niagara r2.3.4, the priorityArray property of output-type objects (AO, BO, MSO) and value-priority objects (AVP, BVP, MSVP) is polled, in addition to presentValue and statusFlags properties. This is done as part of a rewrite mechanism (see Rewrite Mechanism, page 3-25). Although you can configure any of these BACnet objects to useCOV, the object remains in the poll queue to receive priorityArrayas this property cannot be received using SubscribeCOV logic. Therefore, configuring these objects to useCOV will not significantly reduce message traffic. The poll message for each will request only one value instead of three, but this typically makes little difference. Therefore, it is recommended that you do not configure any output-type and value-priority objects for COV usage, unless the device can support plenty of COV subscriptions, and you have already subscribed all of the input and non-priority value type objects. Related BACnet Service PropertyOn the Engineering tab of the BACnet service is a property covResubscriptionInterval, in seconds. The default value is 600 seconds, and the range is from 300 to 2147483647 (MAX_VALUE). This value is global for all objects in the station configured to useCOV, and represents the frequency at which COV resubscription requests are sent to the various devices. Typically, there is no reason for you to change this property. However, you may notice that if you disable a device for polling, objects configured to useCOV will update for some period of time, but typically not longer than this period.
319
Common BACnet Shadow Object Properties

Table 3-3
Table 3-3 lists important common properties for any BACnet (child) shadow object. These properties are in addition to the standard Niagara properties common among all object types, such as executionParameters, position, and securityGroups. For a listing of properties unique to each of the different shadow object types, see sections ahead.
Common properties for all BACnet (child) shadow objects.
Tab Property Name

objectType
Description
Read Only: The BACnet shadow object type. If copied from the Local Library, the object uses this string in its name, at least until renamed. Read Only: The polled (or COV updated) state of the objects status flags, which reflect the general health of the object. Appears as a component of the objects statusOutput.
Valid Values
See Table 3-2.
Default
Notes
reflects An abbreviation for the object type object type appears inside the objects shape (near the top). {ok} The total set of 6 status flags is a superset of the BACnetStatusFlag type, where these 2 flags are added to the 4 BACnet types (originating from the device):
statusFlags
where values appear in braces { }:
inAlarm fault Depending on conditions, status flags can overridden be set in combinations. A dominant flag sets outOfService the objects color to something other than unackedAlarm gray (the same color appears at its outputs). down A normal state (no flags set) is where the status flags value is {ok}, and the objects color is gray. Outputs appear normally. Briefly, status flag values mean:
unackedAlarm down
inAlarmAn alarm state currently exists.

The objects shape and outputs are red. Another property, alarmState, is True. faultA fault state occurs when another property, reliability, has any value except no_fault_detected. The objects shape and outputs are orange. overriddenThe objects properties presentValue and reliability are no longer tracking changes. outOfServiceThe objects property outOfService has been set to True. The objects shape and outputs are cyan. unackedAlarmAn alarm has occurred that is still pending acknowledgement. If the inAlarm flag is still set, the object outputs are red and also flashing. downThe device is down or offline. The object s shape and outputs are yellow. See Description Status
description
Read-Write: Permits a user-defined text descriptor for describing the object. Any printable characters, including spaces and mixed case characters, are allowed.
320
Chapter 3
Table 3-3
Common properties for all BACnet (child) shadow objects. (continued)
Tab Property Name

presentValue
Description
Read Only: The polled (or COV received) value of the object, which appears as a component of the objects statusOutput.
Valid Values
output value or state
Default
Notes
For analog types, is a floating point value. For binary types, is the assigned active or
inactive text (if full object), or either false or true (if lite). For multistate types, is a text state (if a full object) or an integer value (if lite). eventState Read Only: Shows the objects current alarm state, which is one shown at right. normal fault offnormal high_limit low_limit False, True normal Offnormal applies to binary and multistate types. High_limit and low_limit states apply to analog types. Property is read-only for any of the writable input types. It is set by the input value only (see page 3-3).
Status, cont.
outOfService
Read-Write: Allows setting the object as out of service (when set to True). This allows logic testing of error conditions. While set to outOfService, you can then select a value for the reliability property.
False
reliability (not Lite objects)
Read-Write: Can be used to indicate whether the presentValue or operation of the object is reliable, and if not, why. Selections include: no_fault_detected, no_sensor, overrange, under_range, open_loop, shorted loop, no_output_value, unreliable_other, process_error
See Description
no_fault_ detected
ackedTransitions (not Lite objects)
Read Only: Flags, that when cleared, indicate that an unacknowledged event transition has occurred. Separate for event types: to-offnomal, to-fault, to-normal. Read Only and Read/Write: Object Type field is read-only, and reflects the type of BACnet object. For example: binary_output, analog_value, or multi_state_input. Instance Number is read/write (integer) and defines the object instance.
set or cleared
set
Relates to the setup of the associated NotificationClass object. Instance Number must be unique in the device for that particular object type.
objectIdentifier, Object Type Instance Number
<object type> <integer>, 1 to 4194302

(BACnet max.)
<type> -1
objectName
Config
Read-Write: The assigned object name for the BACnet object. In most BACnet devices, this name must be unique among all BACnet objects in the device.
If the shadow object was created by the BACnetUtility, any spaces in this name appear as underscores (_) in its originally assigned name. If the parent device does not support SubscribeCOV, these properties do nothing. If covSubscribed is True, the objects shape shows COV. See page 3-18 for more.
useCOV
Read-Write: Used to configure for COV subscription to receive data updates, vs. polling updates. A False-to-True transition produces the COV subscription request. Read Only: Indicates whether the object is currently successfully subscribed for COV notifications from the parent BACnetDevice.
False, True
False
covSubscribed
False, True
False
321
Table 3-3
Common properties for all BACnet (child) shadow objects. (continued)
Tab Property Name

timeDelay
Description
Read-Write: Minimum time period in Hr:Min:Sec, that an alarm (off-normal) condition must exist before the object alarms (statusFlag inAlarm becomes set and the object and outputs turn red).
Valid Values
any practical value in Hr:Min:Sec
Default
00:00:00 (no delay)
Notes
This delay time routine also applies to an object returning to-normal from an alarm state. The timeDelay routine does not affect reporting of fault conditions.
Typically, this is some number The delay timer begins when an alarm of seconds and condition, as configured, occurs. If the alarm or minutes condition clears before the delay timer expires, the object does not alarm and the delay timer is reset. notificationClass Read-Write: The assigned notification class number, used in routing alarms. If alarms for this object are needed in Niagara, a NotificationClass object using the same number should exist in the stations NotificationService container. Configuration of this NotificationClass object determines what type of events (to-offnormal, to-fault, to-normal) require acknowledgement (ack). If an event type, such as to-normal, does not require an ack, then it is always set (checked) in this objects status property, ackedTransitions. Such an event transition will never set this objects statusFlag {unackedAlarm}. eventEnable Read-Write: Flags that define the types of event (alarm) transitions for this object that are sent to the alarm console. Selection to-offnormal applies to any alarm state, e.g. high-limit or low-limit for an AI, AO, AV object, or offnormal for a BI, BO, BV, MSI, MSO, or MSV object. notifyType Read-Write: Required for BACnet compliance. The only effective difference is that unacknowledged events for objects with notifyType of event do not appear in a server response to a BACnet GetAlarmSummary client request. selection of any or all: to-offnormal to-fault to-normal (none selected) 0 to any positive integer up to 4194302 0
Alarm Setup (not Lite objects)
NotificationClass objects reside in the NotificationServices container (under the stations services container).
event or alarm
event
Either selection functions in the same manner in the Niagara alarming subsystem.
userData
Read-Write: String-type property common Any string to most Niagara objects. Usually left blank, value for unless special servlet or API access is used. servlet/API use, or Note: In Niagara r2.301.429 and later, this pollDelay=n property lets you specify a poll delay (pause in polling) to a specific child object where n is number of ms (as here), or in the parent BACnetDevice object (delay applied to each child object). delay for the BACnet poll This is done with a poll delay value, defined in milliseconds, using this specific service before polling the entry: object. pollDelay=n For example, pollDelay=100
Poll delay feature does not apply to MS/TP devices or objects. Delay feature is useful only if target device cannot keep up with normal poll rate. Delays added this way append to the overall poll cycle time, (does not help slow polling). Delay is in addition to any imparted by services interNodeDelay.
Engineering
322
Chapter 3
Common BACnet Object Notes
When learning objects to shadow in a BACnet device, the BACnetUtility creates the appropriate Niagara shadow objects based upon the object types in the device. All instances of the supported object types are automatically created in the device container in stations database. The following general topics should be understood about BACnet child objects:

Device Down Inheritance Value-Type Objects, Regular and Priority Value-Type Objects, Input Usage Multistate Object Notes Writing to BACnet Objects
Device Down Inheritance

Whenever a parent BACnetDevice is marked down by the services device status/ping mechanism, all child objects (and their statusOutputs) inherit a down status (yellow color) as shown in Figure 3-13. System users have a quick visual indication whether a device is down or up.
Figure 3-13 Child objects and their outputs indicate Down while parent device is down.
BACnetDevice marked down by Device Status ping. All child objects also indicate Down.
Value-Type Objects, Regular and Priority

In a typical BACnet device (particularly one that has field I/O), input and output objects are used to interface to physical inputs and outputs, and value-type objects (Analog_Value, Binary_Value, Multistate_Value) are used to hold application values. Typical application value examples include setpoints and occupancy states. Value-type objects for these application values may be selectively implemented as either read-only (status) or writable, and (if writable) optionally commandable. In the case of Value types, note there are two separate types of Niagara shadow objects for each (a total of six types, counting full and lite versions):
323
Regular typesBACnetAnalogValue, BACnetBinaryValue, and BACnetMultistateValue. Priority typesBACnetAnalogValuePriority, BACnetBinaryValuePriority, and BACnetMultistateValuePriority. The difference between these two types is that the priority-types are for BACnet objects that are implemented as commandable, meaning that the optional property Priority_Array exists. The regular types are for BACnet objects not implemented with this optional property. The BACnetUtility learn automatically creates the appropriate type (regular or priority) for each value-type object in the device.
You can quickly see the difference between the two shadow object types in the JDE workspace of the BACnetDevice, where priority-types have a P included in the type abbreviation inside the object shape: AVP, BVP, and MSVP.
Value-Type Objects, Input Usage

Regular non-commandable versions of the value-type shadow objects (BACnetAnalogValue, BACnetBinaryValue, BACnetMultistateValue) feature a linkable input, statusInput, designed to allow the Niagara station to supply presentValue. However, you should understand there is no way for Niagaras BACnet service to determine if the BACnet object is implemented with a read-only presentValue, in which case linking to this input is not advisable (see Note below). In Niagara r2.3.4 and later, a rewrite mechanism periodically attempts to write a linked input value. If read-only type Value objects are left linked in Niagara, performance may degrade, as resources are wasted trying to write values that can never be written. Priority versions of value-type shadow objects also feature a linkable input, priorityArray, designed to allow the Niagara station to supply presentValue using the BACnet-compatible priority level mechanism. Providing that the device allows property writes (and that you have enabled write services in the parent device object), linking to this input will provide control from Niagara station logic.
Note
Multistate Object Notes

Client support for BACnet multistate object types (Multi-state Input, Output, and Value) is provided. However, be aware that Niagara multistate objects differ from BACnet multistate objects in the implementation of presentValue. Specifically, a presentValue of 0 (zero) is valid in the Niagara object, whereas it is not valid for a BACnet object. For more details from the server-side perspective, refer to the Multistate Object Considerations section on page 4-5. From a client-side perspective, this difference means that multistate shadow objects can never have an integer value lower than 1, even for state0 (the first state). These differences are mentioned here, and also in the individual sections ahead on multistate shadow objects (BACnetMultistateInput, BACnetMultistateOutput, BACnetMultistateValue, and BACnetMultistateValuePriority).
324
Chapter 3
Writing to BACnet Objects

Starting in r2.3.4, changes were made in how writes to shadow objects are executed. Specifically, a rewrite delay mechanism was implemented. Related to this, all commandable objects (AO, AVP, BO, BVP, MSO, and MSVP) are now polled for their priorityArray value, in addition to presentValue and statusFlags.
Note
Be aware that all commands, input value writes, property edits from Niagara to BACnet shadow objects in a device still have two prerequisites, namely:
1. 2.
The BACnet device must be configured to allow external writes. How this is accomplished is a local matter, and will vary from device to device. The device shadow object (BACnetDevice) must be configured to allow writes. On the Config tab of its property sheet, writePropertyEnabled must be True.
Otherwise, no commands, input writes, or property edits from Niagara will succeed. Rewrite MechanismBy default, rewrite messages occur if the station detects the initial command or input value change is not accepted. Some examples: An object (AO, AVP, BO, BVP, MSO, MSVP) receives a Niagara write to an element of the priorityArray input at a particular level (1 to 16), or a command (level 1 or 8). The write may be a value or an auto. A rewrite delay timer is started, and the array values are stored away. Upon the next poll of the object, its priorityArray is compared to the stored array. If the entry in the stored array does not match the objects current priorityArray, and the rewrite delay time has expired, a write (rewrite) of the value/auto is issued again. (If the entry does match, the rewrite timer is cleared.) This underscores the need for Niagara not to contend for control with another source at a particular control levelby default, Niagara will always attempt to win. A rewrite is also issued to input-linked value objects (AV, BV, and MSV) and writable AI, BI, and MSI input objects upon each object poll, providing that a mismatch exists between the input and output, and the rewrite delay time has expired. In the case of a value (AV, BV, or MSV) object, the source object must be writable to benefit from the rewrite. If the value object is read-only, the rewrite is actually detrimental, as station resources are spent trying to do the impossible. To summarize, unlink the input of any AV, BV, or MSV object known to be read-only, or that does not respond to a Niagara input write. In the case of a writable input object, the input must have an out_of_service status, or the input is ignored. See About Writable Input Objects, page 3-3.
Note
Rewrite Delay TimeDefault rewrite delay time is 60 seconds. Adjust this globally on the property sheet for the BACnet service (General, Engineering tab). rewriteDelay: range is from 30 seconds minimum, to 2147483647 (MAX_VALUE). If you set rewriteDelay to a high value or MAX_VALUE, this essentially disables the rewrite feature. Basic operation can then be described as last command wins.
325
Chapter 3 BACnetAnalogInput
BACnetAnalogInput
abbrev: AI These objects shadow Analog Input objects in BACnet devices. They are used to bring sensed values from device AIs into the control engine, format them for display, and link into other control logic. If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Default Resource Count: 59 (full), 41 (lite) Trigger Properties
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input/Output Property Reference for BACnet AI Object

Type
input1 output 1.
Label
exe sOut
Property Name
executeTrigger statusOutput
Data Species
TriggerType FloatStatusType
If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species FloatStatusType (see below).
Writable Type, All Used Inputs /Outputs

Inputs
statusInput (not shown): executeTrigger
Outputs
statusOutput
The BACnet AI object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.
Commands Properties
Table 3-1 BACnetAnalogInput (AI) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, Status reliability, ackedTransitions (not Lite objects) updateInterval (not Lite objects)
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.
Valid Values
Default
Notes
If a writable AI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.
See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Specifies maximum time period, in hundredths of second, between updates to presentValue when the input is not overridden and not outOfService. Read-Write: Specifies the smallest recognizable change that can be reliably obtained for presentValue.
integer
resolution (not Lite objects)
valid float
0.0
326
Chapter 3
BACnet Client Operation BACnetAnalogInput
Table 3-1 BACnetAnalogInput (AI) object properties. (continued)
Tab Property Name

Status, cont. statusInput (input: sIn) (only writable AI)
Description
Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service.
Valid Values
<float value> {status flags}
Default
00.0 {ok}
Notes
See About Writable Input Objects, page 3-3.
objectIdentifier, objectName useCOV covSubscribed units Config
See Table 3-3 on page 3-20 for details on these common shadow object properties.
Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Text descriptor typically used to describe the physical device (sensor) connected to the analog input. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. Read-Write: Lowest number that can be reliably used for presentValue. Below this value, the object and its output have a fault status (orange color). Read-Write: Highest number that can be reliably used for presentValue. Above this value, the object and its output have a fault status (orange color). See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit.
Select any (BACnet-type unit choices) Device-support ed text string. valid float
Other, no_units -
deviceType (not Lite objects) covIncrement (not Lite objects) minPresentValue
0.0 (no minimum)
valid float
0.0
maxPresentValue
valid float
0.0
Alarm Setup (not Lite objects).
timeDelay, notificationClass highLimit
valid float
0.0
lowLimit
valid float
0.0
deadband
valid float
0.0
Deadband does not apply to fault conditions.
limitEnable
Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values.
(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign
(none)
eventEnable, notifyType Visual decimalFormat
2, no (+) sign
327
Chapter 3 BACnetAnalogInput
Table 3-1 BACnetAnalogInput (AI) object properties. (continued)
Tab Property Name

Engineering statusOutput (output sOut)
Description
Read Only: Shows the current value and status of the statusOutput.
Valid Values
<float value> {status flags}
Default
00.0 {ok}
Notes
BACnet AI Notes
The BACnetAnalogInput object is a real workhorse in most BACnet integrations. The statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Input object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
328
Chapter 3
BACnet Client Operation BACnetAnalogOutput
BACnetAnalogOutput
abbrev: AO These objects shadow Analog Output objects in BACnet devices. Access to an AO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output value at priority levels 1 and 8. If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet).
input output

Inputs Outputs
statusOutput

Inputs
priorityArray (not shown): executeTrigger
Outputs
statusOutput
Input/Output Property Reference for BACnet AO Object

Type
Label
exe pIn sOut
Property Name
executeTrigger priorityArray statusOutput
Data Species
TriggerType FloatPriorityArrayType FloatStatusType
The BACnet AO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides AO control commands. By default, these commands appear as follows (note the descriptors are modifiable using the objects commandTags property): SetTo set an output value at the Manual level (8). Requires Command, Std privileges. AutoTo clear an output value set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output value at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output value set at the Emergency level (1). Requires Command, Emer privileges.
Commands
Properties
Table 3-2 BACnetAnalogOutput (AO) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not AO Lite objects)
Description
Valid Values
Default
Notes
Status
See Table 3-3 on page 3-20 for information on these common full object properties.
329
Chapter 3 BACnetAnalogOutput
Table 3-2 BACnetAnalogOutput (AO) object properties. (continued)
Tab Property Name

Status, cont. resolution (not AO Lite objects)
Description
Read-Write: Specifies the smallest recognizable change that can be reliably obtained for presentValue.
Valid Values
valid float
Default
0.0
Notes
Priorities
priorityArray (input: pIn)
Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.
<valid float> or auto, levels 1 to 16 valid float
auto 1 to 16
May not reflect station generated commands (see intPriorityArray).
relinquishDefault objectIdentifier, objectName useCOV covSubscribed units
0.0
Config
Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Text descriptor typically used to describe the physical device (actuator, etc.) connected to the analog output. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. Read-Write: Lowest number that can be reliably used for presentValue. Below this value, the object and its output have a fault status (orange color). Read-Write: Highest number that can be reliably used for presentValue. Above this value, the object and its output have a fault status (orange color). See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties.
Select any (BACnet-type unit choices) Device-support ed text string. valid float
Other, no_units -
deviceType (not AO Lite objects) covIncrement (not AO Lite objects) minPresentValue
0.0 (no minimum)
valid float
0.0
maxPresentValue
valid float
0.0
Alarm Setup (not Lite objects).
timeDelay, notificationClass highLimit
valid float
0.0
lowLimit
valid float
0.0
deadband
valid float
0.0
limitEnable
(select) low-limit, high-limit
(none)
eventEnable, notifyType
330
Chapter 3
BACnet Client Operation BACnetAnalogOutput
Table 3-2 BACnetAnalogOutput (AO) object properties. (continued)
Tab Property Name

decimalFormat
Description
Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:
Valid Values
0 to 6, (+) sign no (+) sign Any desired text string, including spaces and numerals.
Default
2, no (+) sign See descrip.
Notes
commandTags Visual

intPriorityArray Engineering (input pIn)
Set (manualSet level) Auto (manualAuto level) Emergency Set (emergencySet level) Emergency Auto (emergencyAuto level)
If a tag is blank (no characters), the command is not available on the command menu.
Read Only: Shows the commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current value and status of the statusOutput.
<valid float> or auto, levels 1 to 16 <float value> {status flags}
auto 1 to 16
These station-generated commands can dynamically update.
statusOutput (output sOut)
00.0 {ok}
BACnet AO Notes
Depending on the BACnet device and the vendors implementation, BACnet Analog_Output objects may exist for either (or both) physical analog outputs and/or commandable values, such as setpoints. For example, Figure 3-14 shows a BACnetAnalogOutput object used for setpoint control in an AHU controller.
Figure 3-14 BACnet AO objects are sometimes used for setpoint control.
As with other analog-type BACnet objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Output object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
331
Chapter 3 BACnetAnalogValue
BACnetAnalogValue
abbrev: AV This object shadows a non-commandable Analog Value object in a BACnet device. It is one of two Niagara shadow-object types possible for a BACnet Analog Value object; the other is BACnetAnalogValuePriority. This object brings an analog control-system value into the control engine. A linkable statusInput allows the analog value to be sourced from another Niagara object (providing that the value is writable). If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for BACnet AV Object

Type
input output
Label
exe sIn sOut
Property Name
executeTrigger statusInput statusOutput
Data Species
TriggerType FloatStatusType FloatStatusType
The BACnet AV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.
Commands Properties
Table 3-3 BACnetAnalogValue (AV) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not AV Lite objects) statusInput
Description
Valid Values
Default
Notes
Status
See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the float value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.
valid float {status flags}
Note: Do not link statusInput if the Analog Value object is read-only.
See Value-Type Objects, Input Usage on page 3-24, and Rewrite Mechanism, page 3-25.
332
Chapter 3
BACnet Client Operation BACnetAnalogValue
Table 3-3 BACnetAnalogValue (AV) object properties. (continued)
Tab Property Name

objectIdentifier, objectName useCOV covSubscribed Config units
Description
Valid Values
Default
Notes
Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read Only: Shows the current value and status of the statusOutput.
Select any (BACnet-type unit choices) valid float
Other, no_units 0.0 (no minimum)
covIncrement (not AV Lite objects) timeDelay, notificationClass highLimit Alarm Setup (not Lite objects).
valid float
0.0
lowLimit
valid float
0.0
deadband
valid float
0.0
limitEnable
(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign <float value> {status flags}
(none)
eventEnable, notifyType Visual decimalFormat
2, no (+) sign 00.0 {ok}
Engineering
BACnet AV Notes
BACnetAnalogValue objects are often used for read-only status values, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism As with other analog-type BACnet shadow objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Value object). If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
333
Chapter 3 BACnetAnalogValuePriority
BACnetAnalogValuePriority
abbrev: AVP This objects shadows a commandable Analog Value object in a BACnet device, meaning an AV object with priorityArray and relinquishDefault properties. This object is like the BACnetAnalogValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like an AO object). If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet).
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input/Output Property Reference for BACnet AVP Object

Type
input output
Label
exe pIn sOut
Property Name
Data Species
TriggerType FloatPriorityArrayType FloatStatusType
The BACnet AV object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the AV priority object provides control commands. By default, these commands appear as follows (note the descriptors are modifiable using the objects commandTags property): SetTo set an output value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear an output value set at the Manual level (8). Requires Command, Std user privileges. EmergencySetTo set an output value at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear an output value set at the Emergency level (1). Requires Command, Emer user privileges.
Commands
Properties
Table 3-4 BACnetAnalogValuePriority (AVP) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, Status
Description
Valid Values
Default
Notes
334
Chapter 3
BACnet Client Operation BACnetAnalogValuePriority
Table 3-4 BACnetAnalogValuePriority (AVP) object properties. (continued)
Tab Property Name

Status, cont. reliability, ackedTransitions (not Lite objects)
Description
Valid Values
Default
Notes
priorityArray Priorities
Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.
auto 1 to 16
relinquishDefault objectIdentifier, objectName useCOV covSubscribed
0.0
Config
units
Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:
Select any (BACnet-type unit choices) valid float
Other, no_units 0.0 (no minimum)
covIncrement (not AV Lite objects) timeDelay, notificationClass highLimit Alarm Setup (not Lite objects)
valid float
0.0
lowLimit
valid float
0.0
deadband
valid float
0.0
limitEnable
(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign Any desired text string, including spaces and numerals.
(none)
eventEnable, notifyType decimalFormat
2, no (+) sign See descrip. If a tag is blank (no characters), the command is not available on the command menu.
commandTags Visual
335
Chapter 3 BACnetAnalogValuePriority
Table 3-4 BACnetAnalogValuePriority (AVP) object properties. (continued)
Tab Property Name

Engineering intPriorityArray (input pIn)
Description
Read Only: Shows the commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current value and status of the statusOutput.
Valid Values
<valid float> or auto, levels 1 to 16 <float value> {status flags}
Default
auto 1 to 16
Notes
See Value-Type Objects, Input Usage on page 3-24.
00.0 {ok}
BACnet AV (Priority) Notes
Depending on the BACnet device and the vendors implementation, commandable BACnet Analog_Value objects may exist for setpoints and other application parameters. For example, Figure 3-14 shows a BACnetAnalogValuePriority object used for setpoint control in an AHU controller.
Figure 3-15 Commandable BACnet AV objects are sometimes used for setpoint control.
As with other analog-type BACnet shadow objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for any BACnet Analog_Value object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
336
Chapter 3
BACnet Client Operation BACnetBinaryInput
BACnetBinaryInput
abbrev: BI These objects shadow Binary Input objects in BACnet devices. They are used to bring sensed values from device BIs into the control engine, format them for display, and link into other control logic. If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for BACnet BI Object

(only input and output types, see Table 3-1 for all properties) Type input1 output 1. Label exe sOut Property Name executeTrigger statusOutput Data Species TriggerType FloatStatusType
If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species BooleanStatusType (see below).

Inputs
Outputs
statusOutput
The BACnet BI object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.
Commands Properties
Table 3-5 BACnetBinaryInput (BI) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects)
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BI object, presentValue is displayed in terms of inactiveActiveText. If a Lite BI, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state).
Valid Values
Default
Notes
If a writable BI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.
Status
timestamp or null (none)
null
337
Chapter 3 BACnetBinaryInput
Table 3-5 BACnetBinaryInput (BI) object properties. (continued)
Tab Property Name

changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) Status, cont. elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) statusInput (input: sIn) (only writable BI) objectIdentifier, objectName useCOV covSubscribed Config deviceType (not Lite objects) polarity
Description
Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service. See Table 3-3 on page 3-20 for details on these common shadow object properties.
Valid Values
integer value
Default
0
Notes
timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) false or true, {status flags}
null 00:00:00
null
false {ok}
Read-Write: Text descriptor typically used to describe the physical device (sensor, equipment) connected to the binary input.
Device-support ed text string. normal
Read-Write: Determines if the physical state normal, reverse at the device input is reflected at the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state that is evaluated as an alarm. See Table 3-3 on page 3-20 for information on these common full object properties. True, False
timeDelay, notificationClass alarmValue eventEnable, notifyType
Active
Visual
activeInactiveText (not Lite objects) statusOutput (output sOut)
Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the current boolean state and status of the statusOutput. If a full-type BI object, statusOutput is displayed in terms of inactiveActiveText.
Active, Inactive false {ok}
If a Lite object, states are always false or true.
Engineering
Inactive or Active, {status flags}
BACnet BI Notes
The BACnetBinaryInput is another frequently-used object in typical BACnet integrations. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
338
Chapter 3
BACnet Client Operation BACnetBinaryOutput
BACnetBinaryOutput
abbrev: BO This object shadows a Binary Output object in a BACnet device. Access to the BO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output state at priority levels 1 and 8. If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet). A separate presentValue output is also available. Default Resource Count Trigger Properties 70 (full), 46 (lite)
Inputs

Outputs
statusOutput

Inputs
Outputs
presentValue statusOutput
Input / Output Property Reference for BACnet BO Object

Type
input output
Label
exe pIn present sOut
Property Name
executeTrigger priorityArray presentValue statusOutput
Data Species
TriggerType FloatPriorityArrayType Float FloatStatusType
The BACnet BO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the BACnet BO object provides control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property):

Commands
ActiveTo set an active output at the Manual level (8). Requires Command, Std user privileges. InactiveTo set an inactive value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear any active or inactive output at the Manual level (8). EmergencyActiveTo set an active output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyInactiveTo set an inactive output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear any active or inactive output at the Emergency level (1). Requires Command, Emer user privileges.
339
Chapter 3 BACnetBinaryOutput
Properties
Table 3-6 BACnetBinaryOutput (BO) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects) Status changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) feedbackValue (not Lite objects) priorityArray Priorities
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BO object, presentValue is displayed in terms of inactiveActiveText. If a Lite BO, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state). Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.
Valid Values
Default
Notes
timestamp or null (none) integer value
null 0
timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) False, True
null 0:00:00
null
False
auto 1 to 16
relinquishDefault objectIdentifier, objectName useCOV covSubscribed deviceType
0.0
Config
(not Lite objects) minimumOnTime (not Lite objects)
Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. Read Only: Minimum number of seconds that presentValue remains at the active state after a write to present Value causes that property to assume the active state. An active at the Minimum On Off priority level (6) occurs for this time.
Device-support ed text string. integer value 0
340
Chapter 3
BACnet Client Operation BACnetBinaryOutput
Table 3-6 BACnetBinaryOutput (BO) object properties. (continued)
Tab Property Name

minimumOffTime (not Lite objects) Config, cont.
Description
Read Only: Minimum number of seconds that presentValue remains at the inactive state after a write to present Value causes that property to assume the inactive state. An inactive at the Minimum On Off priority level (6) occurs for this time.
Valid Values
integer value
Default
0
Notes
polarity
Read-Write: Determines if the physical state normal, reverse at the device output is reflected by the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties.
normal
Alarm Setup
timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) commandTags
Read-Write: Defines the labels used to list commands that appear on the right-click command menu. Default text values for commandTags are:

activeInactiveText (not Lite objects) intPriorityArray
Active (active at level 8) Inactive (inactive at level 8) Auto (auto at level 8) EmergencyActive (active at level 1) EmergencyInactive (inactive at level 1) EmergencyAuto (auto at level 1)
Any desired text string, including spaces and numerals.
See descrip.
Visual
Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the boolean commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current boolean state and status of the statusOutput.
Active, Inactive auto 1 to 16
If a Lite object, states are always false or true. These station-generated commands can dynamically update.
Engineering
(input pIn)
false, true, or auto, levels 1 to 16 false or true, {status flags}
false {ok}
BACnet BO Notes
Depending on the BACnet device and the vendors implementation, BACnet Binary_Output objects may exist for either (or both) physical digital outputs and/or commandable states, such as occupancy control. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
341
Chapter 3 BACnetBinaryValue
BACnetBinaryValue
abbrev: BV This object shadows a non-commandable Binary Value object in a BACnet device. It is one of two Niagara shadow-object types possible for a BACnet Binary Value object; the other is BACnetBinaryValuePriority. This object brings a boolean control-system parameter into the stations control engine. A linkable statusInput allows the boolean value to be sourced from another Niagara object (providing that the value is writable). If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for BACnet BV Object

Type
input output
Label
exe sIn sOut
Property Name
Data Species
TriggerType FloatStatusType FloatStatusType
The BACnet BV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.
Commands Properties
Table 3-7 BACnetBinaryValue (BV) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects)
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BV object, presentValue is displayed in terms of inactiveActiveText. If a Lite BV, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state).
Valid Values
Default
Notes
Status
timestamp or null (none)
null
342
Chapter 3
BACnet Client Operation BACnetBinaryValue
Table 3-7 BACnetBinaryValue (BV) object properties. (continued)
Tab Property Name

changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) Status, cont. timeOfActiveReset (not Lite objects) statusInput
Description
Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the boolean value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.
Valid Values
integer value
Default
0
Notes
timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) timestamp or null (none) false, true: {status flags}
null 0:00:00
null
false: {ok}
Note: Do not link statusInput if the Binary Value object is read-only.

objectIdentifier, objectName useCOV covSubscribed timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) alarmValue (not Lite objects) Visual activeInactiveText (not Lite objects) statusOutput (output sOut) Read Only: Defines the presentValue state that is evaluated as an alarm. Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the current boolean state and status of the statusOutput. True, False True Active, Inactive false {ok} Config See Table 3-3 on page 3-20 for details on these common shadow object properties.
Alarm Setup
If a Lite object, states are always false or true.
Engineering
false or true, {status flags}
BACnet BV Notes
BACnetBinaryValue objects are often used for read-only status states, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
343
Chapter 3 BACnetBinaryValuePriority
BACnetBinaryValuePriority
abbrev: BVP This object shadows a commandable Binary Value object in a BACnet devices, meaning a BV object with priorityArray and relinquishDefault properties. This object is like the BACnetBinaryValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like a BO object). If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet). A separate presentValue output is also available.
Inputs

Outputs
statusOutput

Inputs
Outputs
presentValue statusOutput
Input / Output Property Reference for BACnet BVP Object

Type
input output
Label
exe pIn present sOut
Property Name
executeTrigger priorityArray presentValue statusOutput
Data Species
TriggerType BooleanPriorityArrayType Boolean BooleanStatusType
This object has an input trigger-type property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the BACnet BV Priority object provides control commands. By default, these commands appear as follows (note that descriptors are modifiable using the objects commandTags property):

Commands
ActiveTo set an active output at the Manual level (8). Requires Command, Std user privileges. InactiveTo set an inactive value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear any active or inactive output at the Manual level (8). EmergencyActiveTo set an active output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyInactiveTo set an inactive output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear any active or inactive output at the Emergency level (1). Requires Command, Emer user privileges.
344
Chapter 3
BACnet Client Operation BACnetBinaryValuePriority
Properties
Table 3-8 BACnetBinaryValuePriority (BVP) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime Status (not Lite objects) changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) priorityArray Priorities
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BVP object, presentValue is displayed in terms of inactiveActiveText. If a Lite BVP, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state). Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the values and priorities in the objects 16-level priorityArray (in the device). A fetch provides current values. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.
Valid Values
Default
Notes
timestamp or null (none) integer value
null 0
timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) <valid float> or auto, levels 1 to 16 valid float
null 0:00:00
null
auto 1 to 16 0.0
relinquishDefault objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects) minimumOnTime (not Lite objects)
Config
Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. Read Only: Minimum number of seconds that presentValue remains at the active state after a write to present Value causes that property to assume the active state. An active at the Minimum On Off priority level (6) occurs for this time. Read Only: Minimum number of seconds that presentValue remains at the inactive state after a write to present Value causes that property to assume the inactive state. An inactive at the Minimum On Off priority level (6) occurs for this time.
Device-support ed text string. integer value
minimumOffTime (not Lite objects)
integer value
345
Chapter 3 BACnetBinaryValuePriority
Table 3-8 BACnetBinaryValuePriority (BVP) object properties. (continued)
Tab Property Name

polarity
Description
Valid Values
Default
normal
Notes
Read-Write: Determines if the physical state normal, reverse at the device output is reflected by the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties.
Alarm Setup
timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) alarmValue (not Lite objects) commandTags
Read Only: Defines the presentValue state that is evaluated as an alarm. Read-Write: Defines the labels used to list commands that appear on the right-click command menu. Default text values for commandTags are:
True, False Any desired text string, including spaces and numerals.
True See descrip. If a tag is blank (no characters), the command is not available on the command menu.

activeInactiveText (not Lite objects) intPriorityArray (input pIn)
Active (active at level 8) Inactive (inactive at level 8) Auto (auto at level 8) EmergencyActive (active at level 1) EmergencyInactive (inactive at level 1) EmergencyAuto (auto at level 1)
Visual
Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the Niagara (station) boolean commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current boolean state and status of the statusOutput.
Active, Inactive auto 1 to 16
If a Lite object, states are always false or true. See Value-Type Objects, Input Usage on page 3-24.
Engineering
false, true, or auto, levels 1 to 16 false or true, {status flags}
false {ok}
BACnet BV (Priority) Notes
Depending on the BACnet device and the vendors implementation, commandable BACnet Binary_Value objects may exist for application control modes and related parameters. If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.
346
Chapter 3
BACnet Client Operation BACnetMultistateInput
BACnetMultistateInput
abbrev: MSI This object shadows a Multi-state Input object in a BACnet device. It is used to bring a sensed state (integer value) from a device MSI into the control engine, where it can be linked into other control logic. If the object is a full type, the state value is formatted using descriptive state text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for BACnet MSI Object

Type
input1 output 1.
Label
exe sOut
Property Name
executeTrigger statusOutput
Data Species
TriggerType IntegerStatusType
If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species IntegerStatusType (see below).

Inputs
Outputs
statusOutput
The BACnet MSI object has an input property, executeTrigger, (typically not used). Niagara multistate objects differ from BACnet multistate objects in the implementation of presentValue. Specifically, a presentValue (and stateText entry) of 0 (zero) is valid in a Niagara MSI, whereas 0 is not valid in a BACnet MSI object. See the the Common Commands section on page 3-17.
Note
Commands Properties
Table 3-9 BACnetMultistateInput (MSI) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService,
Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor.
Valid Values
Default
Notes
If a writable MSI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.
Status
347
Chapter 3 BACnetMultistateInput
Table 3-9 BACnetMultistateInput (MSI) object properties. (continued)
Tab Property Name

numberOfStates
Description
Read Only: Shows the number of states defined in the objects stateText property. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service. The default value is Error, which occurs with a 0 value or any other inappropriate value.
Valid Values
1 to ?
Default
Notes
Status, cont.
reliability, ackedTransitions (not Lite objects) statusInput (input: sIn) (only writable MSI)
<state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)
Error {ok}
Config
objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects)
Read-Write: Text descriptor that can describe the physical device (sensor, etc.) connected to the multistate input. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state(s) that are evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines all possible discrete states by value-name pairs. Each state has two fields:
Device-support ed text string. state0 through 7 state0 through 7 If the source object has more than 8 states, only the first 8 are accessible.
Alarm Setup (not Lite obj.)
timeDelay, notificationClass alarmValues faultValues eventEnable, notifyType stateText (not Lite objects)
valueUnique integer. Values are

contiguous and typically start at 1. (Only the first 8 stateText are visible as alarmValues or faultValues). tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. statusOutput (output sOut) Read Only: Shows the current state and status present at the statusOutput. Visual
Unique integers, with associated text descriptor. Up to ? states can be learned.
State descriptors (tags) are seen in linked MultistateLog object samples and also can display at a linked GxText object.
Engineering
Lite objects have integer-only values to

represent the different states.
Full objects use the stateText descriptors

to represent the different states.
348
Chapter 3
BACnet Client Operation BACnetMultistateInput
BACnet MSI Notes
Full versions include read-only access to the native text descriptors used in the shadowed MSI object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. If the source BACnet MSI object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues. Note also that BACnet Multistate Input objects, unlike their Niagara equivalents, do not offer runtime (elapsed active time) and change-of-state (COS) count capabilities.
Note
349
Chapter 3 BACnetMultistateOutput
BACnetMultistateOutput
abbrev: MSO This object shadows a Multi-state Output object in a BACnet device, a commandable integer-based object. Access to the MSO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output state at priority levels 1 and 8. If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet).
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for BACnet MSO Object

Type
input output
Label
exe pIn sOut
Property Name
Data Species
TriggerType IntegerPriorityArrayType IntegerStatusType
The BACnet MSO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides MSO control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property): SetTo set an output state at the Manual level (8). Drop Requires Command, Std privileges. AutoTo clear an output state set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output state at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output state set at the Emergency level (1). Requires Command, Emer privileges.
Commands
Note
If full objects, both the Set and Emergency Set command menus provide a drop-down list of states (described in text) for selection. If lite objects, command menus provide only a field in which an integer value can be entered.
350
Chapter 3
BACnet Client Operation BACnetMultistateOutput
Properties
Table 3-10 BACnetMultistateOutput (MSO) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, Status numberOfStates reliability, ackedTransitions (not Lite objects) feedbackValue (not Lite objects) priorityArray Priorities
Description
Valid Values
Default
Notes
presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor.
Read Only: Shows the number of states defined in the objects stateText property. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto.
1 to ?
a valid state
<valid state or integer> or auto, levels 1 to 16 <valid integer>
auto 1 to 16
relinquishDefault
The default value (0) is not a valid value, but does indicate an upload is necessary.
Config
Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. See Table 3-3 on page 3-20 for information on these common full object properties.
Device-support ed text string.
Alarm Setup
timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) commandTags
Visual
Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:
See descrip.
351
Chapter 3 BACnetMultistateOutput
Table 3-10 BACnetMultistateOutput (MSO) object properties. (continued)
Tab Property Name

stateText (not Lite objects) Visual, cont.
Description
Read-Only: Defines all possible discrete states by value-name pairs. Each state has two fields:
Valid Values
Unique integers, with associated text descriptor. Up to ? states learned.
Default
Notes
State descriptors (tags) are used in linked MultistateLog object collections and also can display at a linked GxText object.

contiguous and typically start at 1. tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. intPriorityArray (input pIn) Read Only: Shows the Niagara (station) commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current state and status present at the statusOutput.
<integer or text state>, or auto, levels 1 to 16 <state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)
auto 1 to 16
Station-generated commands only. Dynamically update.
Engineering


BACnet MSO Notes
Depending on the BACnet device and the vendors implementation, BACnet Multi-state_Output objects may exist for either (or both) physical discrete outputs and/or commandable states. Full versions include read-only access to the native text descriptors used in the shadowed MSO object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. Note also that BACnet Multistate Output objects, unlike their Niagara equivalents, do not offer runtime (elapsed active time) and change-of-state (COS) count capabilities.
352
Chapter 3
BACnet Client Operation BACnetMultistateValue
BACnetMultistateValue
abbrev: MSV This object shadows a non-commandable Multi-state Value object in a BACnet device, an integer-based object. It is one of two Niagara shadow-object types possible for a BACnet Multi-state Value object; the other is BACnetMultistateValuePriority. This object brings a multistate (integer) control-system parameter into the stations control engine. A linkable statusInput allows the state to be sourced from another Niagara object (providing that its value is writable). If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Inputs

Outputs
statusOutput

Inputs
Outputs
statusOutput
3
Input/Output Property Reference for BACnet MV Object
Type
input output
Label
exe sIn sOut
Property Name
Data Species
TriggerType IntegerStatusType IntegerStatusType
The BACnet MSV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.
Commands Properties
Table 3-4
BACnetMultistateValue (MSV) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, numberOfStates
Description
Valid Values
Default
Notes
presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor. If more than 8 states, alarm and fault values show only for first 8.
Status
Read Only: Shows the number of states defined in the objects stateText property.
1 to ?
reliability, ackedTransitions (not Lite objects)
353
Chapter 3 BACnetMultistateValue
Table 3-4
BACnetMultistateValue (MSV) object properties. (continued)
Tab Property Name

statusInput Status, cont.
Description
Read Only: Shows the multistate value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.
Valid Values
Default
false: {ok}
Notes
Note: Do not link statusInput if the Multistate Value object is read-only.

objectIdentifier, objectName useCOV covSubscribed timeDelay, notificationClass alarmValues faultValues eventEnable, notifyType See Table 3-3 on page 3-20 for details on these common shadow object properties.
Config
See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state(s) that are evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties.
state0 through 7 state0 through 7
If the source object has more than 8 states, only the first 8 are displayed.
stateText (not Lite objects) Visual

contiguous, and typically start at 1. tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. statusOutput (output sOut) Read Only: Shows the current state and status present at the statusOutput.
Engineering


BACnet MSV Notes
BACnet Multi-state_Value objects are sometimes used for read-only status states, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism. Note that full versions include read-only access to native text descriptors used in the shadowed MSV object. Alarming support is also available for full MSV objects. If the source BACnet MSV object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues.
Note
354
Chapter 3
BACnet Client Operation BACnetMultistateValuePriority
BACnetMultistateValuePriority
abbrev: MSVP This object shadows a commandable Multi-state Value object in a BACnet device, meaning an MSV object with priorityArray and relinquishDefault properties. This object is similar to the integer-based BACnetMultistateValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like an MSO object). If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet).
input output

Inputs Outputs
statusOutput

Inputs
Outputs
statusOutput
Input / Output Property Reference for AI Object

Type
Label
exe pIn sOut
Property Name
Data Species
TriggerType IntegerPriorityArrayType IntegerStatusType
This object has an input trigger-type property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides MSV control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property): SetTo set an output state at the Manual level (8). Drop Requires Command, Std privileges. AutoTo clear an output state set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output state at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output state set at the Emergency level (1). Requires Command, Emer privileges.
Commands
Note
If full objects, both the Set and Emergency Set command menus provide a drop-down list of states (described in text) for selection. If lite objects, command menus provide only a field in which an integer value can be entered.
355
Chapter 3 BACnetMultistateValuePriority
Properties
Table 3-11 BACnetMultistateValuePriority (MSVP) object properties.
Tab Property Name

objectType, statusFlags, description, presentValue, eventState, outOfService, Status numberOfStates feedbackValue (not Lite objects) reliability, ackedTransitions (not Lite objects) priorityArray Priorities
Description
Valid Values
Default
Notes
Read Only: Shows the number of states defined in the objects stateText property. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto.
1 to ? <valid state or integer>
<valid state or integer> or auto, levels 1 to 16 <valid integer>
auto 1 to 16
relinquishDefault
The default value (0) is not a valid value, but does indicate an upload is necessary.
Config
Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state that is evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:
Device-support ed text string.
timeDelay, notificationClass, alarmValues faultValues eventEnable, notifyType commandTags
state0 through 7 state0 through 7
If the source object has more than 8 states, only the first 8 are displayed.
Visual
See descrip.
356
Chapter 3
Table 3-11 BACnetMultistateValuePriority (MSVP) object properties. (continued)
Tab Property Name

stateText (not Lite objects) Visual, cont.
Description
Valid Values
Default
Notes

contiguous and typically start at 1. tagText that describes the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. intPriorityArray (input pIn) Read Only: Shows the Niagara (station) commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current state and status present at the statusOutput.
<integer or text state>, or auto, levels 1 to 16 <state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)
auto 1 to 16
Engineering
See Value-Type Objects, Input Usage on page 3-24.
Error : {ok}


BACnet MSV (Priority) Notes
Depending on the BACnet device and the vendors implementation, commandable BACnet Multi-state_Value objects may exist for application control modes and related parameters. Full versions include read-only access to the native text descriptors used in the shadowed MSO object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. If the source (commandable) BACnet MSV object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues.
Note
357
Chapter 3
358
CHAPTER
BACnet Server Operation

Due to its BACnet heritage, a Niagara station requires minimal configuration for BACnet server operation. The few main topics below explain the related topics. Device Object Exporting Objects Allowing BACnet Write Access Using BACnet Log Objects
Device Object
The Device object that represents the Niagara station has various properties, some of which are populated by BACnetService properties. The Device object has a BACnet Object_Name property derived from the Stations name, with its Device object instance number appended to the end. For example, a Station named EastWing3 running the BACnetService that is configured with a deviceID, Instance Number of 101 will have an object name of: EastWing3_101 Table 4-1 shows how selected properties of the stations Device object are sourced.
Table 4-1 Device object for Station, selected properties and Niagara source.
BACnet property
Object_Identifier Object_Name Object_Type Vendor_Name Vendor_Identifier Model_Name
Niagara source
BACnetService, Config tab Station name and Device ID (fixed)
Niagara property/entry/(Notes)
deviceID, Instance Number <StationName>_<Instance Number> Device typically, is Tridium typically, is 36
typically, from license.properties file typically is value of line productSummary=<value> (plus) of Niagara host - powered by Niagara Framework (example: JACE-NX - powered by Niagara Framework) if productSummary line is absent, then Niagara Station.
Firmware_Revision
version of coreruntime module in Niagara host
(example, 2.301.508.v1)
41
Chapter 4 Exporting Objects
Table 4-1
Device object for Station, selected properties and Niagara source. (continued)
BACnet property
Niagara source
Niagara property/entry/(Notes)
(example, 2.305.508.v1)
Application_Software_Revision typically, is bacnet module version in host Location Description Segmentation_Supported Local_Time Local_Date APDU_Segment_Timeout APDU_Timeout Number_of_APDU_Retries Max_Master Max_Info_Frames BACnetService, Config tab
license.properties file of Niagara Default is value of line customerSite=<value> host (Each value can be overridden, see Adjunct Configuration: Default is value of line customerName=<value> bacnet.properties File, page 6-28 BACnetService, Config tab Station time Station data segmentationSupported apduSegmentTimeout apduTimeout numberOfApduRetries BACnetService, maxMaster BACnetMSTP tab, Config sub-tab maxInfoFrames
Note that other Device object properties not shown in Table 4-1 (where applicable), are sourced from the BACnetService, but have no visibility in Niagara.
Exporting Objects
The station acts as a BACnet server when exposing (exporting) Niagara objects as BACnet objects. By default, read-only access is given to all remote BACnet clients. Write-access is optionalsee Allowing BACnet Write Access, page 4-6. You can expose any of the following standard Niagara objects as BACnet objects, regardless of where they are in the station database:

AnalogInput (AI) AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)

1.
MultistateInput 1 (MSI) MultistateOutput 1 (MSO) Calendar Schedule
All Ndio types (JACE-4 only), see Ndio Considerations, page 4-6.
StateText limitations apply. See Multistate Object Considerations, page 4-5.
In addition, you can expose Niagara logs as BACnet Trend_Log objects, but only by using the following special versions of Niagara log objects. You must copy and paste these log objects from the Local Library into your station database.
BACnet log objects have the following types:

BACnetAnalogLog BACnetBinaryLog BACnetIntegerLog
BACnetMultistateLog BACnetStringLog
42
Chapter 4
BACnet Server Operation Exporting Objects
See the later section Using BACnet Log Objects, page 4-8, for more details. The following main topics apply when exporting Niagara objects to BACnet: Setting Object Properties Object Name Conventions
It is recommended that you read through both sections before exposing objects.
Setting Object Properties

For any Niagara object to be exported as BACnet, you must assign it an object instance number (foreignAddress property). Details are explained in these sections: Setting the foreignAddress BACnet Export Rules and Considerations
Note
Any Niagara object exported as BACnet incudes its entire station swid in its object name. This enforces (externally) the BACnet requirement for unique names for all objects in a device. The config property foreignAddress exists for most standard types of standard Niagara objects. However, foreignAddress currently applies only to object types previously listed under Exporting Objects, page 4-2. In combination with the objects type, foreignAddress specifies the objects BACnet object identifier within the Niagara station.
Figure 4-1 foreignAddress is a Config property that defines BACnet instance number.
Setting the foreignAddress
Note
The BACnet service has a similar property: deviceID, Instance Number, for the externally visible Device object that represents the running Niagara station. Refer to page 1-11 for more details.
43
Chapter 4 Exporting Objects
Per the BACnet specification, each object in a device must have an identifier that is the unique combination of its object type and instance number, for example: Analog_Input: 2 Binary_Output: 11
The default foreignAddress for any Niagara object is -1 (not a BACnet object). To expose a Niagara object as BACnet, you must assign it a foreignAddress number.
BACnet Export Rules and Considerations
Before you export Niagara objects to BACnet, it is recommended that you read and understand the following rules and considerations: Instance Number Rules Multistate Object Considerations Ndio Considerations
Instance Number Rules

The following rules apply when you wish to expose an object as BACnet. A valid foreignAddress property value for a Niagara object is an integer from 0 to 4194302 (BACnet maximum for configured instance number). A BACnet device cannot contain two objects with the same object identifier, meaning type and instance number. This means that when exporting Niagara objects in a Niagara station, you must be careful to assign unique numbers to foreignAddress properties among any specific BACnet object type. It is permissible, for example, to have as many as 8 objects that each have a foreignAddress of 3 (when each object is a different type). However, you can only have one Calendar object with a foreignAddress of 3, one AnalogInput object with a foreignAddress of 3, and so on.
Note
The JDE does not automatically enforce this rule when editing properties. Therefore, you must keep track of foreignAddress values within object types.
If you try to export an object with a duplicate indentifier (or try to export a Niagara object with no BACnet equivalent), you see no indication of a problem from the property sheet. However, a specific WARNING is logged in the stations ErrorLogService, and also appears in the stations Standard Output.
Niagara multistate objects and Ndio objects (JACE-4 only) have special export considerationssee immediately following sections.
Note
When you duplicate or copy-and-paste Niagara objects that have been exported (assigned a specific foreignAddress), notice that the new objects do not have duplicate instance numbers. Instead, they automatically have a foreignAddress = -1, meaning not a BACnet object. If you wish to export them, you must assign foreignAddress appropriately.
44
Chapter 4
BACnet Server Operation Exporting Objects
Multistate Object Considerations

Before exposing a Niagara MultistateInput (MSI) or MultistateOutput (MSO) object as a BACnet object, be aware that you must first edit its stateText property to be compliant with the BACnet definition. This is a Visual tab property (Figure 4-2). Specifically, a zero (0) value is not allowed, plus all values must be contiguous.
Figure 4-2 Niagara MSI or MSO object must have stateText with contiguous values, and with no zero (0).
Default stateText values for a Niagara MSI and MSO object include the non-compliant 0 value.
This MSI object has had its stateText property edited to remove the 0 value. Other values were modified and added as needed, using the StateText Guidelines (below).
By default, Niagara stateText settings include a 0 value for the Off (first) state. However, the BACnet protocol reserves a presentValue of 0 as an index into the array of possible states defined by stateText. Therefore, you cannot expose a Niagara MSI or MSO without first editing stateText using the guidelines below.
StateText Guidelines
If you follow these guidelines when assigning stateText values, you can then expose a Niagara MSI or MSO object as BACnet.
1.
Assign numerical states starting at 1 (not 0, as in a standard Niagara multistate). For a two-speed object, for example, this means 1 = Off, 2 = On, and 3 = Fast, versus the numerical 0, 1, and 2 assignments used in stateText defaults. Assign state numbers contiguously (without skipping a number), with a maximum of 8 discrete states for an MSI (1 to n, where n < 9). MSO objects may have more states, but they must be contiguous. Limitations on number of MSI states are from Niagara, while the contiguous restriction is from BACnet. If you assigned a foreignAddress value to expose an MSI or MSO object, but did so before stateText is in BACnet compliance, you will need to reassign the foreignAddress value (first to -1 and then back to the desired value). If you assign a foreignAddress value to an MSI or MSO object that has a non-compliant stateText configuration, this is recorded in the stations ErrorLogService.
2.
Notes
45
Chapter 4 Allowing BACnet Write Access
Ndio Considerations
When exposing Ndio objects (JACE-4 station), be aware that following object types count as standard Niagara objects: Ndio0to10VInput, NdioHighSpeedCounterInput, NdioResistiveInput, and NdioThermistorType3Input each count as a standard AnalogInput object. Ndio0to10VOutput and Ndio0to20MAOutput objects each count as a standard AnalogOutput object. (Ndio0to20MAOutput is for future use). NdioBinaryInput objects count as a standard BinaryInput. NdioBinaryOutput objects count as a standard BinaryOutput.
Refer to ndio (bacxNdio), page D-2 of Appendix D, Niagara bacnetx Modules, for more information.
Object Name Conventions

Typically, a BACnet device requires a unique name for each contained object. Due to the hierarchical architecture of a Niagara station, however, it is quite possible for a JACE to contain many objects with the same name (where each object resides in a different container). For example, there may be many objects named SpaceTemp, each with a unique swid, because each object has a unique parent container. When exposing Niagara objects as BACnet objects, Niagara accounts for this. Each exposed object uses the complete Niagara station swid as its BACnet object name. For example, an exposed BinaryOutput object from station demoR2 is named:
demoR2_Sim_LogicScreens_AirHandler_supplyFan
As needed, the station sends an I-Have message to respond to Who-Has service requests from other networked BACnet devices. Note that the stations I-Have service responds to a name-based request only if the objects swid is given. This is because multiple BACnet objects with the same name can exist in a station. The swid syntax for a Who-Has (by name) in stations running older builds is:
/<stationName>/<containerPaths>/<objectName>
for example,
/NewJ5b/AirHandlers/AHU1/Logic/SupplyFan
Allowing BACnet Write Access

To allow other BACnet devices (BACnet workstations included) to write values in exposed Niagara objects, you must define a special BACnet user for the station.
Procedure 4-1 Configuring a BACnet user.
Step 1
In the Tree View of JDE, right-click on the station and select Go > UserAdmin.
46
Chapter 4
BACnet Server Operation Allowing BACnet Write Access
Step 2
From the UserAdmin menu, select New User. A New User dialog appears.
Figure 4-3 Adding a BACnet user to allow write access from other BACnet devices.
Step 3
Enter a user name of BACnet, any desired password, and click OK. While a password is technically not necessary, you should assign one because you must give write privileges to the BACnet user.
Note
Step 4
Double-click on the BACnet user in the Workspace to bring up the User Preferences dialog box. Click the Security tab. Assign write access, as needed, to appropriate security group(s) at the desired levels (Admin, Operator, Command). Figure 4-4 shows full access for the General group.
Figure 4-4 Assign write privileges as needed by security group and levels.
Step 5
Notes
If needed, you can assign BACnet-exposed objects to certain security groups and then define the appropriate access to those groups to the user BACnet. Generally, Admin-level write-access is required to modify most Niagara object properties, including configurations of Calendar and Schedule objects. Command access applies to commandable-type objects, such as AnalogOutput (AO) and BinaryOutput (BO) objects.
47
Chapter 4 Using BACnet Log Objects
Using BACnet Log Objects

Starting in Niagara r2.3.4, the Niagara BACnet module contains special versions of log objects that you copy and paste from the Local Library. Use them in place of standard Niagara logs whenever you need to export a log as a BACnet Trend Log1. The following subsections apply to Niagara BACnet log objects: BACnet Log Overview Adding BACnet Logs BACnet Log Shapes BACnet Log Shapes
BACnet Log Overview

Each BACnet log object works exactly like the equivalent standard Niagara log object in all respects but oneconfig properties that define valid collection periods. Niagara logs have config properties daysOfWeek and timeRange. BACnet logs have (instead) config properties startTime and endTime, per the BACnet specification. See Collection Time Differences for more details.
Other features of the BACnet log objects are identical to standard Niagara logs, including archive functions, LogChart and LogTable views, commands, inputs, outputs, and config properties (except the two properties noted above). BACnet log objects also appear in the stations log index and log selector like standard logs.
Note
Refer to the Niagara Standard Programming Reference for detailed information about the equivalent standard Niagara log objects, which include:

AnalogLog Binary Log Integer Log
MultistateLog StringLog
Adding BACnet Logs

You add BACnet log object by copying and pasting from the Local Library.
Procedure 4-2 Copying BACnet logs into a station database.
Open the station to receive a BACnet log, and navigate to the target container. Open the Local Library. Working in Tree View, expand the folder tridiumx, then the bacnet JAR.
1. BACnet Trend Log type 135-2001, not 135b-2001 (no concept of sequence number).
48
Chapter 4
BACnet Server Operation Using BACnet Log Objects
Step 4
Under bacnet, expand services, then the sub-folder server. This reveals the 5 different BACnet log objects available. Right-click any object and select Copy, and then Paste it in the station in the desired container (Figure 4-5).
Figure 4-5 Copy BACnet logs from the tridiumx/bacnet/services/server folder.
Step 5
Local Library Right-click to paste copied BACnet log.
Right-click objects to copy
Step 6
Rename any copied log with an appropriate name, and configure standard log properties as needed for archiving, display, and so forth. When ready to export a copied log to BACnet, assign it a foreignAddress property number that is unique among all other BACnet log objects in the station.
Note
Step 7
All Niagara BACnet log objects are exported as a BACnet Trend_Log object.
Step 8
Continue to copy and paste BACnet logs as needed, either from logs previously copied/configured, or from the Local Library. Assign unique foreignAddress values.
BACnet Log Shapes

In BACnet log objects, the assigned foreignAddress value appears within its object shape, similar to what appears for BACnet client (shadow) objects. This is unique among BACnet-exported Niagara objects, and is useful when viewing a workspace to see assigned instance numbers (foreignAddress) for exposed Trend_Logs.
49
Figure 4-6
Default BACnet log objects copied from Local Library
Instance number (foreignAddress) appears within BACnet log objects shapes.
Trend Log instance number
Mouse over BACnet log object to see Niagara object type.
Note that the different Niagara type of BACnet log object (Analog, Binary, etc.) is not shown within its shapehowever, when you mouse over the object, its object type appears in the windows lower status line (Figure 4-6, right).
Collection Time Differences

By default, any BACnet log object copied from the Local Library will have all wildcards (*) for all fields in the properties startTime and endTime (Figure 4-7). The log will start collecting as soon as you connect the statusInput to a source data output. This is similar to how a standard Niagara log works, whereby by default, all days of week are selected, and the time range is from 12:00 AM to 12:00 AM.
Figure 4-7 Config properties startTime and endTime apply to each BACnet log object.
However, this similarity ends with a BACnet log if you need a daily timer to enable log collection. If any field in startTime or endTime contains a wildcard (*), this essentially disables that entire property (per the BACnet spec for a Trend_Log). For example, if you want to log daily only between the period of 8:00 AM and 5:00 PM, the startTime and endTimes values as shown in Figure 4-8 will not work. Instead, logging will continue all 24 hours, as startTime and endTime are ignored.
410
Chapter 4
BACnet Server Operation Using BACnet Log Objects
Figure 4-8
Both startTime and endTime here are ignored, as each contains a wildcard (*).
Invalid entries due to the wildcard (*) fields.
In this case, you could link a Schedule to the log objects logEnable input, and define the desired log periods in the configuration of the Schedule object (Figure 4-9).
Figure 4-9 BACnet logs input logEnable is used (link to Schedule object).
logEnable input controlled by Schedule object.
Schedule objects weekly schedule will enable log collection.
Using Log Start and End Times
If you have an application to either start and/or stop log collection at a specific date and time, you can configure the startTime and endTime properties appropriately. For example, a BACnet log configured as shown in Figure 4-10 will collect only during February, 2003both startTime and endTime properties have no wildcards.
Figure 4-10 Both startTime and endTime here are observed, as there are no wildcards (*).
Either of these properties is observed only if wildcard (*) free.
411
412
CHAPTER
Configuring BACnet Alarming

A Niagara station supports BACnet intrinsic event reporting, more commonly called alarming. Support is available for both client and server operations, meaning the station can both receive (and reroute) BACnet alarms from shadowed objects, and also send BACnet alarms from objects exposed as BACnet. The following sections explain configuration required for BACnet alarming: Generating BACnet Alarms Receiving BACnet Alarms
Generating BACnet Alarms

Niagara alarms are exported to BACnet using a special notification recipient object, BACnetRecipient (Figure 5-1). The BACnetRecipient stores an address of a remote BACnet device to which alarms shall be sent.
Figure 5-1 BACnetRecipient object routes a Niagara alarm as a BACnet alarm.
51
Chapter 5 Generating BACnet Alarms
When a Niagara alarm occurs and is routed to a BACnetRecipient, the recipient creates a BACnet Event Notification Request and sends it to the configured device. The alarm is also routed in the standard manner to the station, Alarm Console, and Vykon Alarm Service (VAS) client. The alarm can be acknowledged normally using the Alarm Console/VAS client, or the remote BACnet device can issue a BACnet Acknowledge Alarm request to acknowledge the alarm. Upon receiving a valid BACnet ack request from the remote device, the station routes the ack throughout the Niagara system and removes the corresponding alarm from the Event.UnackedAlarms table of the Supervisor. Sections ahead explain the following Niagara BACnet alarm-generation topics: Requirements and Restrictions Configuring for BACnet Alarm Generation BACnetRecipient Object BACnetRecipient Notes
Requirements and Restrictions

These requirements and restrictions apply to Niagara BACnet alarm generation:
Only Niagara objects that are exposed as BACnet objects can generate BACnet alarms. This means only alarms from Niagara AIs, AOs, BIs, BOs, MSIs, and MSOs can be routed to BACnet devices (Calendar and Schedule objects are not alarmable). This draws from the BACnet requirement that every alarm message must contain the BACnet object ID of its source. Only local objects in a station can generate BACnet alarms. Therefore, a supervisor station cannot generate a BACnet alarm on behalf of an object in a subordinate station. If a subordinate station needs to generate a BACnet alarm, it must be configured with the BACnet service and the appropriate recipient(s). A separate BACnetRecipient must be created for each remote device to which BACnet alarms must be routed (one-to-one BACnetRecipient to device). Alarms are not regenerated. If a BACnet device is down when the Niagara system sends an alarm, the alarm is not saved for retransmission later. The Niagara system, of course, still maintains a record of the alarm in its buffer. The Niagara system does not support setting up a third-party BACnet system to receive BACnet alarms, configure its notification classes, and so forth. All alarm configuration and setup must be done using the systems native tools.
52
Chapter 5
Configuring BACnet Alarming Generating BACnet Alarms
Configuring for BACnet Alarm Generation

Using the JDE, follow these steps to configure a station running the BACnet service to generate BACnet alarms.
Procedure 5-1 Configuring for BACnet alarm generation.
Step 1
Create (if not already created), BACnetDevice objects in the station. Typically, you use the BACnetUtility and its learnNetwork command. Note the device objects specific BACnet address (instance number) as shown in their respective shapes. In the NotificationService container, create a NotificationClass object to handle BACnet alarms. A dedicated NotificationClass is not necessary, but it helps you ensure that only objects exposed as BACnet use this notification class. In the JDE Tree View, open the Local Library and expand its tridiumx folder. Expand the bacnet JAR to the tridiumx/bacnet/notification level, and copy a BACnetRecipient (Figure 5-2).
Figure 5-2 BACnetRecipient objects are copied from the Local Library.
Local Library
Step 2
Step 3
tridiumx/bacnet/notification folder (right-click and select Copy).
Step 4
Paste the BACnetRecipient in the NotifcationService container, and link it to the NotificationClass created above.
Note
Paste and link an additional BACnetRecipient, as needed, for each remote BACnet device that needs to receive Niagara alarms.
Step 5
Edit the BACnetRecipient objects Config property, recipientDeviceId, to hold the Device object ID of the BACnet device to receive the alarms. The property field is Instance Number, which is -1 by default. Change this to the unique Device object ID (instance number) of the target BACnet device.
53
Step 6
If needed, edit other Config properties of the BACnetRecipient object. See the BACnetRecipient Properties, page 5-5 for more details. For any Niagara AI, AO, BI, or BO object that is exposed as a BACnet object (foreignAddress property configured), assign the notification class (created above) used to handle BACnet alarms. The station is now configured to generate BACnet alarms for the specified objects. See the next section, Testing BACnet Alarm Generation, to verify proper operation.
Step 7
Testing BACnet Alarm Generation
In order to test Niagara BACnet alarm generation, you should have access to third-party BACnet tools for the remote devices. In addition, the Niagara system should be configured for standard Niagara alarming (Alarm Console receives alarms).
Procedure 5-2 Testing BACnet alarm generation from the JACE.
Step 1
Force into an alarm condition one of the standard AI, AO, BI, BO, MSI, or MSO objects that is exposed to BACnet (and assigned to the BACnet notification class). For example, with an analog object type, you can do this by setting the appropriate eventEnable properties and then modifying the alarm high or low limit. The alarm is routed via the notification class created in the previous Step 2, and passed onto the BACnetRecipient. The BACnetRecipient translates the alarm from the Niagara format to a BACnet format, and sends it to the BACnet device specified in the previous Step 5. At the same time, the alarm is also routed to its NotificationService archive location (local or supervisor) using the standard Niagara alarm mechanism.
Step 2
Using the third-party tool to access the remote BACnet device, verify the device receives the alarm. Open a Niagara alarm console and verify the alarm was received by Niagara. Using the third-party BACnet tool, issue an acknowledgement for the alarm. Verify an acknowledgment is received by the Niagara station. The alarm acknowledgement will be saved in the event history table. The alarm should also be removed form the list on unacknowledged alarms in the Alarm Console.
54
Chapter 5
Configuring BACnet Alarming Generating BACnet Alarms
BACnetRecipient
abbrev: none (BACnetRecipient) This object receives a Niagara alarm routed to a Niagara notification class, reformats it as a BACnet alarm, and sends it to a particular BACnet device. The object has a single linkable input property, notificationInput, for linking to NotificationClass object(s). The target BACnet device is identified in a Config property: recipientDeviceId. A separate BACnetRecipient object is needed for each remote BACnet device required to receive station-generated alarms.
Default Resource Count: 21 Dependencies
Inputs

Outputs
(none)

Inputs
notificationInput
Outputs
(none)
Input / Output Property Reference for BACnetRecipient

Type
input: output:
Label
notifica: (none):
Property Name
notificationInput: :
Data Species
NotificationTriggerType: :
Like other notification-type objects, a BACnetRecipient object must reside under the stations NotificationService container object. Important properties for a BACnetRecipient object are on its property sheets Config tab. Values reflect a BACnet Notification Class objects Recipient_List property. Description Valid Values Default
(all)
Properties
Table 5-1
BACnetRecipient object, important (Config) properties.
Tab Property Name

validDays
Notes
Default is for all days of the week. Separate recipient objects may specify the same BACnet device, but have different time ranges and other properties. See BACnetRecipient Notes for example.
Read-Write: Defines days of valid operation, Sun, Mon, Tue, by days of week. Any combination of days Wed, Thu, Fri, can be selected. Sat Read-Write: Defines time of valid operation, which applies to any of the defined valid days of week. The exclusive option, when checked, means the valid time range is any time outside the time range specified. 12:00 AM/PM to 12:00AM/PM, exclusive
timeRange
12:00 AM to 12:00 AM (constant)
Config
recipientDeviceId
Read-Write: Defines the target BACnet device to receive the alarm, by the instance number of its Device object. Read-Write: The handle of a process within the recipient device that is to receive the event notification. Read-Write: Defines whether notifications are to be sent using confirmed services (True) or unconfirmed services (False).
valid device instance number integer
-1 The single most (no device) important property. 0 Use of this property is a local matter in the remote device. If False (default), the station does not expect a response from the target device. Cleared transition types are not sent.
processId
issueConfirmedNotifications
False, True
False
validTransitions
Read-Write: Defines which event transition-types are valid for transmission.
to-offnormal, to-fault, to-normal
(all)
55
BACnetRecipient Notes
Depending on how a remote BACnet device processes received alarms, you may wish to configure BACnetRecipient properties apart from just recipientDeviceId. For example, if a device is configured to route incoming alarms received during weekdays to Process ID 1, and during weekends to Process ID 2, then in the station, two BACnetRecipient objects could target the same BACnet device (Figure 5-3).
Figure 5-3 Example of two BACnetRecipient objects with the same target BACnet device.
validDays = Mon, Tue, Wed, Thu, Fri deviceRecipientId = 14 processId = 1
validDays = Sat, Sun deviceRecipientId = 14 processId = 2
In the above example, both BACnetRecipient objects target BACnet device 14, however, they differ by values in properties validDays and processId. The validTransitions property is typically set to match the ackRequired property setting in the linked NotificationClass object. Depending on the capability of the target BACnet device, the property issueConfirmedNotifications may be left at default (False) or set to True.
Notes
If False, the alarm message is sent once, without any subsequent confirmation required from the target BACnet device. If True, a confirmation message from the target device is expected for each alarm issued (note this does not mean operator acknowledgement). If message confirmation is not received in the apduTimeout period, the alarm message is resent, up to the number of times specified in numberOfApduRetries (both are properties of the BACnet service). In general, by setting ackRequired in the linked NotificationClass object and issueConfirmedNotifications to True in the BACnetRecipient, the most secure communications between devices is provided.
56
Chapter 5
Configuring BACnet Alarming Receiving BACnet Alarms
Receiving BACnet Alarms

The BACnet service can accept incoming alarms from remote BACnet devices, convert them to the Niagara alarm format, and route them through the Niagara system. In this way, BACnet alarms can be sent to printer recipients, e-mail recipients, and so forth. BACnet alarms will also appear in the Niagara Alarm Console (Figure 5-4) or Vykon Alarm Service (VAS) client. A console or VAS client user can acknowledge the BACnet alarms just like native Niagara alarms.
Figure 5-4 BACnet alarm received in the Niagara Alarm Console.
A Niagara BACnet alarm record has two additional fields from a native alarm: extEventData and proxySwid.
The extEventData field shows the received value of the BACnet-formatted BACnetTimeStamp. Depending on the capability of the device generating the alarm, this may be a date-time or a simple sequence number.
Note: eventCount remains at 0 for a BACnet alarm. (This feature is proprietary to Niagara).
The proxySwid field shows the BACnetService, used to route alarm acknowledgements back to the generating BACnet device. A proxySwid field can appear in an alarm record for another integration object that does not directly alarm, for example, a LON device. However, in this example, the proxySwid names the BACnetService, because this is a BACnet alarm.
Sections ahead explain the following topics on receiving BACnet alarms: Requirements and Restrictions Configuring for BACnet Alarm Reception Testing BACnet Alarm Reception Using the GetAlarmSummary
57
Chapter 5 Receiving BACnet Alarms
Requirements and Restrictions

The following requirements and restrictions apply to BACnet alarms received by a Niagara station: A BACnet alarm must be generated by a BACnet device / object combination that is represented by valid shadow objects in the Niagara station. Otherwise, the alarm is discarded. The station must have the corresponding NotificationClass object in its NotificationService container (must be the same notification class number used by the alarming object in the remote BACnet device. In the property sheet of the alarmable shadow object, this is its notificationClass property.) Any BACnet alarms sent to a non-operative station are lost. The Niagara system does not query remote BACnet devices to retrieve lists of unacknowledged alarms. However, a JDE user can use the BACnetUtility command, getAlarmSummary, to retrieve a list of unacknowledged alarms from any specific BACnet device (providing it was previously learned). The Niagara alarming subsystem requires each alarm to be uniquely identified by a timestamp containing both time and date. Each BACnet alarm contains a BACnetTimeStamp field, which corresponds to the events to-<state> time. The value of this field can be a time, date-time, or simply a sequence number. For a BACnet alarm received with a date-time BACnetTimeStamp value, the date-time value is converted directly to a Niagara timestamp. Any BACnet alarm received with a time or sequence number is assigned a Niagara-type timestamp equal to its arrival time. The original BACnetTimeStamp value is stored in text format in the extEventData field of the Niagara alarm record.
Configuring for BACnet Alarm Reception

To configure BACnet alarm reception in a Niagara station, you need access to third-party configuration tools for the remote BACnet devices.
Procedure 5-3 Configuring for BACnet alarm reception.
Step 1
Using the JDE, create (if not already created), BACnetDevice objects and child objects in the station. Typically, you use the BACnetUtility and its learnNetwork and learnDevice commands. Refer to Chapter 2, Using the BACnet Utility for details. Using third-party tools for the remote BACnet devices, configure them to generate alarms for shadowed objects, and route them to the Niagara station. Note the notification class numbers used by the objects that will alarm (each Niagara shadow object will show its assigned notificationClass number). Using the JDE, create the necessary NotificationClass objects in the stations NotificationService container, based upon notification numbers obtained in Step 2.
Step 2
Step 3
58
Chapter 5
Configuring BACnet Alarming Receiving BACnet Alarms
Testing BACnet Alarm Reception

Step 1
In order to test Niagara BACnet alarm generation, you should have access to third-party BACnet tools for the remote devices. In addition, the Niagara system should be configured for normal Niagara alarming (Alarm Console receives alarms).
Procedure 5-4 Testing BACnet alarm reception by the JACE.
Force into an alarm condition one of the remote BACnet objects (as configured in Step 2 of the previous procedure). Using the JDE and the Alarm Console, verify the alarm is received by the Niagara station. The alarm will be routed using a notification class created in Step 3 of the previous procedure. Using the Niagara Alarm Console, acknowledge the alarm. A BACnet AlarmAcknowledgement message is issued to the remote device. Upon receipt of the acknowledgement message, the BACnet device will generate an ack notification message to indicate the alarm was successfully acknowledged. This message is sent to the Niagara station. The ack notification will be routed using the same notification class as the alarm. The alarm is then removed from the Alarm Consoles list of unacknowledged alarms.
Step 2
Step 3
Using the GetAlarmSummary

Related to BACnet alarm reception is the BACnet GetAlarmSummary service, provided as a device command in the stations BACnetUtility. For more information on this service, refer to the getAlarmSummary section on page 2-13.
59
Chapter 5 Receiving BACnet Alarms
510
CHAPTER
Configuring BACnetService Properties

The property sheet for the Niagara BACnet service contain parameters that affect the polling of BACnet shadow objects, the device status (device/ping) mechanism, link-layer-specific engineering properties, plus a variety of other parameters. Included is a router table listing known BACnet routers. The property sheet is also where you selectively toggle debug services (if needed), as well as issue commands to the service. The following main topics are explained ahead:

BACnetService Property Sheet Overview General Properties Status (current object counts and limit) Config (includes router table) Engineering (includes time synch master setup) Configuring BACnet Polling Configuring Device Status/Ping Configuring BACnet/IP Properties Config (to define BBMD role) Engineering (BBMD tables for broadcast distribution and foreign devices) Configuring BACnet/Ethernet Properties Commands to the BACnet Service Using Debug Options Adjunct Configuration: bacnet.properties File
61
Chapter 6 BACnetService Property Sheet Overview
BACnetService Property Sheet Overview

The BACnetService property sheet has two major types of tabs (Figure 6-1): Main tabsGeneral, Poll, DeviceStatus, and tabs for different link-layer (networks), BACnetIP, BACnetEthernet, and BACnetMSTP, 2, 3 and 4. Sub-tabsvary by main tab selected. For the main tab General, sub-tabs include Status, Config, Visual, Engineering, and Security.
Figure 6-1 BACnetService property sheet.
Right-click BACnetService, select Go > Properties.
Two rows of tabs, with main tabs at top and subtabs at bottom. When you click (select) any main tab, whatever subtabs it has appear at the bottom.
Resizing the JDE window smaller creates more rows for the tabs, with some link-layer main tabs remaining at the top. Subtabs always remain at the bottom.
When first configuring a station, you need to change properties on at least one of the link-layer (network) tabs, as described in Chapter 1, Getting Started. You also need to assign a unique device ID on the General, Config tab.
Note
Properties on the BACnetMSTP tabs are covered in Appendix F, Niagara MS/TP Support. Please refer to BACnetMSTP, page F-8. As explained in that appendix, initial support for BACnet MS/TP is available only JACE-4 or JACE-5 platforms, and requires the JACE to be licensed with the optional bacnetMSTP feature.
62
Chapter 6
Configuring BACnetService Properties General Properties
General Properties
General properties have no specific associated task, however, among the different sub-tabs there is valuable information. Included are status counts on BACnet object capacities, config properties with a router table, engineering properties including setup for BACnet time-synch reception, and various other items. The important General sub-tabs are Status, Config, and Engineering.
Status
Figure 6-1 shows the General, Status tab for the BACnetService, where all properties (except description) are read-only. Included are object count figures which can be useful to estimate remaining object capacities. Each property is listed below with a brief description.
objectType: Fixed as BACnetService. statusFlags: Current Niagara service state, as either {ok} if station is running or Down if station is opened offline.
Note
Starting in r2.3.5, a {fault} status is displayed if a link-layer tab is enabled but has a fault condition.
description: Niagara service description, by default Handles reads / writes to
remote BACnet devices.

bacnetObjectCount: Total number of all BACnet shadow objects currently in the
station, including both parent device objects and child shadow objects.
bacnetDeviceCount: Number of parent (BACnetDevice) objects in the station.
Includes devices associated with all link-layers and networks.

routingEnabled: Applies if multiple link-layers (for example, BACnet/IP and
BACnet/Ethernet, or perhaps BACnet/IP and BACnetMSTP) are enabled. Shows True provided a single path to BACnet devices is detected, else False if multiple paths to devices are detected, such as from a Who-Is request. If routingEnabled is False it means the station is configured as a router (more than one link-layer tab is enabled), but it is not currently operating as a router, because another remote device is performing routing between the associated networks. In this case, it is recommended that you investigate and eliminate the redundant paths between BACnet devices.
Note
63
Chapter 6 General Properties
Config
Apart from the Device ID for the JACE station (see Configuring Essential Station Properties, page 1-11), other properties on the General, Config tab are for: APDU properties, used for BACnet messaging. A router table, showing BACnet routers known to the station. Included is the ability to modify, add, or remove routers in this table.
Typically, the default APDU parameters for the BACnet service are sufficient when integrating a Niagara host in a BACnet network. Also, necessary routers are typically learned as a result of a whoIs command issued from the BACnetUtility.
Procedure 6-1 Accessing APDU properties and router table.
Step 1
In the Tree View, expand the stations services folder and right-click the BACnet service node. Select Go > Properties to open its Property Sheet. Click on tabs General, Config. (Figure 6-9).
Figure 6-2 General, Config tab of BACnet service property sheet.
Step 2
APDU properties Only the bottom two properties effect any change in the stations handling of APDUs in BACnet messaging.
APDU properties
APDU (application protocol data unit) handling properties are described as follows:
segmentationSupported: Shows that segmentation is supported by the Niagara station. This is a read-only property. apduSegmentTimeout: Specifies a timeout, in milliseconds, for retransmission of APDU segments. The default value is 2000 ms. apduTimeout: Defines the timeout, in milliseconds, for any APDU requiring
retransmission, before it is resent. APDUs are required to be retransmitted whenever a confirmed message service is used, and a message-reception acknowledgement is not received. The default value is 3000 ms.
numberOfApduRetries: Defines the maximum number of times an APDU will be resent, each following an APDU timeout, when a message-reception acknowledgement is not received. The default value is 3.
64
Chapter 6
Notes
In practice, BACnet recommends the same APDU timeout and retry parameters to be used among all BACnet devices on the same network. APDU parameters affect Niagara-generated BACnet alarms, if associated BACnetRecipient object(s) are configured to issueConfirmedNotifications. For more details, see the BACnetRecipient section on page 5-5.
Router Table
The router table is shown near the bottom of the property sheets General, Config tab (Figure 6-3). It shows all external BACnet routersmeaning all those currently known to the station. Each row in the table represents one logical router. Starting in r2.3.5, the router table shows BACnet router attributes Port ID, Status, and Port Info (in addition to DNET, Rtr Net#, and Rtr MAC Addr.).
Figure 6-3 Router table on General, Config tab.
Note
Port ID
DNET
Rtr Net#
Rtr MAC Addr
Status
Port Info
From left-to-right, the six routerTable columns are described below:

Port ID: Logical mapping to the local port on the Niagara host used to rout to this
network, where 1=BACnet/IP, 2=Ethernet, 36=Serial (MSTP1MSTP4).

DNET: Destination network number, meaning the remote BACnet network reached
through the router. The far-side network.

Rtr Net#: Local network number for the router, or the near-side network. This is a
network number on the services link-layer tab (BACnet/IP or BACnet/Ethernet).

Rtr MAC Addr: BACnet MAC (media access control) address of router device, in hexadecimal. Format varies according to link-layer for the local (Rtr Net#) network.
BACnet/IP: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. BACnet/Ethernet: devices 48-bit Ethernet MAC address nn:nn:nn:nn:nn:nn
65
Status: Currently known status of this router, either:

okCan be used to get to other networks. router unavailableA reject message was received from this router for this DNET, or the port used to reach this network is not enabled in Niagara. router busyA Router-Busy-To-Network message was received, indicating that this router is temporarily implementing congestion control. router not connectedAn I-Could-Be-Router-To-Network message was received from a BACnet half-router (provides PTP connection to another half-router, through which another DNET is reachable, but by request only). unknownA router table entry exists for the destination network, but verification has not occurred (not sent packets to the network and received messages from that router, indicating existence and operation for that DNET).
Port Info: Information about the local port, where Annex J IP is the default text
for BACnet/IP, Ethernet is the default text for BACnet/Ethernet, and MSTP14 is the default text for local MS/TP ports. Networks reachable through routers may not show port info (may have blank field), or if port info was received with unprintable characters, the read-only checkbox Binary-converted port info will be checked when selecting the router in the table.
Changing the Router Table

Typically, the router table is automatically populated after performing whoIs command(s), and does not require further maintenance. However, in some scenarios you may need to manually add, remove, or modify router entries. Procedure 6-2 provides the suggested steps for manually adding a new router.
Procedure 6-2 Manually adding a new router.
Step 1
Click in the Port ID field and enter the local port used to access the remote router, either 1 (IP/Ethernet), 2 (Ethernet), 36 for MSTP1MSTP4 (if JACE-4/5 only). Click in the DNET field and enter the known remote (far-side) network address. Click in the Rtr Net# field and enter the local network number used to reach the router. Click in the Rtr MAC Addr field and enter the known BACnet MAC address for the router device. Click the Add button, then Apply button (window bottom). The router is added to the table with an initial status of unknown, until verification is received that it is operational.
Step 5
Notes
To modify an entry, click it in the table, then edit any selected field as needed. When done, click Modify button, then the Apply button (window bottom). The routers status changes to unknown until verification is received. To remove an entry, click it in the table. Click Remove button, then Apply.
66
Chapter 6
Engineering
Apart from various debug options covered in another section (Using Debug Options, page 6-24), the General, Engineering tab holds a number of properties that affect ongoing station operation.
Figure 6-4 General, Engineering tab of BACnet service property sheet.
Message Queue Properties
Four Unrelated Properties
They are described in the following sections, following a top-to-bottom order of how they appear on the Engineering tab. Message Queue Properties Four Unrelated Properties
Message Queue Properties
Three properties specify message queue sizes, which apply to different protocol layers.
transportQueueSize: Message capacity of the transport layer queue. serverQueueSize: Message capacity of the server layer queue. clientQueueSize: Message capacity of the client layer queue.
These properties specify the number of messages each queue can hold before overflowing. As messages in queues are typically processed very quickly, the default settings for each, 16 (messages), is typically sufficient. In the case of a Who-Is command, a symptom of a queue-size problem may be that some devices (otherwise known to exist on the network) are not reported.
Note
67
Leave queue sizes at 16, unless you receive exceptions in Standard Output with messages like QueueFullException or QUEUE_OVERFLOW, with an accompanying transport or server label. In this case, increase queue sizes slightly (say to 18 or 20), until the same behavior does not generate the queue overflow. The possibility of queue-full exceptions is greatest when:
1. 2.
There are many BACnet devices, all responding simultaneously to a request (Who-Is, Who-Has) issued from the Niagara station. Most BACnet devices are the same types, meaning that they respond at the same time (far less likely if devices are different).
The recommended adjustment range for each is from 16 to 100, maximum. If many BACnet devices are the same, you may need to adjust each queue size upwards, to a number nearly equal to the number of identical devices.
Four Unrelated Properties
These unrelated properties appear grouped together: transportLockupThreshold, covResubscriptionInterval, timeSynchAcceptType, and rewriteDelay.
transportLockupThreshold: Default value is 30000 ms (30 seconds).
The need to edit this parameter is expected to be rare. You might need to adjust this upwards if a device (for whatever reason) takes longer than this period to respond to a learnDevice commandfor example, build its object list.
covResubscriptionInterval: Default value is 600 seconds, and the range is from
300 to 2147483647 (MAX_VALUE). This value is global for all objects in the station configured to useCOV, and represents the frequency at which COV resubscription requests are sent to the various devices. Typically, there is no reason for you to change this property. However, you may notice that if you disable a device for polling, objects configured to useCOV will update for some period of time, but typically not longer than this period. For related information, refer to Using COV in Shadow Objects, page 3-18.
timeSynchAcceptType: Default is None (no BACnet time synchronization
messages are accepted). Available options are: TimeSynch Only, UTCTimeSynch Only, and Both. A JACE station can be configured to accept periodic time-synchronization messages from any networked BACnet time-synchronization master device, which is in turn configured with a list of specific recipients. Acceptable messages types can be either BACnet TimeSynchronization or UTCTimeSynchronization, or both. Upon receipt of a valid message, the JACE adjusts its internal clock if necessary. Typically, you configure the JACE to accept UTC time-synch only when the sending BACnet master is in a different time zone.
rewriteDelay: Global rewrite value that applies to all input-writable shadow objects.
Default is 60 seconds, range is from 30 to 2147483647 (MAX_VALUE). This delay is observed following an input write to a shadow object and a subsequent poll determines a mismatch between the input value and output value. For more complete information, refer to Writing to BACnet Objects, page 3-25.
68
Chapter 6
Configuring BACnetService Properties Configuring BACnet Polling
Configuring BACnet Polling

The BACnet service uses an object poll scheduler to periodically poll1 shadow objects in BACnet/Ethernet and BACnet/IP devices set for polling. A continuously-repeating, consecutive scan is performed by the BACnet poll scheduler. Polling of these objects uses a single process thread in the running station.
Note
In r2.3.5, you can define a poll delay for BACnet devices that cannot keep up with Niagara polling, either at the parent (device) or child shadow object level. Due to token-passing timing issues, this option does not apply to BACnet MS/TP devices. For details, see descriptions for the BACnetDevice engineering property userData, page 3-10, and child objects engineering property userData, page 3-22. Need for this configuration is expected to be rare. Please note that it adds to the overall poll cycle time, but may be necessary under certain circumstances. If the station is enabled for BACnet MS/TP, that is a JACE licensed for bacnetMSTP, a separate (but similar) polling scheduler is used for each enabled BACnetMSTP tab or network. For related details, refer to Appendix F, Niagara MS/TP Support.
Note
The remainder of this section applies only to the main BACnet poll scheduler used for retrieving values from objects in BACnet/Ethernet and BACnet/IP devices. The property sheet for the BACnet service includes Poll and DeviceStatus tabs with properties for configuration and status of both the poll scheduler and device status monitoring/ping mechanism. The following sections apply to the BACnet poll scheduler: About the Poll Scheduler Accessing Poll Scheduler Properties
About the Poll Scheduler

The poll scheduler periodically polls BACnet objects represented by BACnet shadow objects, provided that: The parent (BACnetDevice) object is enabled for polling (status ok). The shadow object resides in a container under that BACnetDevice object. See the next section, Exceptions to Polling.
Each object is polled with a message sent to the BACnet device requesting the shadowed objects current values for properties Present_Value and Status_Flags. The property sheet for each shadow object shows a {P} by these two polled properties (presentValue and statusFlags), which are transient types. The combination of these properties is also reflected at the statusOutput for each object.
1. For all shadow objects not successfully subscribed for COV notifications.
69
Chapter 6 Configuring BACnet Polling
In r2.3.4 and later, BACnet shadow objects with a priorityArray input (types AO, BO, MSO, AVP, BVP, MSVP), also have the objects Priority_Array values polled. Remaining properties of a shadow object are mostly on_demand_transient types and foreign_persistent types, are indicated by an {F} on the property sheet. You must issue a fetch command (or an upload command) for the shadow object to refresh these values. Refer to the Common Commands section on page 3-17.
Exceptions to Polling
A BACnet shadow object is not polled under any of the following circumstances: It does not have a priorityArray input, and has successfully subscribed for COV notifications with the remote device. In this case, properties Present_Value and Status_Flags are updated with received COV notifications. (See the next Note.) If the object resides in a PollOnDemand container, and its linked Gx object is not currently being viewed (or in a view cache). See Polling On Demand. If the objects parent (BACnetDevice) object is disabled (outOfService). Typically, this means it has been given a disablePolling command. If polling is disabled (On the Poll, Config tab, pollDisabled is set to True). No BACnet shadow objects are polled in this case.
Polling On Demand
The BACnet service supports use of the PollOnDemand container under any BACnetDevice container. A BACnet shadow object in a PollOnDemand container polls only while a linked Gx object is viewed in a GxPage graphic. Such dynamic polling is automatic, and applies whether the GxPage is being viewed in the JDE or in a Web browser connection. This feature allows the services Poll Scheduler to keep a smaller list of poll always objects. The resulting poll cycle time is reduced for better control response (and also quicker updates when monitoring).
Note
If a BACnetDevice is configured to useCOV (and the device supports SubscribeCOV), child objects configured for useCOV that are placed in PollOnDemand containers operate in the follow manner:
When first being viewed, child objects are polled on the first cycle, and issue a subscription request to the device (COV server). If an object successfully subscribes for COV, it is removed from the polling list, and future updates are from COV notifications while it is being viewed (or in the view cache). If the object cannot successfully subscribe after 3 successive attempts, it remains in the poll list while it is being viewed (or in the view cache). When viewing ends (or the view cache is overwritten) child objects that are subscribed for COV request to unsubscribe from the device (COV server), and become unsubscribed.
For related information, refer to Using COV in Shadow Objects, page 3-18.
610
Chapter 6
PollOnDemand Containers
Icons for the two types of containers appear slightly different in JDE Tree View. The PollOnDemand container shows a diagonal line through it: The PollAlways container shows no diagonal line:
Figure 6-5 PollOnDemand containers for BACnet shadow objects linked to Gx objects.
BACnetDevice object operates like a PollAlways container for any directly contained shadow objects. You can create other PollOnDemand and/or PollAlways containers under the BACnetDevice and move (or cut and paste) shadow objects to them.
Caution
BACnet shadow objects in PollOnDemand containers should only be linked to Gx objects, and not to other control objects (or log-type objects). If the linked Gx objects are in a GxPage container, this provides dynamic system monitoring for a user, including right-click command access. However, when not being polled, the shadow objects output(s) go to an outOfService status. Furthermore, following a station restart, outputs of unpolled objects initialize as 0 if analog, or inactive if binary.
Notes
PollOnDemand behavior is controlled by a child objects immediate parent containera PollOnDemand container somewhere else in the parentage of an object is inconsequential. Linkage to any of the single-input type Gx objects is supported when using shadow objects in a PollOnDemand container. This includes types GxText, GxBoolean, GxDamper, GxFan, GxFloat, and GxInteger. Linkages to multi-input Gx types, such as GxSpectrum and GxTimePlot, are not supported. After viewing linked Gx objects in JDE, polling continues for the associated shadow objects in PollOnDemand containers until that view is removed from the view cache. Typically, this means 4 view changes before polling stops.
Calculating the BACnet Poll Cycle Time
Value/status updates from object polling can be just a few seconds apart or may be a minute or more. The main factors are the number of shadow objects being polled, and if the BACnet ReadPropertyMultiple service is supported by devices. If supported, any learned device will automatically have its Config property readPropertyMultiple set to Truethis results in approximately 60% faster poll of objects in that device (than if just the readProperty service was used). Table 6-1 shows some polling time measurements taken with a station on a BACnet/Ethernet network. In this example, all BACnet shadow objects are in containers to poll always, and all BACnet devices support the ReadPropertyMultiple service.
611
Note
In practice, actual objects-per-second rates are dependent on a number of variables, including the existing network topology and the capabilities of the BACnet devices.
Table 6-1 Example BACnet poll cycle times for BACnet/Ethernet network.
Objects / Sec
32 objects / sec
Poll Time for 125 objects

4 seconds (4000 ms)
Poll Time for 250 objects

8 seconds (8000 ms)
COV Updates
Client-side support for the BACnet SubscribeCOV service means quicker data updates (than polling) for those shadow objects successfully subscribed for COV. Binary and multistate-type shadow objects update the statusOutput (Present_Value, Status_Flags) immediately upon any change. Analog-type shadow objects update the statusOutput upon each Present_Value change equal or greater to the objects COV_Increment value, or upon any change to Status_Flags. For related information, refer to Using COV in Shadow Objects, page 3-18.
Accessing Poll Scheduler Properties

Poll scheduler properties are under the Poll tab of the BACnet service. Properties are grouped under three sub-tabs: Status, Config, and Engineering.
Procedure 6-3 Accessing poll scheduler properties.
Step 1
In the Tree View, expand the stations services folder and right-click the BACnet service node. Choose Go > Properties to open its property sheet. For status properties, click on tabs Poll, Status. A collection of 10 real-time status properties related to polling is shown (Figure 6-6).
Figure 6-6 Poll, Status tab of BACnet service.
Step 2
Step 3
For config properties, click on tabs Poll, Config. This shows the 3 configuration properties related to polling (Figure 6-7).
612
Chapter 6
Status
Poll status properties show accumulated poll statistics since the last station restart, or since a resetStatistics command (see Tip, below). Status properties include:
polledDeviceCount: Total number of BACnet/Ethernet and BACnet/IP devices shadowed in the station. Note that directly-connected BACnet MS/TP devices (if any) are not included. polledObjectCount: Total number of child BACnet shadow objects in the devices
above, minus any inactive ones in PollOnDemand containers. This number varies if PollOnDemand containers are used and GxPages are being viewed and/or closed. polledObjectCount does not vary as BACnetDevices are enabled/disabled for polling (all devices can be disabled without affecting the objectCount).
Note
averagePollExecuteTime: Reflects the average time, in milliseconds, for the object
poll cycle. Equals the totalExecuteTime / executionCycles.

totalPollExecuteTime: Reflects the total time, in milliseconds, that object polling
has operated.
pollExecutionCycles: Total number of poll scheduler cycles. pollOverruns: Number of times the poll cycle took longer than the configured
pollCycleTime (as defined on the Poll, Config tab), within a 10% margin. Note this does not indicate a problem (all objects are polled), merely that cycleTime is set too short. If overruns continue, the pollInterNodeDelay value will likely be at or near 0.
pollStartTime: Shows the date and timestamp for when the BACnet service was last started (station restarted). averagePollIntercycleDelay: Average time, in milliseconds, between successive
starts of the poll cycle since statistics were accumulated. Provides a possible starting point for a target poll cycle time.
pollLateStarts: Another polling statistic. The number of poll cycles that started later than anticipated (going by the pollCycleTime, configured on the Poll, Config tab). pollInterNodeDelay: Shows the idle time (if any), in milliseconds, between polls of individual objects during the last poll cycle. This value ranges from 0 (no delay, poll running as fast as possible) to some positive value. A large value indicates that the pollCycleTime could be adjusted smaller (providing polledObjectCount is static) to provide faster data response.
Tip
In general, the most useful status properties are pollOverruns, polledObjectCount, and averagePollExecuteTime, particularly when setting a median cycleTime. To reset the poll status properties, with the BACnet service property sheet open, select Commands > resetStatistics from the JDE menu bar.
613
Config
Figure 6-7
Poll, Config tab of BACnet service.
Poll config properties are described as follows:

pollCycleTime: Determines the target time, in milliseconds, to complete a poll cycle. The default value is 5000 ms. Typical cycle times range from 5000 ms upwards (although you can set it lower, in general this is not recommended). See the Calculating the BACnet Poll Cycle Time section on page 6-11 for some examples.
If set lower than the actual poll cycle time, the Status property pollOverruns will steadily increment and the pollInterNodeDelay will approach zero (0). This does not mean a problem, however, merely that the poll cannot run any faster.
pollDisplayDots: For debug mode for the BACnet service. The default is False. If set to True, the characters1 BAC IP/Eth Poll appear in the stations Standard
Output window upon each completed execution of the poll cycle.

pollDisabled: For toggling object polling on and off. The default is False (polling
enabled). While set to True, all object polling is stopped.
Engineering
The Poll tab has an Engineering sub-tab with a single property:

pollDebug: For debug usage. Default is False. While set to True, each polled device
appears as a line in the stations Standard Output window, using the format:
BPoll: polling device <deviceName> {<object type>:<instance number>}
For example:
BPoll: polling device BACdev102 {device:102} @85 00:07:E9:B1:32:77 BPoll: polling device BacSup100c {device:100} @85 00:01:03:E9:F9:56 BPoll: polling device station_x {device:99} @85 00:01:F0:00:02:07 (and so on)
Note
Disable polling debug (pollDebug=False) unless you are investigating a particular poll-related problem. It adds system overhead and decreases overall throughput.
1. Prior to r2.3.5, only a B character is sent to Standard Output upon each poll cycle.
614
Chapter 6
Configuring BACnetService Properties Configuring Device Status/Ping
Configuring Device Status/Ping

The device status monitor (ping mechanism) operates independently from the poll scheduler. Periodically, a ping message is sent to each BACnet device represented by a BACnetDevice object, requesting the device objects System_Status value. The devices response updates the BACnetDevices systemStatus property; this is typically operational (the default). For any response (except non-operational) the statusFlags property for the BACnetDevice object remains at ok.
If a BACnet device does not respond to the device status ping, or responds with non-operational: Its associated BACnetDevice object updates statusFlags to down, Its object shape, plus the shape and outputs of all child objects turns yellow (down), and, A Niagara Device down alarm is generated (Figure 6-8). All on_demand_transient properties for the device object and child objects show down. The device status monitor continues to ping the device. If the status monitor later receives a response from a down BACnet device: Its associated BACnetDevice object updates statusFlags to ok, Object shapes (and child object outputs) are restored from down, and, A Niagara Device up alarm is generated. All on_demand_transient properties for the device object are refreshed.
Niagara alarm record for a BACnet service alarm.
Figure 6-8
Devices object name in the station appears at the end of eventSwid.
Device up or Device down.
BACnetService shown in the proxySwid.
Note
The device status monitor does not ping any device that is currently shown as outOfService in the station, that is, disabled from polling. These devices appear as cyan in the JDE WorkSpace.
615
Chapter 6 Configuring Device Status/Ping
Accessing Device Status Monitor Properties

Under the DeviceStatus tab of the BACnet service are three sub-tabs: Status, Config, and Alarm Setup. Each tab holds properties affecting device status.
Procedure 6-4 Accessing device status monitor scheduler properties.
Step 1
In the Tree View, expand the stations services folder and right-click the BACnet service node. Select Go > Properties to open its Property Sheet. For status properties, click on tabs Device Status, Status. Displayed are 5 real-time status properties for device status (Figure 6-9).
Figure 6-9 Device Status, Status tab for BACnet service property sheet.
Step 2
The deviceStatusObjectCount value shows the total number of BACnet devices. This includes BACnetDevice objects that are currently outOfService (disabled for polling), which are not being pinged for device status.
Step 3
For config properties, click on tabs Device Status, Config. Displayed are 3 configuration properties related to device status (Figure 6-10). For alarm setup, click on tabs Device Status, Alarm Setup. The single property notificationClass is available (Figure 6-11).
Step 4
Status
Device Status status properties (Figure 6-9) show statistics that have accumulated since the last station restart, and are described as follows:
deviceStatusAverageExecuteTime: Reflects average time, in milliseconds, for the
device status cycle (deviceStatusTotalExecuteTime / deviceStatusExecutionCycles).

deviceStatusTotalExecuteTime: Reflects the total time, in milliseconds, for device
status monitoring.
deviceStatusExecutionCycles: Total number of device status monitoring cycles. deviceStatusObjectCount: Number of BACnet devices available for status
monitoring. Includes all BACnetDevice objects, regardless of associated link-layer.

deviceStatusStartTime: Date and timestamp for when the BACnet service was last
started (station restart time).
616
Chapter 6
Configuring BACnetService Properties Configuring Device Status/Ping
Config
Figure 6-10
DeviceStatus, Config tab for BACnet service property sheet.
Device Status config properties are described as follows:

deviceStatusPingDelay: Determines the wait time between the ping of one
device and the ping of the next device. Typical values are from 500 to 5000 ms. The complete cycle time of the device monitor approximately equals: (number of devices) x deviceStatusPingDelay.
Note
deviceStatusDisplayDots: For debug use with the BACnet service. The default is False. If set to True, a B character appears in the Standard Output window with each execution cycle of the device monitor. deviceStatusDisabled: For toggling the device status monitor on and off. The
default is False (device status enabled). While set to True, the device status monitor is disabled. However, normal polling of objects, if enabled, continues.
Alarm Setup
Figure 6-11
DeviceStatus, Alarm Setup tab for BACnet service property sheet.
A single property is on the DeviceStatus, Alarm Setup tab:

notificationClass: Determines the assigned notification class for BACnet device
alarms. These alarms may be received whenever the device status monitor is enabled. By default, notification class 0 is used. Any value from 0 to 8388607 is valid, providing a NotificationClass object with that same number exists in the stations NotificationService container.
617
Chapter 6 Configuring BACnet/IP Properties
Configuring BACnet/IP Properties

The BACnetIP tab has two sub-tabs: Config and Engineering. Properties apply only if the IP link layer is enabled (first Config property: ipEnable = True). For additional background information on BACnet/IP configuration, including diagrams, refer to Appendix E, Internetworks and BACnet/IP.
Note
Config
Properties on this tab enable BACnet/IP link-layer support, define various operating parameters, and specify the BBMD-related role of the Niagara station (Figure 6-12).
Figure 6-12 BACnet/IP, Config tab for BACnetService.
Typically, key properties on the BACnet/IP Config tab are changed from defaults only when the BACnet service is first configured. Procedures are given in Chapter 1, Getting Started. Refer to the BACnet/IP Considerations section on page 1-11. Config properties are listed here with a brief explanation, default value, and range (if applicable).
ipEnable: Enables or disables all BACnet IP link layer communications. ipNetworkNumber: The BACnet network number associated with this IP link layer.
The default value is 1. Valid range is from 1 to 65534. This number must be unique from any other BACnet network number across an internetwork. If an existing external router resides on this network, use the same network number in use by that router for this network.
subnetMaskString: Defines the working subnet range for the JACE host, using format xxx.xxx.xxx.xxx, where xxx is decimal.
618
Chapter 6
Configuring BACnetService Properties Configuring BACnet/IP Properties
udpPortString: Defines the UDP port monitored for BACnet/IP messaging, both
directed and broadcast. Can be entered using either decimal or hexadecimal format (if hex, requires a 0x prefix, for example 0xBAC0). The default value, 0xBAC0, (47808 decimal) is the defacto BACnet/IP standard. Do not change (unless an existing BACnet/IP network is already configured otherwise). Niagara BACnet 2.203.221 and earlier would always respond (and send to) remote devices on port 0xBAC0, regardless of the UDP port monitored. If you need backwards compatibility with this behavior, you can specify a UDP port for Niagara to always send to, by editing a specific line in the bacnet.properties file, found in the niagara\<release>\nre\lib folder. See Adjunct Configuration: bacnet.properties File, page 6-28.
Note
bacnetIPDeviceType: The BBMD-related role of the Niagara station, either as a:
bbmdBBMD host. foreignDeviceForeign device registered with a BBMD on another IP subnet. noneNeither BBMD or foreign device (default). This is the proper choice if the Niagara host exists on an IP subnet that already has an operating BBMD, or if the installation is not using multiple IP subnets.
remoteBBMDAddress: An operating BBMD for this BACnet network that exists on another (remote) IP subnet. Required if device type is BBMD or a foreign device.
Note
Entry format requires all hexadecimal with colons: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. For example, if the BBMD has an IP address of 192.168.1.21 and is using the default UDP port (BAC0), its MAC Address is: C0:A8:01:15:BA:C0 You can use the Windows Calculator to convert the IP octets from decimal.
registrationLifetime: (Applies only if the station is configured as a foreign device).
Time period, in seconds, in which the Niagara station will register as a foreign device with the remote BBMD. The station will automatically re-register within this period. The default value is 900 seconds, the valid range is from 300 to 65,535 seconds.
619
Chapter 6 Configuring BACnet/IP Properties
Engineering
BACnet/IP Engineering properties apply only if the station is configured to operate as a BBMD (bacnetIPDeviceType is bbmd). This page is divided into two areas: Broadcast Distribution Table (BDT) Foreign Device Table (FDT)
Broadcast Distribution Table (BDT)
This table lists remote BBMDs, and is typically populated as a result of entering a valid IP address in the remoteBBMDAddress property on the Config tab.
Figure 6-13 broadcastDistributionTable, BACnet/IP Engineering tab.
If needed, you can manually add, remove, or modify entries in the BDT. Note that the Distribution Mask property determines if a one-hop or two-hop distribution. To add a new entry, click in the B/IP Address field and enter the remote BBMDs IP address and UDP port in hexadecimal (see Note below), and then click in the Distribution Mask field and enter either FF:FF:FF:FF (for two-hop) or the subnet mask in use for one-hop method. Click the Add button, then Apply button (window bottom). To modify an entry, click it in the table, then edit either property as needed. When done, click Modify button, then the Apply button (window bottom). To remove an entry, click it in the table. Click Remove button, then Apply.
Note
B/IP entries require all hexadecimal format with colons:

xx:xx:xx:xx:xx:xx
For example, to add a BBMD with an IP address of 192.168.1.21 using UDP port BAC0 and a two-hop distribution, the properties would be: B/IP Address: C0:A8:01:15:BA:C0 Distribution Mask: FF:FF:FF:FF You can use the Windows Calculator to convert the IP octets from decimal.
620
Chapter 6
Configuring BACnetService Properties Configuring BACnet/IP Properties
Foreign Device Table (FDT)
This table is populated as BACnet devices (on other subnets) register with the Niagara station/BBMD as a foreign device. Each entry lists the B/IP address (in hex) of the remote device, the registration period (Time To Live in seconds), and the remaining time before the station will purge the entry (providing the device does not reregister).
Figure 6-14 foreignDeviceTable, BACnet/IP Engineering tab.
If needed, you can manually add, remove, or modify entries in the FDT table. You may need to add a device if its incapable of registering itself as a foreign device (likely done through some local configuration at that device). To add a new entry, click in the B/IP Address field and enter the devices address (IP and UDP in hex, see prior Note), and then click in the Time To Live field and enter a registration period, in seconds. See Time To Live, below. Click the Add button, then Apply button (window bottom). To modify an entry, click it in the table, then edit either property as needed. When done, click Modify button, then the Apply button (window bottom). To remove an entry, click it in the table. Click Remove button, then Apply.
Time To Live: The registration period for the device to remain in the stations
BBMD foreign device table, during which period it must reregister to keep from being purged from the table. Devices that externally register typically place a numeric value in this property, such as 1200 (seconds). The default value is infinite (*), meaning that device will never need to reregister with the station, and so will never be automatically purged. In the case of a permanently-installed B/IP device that is incapable of registering as a foreign device itself, * may be the best choice. Impending purge times are displayed in the right-hand Purge Time column of the table. Each device with a numeric Time To Live must reregister before this time to keep from being removed from the FDT. When the device reregisters, the Purge Time value is updated to reflect the new time. Devices with infinite Time To Live (*) have no effective Purge Time.
621
Chapter 6 Configuring BACnet/Ethernet Properties
Configuring BACnet/Ethernet Properties

BACnet/Ethernet has only a Config sub-tab with just two properties (Figure 6-15).
Figure 6-15 BACnet/Ethernet tab has only a Config tab with two properties.
ethernetEnable: Enables or disables all BACnet over Ethernet link layer
communications.
ethernetNetworkNumber: The BACnet network number associated with this Ethernet link layer. The default value is 2. Valid range is from 1 to 65534.
This number must be unique from any other BACnet network number across an internetwork. If an existing external router resides on this network, use the same network number in use by that router for this network.
Commands to the BACnet Service

The BACnet service has several commands, available from the JDE menu bar when the services property sheet or BACnetUtility view is displayed (Figure 6-16).
Figure 6-16 Commands to the BACnet service.
622
Chapter 6
Configuring BACnetService Properties Commands to the BACnet Service
BACnet service commands are described briefly below:

dump resetStatistics readBACnetPropertiesFile dumpBACnetPropertiesFile dumpIPTable printLine
dump: Available for every Niagara objectsends debug-level information for that object to the stations Standard Output window. resetStatistics: Resets BACnet service accumulated poll status properties such as
counts (execution cycles, overruns, late starts, etc.) delay times, and elapsed times. Affects both the main Poll scheduler (for BACnet/Ethernet and BACnet/IP) and any enabled BACnetMSTP tabs. See Accessing Poll Scheduler Properties, page 6-12.
readBACnetPropertiesFile: Makes effective any parameters present in the Niagara hosts bacnet.properties file (file must exist in the nre\lib folder). See Adjunct Configuration: bacnet.properties File, page 6-28. dumpBACnetPropertiesFile: Debug command to send the currently effective bacnet.properties settings to the stations Standard Output. For development use. dumpIPTable: A BACnet/IP debug command that lists (to Standard Output) a table of BACnet MAC addresses of known BACnet hosts. An example is shown below.
MAC Address Table: inet:JACENX3/192.168.1.98 mac:C0:A8:01:62:BA:C0 inet:JACENP/192.168.1.102 mac:C0:A8:01:66:BA:C0 Inet Address Table: ipHash:-1062731265 inet:192.168.1.255/192.168.1.255
printLine: Debug usage. Produces a popup dialog (Figure 6-17) in which you can type a line to appear in the stations Standard Output window, for annotation needs.
Figure 6-17 Popup dialog box from printLine command (with default text shown).
623
Chapter 6 Using Debug Options
Using Debug Options

The BACnetService includes ten separate debug options, each of which can produce debug-level messages in the stations Standard Output window. By default, each debug option is not enabled (set to False). A lot of BACnet-related information is always sent to Standard Output by the BACnet service (regardless of debug option settings). It is recommended that you read the Standard BACnet Debug Output section first. Typically, you only enable those debug options needed, and only for a short period, while working to understand a BACnet-related issue. The reason for this is that debug operations consume station resources. These resources are normally used to improve performance, such as improved polling times.
Notes
Standard BACnet Debug Output

Before enabling BACnet debug options, it is best to understand what gets sent to the stations Standard Output without any debug options enabled.
Figure 6-18 Standard BACnet debug messages.
The following messages are always sent to Standard Output by the BACnet service: All results from any BACnetUtility command (whoIs, whoHas, learnNetwork, learnDevice, etc.). This is the same text output seen in the utilitys window. All WARNING, TIMEOUT, and ERROR messages related to the operation of the BACnet service. WARNING messages are typically seen as a result of a fetch or upload command for a shadow object, where some requested properties are not known (used) in BACnet object(s). For example, deviceType for an AI:
WARNING: BACnet Read Property Multiple Error: deviceType [/NewJ5b/FirstFloor/BnJACE/Room102]
624
Chapter 6
Configuring BACnetService Properties Using Debug Options
TIMEOUT messages are typically seen for a down BACnet device, such as produced by the ongoing device monitor ping routine. For example:
TIMEOUT: 227 Client 0 00:01:F0:00:02:07 Server 0 00:50:DA:04:E8:6B Transaction Timed out! invokeId 228
ERROR messages occur when the stations BACnet service cannot complete an operation. For example, if you issue a getAlarmSummary for a device that doesnt support this service, a message appears (in part):
In doGetAlarmSummary device.... Transaction Timed out! invokeId 96 TIMEOUT: 96 Client 0 00:01:F0:00:02:07 Server 16 03 ERROR: GetAlarmSummary failed [/NewJ5b/services/BACnetService] tridiumx.bacnet.BACnetException E_BACNET_TIMED_OUT_WAITING_FOR_RESPONSE at tridiumx.bacnet.services.transport.TransactionTag.waitForConfirmation() at tridiumx.bacnet.services.BACnetTransport.sendConfirmedRequest() (plus others similar in nature...)
Various ongoing informational messages, for example:

BACnet Queue event: update unacked alarm table
Debug Option Selections

Debug options are enabled/disabled on the property sheet for the BACnet service, on the General, Engineering tab (Figure 6-19). Debug options can be enabled in any combination. However, be aware that the lower eight (transport, network, ipLink, ethernetLink, mstpnLink n=14) each produce extremely large amounts of output. Output from any debug option is interleaved with Standard BACnet Debug Output.
Figure 6-19 BACnet service Debug Options are on the General, Engineering tab.
Note
625
Chapter 6 Using Debug Options
The ten debug selections are described as follows: To decipher this output data, intimate knowledge of the BACnet communications protocol is often needed. Output information is typically useful only to developers.
clientDebugOn: Shows client requests from the station to remote BACnet devices. However, note that client requests related to polling are not included. serverDebugOn: Shows server responses from the station to client requests from
Note
remote BACnet devices.

transportDebugOn: Shows low-level (transport layer) message details on PDUs to
and from remote BACnet devices, including ConfirmedRequests, ComplexAcks, etc. This debug option might be useful in a timeout scenario where the target BACnet device is known to be up.
networkDebugOn: Shows low-level (network layer) message details on PDUs to
and from remote BACnet devices, including address (subnet and device) information. This debug option might be useful in a scenario where BACnet devices are not on the local network (are on the far side of a router).
ipLinkDebugOn: Shows low-level (link layer) message details on the complete PDUs sent and received, in both hexadecimal and ASCII formats. Includes IP address and UDP port information (Example 6-1).
Example 6-1 Example IP Link Debug output (snippet).
lookupInetAddr: C0 A8 01 62 BA C0 <-> ...b.. IP:192.168.1.98 port: 47808 length 30 Packet Sent on port 47808: 81 0A 00 1E 01 0C 00 55 <-> .......U 06 00 01 F0 00 02 07 02 <-> ........ 73 7F 0E 0C 00 00 00 01 <-> s....... 1E 09 55 09 6F 1F <-> ..U.o. Packet Rcvd on port 47808 addr:192.168.1.98, srcPort:47808 81 0A 00 2A 01 20 00 55 <-> ...*. .U 06 00 01 F0 00 02 07 FF <-> ........ 30 7F 0E 0C 00 00 00 01 <-> 0....... 1E 29 55 4E 44 42 80 00 <-> .)UNDB.. 02 4F 29 6F 4E 82 04 00 <-> .O)oN... 4F 1F <-> O. lookupInetAddr: C0 A8 01 62 BA C0 <-> ...b..
Note
By default, IP link-layer debug does not contain the host name for BACnet devices, only their IP address. This provides the most efficient output rate. However, if you require host name data, you can set this in the JACEs bacnet.properties file (at great expense in speed). See Adjunct Configuration: bacnet.properties File, page 6-28.
626
Chapter 6
Configuring BACnetService Properties Using Debug Options
ethernetLinkDebugOn: Shows low-level (link layer) message details on the
complete PDUs sent and received, in both hexadecimal and ASCII formats. See Example 6-2.
Example 6-2 Example Ethernet Link Debug output (snippet).
Packet Sent: 00 01 03 E9 F9 56 F0 00 02 07 00 13 03 01 00 30 2A 0C 00 00 63 19 70 3E 3F Packet Sent: 00 01 03 E9 F9 56 F0 00 02 07 00 20 03 01 08 00 0B 01 29 0E 0C 01 40 00 29 55 4E 91 00 4F 4E 82 04 00 4F 1F Packet Received: 00 01 F0 00 02 07 03 E9 F9 56 00 19 03 01 24 00 0B 01 02 05 2B 0E 0C 01 2A 1E 09 55 09 6F Packet Sent: 00 07 E9 B1 32 77
00 82 0C 91
01 82 02 00
<-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <->
.....V.. ........ ...0*... ..c.p>.. ? .....V.. ..... .. ......g0 )...@.+. )UN..O)o N...O. ........ ...V.... ..$...g. ..+...@. *..U.o. ....2w..
00 82 67 2B 29
01 82 30 1E 6F
00 82 67 40 1F
01 82 FF 00
00 01
mstpnLinkDebugOn: Where n = 1 to 4 according to the corresponding MS/TP network. Shows low-level (link layer) message details on MS/TP frames sent and received, in both hexadecimal and ASCII formats. See Example 6-3.
Example 6-3 Example MSTP Link Debug output (snippet).
Frame 01 00 00 04 83 B8 04 00 Frame 01 04 00 00 1F Frame 01 0C E9 F9 00 80 6F 1F Frame 01 20 E9 F9 02 00
rcvd from 103 DER false 30 BB 0E 0C 00 00 <-> 1E 29 55 4E 44 40 <-> 50 4F 29 6F 4E 82 <-> 4F 1F <-> sent to 103 DER true 02 03 BC 0E 0C 00 <-> 05 1E 09 55 09 6F <-> <-> sent to 103 DER true 00 55 06 00 01 03 <-> 56 02 05 16 0E 0C <-> 00 68 1E 09 55 09 <-> <-> rcvd from 103 DER false 00 55 06 00 01 03 <-> 56 FF 30 15 0C 0C <-> 00 67 19 70 3E 91 <->
..0..... ...)UND@ ..PO)oN. ..O. ........ .....U.o . ...U.... ..V..... ...h..U. o. . .U.... ..V.0... ...g.p>.
Refer to Appendix F, Niagara MS/TP Support, for more information about BACnet MS/TP in Niagara.
627
Chapter 6 Adjunct Configuration: bacnet.properties File
Adjunct Configuration: bacnet.properties File

Starting in Niagara Release 2.3 (r2.3.3), several BACnet-related setup properties became available only by editing a text file named bacnet.properties, which resides on the Niagara host in its niagara\<release>\nre\lib folder. This was done to prevent a database schema change for various Niagara 2.3 builds, which would otherwise be required if new properties were modifiable on the BACnet services property sheet. When r2.3.4 was released, changes were numerous enough for a schema change, and these properties (or their equivalents) were moved to the BACnet services property sheet. At the time of the r2.3.5 update to this document, very few BACnet setup properties still require editing of the bacnet.properties file. Example 6-4 shows the default release 2.3.5 bacnet.properties file, containing four properties with explanations. For a related details on bIPAlwaysSentToPort, see the BACnet/IP config property udpPortString:, page 6-19.
Example 6-4 Contents of bacnet.properties file, showing effective default values.
########################################################### # # bacnet.properties # # BACnet properties file # This file contains properties to configure the BACnet # service, that are not included in the property sheets # of the various node objects. # ########################################################### # Niagara versions 2.203.221 and earlier would always respond on port 47808 # (0xBAC0), and always to the remote device's port 47808 as well, regardless of # what UDP port was chosen to listen on. This was fixed in 2.203.222, and in # 2.3 and later releases. In order to provide backward compatibility with # products that may depend upon this earlier behavior, this flag can be set to # force Niagara to always send to a specific port. # Default value: -1 (no always send port) # Typical value: 47808, or 0xBAC0 bIPAlwaysSendToPort=-1 # The 2.5 release of Niagara does not print the host name in # information, because it is a very time-consuming operation # host name from the IP address. If you wish to display the # debug printouts, set this flag to true. # Remember that this significantly slows down the processing # Default value: false bIPDisplayHostName=false IP debug to look up the host name in IP of IP packets.
# By default, any station running the BACnet service uses values found in its # hosts license file (nre\lib\license.properties) to expose as description # and location properties in the BACnet Device object (server object) that # represents the station. The lines used in the license file are as follows: # # customerName=<text string> (used as description) # customerSite=<text string> (used as location) # # If desired, you can override either (or both) of these exposed property text # strings with other text strings by uncommenting (remove leading #) in the # lines below and entering the desired text string immediately after the =: # #description= #location=
628
Chapter 6
Configuring BACnetService Properties Adjunct Configuration: bacnet.properties File
Notes
As with other Niagara properties files, lines with a leading # character denote comments used to describe the parameter, as used in the example above. The BACnet service also has two related commands: readBACnetPropertiesFileMakes effective any changes made in the hosts bacnet.properties file since the station last started, or since this command was last issued. dumpBACnetPropertiesSend the currently effective bacnet.properties settings to the stations Standard Output window.
Editing bacnet.properties
You can follow Procedure 6-5 to edit and add a bacnet.properties file in a JACE. This procedure makes use of the Host > Edit File feature in the Admin Tool, and works with any JACE platform.
Procedure 6-5 Editing the bacnet.properties file.
Step 1 Step 2
Copy the text lines shown in Example 6-4 (or whatever source) to a new text file. Make the desired changes in the parameter values, and copy the entire contents of the file to the Windows clipboard. Save the file locally as bacnet.properties for future reference, using the path:
D:\niagara\<release>\nre\lib\bacnet.properties
Step 3
Step 4
Open the Admin Tool and connect to the target Niagara host (from the menu bar): Admin Tool > File > Open. Type in the necessary host address, and then host user name and password. With the host visible in the Admin Tool, select from the menu bar: Admin Tool > Host > Edit File > BACnet Properties. This opens an edit window for bacnet.properties. If the JACE already has a bacnet.properties file, you will see its contents in the edit window. You can edit as desired from what you already copied from Example 6-4, or add additional updated information if needed. In the edit window, select Edit > Paste to copy the clipboard contents from Step 2. Click File > Save to create the bacnet.properties file on the remote host, and then close the edit window. The file is created in the nre/lib folder, as needed, on that host. If necessary, you can make future edits to the remote hosts bacnet.properties by simply opening the host in the Admin Tool, reselecting the BACnet Properties file, and then make (and save) any changes.
Step 5
Note
Step 6 Step 7
629
Chapter 6 Adjunct Configuration: bacnet.properties File
Current properties
Apart from the bIPAlwaysSentToPort property already explained, at the time of this manual these other entries are valid in bacnet.properties:
bIPDisplayHostName=true (or false) Applies to BACnet/IP debug usage only. The effective default (no entry) is false. This allows the most efficient BACnet/IP debug to Standard Output, but with only host IP addressesand not host names.
If you require host names as well as IP addresses in debug output (ipLinkDebugOn), but at the expense of much slower response, set this value to true. See Debug Option Selections, page 6-25, for more information on BACnet debug.
description=<string value>
Overrides whatever customerName value is in the hosts license file for usage in the stations Device object property Description. Overrides whatever customerSite value is in the hosts license file for usage in the stations Device object property Location.
location=<string value>
630
APPENDIX
Troubleshooting
This appendix explains some troubleshooting techniques that apply to the BACnet service. The following main sections are included: Go/No-Go Communications Checklist Objects Not Polling Checklist Object Color and Status Debug and Standard Output
Go/No-Go Communications Checklist

Use the following checklist when troubleshooting BACnet communications from a JACE station. Only new installations typically require all of these checks.
Table A-1 Go/No-Go Checklist for BACnet service communications.
Check
Is the Niagara host licensed for the BACnet service?
Method
Check that the JACE is licensed. With the JACE open and selected in the Admin Tool, select the Installation tab, then View License. The features line must include bacnet. If a JACE-4/5 requiring MS/TP support, the features line must include an additional bacnetMSTP entry. For further MS/TP details, see Prepare the JACE Host, page F-3.
Is the BACnet service configured for the correct link layer type? If BACnet/Ethernet is used, is the host (PC) properly configured?
Supported BACnet link-layer types include Ethernet and/or IP, and if a JACE-4/5, also MS/TP. For basic BACnet service properties, see Configuring Essential Station Properties, page 1-11. If MS/TP, also see Configure Essential MS/TP Link-Layer Properties, page F-7. If BACnet/Ethernet is used in an engineering PC workstation, see BACnet Over Ethernet Considerations, page C-2.
Is the Niagara host assigned to a unique address on the BACnet network?
The BACnet address for any device is determined by the Device ID of its contained Device object. For a Niagara station, this appears as a Config property of its BACnet service. See Configuring Essential Station Properties on page 1-11.
A1
Appendix A Objects Not Polling Checklist
Troubleshooting
Objects Not Polling Checklist

Use the following checklist when troubleshooting BACnet shadow objects that do not appear to be polling, even though BACnet communications appear working.
Table A-2 BACnet Integration object Polling Checklist.
Check
Is BACnet (client) polling enabled?
Method
With the station opened in JDE, expand the services folder and right-click on the BACnet service. Select Go > Properties. Then click tabs Poll, Config. The property disabled must be set to False. With the station opened in JDE, double-click on the parent container for the BACnetDevice objecttypically, this is the BACnetTemp container. This displays the device object in the Workspace. A device enabled for polling appears gray; a disabled device appears cyan. Right-click on the disabled device and select enablePolling. In the Tree View, see if the object is in a PollOnDemand container: If so, it will appear with cyan output color whenever its linked Gx object is not being viewed in JDE or from a Web browser.
Is polling enabled for the parent (BACnetDevice) object?
Is the object in a PollOnDemand container?
Is the poll cycle taking longer than anticipated?
Right-click on a static shadow object and select pollRenew. This should cause an immediate update of the objects statusOutput (presentValue and statusFlags), regardless of how many objects are being polled. See Configuring BACnet Polling on page 6-9
Object Color and Status

Color of objects in the JDE is useful in determining object status. This is true with BACnet shadow objects, which have five possible colors:

Gray (status ok) Red (status inAlarm) Orange/Dark Yellow (status fault) Cyan/Light Blue (status outOfService) Yellow (status down)
In addition, color of outputs on BACnet shadow objects can vary from black on white background to other colors. In all but one case, an objects output color reflects its object color (meaning that its output status is the same as its object status). See the Note on page A-5 for the sole exception.
Gray
Gray object color means status ok (Figure A-1). This is the color seen when a BACnet shadow object is created from the BACnetUtility, after BACnet objects have been learned. If the output is linked to another object in the station, its output value seen in Monitor Mode is typically black (normal). By default, BACnet shadow objects copied from the Local Library also show this color (are status ok).
A2
Appendix A
Troubleshooting Object Color and Status
Figure A-1
Gray object color is status OK.
Notes
Shadow objects and their statusOutputs change from the gray (ok) color to yellow (down) whenever the device status ping marks the parent device down, or when a non-operational response is received. Objects appear as in Figure A-8. Refer also to Configuring Device Status/Ping, page 6-15. In previous Niagara releases, when the parent (BACnetDevice) object goes down, child BACnet shadow objects retain the last known value and status (typically ok, meaning gray object color). However, the BACnetDevice object itself changes color to yellow (down), as shown in Figure A-7.
Red
Red object color means status inAlarm. BACnet shadow objects become this color when presentValue meets the objects configured alarm setup (high or low limits if analog, alarmState if binary). The statusFlags property shows inAlarm and the statusOutput also becomes red, to indicate an alarm condition.
Figure A-2 Red object color is status inAlarm.
Orange/Dark Yellow
Orange/dark yellow object color means status fault. Analog type objects (AI, AO) become this color when the presentValue goes below minPresentValue or above maxPresentValue. The statusFlags property shows fault and the statusOutput also becomes orange, to indicate a fault.
A3
Appendix A Object Color and Status
Troubleshooting
Figure A-3
Orange object color is status fault.
Cyan/Light Blue
Cyan/light blue object color means status outOfService. BACnet shadow objects show this color under these circumstances: If a parent (BACnetDevice) object, whenever it is commanded to disablePolling (provided it was previously status ok). See Figure A-4. If a child BACnet object, whenever it is set to this state by writing a True to the outOfService property (providing the object was previously status ok). Outputs of an object set to outOfService are also cyan. See Figure A-5. If an object is in an alarm or fault state, however, its object color (and outputs) remain red or orange, respectively, even when set to outOfService.
Figure A-4 BACnetDevice set to disablePolling is cyan (outOfService).
Figure A-5
Cyan object color and outputs means status outOfService.
A4
Appendix A
Troubleshooting Object Color and Status
Note
A BACnet shadow object in a PollOnDemand container will show outputs as cyan (outOfService) yet remain gray (status ok) whenever it is not currently polled by the JACE (Figure A-6). Polling occurs only when its linked Gx object is viewed in the JDE or a Web browser connection. See Polling On Demand on page 6-10
Figure A-6 Cyan output (only) occurs for inactive objects in a PollOnDemand container.
Yellow
Yellow object color means status down. If the device status monitor (ping) is enabled, a BACnetDevice object will show as down (yellow) whenever the associated BACnet device does not respond to the device status ping (Figure A-7). Only BACnetDevices that are enabled for polling (status ok) are pinged by the device status monitor. If commanded to pollingDisabled, a device is not pinged.
Figure A-7 Yellow BACnetDevice object means the BACnet device is down.
Note
All child shadow objects (and their outputs) are also yellow (down) in this case. See Figure A-8. Also, for all objects, down is the normal object status if the station is opened offline.
A5
Appendix A Debug and Standard Output
Troubleshooting
Figure A-8
Yellow object color (status down) occurs when the parent device is down or whenever the station is opened offline.
Debug and Standard Output

The BACnet service displays numerous messages in the stations Standard Output. Using the Admin Tool, observe the stations Standard Output (without enabling any of the special BACnet debug options). If you are having problems with the BACnet integration, you will typically see some related messages (Figure A-9).
Figure A-9 Standard Output can provide clues for BACnet-related problems.
Note
If you want, you can set further debug options on the General, Engineering tab of the BACnet services property sheet. Refer to the the Using Debug Options section on page 6-24 for more information. You can also set the BACnet services poll scheduler and device status mechanisms to post a debug character in Standard Output for each execution cycle. Each cycle is indicated by a B, as shown in Figure A-10 below. Enable or disable these characters from the property sheet for the BACnet service: Poll, Config tab (displayDots property). DeviceStatus, Config tab (deviceStatusDisplayDots property).
A6
Appendix A
Troubleshooting Debug and Standard Output
Figure A-10 displayDots posts a B for each poll cycle and/or device status ping cycle.
BACnet Troubleshooting Tips

Because each BACnet integration is unique, there is no set procedure to use when using Standard Output to troubleshoot BACnet issues. However, the following tips may prove useful:

If the station is running other device integrations, disable their debug settings (assuming only BACnet service messages are needed). Reduce the scope of BACnet client polling, as needed, by issuing disablePolling commands to the appropriate BACnetDevice objects. Enable specific BACnet debug options only if prepared to collect (and parse through) large amounts of data. This is especially true for the protocol layer-specific debug options (transport, network, and link options). Refer to the the Debug Option Selections section on page 6-25 for more information. Dont leave BACnet debug options, if any, enabled unless you are using this feature to troubleshoot. Debug options require additional station resources that are better left for normal operation. In the case of errors, it can be helpful to copy and save Standard Output. Do this by clicking on Freeze and then blocking the text of interest. Then click Copy to put the text on the Windows clipboard. Paste the output in Notepad or any other text editor and save, if needed.
A7
Appendix A Debug and Standard Output
Troubleshooting
A8
APPENDIX
BACnet PICS
This appendix provides the PICS (Protocol Implementation Conformance Statement) for the Niagara Framework, with the following main sections:

PICS BACnet Conformance Class Supported PICS BACnet Functional Groups Supported PICS BACnet Standard Application Services Supported PICS Standard Object-Types Supported Segmentation Capability PICS Data Link Layer Option Networking Options PICS Character Sets Supported BIBBs Compatibility (BACnet Interoperability Building Blocks)
BACnet Protocol Implementation Conformance Statement

Vendor Name: Tridium, Inc. Product Family: Niagara Framework, including Vykon Web Supervisor, Vykon
BACnet Supervisor, JACE-NP-1, JACE-NP-2, JACE-4XX, JACE-5XX at Release 2.3.4XX or 2.3.5XX.

Description: This product family provides bi-directional communication between the Tridium Niagara Framework, and a BACnet system operating at BACnet Conformance Class 3, over Ethernet media or over MS/TP.
PICS BACnet Conformance Class Supported

Class 1 Class 2 Class 3 Class 4 Class 5 Class 6 complete complete complete partial partial partial
B1
Appendix B BACnet Protocol Implementation Conformance Statement
BACnet PICS
PICS BACnet Functional Groups Supported

HHWS PCWS partial partial
PICS BACnet Standard Application Services Supported

Application Service
ReadProperty ReadPropertyMultiple ReadRange (trend log only) WriteProperty WritePropertyMultiple ConfirmedEventNotification UnConfirmedEventNotification AcknowledgeAlarm GetAlarmSummary Who-Has I-Have Who-Is I-Am SubscribeCOV ConfirmedCOVNotification UnconfirmedCOVNotification
Initiate Requests
yes yes no yes yes yes yes yes yes yes yes yes yes yes no no
Executes Requests
yes yes yes yes yes yes yes yes yes yes yes yes yes no yes yes
PICS Standard Object-Types Supported

Object-Type
Analog Input Analog Output Analog Value Binary Input Binary Output Binary Value Schedule (exported as read only) Calendar (exported as read only) Trend Log (exported as read only) Multistate Input Multistate Output Multistate Value Device
Supported
yes yes yes yes yes yes yes yes yes yes yes yes yes
Dynamically Dynamically Creatable Deletable

no no no no no no no no no no no no Not applicable no no no no no no no no no no no no Not applicable
B2
Appendix B
BACnet PICS BACnet Protocol Implementation Conformance Statement
Segmentation Capability
Feature
Segmented Request Segmented Response
Supported
yes yes
Window size
any any
PICS Data Link Layer Option

ISO 8802-3, 10BASE5 ISO 8802-3, 10BASE2 ISO 8802-3, 10BASET ISO 8802-3, Fiber BACnet / IP - Annex J MS/TP master (JACE only) yes yes yes yes yes yes
Networking Options
Router, Clause 6 - Ethernet IP-Ethernet, Ethernet-MS/TP, Ethernet IP-MS/TP BACnet Broadcast Management Device (BBMD) yes yes
PICS Character Sets Supported

ANSI X3.4 yes
BIBBs Compatibility (BACnet Interoperability Building Blocks)

Data Sharing
DS-RP-A, B DS-RPM-A, B DS-WP-A, B DS-WPM-A, B DS-COV-A DS-COVU-A
Alarm & Event Management

AE-N-A, B AE-ACK-A, B AE-ASUM-A, B
Scheduling
SCHED-B
Device & Network Management

DM-DDB-A, B DM-DOB-A, B NM-RC-A
Trending
T-VMT-B
B3
Appendix B BACnet Protocol Implementation Conformance Statement
BACnet PICS
B4
APPENDIX
BACnet PC Notes
This appendix provides configuration details for running the Niagara BACnet service on a PC. This configuration is not necessary for any JACE controller, which is shipped from the factory with the appropriate communications adapters and drivers.
Note
BACnet is not typically licensed to run on a Web Supervisor (a station that runs on a job-owned PC). However, a Vykon System Integrator may need to run the BACnetService on a company-owned PC for job configuration, maintenance, or demonstration purposes. Also, a BACnet Supervisor product is now available. For equivalent information, please refer to the Niagara BACnet Supervisor Reference. The following main topics are contained: Installing the BACnet Service BACnet Over Ethernet Considerations
Installing the BACnet Service

The Niagara BACnetService can run on a PC station using a link-layer type of either Ethernet and/or IP, the same as on a JACE controller. However, BACnet over Ethernet on a PC requires a special device driver for low-level network access.
Procedure C-1 Installing the BACnet service at a PC station, using the installed JDE.
Step 1
In the station on the PC, add the BACnet service, if not already installed. Refer to the Installing and Configuring the BACnet Service section on page 1-8. In the BACnetService, specify the unique BACnet Device ID (Instance Number) for the PC, and configure the link-layer types to be Ethernet and/or IP link layer. Refer to the Configuring Essential Station Properties section on page 1-11.
a. b.
Step 2
If Ethernet link layer, follow instructions in the next section, BACnet Over Ethernet Considerations. If IP link layer, refer to the the BACnet/IP Considerations section on page 11.
Step 3
Follow instructions in the Verifying Communications section on page 1-13.
C1
Appendix C BACnet Over Ethernet Considerations
BACnet PC Notes
BACnet Over Ethernet Considerations

If you have a Niagara PC or Web Supervisor that is licensed for the BACnet service, and you will be using it for BACnet over Ethernet, the drivers.properties file in its niagara\<release>\nre\lib directory must have an entry for the device name of the Ethernet adapter (as it is known your PCs operating system). In Niagara r2.301.430 or later (r2.3.5), a setAdapter utility greatly simplifies this. Simply follow the few steps in the next section, Using setAdapter.exe. If you are using Niagara r2.3.4 or earlier (any build prior to r2.301.430), jump ahead to the section Manually Editing driver.properties.
Notes
If at some point you modify this entry in drivers.properties again, you must restart any running station for the BACnetService to use it. This configuration applies to the host (PC), and not the Niagara station. If you install a later 2.x Niagara build on your Niagara engineering PC, copy the edited drivers.properties file to the new niagara\<release>\nre\lib folder. Otherwise, BACnet/Ethernet link-layer communications will not work.
Using setAdapter.exe
Procedure C-2 Using setAdapter.exe to edit drivers.properties.
At the Web Supervisor / Niagara engineering PC, stop any currently running station. Open a Niagara console window (Start > Programs > Niagara (build) > Console). At the command prompt, type: setAdapter and press ENTER. This returns a list of all real Ethernet adapters in the PC (typically only one). At the enter number of choice prompt, type the appropriate number for the Ethernet adapter used for BACnet communcations, then press ENTER. The utility automatically edits the drivers.properties file with the correct device name, for example:
ethernet.deviceName=\\Device\\{C37783-84DC-430E-B3B6-25AE81E77F88}
Step 4
and also saves the file.

Step 5
Close the Niagara console and restart the station.
C2
Appendix C
BACnet PC Notes BACnet Over Ethernet Considerations
Manually Editing driver.properties

The following two topics explain how to proceed: Determine Device Adapter Name Edit drivers.properties
Determine Device Adapter Name
Depending on the operating system used on your PC, there are two different methods to determine the Ethernet adapter device name. Windows NT method Windows 2000 or XP Pro method
Windows NT
The Ethernet device adapter name under Windows NT is a short character string.
Procedure C-3 Determining the Ethernet device name under Windows NT.
Step 1 Step 2
Open a command prompt (MS-DOS) window. Type ipconfig and press ENTER. Your Ethernet adapter name and IP configuration appear, as shown in Figure C-1.
Figure C-1 Ethernet adapter device name in a command prompt window.
Ethernet adapter name. In this example, the name is El90x1.
Notes
If multiple adapters are installed, you must select the proper one. Be careful to note differences between letters and numerals. In this example, the second character is a letter l (el), and not a number 1 (one).
C3
BACnet PC Notes
Windows 2000 or XP Pro

In Windows 2000 or XP Pro (Professional), the Ethernet device adapter name is a long character string in hexadecimal format. Apart from appearing in the Windows registry, this string is not found with normal system utilities, such as the Windows Device Manger. However, Niagara includes a special utility that you can use to find and copy this string.
Procedure C-4 Determining Ethernet adapter device name in Windows 2000/XP Pro.
Stop any station running on the PC. Open a Niagara Console window. Type showAdapters, and press ENTER. This utility displays both physical and virtual network adapters (Figure C-2).
Figure C-2 Both physical and virtual adapters appear in the showAdapters utility.
Physical adapters have a manufacturer name and model number. Typically, the first adapter listed is a physical adapter.
The adapter device name is the entire character string between quotes (" ").
Step 4
Select the physical adapter that will be used for BACnet over Ethernet communicationsuse the windows scroll bar if necessary. In most cases, the first adapter listed will be a physical adapter (have an associated manufacturer and model number). If multiple physical adapters exist, you will need to select the one to be connected to the BACnet network.
Step 5
Highlight the adapter names value, by dragging the mouse over all characters shown between the quotation marks (" "), as shown in Figure C-3.
C4
Appendix C
BACnet PC Notes BACnet Over Ethernet Considerations
Figure C-3
Highlight the adapter name, right-click the title bar, and select Edit > Copy.
Step 6
With this string highlighted, right-click on the title bar and select Edit > Copy. The adapter name string is now copied to the Windows clipboard. Close the Niagara Console, and follow the next procedure, Edit drivers.properties
Step 7
Edit drivers.properties
After finding the Ethernet adapter device name, verify that the Niagara build has the proper entry in the niagara\<release>\nre\lib\drivers.properties file.
Procedure C-5 Editing the drivers.properties file.
Step 1 Step 2
Using Notepad, open the drivers.properties file. Edit (or add, if missing) the Ethernet device name line with the proper adapter name. The proper syntax is:
ethernet.deviceName=\\Device\\<Ethernet device adapter name>
For example, if a Windows NT system, this line might look like:

ethernet.deviceName=\\Device\\El90x1
If a Windows 2000 /XP Pro system, this line might look like:
ethernet.deviceName=\\Device\\{B2996882-D086-4532-B6F5-D82A950570AA}
Note
If a Windows 2000/XP Pro system, use CNTRL-V to paste the adapter name string immediately behind the leading ethernet.deviceName= portion.
Step 3
Save and close the drivers.properties file.
C5
BACnet PC Notes
C6
APPENDIX

This appendix explains the Niagara BACnet extension (bacnetx) modules, which are located in the tridiumx/bacnetx folder of the Local Library.
Figure D-1 Extensions to Niagara BACnet are in the bacnetx folder of tridiumx.
About bacnetx Modules

The bacnetx folder contains extension modules that provide special-purpose functions not required by most BACnet integrations. This allows development of future modules independent of the core bacnet module (similar to the modules in the londevices folder and the core lonworks module). No additional license requirements exist for bacnetx modulesthe license.properties file must contain just the standard bacnet feature. Currently, the bacnetx folder contains only two modules, each as separate JARs: ndio (bacxNdio)Used to expose Ndio objects in a JACE-4 directly as BACnet objects (BACnet server operation). notifier (bacxNotifier)Provides special BinaryValue shadow objects for monitoring Notifier panels (BACnet client operation).
D1
Appendix D ndio (bacxNdio)
ndio (bacxNdio)
This module applies only to a JACE-4 controller with integral I/O, when you need to expose I/O points (Ndio objects) directly as BACnet objects. To use this feature, you must install both the bacnet and the bacxNdio module in the JACE-4 (in addition to the ndio module). The bacxNdio module is relatively small: approximately 12Kb, versus 475Kb for bacnet. A BACnet Supervisor (or Web Supervisor) also requires a bacxNdio module. This NT version of the bacxNdio module is approximately 22Kb.
Notes
Using the bacxNdio Module

Apart from the following steps, the bacxNdio module requires no configuration.
Procedure D-1 Using the bacxNdio module.
Step 1
Using the Admin Tool, install the bacxNdio module in any JACE-4 in which the bacnet module is also installed. After the JACE-4 reboots and its station is restarted, open the station in the JDE and expand its services folder (to verify the BACnetNdioService does not already exist). In the JDE, open the Local Library, and use the Tree View to expand the ndio JAR under the tridiumx/bacnetx folder. Right-click on the BACnetNdioService and select Copy. Paste the BACnetNdioService into the JACE-4 stations services folder. Save the JACE-4 station database (Backup SNS) and then reboot the JACE-4. After the host reboots and the station is restarted, you can expose Ndio objects directly as BACnet objects, using each objects Config property foreignAddress. Ndio primitive objects closely resemble standard Niagara control objects in linkable properties, Config properties, commands, and behavior. Table D-1 lists the different Ndio object types, and what BACnet object types they expose as (server operation).
Table D-1 Ndio objects types expose as certain BACnet objects.
Step 2
Step 3
Ndio source object

Ndio0to10VInput, NdioHighSpeedCounterInput, NdioResistiveInput, NdioThermistorType3Input
Exposed as BACnet object type Niagara Std. Equivalent

Analog_Input AnalogInput (AI)
Analog_Output Ndio0to10VOutput1, Ndio0to20MAOutput1 (future use) NdioBinaryInput NdioBinaryOutput

1.
AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)
Binary_Input Binary_Output
AnalogOutput type Ndio objects only available in JACE I/O Expansion Modules.
D2
Appendix D
Niagara bacnetx Modules notifier (bacxNotifier)
Note
Assign unique foreignAddress numbers among all Ndio objects within any group of standard Niagara equivalent object types. For example, Ndio0to10Vinput, NdioHighSpeedCounterInput, NdioResistiveInput, and NdioThermistorType3Input objects all count as AnalogInput objectseach requires a unique foreignAddress. Refer to Instance Number Rules, page 4-4, for more information.
notifier (bacxNotifier)
This module applies to any BACnet job that includes Notifier fire system panels. It includes a special BinaryValue shadow object that provides Event_State polling. The bacxNotifier module became available in Niagara Release 2.2 and later. To use this feature, you must install both the bacnet and the bacxNotifier module. The bacxNotifier module is very small (13.2Kb or less).
Notes
The NotifierBinaryValue object is the sum total of the bacxNotifier module. It works with the standard Niagara BACnet service (BACnetWSService if BACnet Supervisor, or BACnetService if JACE controller). The learnDevice command does not automatically create NotifierBinaryValue objects for a Notifier panelyou will need to add these objects manually.
Note
Using the bacxNotifier Module

To use the bacxNotifier module, follow Procedure D-2.
Procedure D-2 Using the bacxNdio module.
Step 1
Using the Admin Tool, install the bacxNotifier module in any Niagara host in which the bacnet module is also installed. After the station is restarted, open it in the JDE. Use the Tree View to expand the notifier JAR under the tridiumx/bacnetx folder. Expand the objects container to reveal the NotifierBinaryValue object. Copy and paste, as needed, NotifierBinaryValue objects from the Local Library into appropriate containers under a BACnetDevice object (representing a Notifier panel). Refer to Adding a Child Object, page 2-16, for details on manually adding objects.
Step 2 Step 3
Step 4
D3
Appendix D notifier (bacxNotifier)
NotifierBinaryValue
The NotifierBinaryValue object is nearly identical to the BACnetBinaryValueLite object, but with an additional eventState output that displays the current BACnet Event_State (alarm status) value (Figure D-2). Unlike with a normal BACnetBinaryValue object, the BACnet Poll Scheduler continuously polls the value of the target objects Event_State property, in addition to the normal Present_Value and Status_Flags properties.
Figure D-2 NotifierBinaryValue object has both a statusOutput and an eventState output.
Present_Value, Status_Flags and Event_State are continuously polled. NotifierBinaryValue object
BACnetBinaryValueLite (normal) object. Event_State can be fetched or uploaded, but is not polled.
The eventState output value appears in text using the Niagara EventStateEnum descriptors, as either:

normal fault offnormal high_limit low_limit unknown
This output can be linked to a GxText object for display in a GxPage, or fed into a Program object for other control logic purposes. The bacxNotifier module was originally developed before Niagara client support for BACnet multistate objects. It is possible that a Notifier panel can be better integrated using these standard objects (BACnetMultistateValue, BACnetMultistateInput, etc.) than using by using the bacxNotifier module. If integrating a Notifier panel, you should investigate the makeup of its BACnet objects to get a better understanding of how to engineer the best solution. For details on internal properties of a NotifierBinaryValue object, refer to the BACnetBinaryValue, page 3-43, ignoring any that are not in Lite objects.
Notes
D4
APPENDIX

The BACnet standard defines an internetwork as a set of two or more (BACnet) networks connected by (BACnet) routers. This appendix explains topics relating to BACnet internetworks and Niagara station configuration. Also provided are BBMD-related details that apply only to a BACnet/IP network. The following main topics are discussed: BACnet Network Numbers Internetwork = BACnet Routers BACnet/IP and BBMDs Example Internetwork Diagrams
BACnet Network Numbers

In pre-2.3.4 releases, the Niagara BACnet service could be enabled for only one link layer type, either BACnet/IP or BACnet/Ethernet. Network association was implicit. The station was simply a device on its local BACnet network (by BACnet convention, network 0). The range for BACnet network numbers is 165535. However, the station could find and/or learn BACnet devices on other networks. An internal router table was built, based upon messages received from the global I-Am messages received from other devices (and routers) on remote networks. A BACnet service command let you print this router table to the stations Standard Output. Starting in Niagara r2.3.4, BACnet network awareness is explicityou must declare the network number for any link-layer tab that you enable in the BACnet service. If a station has multiple BACnet link-layers (tabs) enabled (for example, both BACnetIP and BACnetEthernet), a unique network number is required for each. The station automatically performs router functions between these networks. If installing a Niagara station on an existing BACnet internetwork (one or more BACnet routers already exist), you need to know all assigned network numbers, and enter them (as appropriate) on any enabled link-layer tab in the BACnet service. Find the existing network number information in the configuration setup of routers.
Note
E1
Appendix E Internetwork = BACnet Routers
Internetwork = BACnet Routers

The Niagara BACnet service now provides a view of the router table, which lists all external BACnet routers known to the station. Included is the ability to modify, add, or remove entries representing BACnet routers. Refer to Router Table, page 6-5. Typically, you should not need to edit this table, which is automatically populated when you perform a Who-Is or learnNetwork command from the BACnetUtility. Internetwork Rules BACnet Router Functions
Internetwork Rules
When implementing a BACnet internetwork there are several rules that must be followed:
1.
Rule: There must be only one message path between any two BACnet devices on an internetwork. No communication loops are allowed. Example: You should not configure multiple Niagara stations on the same LAN with both BACnet/IP and BACnet/Ethernet enabled.
2.
Rule: A BACnet router must exist between two different BACnet networks (different network numbers) for BACnet messages to pass between the devices on the two networks. This applies to any link-layer type(s). Concept: A BACnet router can be a single-purpose device, or an application layer device (controller) that also includes router functionality, such as with Niagara stations r2.3.4 and higher. If the station in a Niagara host has support enabled for multiple link-layers, it automatically acts as a router between those 2 (or more) BACnet networks to which it is directly attached. For example, if BACnet/Ethernet, MS/TP1, and MS/TP2 are all enabled in a JACE station, it operates as a BACnet router between those 3 networks. If BACnet/IP, BACnet/Ethernet, and MS/TP1 are enabled, the station operates as a BACnet-to-BACnet/IP router between those 3 networks, and so forth. A Niagara station does not act as a BACnet/IP router, which is required on any internetwork with more than one BACnet/IP network.
Note
3.
Rule: Within any given internetwork, each BACnet network must have unique network number, from 1 to 65534. Concept: Each link-layer tab that is enabled in the Niagara BACnet service corresponds to a specific BACnet network.
If establishing a new BACnet internetwork, the default network numbers that appear on a stations BACnet service tabs can be used. For example, BACnet/IP = net 1, BACnet/Ethernet = net 2, and (if a JACE-4/5), MS/TP1 = net 11, MS/TP2 = net 22, and so forth.
E2
Appendix E
Internetworks and BACnet/IP BACnet/IP and BBMDs
4.
If adding a JACE on an existing BACnet internetwork, you must specify the established BACnet/IP network number and/or BACnet/Ethernet network number currently in use. If a JACE with one or more enabled MS/TP ports, you must also specify a previously unused network number for each MS/TP (RS-485) port. Rule: Every BACnet object, including the Device object in each BACnet device, must have a unique numeric object_identifier (within all other objects of that same object type), internetwork-wide. Valid values for this identifier range from 0 to 4194302.
Concept: BACnet devices respond to a Who-Is broadcast messge with an I-am message that includes each Device objects unique numeric object_identifier. If you receive duplicate I-am messages (multiples showing same device, by number), it means either that more than one device has been assigned that same identifier (number), or that a message loop exists.
BACnet Router Functions

A full listing of all BACnet router functions is extensivesee the BACnet specification for complete details on routers. From a general perspective, BACnet routers are required to pass BACnet messages between different BACnet networks. This applies to all directed messages as well as broadcast messages. Usually, a BACnet router is used to join networks of different media/link-layer types, for example a router with RS-485 MS/TP port(s) and an Ethernet-BACnet/IP port. For some examples, see Example Internetwork Diagrams, page E-7.
BACnet/IP and BBMDs

Starting in Niagara r2.3.4, Niagara BACnet/IP support expands with BBMD-hosting capability. If a station is configured for BBMD operation, you can review (and if necessary, modify) the broadcast distribution table common to all BBMDs on the B/IP network, as well as the foreign device table used in the Niagara station. The following sections discuss BBMD-related topics: About BBMDs Niagara BBMD Configuration Tips
About BBMDs
Use of BBMDs (BACnet broadcast management device) is the answer to a single B/IP network that needs to span across multiple IP subnets. Each IP subnet with BACnet/IP devices requires one (and only one) BBMD. An installation with BBMDs may not be an internetwork, but just have a single B/IP network.
E3
Appendix E BACnet/IP and BBMDs
A BBMD may be a device operating solely as a BBMD, or more typically, include BBMD functions in addition to other application/controller duties. This is the case with a Niagara r2.3.4 station running the BACnet service with BACnet/IP enabled, and configured with property bacnetIPDeviceType set to bbmd. Refer to Configuring BACnet/IP Properties, page 6-18, for where to find these properties. The following BBMD topics are explained: Why and What a BBMD Does Foreign Device Table
Why and What a BBMD Does
A BBMD is used to support delivery of BACnet broadcast messages, such as Who-Is and Who-Has. As a rule, globally broadcast messages are inherently blocked by standard IP routers, which are used to connect separate IP subnets. Note this issue does not exist for any directed message between devices on different subnets, such as a common ReadProperty requestnot a broadcast message. The BBMD resolves this issue by acting as a broadcast manager for its subnet, working in coordination with other peer BBMDs. Each other IP subnet that contains BACnet/IP devices has one BBMD. Each BBMD stores a table with the IP address and distribution mask of all BBMDs, itself included. This is called the BBMDs BDT (broadcast distribution table), and is identical in each BBMD for that entire B/IP network. When a global broadcast message is sent, it is automatically received by all devices on its local subnet, including the BBMD. (Local devices reply as needed to the broadcast device, without BBMD involvement.) The local BBMD forwards the broadcast message to the other subnets, using one of two methods (as defined for each remote subnet): One-Hop Two-Hop
One-Hop: The BBMD sends the message using a directed broadcast, whereby the
IP router for the destination subnet broadcasts the message on its local subnet. The router must support directed broadcasts, otherwise the two-hop method must be used.
Two-Hop: The BBMD sends the message to its peer BBMD on the remote subnet, whereby that BMMD broadcasts the message on its local subnet.
Note that replies to BACnet broadcast messages do not require BBMD involvement, as these are directed messages back to the particular B/IP device that generated the message (that is, the destination IP address is specific to that one device).
Foreign Device Table
In a case of an IP subnet where only a few (or perhaps just one) B/IP device exists, a local BBMD may be considered excessive for BACnet broadcast message support. An alternative for that subnet is for each B/IP device to register as foreign device with a particular BBMD on a remote subnet. Once registered, the device is added to that BBMDs FDT (foreign device table). It then becomes that BBMDs responsibility to deliver global BACnet broadcast messages to that remote device.
E4
Appendix E
Internetworks and BACnet/IP BACnet/IP and BBMDs
Because this scheme is sometimes used for B/IP devices that are not permanent, it was designed with a mandatory registration lifetime feature. When any B/IP device registers as a foreign device with a BBMD, it must specify its Time-to-Live value, in seconds. It is then expected to re-register within this period, else the BBMD will remove (purge) it from its FDT. This prevents unneccesary broadcast delivery attempts to part-time participants. The FDT in any BBMD reflects the current list of its registered foreign devices, along with each devices Time-to-Live value and calculated purge time. If the Niagara station is configured as a BBMD, you can view this table on the BACnet services property sheet (BACnet/IP, Engineering tab). Refer to Foreign Device Table (FDT), page 6-21, for information on using this feature. The foreign device term implies no stigmait is purely BBMD-centric. The most expedient configuration for a Niagara station may well be as a foreign device, providing its local IP subnet has no BBMD and other B/IP devices (if any) are currently each registered as foreign device with a remote BBMD. Unlike a BBMDs broadcast distribution table, which is identical in each BBMD, the foreign device table in each BBMD is unique to that BBMD.
Notes
Niagara BBMD Configuration Tips

The following BBMD configuration tips are grouped into two categories: Existing BACnet/IP Network New BACnet IP Network
Existing BACnet/IP Network
If you have an existing BACnet/IP network that spans IP subnets, chances are that it has at least one existing BBMD. Unless the host for the Niagara station is located on that same IP subnet as an existing BBMD1, you must choose one of the following: Configure As BBMD Configure As Foreign Device
Configure As BBMD
Typically this is best if the local subnet is receiving other new B/IP devices, and/or existing B/IP devices on this subnet are not currently supported by a BBMD. You should determine if the router for the local subnet supports directed broadcasting.
Procedure E-1 Configure Niagara station as BBMD.
Step 1
On the BACnet/IP, Config tab of the BACnet services property sheet, set the property bacnetIPDeviceType to bbmd. Refer to page 6-19.
1. If the Niagara host is being installed on an IP subnet with an existing BBMD for that BACnet/IP network, you are done. Leave bacnetIPDeviceType = none.
E5
Appendix E BACnet/IP and BBMDs
Step 2
For the next property, remoteBBMDAddress, enter the BACnet MAC address of any known operating BBMD for this B/IP network (on another subnet). Refer to page 6-19 for details on syntax when entering a B/IP MAC address. Click Apply at the bottom of the BACnet/IP, Config tab. Perform a whoIs command from the BACnet services BACnetUtility. On the BACnet/IP, Engineering tab of the BACnet services property sheet, examine the BDT in the top half of the property sheet. The remote BBMD you entered should appear in the BDT, as well as other BBMDs (if existing). If an entry for the host of the running Niagara station does not already appear in the BDT, add it. Refer to Broadcast Distribution Table (BDT), page 6-20, for syntax details. If the router for the local subnet supports directed broadcasting, enter the local hosts subnet mask (in hex) in the Distribution Mask field. Otherwise, if the router does not support directed broadcasting, or you are not sure, enter FF:FF:FF:FF as the Distribution Mask.
Step 6
Step 7
Click Apply at the bottom to make changes effective. This should update all other BBMDs on the B/IP network with the same BDT information. Perform a whoIs command from the BACnetUtility. If the BBMD configuration was successful, you should see devices from other subnets respond.
Step 8
Configure As Foreign Device

Typically this is best when a remote subnet BBMD exists and the local subnet has only the Niagara station as a B/IP device, or if other B/IP devices on the local subnet are currently registered as foreign devices.
Procedure E-2 Configure Niagara station as foreign device.
Step 1
On the BACnet/IP, Config tab of the BACnet services property sheet, set the property bacnetIPDeviceType to foreignDevice. Refer to page 6-19. For the next property, remoteBBMDAddress, enter the BACnet MAC address of a known operating BBMD for this B/IP network (on another subnet). This is the BBMD the station will attempt to register with as a foreign device. Refer to page 6-19 for details on syntax notes when entering a B/IP MAC address. For the last property, registrationLifetime, either accept the default 900 seconds, or enter another value from 300 to 65,535 seconds. Click Apply at the bottom of the BACnet/IP, Config tab. The station attempts to register with the remote BBMD at the remoteBBMDAddress. Perform a whoIs command from the BACnetUtility. If the foreign device registration was successful, you should see devices from other subnets respond.
Step 2
Step 3
Step 4
Step 5
E6
Appendix E
Internetworks and BACnet/IP Example Internetwork Diagrams
New BACnet IP Network
If you are configuring the Niagara station while installing B/IP devices for a new B/IP network, there are probably no existing BBMDs. In this case, you would typically follow Procedure E-1 Configure Niagara station as BBMD. This would allow B/IP devices on remote subnets to register with the station as foreign devices. However, you would skip Step 2 to specify a remoteBBMDAddress. You would also not see any other remote BBMDs when you followed Step 5.
Example Internetwork Diagrams

Figure E-1 shows an internetwork with 2 BACnet routers and 4 BACnet networks.
Figure E-1 Four physical networks, 2 routers.
BACnet Node BACnet Router Network 2 B/Eth
A
10 Network 11 MS/TP 11 39 70 71 99
40 Network 22 MS/TP
41
68
Network 8 ARCNET
In the example above, routers A and B join together three different media and link-layer types: BACnet over Ethernet (network 2), BACnet MS/TP (networks 11 and 22), and BACnet ARCnet (network 8). Note that each BACnet node has a unique Device ID number (shown inside node). Note also that router A could actually be a JACE-4/5 licensed for MS/TP, as shown in Figure E-2.
Figure E-2 BACnet Ethernet to MS/TP router functions provided by station in JACE-4/5.
Network 2 B/Eth JACE-4/5 with two MS/TP trunks. 10 Network 11 MS/TP 11 39
8 A
70
40 71 99 Network 22 MS/TP
41
68
Network 8 ARCNET
E7
Appendix E Example Internetwork Diagrams
For an Ethernet LAN, there may be two separate BACnet networks sharing the same mediaBACnet over Ethernet and BACnet/IP, as shown in Figure E-3.
Figure E-3 Same physical Ethernet LAN, router joins two BACnet networks.
BACnet Node BACnet Router
6
Network 1 B/IP
Network 2 B/Eth
Again, note that each BACnet node has a unique Device ID number (shown inside node). Note also that this router function could actually be provided by a Niagara station, as shown in Figure E-4.
Figure E-4 BACnet Ethernet to BACnet/IP router functions provided by Niagara station.
JACE controller (or BACnet Supervisor) with both BACnetEthernet and BACnet/IP enabled.
10
6
Network 1 B/IP
Network 2 B/Eth
In this case, you must be especially careful that no other router exists between the BACnet Ethernet and BACnet/IP networksif the Niagara station detects this illegal (loop) configuration, the routing functions performed by the station are stopped. This condition is indicated on the property sheet for the BACnet service on the General, Status tab, whenever the property routingEnabled is shown as False.
E8
Appendix E
Internetworks and BACnet/IP Example Internetwork Diagrams
BACnet/IP
BACnet/IP networks can be more involved, with devices designated as BBMDs and foreign devices, plus standard TCP/IP (IP) routers. Note that BBMDs are used to avoid having separate B/IP networks for each subnetthis would require a BACnet/IP router to exist on each subnet (yet even more complexity). Figure E-5 shows an example internetwork that includes an Ethernet/IP backbone. The B/IP network shown spans multiple IP subnets. Use of BBMDs provides BACnet broadcast message delivery through IP routers.
Figure E-5
Internetwork that includes single B/IP network spanning multiple IP subnets, plus other BACnet networks.
BACnet Node BACnet Router IP Router BBMD BACnet Foreign Device subnet 192.168.1 Network 1 B/IP
9
subnet 192.168.5
11
10 8
Network 8 ARCNET 40 41 69
7 14
subnet 192.168.3
A
20 Network 11 MS/TP 21 39 70 71 99
15
Network 22 MS/TP
3
subnet 192.168.7
4
Network 2 B/Eth
Note that on subnet 192.168.1, there is no BBMD. Both BACnet/IP nodes on that subnet (Device IDs 7, 8) are registered as a foreign device with a remote BBMD. Note also that on the physical Ethernet segment used by subnet 192.168.7, there are both BACnet/IP devices (Device IDs 2 and 3) and BACnet over Ethernet devices (Device IDs 4, 5, and 9). Router C provides communications between these two BACnet networks. With the exception of router B (B/IP to B/ARCNET), all BACnet routing and BBMD functions can be performed by Niagara stations. On subnet 192.168.3, router A functions (B/IP to MS/TP) and BBMD functions can be performed by a JACE-4/5 with its BACnet service enabled for BACnet/IP and BACnetMSTP1 and 2. On subnet 192.168.5, BBMD functions can be performed by any Niagara station with BACnet/IP enabled. On subnet 192.168.7, router C functions (B/IP to B/Eth) and BBMD functions can be performed by any Niagara station with both BACnet/Ethernet and BACnet/IP enabled.
E9
Appendix E Example Internetwork Diagrams
Figure E-6 shows an a similar internetwork with these functions provided by Niagara stations, as previously described.
Figure E-6 Similar internetwork with Niagara stations providing BBMD and routing functions.
Niagara station with B/IP enabled
BACnet Node BACnet Router IP Router BBMD BACnet Foreign Device subnet 192.168.1 Network 1 B/IP
9
subnet 192.168.5
11
10 8
Niagara station with B/Eth and B/IP enabled
Network 8 ARCNET 40 41 69
7 14
subnet 192.168.3
JACE-4/5 with two MS/TP trunks, also B/IP enabled. 20 Network 11 MS/TP 21 39
6 16 15
70 71 99 Network 22 MS/TP
subnet 192.168.7
4
Network 2 B/Eth
E10
APPENDIX

This appendix covers BACnet MS/TP (master-slave/token-passing) support provided in the Niagara BACnetService. BACnet MS/TP is often used in lower-cost unitary controllers and other application-specific devices. MS/TP devices are networked using the EIA-485 physical layer, where the term RS-485 is also used. The following main topics are explained ahead: Niagara MS/TP Overview Configuring for BACnet MS/TP Engineering Considerations for MS/TP
Niagara MS/TP Overview

In Niagara r2.3.4 and later, direct support for BACnet MS/TP devices is available for JACE-4 and JACE-5 series controllers1. You can attach a network of BACnet MS/TP devices to an RS-485 port on a JACE-4/5, and use the same familiar BACnet client shadow objects to represent device and application data.
Figure F-1 BACnet MS/TP support via RS-485 port on JACE-4/5.
JACE-5
HE AR TB EA T Rx D TxD Rx RS D RS PO 2 RT 32 1 TxD 232 PO /RS RT 4 2 85 DA ETH 10 ER 0 NE T LO N TA Rx D TxD
General I/O
Lighting Control Some defined number of BACnet MS/TP devices per network (see Networks and Device Limits, page F-2).
RS-485
BACnet MS/TP Field Bus
VAV Controllers
HVAC Control
1. Niagara BACnet MS/TP support is available only for embedded JACEs with the VxWorks operating system.
F1
Appendix F Niagara MS/TP Overview
Typically, the BACnetService in the JACE station is also enabled for BACnet/IP and/or BACnet/Ethernet. The station provides BACnet router support between the BACnet MS/TP network(s) and the Ethernet-connected BACnet network(s). The following additional overview topics apply to BACnet MS/TP in Niagara: MS/TP Boundaries Station Engineering Considerations
MS/TP Boundaries
Boundaries for BACnet MS/TP integrations in Niagara are summarized in the following sections: Licensing Networks and Device Limits
Licensing
BACnet MS/TP is a separately-licensed option on a JACE host, with a required feature entry of bacnetMSTP in the JACEs license file. Additional lines in the license file can specify other MS/TP trunk and/or device limits. The JACE also requires general BACnet licensing, however, this is typically standard for all JACEs. For further details, see Licensing for BACnet MS/TP, page F-4.
Networks and Device Limits
Each BACnet MS/TP network requires a separate JACE-4/5 RS-485 port, which can support some number1 of MS/TP BACnet devices. Both master and slave-type MS/TP devices are supported (and count) equally. If a standard JACE-403, no more than 27 BACnet devices can be shadowed in the station database. Moreover, a total of 27 networked devices (of any type) are supported. This limit applies across all possible drivers and communications ports, for example, LonWorks, Modbus, and BACnet (and BACnet MS/TP). Beyond this 27 total, operation is not assured, and technical support may become unavailable. An extended JACE-403 (and license upgrade) is also available, which removes device count limits. For more information, please contact your Niagara sales channel. Depending on the number of RS-485 ports available on a particular JACE-4/5 model, up to 4 MS/TP networks are supported. See RS-485 Port Guide, page F-12. All BACnet MS/TP devices on the same network must use the same communications baud rate, configurable in the Niagara station at either 9600, 19.2Kb, 38.4Kb, or 76.8Kb. For various performance reasons, it is recommended that all BACnet MS/TP devices on the same network also be made by the same manufacturer.
Note
1. The actual number of BACnet MS/TP devices supported per trunk depends on the devices electrical RS-485 loading characteristics, in addition to corresponding entries in the JACEs license file. See Licensing for BACnet MS/TP, page F-4, for more information.
F2
Appendix F
Niagara MS/TP Support Configuring for BACnet MS/TP
Station Engineering Considerations

Few differences apply to engineering a Niagara station that includes BACnet MS/TP network(s), as the same BACnet client shadow objects are used. However, there are some engineering considerations listed here, and explained in detail in later sections: Maximum device limit (per MS/TP trunk) is strictly enforced by the Niagara BACnetService. If this device limit is exceeded on an MS/TP trunk, some devices cannot be monitored in the Niagara station. Similar device restrictions apply in a standard JACE-403 (27 maximum of any kind), and possibly across all BACnet link-layer types (depending on the specific installed license file). The whoIs and learnNetwork commands in the BACnetUtility can discover master MS/TP devices, but not slave MS/TP devices. By BACnet design, slave devices are not permitted to generate messages, including I-am. For any MS/TP slave device, you manually copy and paste a BACnetDevice for it, and then enter its known network number, MAC address, and Device ID number. For more details, see Working with Slave Devices, page F-18.

The JACE station uses separate polling threads for each BACnet MS/TP network, and another (combined) polling thread for BACnet/Ethernet and BACnet/IP. This isolates poll-response issues from the different link-layer types, maximizing update efficiency. Be aware, however, that performance of any MS/TP network can be greatly affected by the configuration of its devices. For related details, see Engineering Considerations for MS/TP, page F-13.
Configuring for BACnet MS/TP

Configuring a JACE-4/5 for BACnet MS/TP can be divided into two areas: Prepare the JACE Host Configure Essential MS/TP Link-Layer Properties
Prepare the JACE Host

Before a JACE-4/5 can talk to BACnet MS/TP devices, it must be specially licensed and have an entry (referencing a low-level MS/TP driver) in its drivers.properties file. Also, Niagara Release 2.3.5, including the bacnet module, must be installed. There is no separate tridiumx module (JAR file) for MS/TP BACnet. The Niagara bacnet module, and BACnetService therein, contains all required components. Licensing for BACnet MS/TP Verifying drivers.properties Installing the BACnet module
Note
F3
Appendix F Configuring for BACnet MS/TP
Licensing for BACnet MS/TP

Caution
Use the Admin Tool to open the JACE-4/5 host and verify the needed entries exist. From the Installation tab, select View License.
Do not attempt to edit the license file. If you make any changes to the license file, your JACE-4/5 station will not operate! Contact Tridium if you need any changes made to your license, so that you may be sent a proper license.
To allow BACnet MS/TP operation upon station startup, the license.properties file in the JACE-4/5 is checked for the following line:
features=coreRuntime;<features>;<features>;bacnet;bacnetMSTP;
where: <features> are other licensed features for the JACE. Note that the order of the features in the feature line is not important.
checked
Starting in Niagara r2.3.5 (build 2.301.508 or later), 3 additional lines are in the license.properties file, and if present, define other limits, as follows:
numberOfBACnetDevices=n
where: n is the total number of BACnet devices, across all BACnet link layers, that are supported in its station. For a standard JACE-403 this may be up to 27, or (27 - maxLonDevices). If this line is absent, there is no defined limit.
numberOfBACnetMSTPTrunk=n
where: n is the maximum number of MS/TP trunks that can be enabled on this JACE, where the maximum value is 4. If this line is absent, the default is 1.
numberOfDevicesPerMSTPTrunk=n
where: n is the maximum number of devices supported on any one MSTP trunk. If this line is absent, the software-enforced limit is 124. Physically, this limit is enforced by the electrical RS-485 loading characteristics of MS/TP devices, e.g.: 31 (full-load), 62 (half-load), and 124 (quarter-load) maximum.
Note
Niagara software limits for BACnet are specified within the hosts license only. Example F-1 shows an example portion of a JACE-512 license file, created to support a total of 300 BACnet devices, of which up to 248 can be MS/TP devices networked on 2 MS/TP trunks (RS-485 ports) on the JACE.
Example F-1 Example license portion, 2 MS/TP trunks, allowing quarter-load devices.
features=coreRuntime;<features>;<features>;bacnet;bacnetMSTP; numberOfBACnetDevices=300 numberOfBACnetMSTPTrunks=2 numberOfDevicesPerMSTPTrunk=124
In this case, for either trunk to actually support 124 devices, all installed MS/TP devices must be (electrically speaking) quarter-load devices. Otherwise, an RS-485 trunk with this number of devices would not operate correctly if there were full-load or half-load types.
F4
Appendix F
Verifying drivers.properties
The drivers.properties file on the JACE-4/5 must include the following line:
driver.mstp=tridium.nre.vxworks.mstp.VxWorksMstpDriver
This line references the low-level driver used for Niagara BACnet MS/TP communications. This entry exists in JACE-4/5s starting around the Niagara r2.3.4 time framehowever, you should check to make sure. Use Procedure F-1 to verify this exists in the JACE-4/5s drivers.properties file.
Procedure F-1 Editing the drivers.properties file.
Step 1 Step 2
With the Admin Tool, open the JACE-4/5 host and select the Installation tab. Click Edit drivers.properties. The edit window for drivers.properties appears. Look for this line:
driver.mstp=tridium.nre.vxworks.mstp.VxWorksMstpDriver
Step 3
Step 4
If not present: a. Enter the line exactly as shown in Step 3, at the end of the file. b. From the edit windows menu bar, select File > Save. Close the edit window for drivers.properties. If you added this line, you need to reboot the JACE-4/5 for it to become effective. You may wish to do this as part of installing the bacnet module, if the JACE requires it as an addition or upgrade. If the JACE-4/5 already has the Niagara r2.3.5 release installed, including the bacnet module (and if a JACE-4 with I/O, the bacxNdio module), reboot the JACE now.
Step 5 Step 6
Installing the BACnet module
For any JACE-4 or JACE-5, you must install all needed modules. If the JACE-4/5 already has the same Niagara r2.3.5 NRE and bacnet module installed that you are using on your Web Supervisor/Niagara Engineering PC, you can skip this section. You may receive updated BACnet module files as: (for JACE-4 and JACE-5) bacnet-<release>.jar.nt (for JACE-NX, JACE-NP and Web Supervisor) You can follow this procedure to install all BACnet modules.
bacnet-<release>.jar.jace
Procedure 7 Installing the necessary Niagara modules.
Step 1
Make station backups of any existing stations to have modules installed or upgraded, saving databases to XML. For procedures, see the Niagara JDE Users Guide. On your Web Supervisor/Niagara engineering PC, copy the nt jar file to the Niagara modules subdirectory, for example, D:\niagara\<release>\nre\modules
Step 2
F5
Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes BACnet components available to the Supervisor PC and Local Library.
Step 3 Step 4
Close and restart the JDE to load updated module(s) on your PC. On your Web Supervisor/Niagara engineering PC, copy the nt jar file (again) to the Niagara subdirectory you use to store JACE-NX/NP modules, for example,
D:\niagara\<release>\nt
Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-NX or JACE-NP.
Step 5
On your Web Supervisor/Niagara engineering PC, copy the jace jar file to the Niagara subdirectory you use to store JACE-4/5 modules, for example,
D:\niagara\<release>\emb
Remove the .jace portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-4 or JACE-5.
Step 6
Using the Admin Tool, open the JACE-4/5 host and select Installation tab, Installation Wizard. In the Select Distribution Directory dialog box, select emb. Click Install. In the Niagara Remote Installation dialog box, click the radio button for Configure Modules Only. Click Next. In the Configure Modules dialog box, scroll down to find the row for the bacnet module and click in the Upgrade/Add column beside it. A red check mark appears besides bacnet module in Upgrade/Add.
Note
Step 10
If installing in a JACE-4, also select (upgrade/add) the bacxNdio module. This allows Ndio objects in the JACE-4 to be exposed as BACnet objects.
Click Next. In the Database Backup dialog box, select the database to be backed up. Enter a valid, administrative-level station user name and password. Click Next to continue. Click Finish.
Step 14 Step 15
In the summary dialog box, click OK to continue. A dialog box displays each task as it is performed. Typically, this process takes a couple of minutes. Step 16 When the installation is complete, click OK.
F6
Appendix F
Configure Essential MS/TP Link-Layer Properties

The BACnetService property sheet has four tabs that apply to MS/TP networks, BACnetMSTP, BACnetMSTP2, BACnetMSTP3, and BACnetMSTP4 (Figure F-2). Each MSTP tab has three sub-tabs: Status, Config, and Engineering.
Figure F-2 BACnetService property sheet, with 4 MSTP main tabs (currently apply only to JACE-4/5 station).
Four MSTP tabs. Each has three sub-tabs, Status, Config, and Engineering.
Note
When first configuring a station, you need to assign a unique device ID on the BACnet Services General, Config tab. This will be the JACE stations BACnet Device ID (identifier) across however many BACnet networks (link-layers) are enabled in the BACnet service. For BACnet/IP and BACnet/Ethernet configuration details, see the appropriate sections of this document. The following topics apply to initial BACnet MS/TP configuration:

BACnetMSTP tab Config properties Status properties Engineering property Remaining MSTP tabs RS-485 Port Guide Example MS/TP Configuration
F7
BACnetMSTP
For BACnet MS/TP, the first tab BACnetMSTP is always used, regardless of the total number of MS/TP networks (1, 2, 3, or 4). Each BACnetMSTP(N) tabs contain Config properties for that MS/TP network (and its separate polling mechanism). Global Config Properties (BACnetMSTP tab only) Config properties (for each BACnet MS/TP network)
Global Config Properties (BACnetMSTP tab only)

The first two properties on the BACnetMSTP, Config sub-tab apply globally for Niagara communications to all JACE-connected MS/TP networks.
Figure F-3 BACnetMSTP tab, Config properties.
Global properties mstpMaxMaster and mstpMaxInfoFrames are on the first (BACnetMSTP) tabs Config sub-tab.
All other Config properties apply only to that selected MS/TP networkmstpNEnable through mstpNpollDisabled
mstpMaxMaster: Specifies the highest allowable address for master nodes on the
network. The default (and highest) value is 127. Allowable range is from 1 to 127. Visible as a property of the stations Device object. Affects token-passing operation. If master devices (apart from the JACE) are MAC-addressed contiguously starting at 1, it may be best to set this to one-higher than the highest addressed master device.
mstpMaxInfoFrames: Specifies the maximum number of messages (frames) the
station will send before it passes the token. The default (and lowest) value is 1. Allowable range is from 1 to 100. Visible as a property of the stations Device object. Polling efficiency may be increased by setting this higher, say to 10. However, anything more than 2 may not actually increase efficiency, depending on how responsive the networked devices are. Communications using default values for mstpMaxMaster and mstpMaxInfoFrames are possible, but various configurations may be optimized with different values. In addition, equivalent settings in other devices may affect operation, and there may be advantages to reviewing the MAC address scheme for all networked devices. For related information, see Engineering Considerations for MS/TP, page F-13.
Note
F8
Appendix F
Config
Remaining properties on the BACnetMSTP Config tab apply to the first MS/TP network that you are configuring. Properties on remaining MSTP tabs (2, 3, and 4) are identical except for mstp number (N), such as mstp2Enable, mstp2Address, etc. Use the remaining MSTP tabs (in order) only if you have more than one MS/TP network, otherwise leave their properties at defaultsespecially mstpNEnable.
mstpNEnable: Used to enable /disable all communications to the MS/TP network, meaning the one connected to the RS-485 port associated with mstpNCommPort.
While set to False (default), no communications are attempted. If previously used, all shadow objects in the station associated with this network show Down (yellow).
mstpNNetworkNumber: The BACnet network number associated with devices on
this MS/TP network. Default values are 11, 22, 33, and 44 for BACnetMSTPN 14. The valid range is from 1 to 65534. Must be unique among all BACnet networks on the jobs BACnet internetwork. The JACE station acts as a router between this network and other BACnet networks (from other enabled link-layers in the BACnetService, for example). Consider all default values for network numbers as random, to which you must reassign accordinglyno duplicate BACnet network numbers (across all link-layers) should exist in the entire BACnet installation!
Note
mstpNAddress: The BACnet MAC address for the JACE-4/5 station, in decimal.
Default is 0. Valid range is 0 to 127 (BACnet range for master devices). Generally, it is recommended that you leave the mstpNAddress at 0, and also verify that no other MS/TP device on this network uses this same address. If there is ever a lost token, the device with the lowest MAC address regenerates the token, which in this case would be the JACE station. Exceptions to this advice may exist, see Exception Cases, page F-16.
Note
The MAC address of most other BACnet MS/TP devices on the network is likely set by an onboard DIP switch.
mstpNCommPort: JACE software comm port number for this network. Each
associates with a particular physical RS-485 port on the JACE-4 or JACE-5. Default value is COMN, (for example, mstp3CommPort=COM3), which is often not correct. See RS-485 Port Guide, page F-12. Consider all default values as placeholders, to which you must edit to the correct COMN value. Note that a valid RS-485 port is recommendedan RS-232 port with external RS-232 to RS-485 adapter can be used, but introduces another variable for possible issues.
Note
F9
mstpNBaudRate: Communications transmission speed for that network. Default
(all MSTP tabs) is baud_9600. Options are baud_19200, baud_38400, baud_76800. Must match comm rate of all other BACnet MS/TP devices on the network.
mstpNpollCycleTime: Target cycle time, in milliseconds, to complete one poll of
objects for that MS/TP network. Polled objects will not update any faster than this. Default is 5000 ms (5 seconds). Note that typically, a poll cycle will take much longer than thishowever, there is no harm in leaving the default value. Poll statistics for that MS/TP network (Status sub-tab) will show overruns and possibly late starts. After some run time, you may wish to adjust this upwardspossibly a value slightly greater than the mstpNaveragePollInterCycleDelay, shown on the Status tab for that MS/TP network.
mstpNpollDisplayDots: For debug mode. Default is False. If set to True, the
following characters are sent to Standard Output upon poll cycle competition. BAC MSTPN Poll (where N is 14, according to MS/TP trunk number)
mstpNpollDisabled: For debug mode. Default is False. While set to True, Niagara polling of the BACnet MS/TP network stops, and all polled values remain frozen. However, input writes and commands to client objects are still processed, devices on the network are still pinged for device status (providing deviceStatusDisabled =False), and server operations to devices are unaffected (much different than mstpNEnable).
Status
Each BACnetMSTP(N) tab has a Status sub-tab that shows current Niagara poll statistics for that MS/TP network (Figure F-4). Device and object counts also display.
Figure F-4 BACnetMSTP(N) Status tab.
The following read-only status properties are available:

mstpNpolledDeviceCount: Number of BACnetDevice objects associated with that MS/TP network. Note that even devices currently disabled for polling are included. This count is part of the total BACnet device count (bacnetDeviceCount, page 6-3). mstpNpolledObjectCount: Number of BACnet shadow objects currently in the poll list for that MS/TP network. If PollOnDemand containers are used, only objects that are currently being viewed (or that are in the view cache) are included.
F10
Appendix F
mstpNaveragePollExecuteTime: Average time, in seconds, accumulated for object
poll cycles. Equals the (mstpNtotalPollExecuteTime / mstpNtotalExecutionCycles).

Note
The BACnetServices command resetStatistics clears all accumulated count and time values to zero (0), and resets the mstpNpollStartTime. This applies to all BACnetMSTP(N) Status properties, plus equivalent main Poll, Status properties.
mstpNtotalPollExecuteTime: Total number of seconds for accumulated statistics. mstpNtotalExecutionCycles: Total number of accumulated poll cycles. mstpNpollOverruns: Accumulated number of times the poll cycle took longer than the configured mstpNpollCycleTime. Note this does not indicate a problem (all objects are polled), merely that the cycle time may be set too short. mstpNpollStartTime: Date and timestamp for the start of all accumulated statistics. mstpNaveragePollInterCycleDelay: Average time, in milliseconds, between successive starts of the poll cycle since statistics were accumulated. Provides a possible starting point for a target poll cycle time. mstpNpollLateStarts: Accumulated number of times the poll cycle has started later
than anticipated, going by the configured mstpNpollCycleTime.
Engineering
Each BACnetMSTP(N) tab has an Engineering tab with a single property:

mstpNpollDebug: For debug usage. Default is False. While set to True, each polled
object appears as a line in the stations Standard Output window, using the format:
BPxMy: polling object <objectName> {<object type>:<instance number>}
where x = MSTP trunk number (14) and y = polling thread number (01). For example:
BP1M1: polling object Space_Humidity {analog_value:102} BP1M0: polling object Microset_Room_Temp_ {analog_value:101} BP1M1: polling object Current_Heating_SP {analog_value:100} (and so on)
Note
Disable polling debug (pollDebug=False) unless you are investigating a particular poll-related problem. It adds system overhead and decreases overall throughput. BACnetService tabs BACnetMSTP2, 3, and 4 should be used only if that number of MS/TP trunks are licensed in the JACE-4/5 host. Use them in order. For example, if the JACE is licensed for 3 MS/TP trunks, use tabs BACnetMSTP, BACnetMSTP2, and BACnetMSTP3. Config properties on these remaining tabs are explained in the previous section, Config, page F-9. Properties on the Status and Engineering tabs are also explained in previous sections.
Remaining MSTP tabs
F11
RS-485 Port Guide
Table F-1 provides a hardware-to-software port guide for RS-485 ports on various JACE-4 and JACE-5 models. Use this to set the mstpNCommPort properties.
Table F-1 Hardware-to-software COM port guide.
JACE model
401, 403
Physical Port
RS-485 3-wire (no integral modem) RS-485 3-wire (has integral modem) RS-485 3-wire Port 1
mstpnCommPort
COM2 COM1 COM3 COM4 COM5 COM6 COM2 COM3 COM4
Notes
RJ-45 is RS-232 and is COM1, not recommended for usage. RS-232 RJ-45 port is unusable.
402, 4041
RS-485 3-wire Port 2 RS-485 3-wire Port 3 RS-485 3-wire Port 4
511 512
1.
RS-485 3-wire RS-485 3-wire Port 1 RS-485 3-wire Port 2
RS-232 Port 2 is unusable.
Be aware that while four (4) BACnet MS/TP networks are possible with some JACE models, performance may be slow depending on a number of factors.
Note
Using an RS-232 port with external RS-485 adapter is possible, but not recommended. Also, MS/TP trunk license limits still count (as if RS-485).
Example MS/TP Configuration
In this example, a JACE-512 is licensed for 2 BACnet MS/TP networks. The first network contains 30 MS/TP devices all communicating at 19.2Kb, and is attached to RS-485 port 1 on the JACE-512. The second network contains 12 devices communicating at 9600 baud, and is attached to RS-485 port 2 on the JACE-512. Across both networks, all devices are master devices, with each MAC-addressed contiguously (on their respective network) starting at address 1.
Table F-2 Example BACnet MS/TP configuration for JACE-512 with 2 MS/TP networks.
BACnetMSTP Property
mstpMaxMaster mstpMaxInfoFrames mstp1Enable mstp1NetworkNumber mstp1Address mstp1CommPort mstp1BaudRate mstp1pollCycleTime mstp1pollDisplayDots mstp1pollDiabled
BACnetMSTP2 Property
mstp2Enable mstp2NetworkNumber mstp2Address mstp2CommPort mstp2BaudRate mstp2pollCycleTime mstp2pollDisplayDots mstp2pollDiabled
Value
31 10 True 3 0 COM3 baud_19200 5000 False False
Value
True 4 0 COM4 baud_9600 5000 False False
F12
Appendix F
Niagara MS/TP Support Engineering Considerations for MS/TP
In this particular case, BACnet network numbers 1 and 2 are already in use by other BACnet link layers, but network numbers 3 and 4 were available. After configuring the BACnetMSTP tabs above and connecting the physical trunks to the JACEs RS-485 ports, a whoIs command is given from the stations BACnetUtility. Devices from both networks respond (all are master devices). If a learnNetwork command is given, BACnetDevice objects will be created in the BACnetTemp folder that reflect the assigned network numbers and whatever Device ID instance numbers have been assigned. Figure F-5 shows an example.
Figure F-5 BACnetTemp workspace after learnNetwork with MS/TP networks.
Engineering Considerations for MS/TP

The following engineering considerations apply to BACnet MS/TP in Niagara: Token Passing and Related Operation MS/TP Network Configuration Guidelines Recommended MS/TP Learn Tips Working with Slave Devices
Token Passing and Related Operation

BACnet MS/TP uses a token-passing scheme to control network access from devices. A single token is passed among master nodes (such as a JACE station), which allows each master node to initiate one or more messages (frames). Slave nodes do not receive the token, but both master and slave nodes transmit data frames in response to requests from master nodes. A master node may initiate a frame only when it holds the token. After sending at most max_info_frames, and waiting for any expected replies, a master node passes the token to the next (higher addressed) master node.
F13
Appendix F Engineering Considerations for MS/TP
When a request that expects a reply is sent to a node, the sender waits for the returned reply before passing the token. If the responding node is a master, it may return either the reply or a reply postponed frame. The latter means the node will reply later, when it receives the token. How This Affects Operation MS/TP Network Configuration Guidelines
How This Affects Operation
Typically you want the JACE station to be configured as the lowest-addressed master node, which by default, it is (mstpNAddress = 0). You also want other master devices to be MAC-addressed contiguously starting at 1, so that the highest-addressed master device is 31 (assuming all devices on the 31-maximum network are master devices). This promotes token-passing efficiency. Also, in the JACE station, you typically want a value for the property mstpMaxMaster, to be equal to the highest addressed master device (or perhaps highest addressed device + 1, where the + 1 will permit discovery of a new master device, if added). Again, assuming a maximum network of 31 master devices, this would mean an mstpMaxMaster value of 32. Also, you would want this same Max_Master property value (32) configured in the MS/TP device that is highest addressed, in this case, the device with address 31. This way, this device would not continue polling for a master all the way up to 127 before the token is finally given to the first master (address 0), typically the JACE station. Furthermore, increasing the property value of mstpMaxInfoFrames in the JACE station is not guaranteed to increase the number of polling values received each token hold, particularly with other master devices.
Dividing Network Scenarios

In a case where an existing BACnet MS/TP network of more than 31 devices (or whatever the effective maximum) needs to be integrated into Niagara, you must divide the network into groups of 31 devices or lesseach must be a separate network under the JACE (or, if another RS-485 port is not available, another JACE). When doing this, be aware that the Config property mstpMaxMaster is global to all connected MS/TP networks under a JACE (up to 4). If possible, try to put equal (or roughly) equal amounts of master devices on each network. The value of this property should be determined by the network with the most master devices.
MS/TP Network Configuration Guidelines

This section attempts to capture some of the important considerations in configuring a BACnet MS/TP trunk for use by Niagara. The performance of Niagaras BACnet MS/TP driver can be greatly affected by the configuration of the MSTP trunk. Information is divided into two sections: Things to Check Best Practices
F14
Appendix F
Note
Poorly-configured trunks can perform orders of magnitude more slowly than well-configured trunks. In addition, poorly-configured trunks can cause the Niagara learn mechanism to fail due to behavior of devices on the trunk. If possible, you should investigate the answers to the following questions:
1.
Things to Check
Is the Max_Master property of the BACnet device(s) on the trunk configurable? Determine this by opening the property sheet of the BACnetDevice object to the Engineering tab, and changing the value of the maxMaster property. When applied, this change is written to the device. If the device accepts the write, the value will remain the same. If not, the value will revert to the previous value. Also, note that it may be necessary for you to clear the JDEs view cache before confirming thistypically 6 new JDE views (displays) are required.
2.
How many Master devices are on the network? Only master devices can initiate BACnet messages. Slave devices can only respond to requests. If an MS/TP device does not respond to a Who-Is with an I-Am, it is likely a slave device. The device vendors documentation should indicate whether it is a master or slave, or if this is configurable.
3.
How quickly does the token cycle around the devices? The best way to measure this is with an MS/TP trunk analyzer. Outside of this, (if necessary) you can roughly measure by performing the following:
a. Set the JACE stations BACnet MS/TP MAC address (mstpNAddress) to
be the highest of all devices on that trunk.

b. Disable all BACnet polling and device status ping (done through service
properties mstpNpollDisabled, pollDisabled, deviceStatusDisabled), and also disable any other BACnet writes.
c. Observe the orange/yellow and green LEDs for the JACE RS-485 port.
The green (receive) LED should be blinking almost constantly. The orange/yellow (transmit) LED should blink once per token cycle, as we pass the token on to our next peer. This should be the regular frequency. Typical token pass times are around 20ms for each device, so by multiplying the number of Master devices, you can calculate an approximate prediction for the token cycle time.
4.
How stable is the token passing on the network? Are there frequent instances of lost or duplicated tokens? Typically, this is most likely if there are different vendors devices on the same MS/TP trunk, but it can also occur with a completely homogeneous trunk. The occurrence of token-passing errors is best detected by using an MS/TP analyzer. Outside of this, a simple estimate whether things are okay can be made (again) observing JACE RS-485 port status LEDs, with the address set as before (1.a).
F15
If the token cycle is regular, the orange/yellow (transmit) LED will flash at the token cycle frequency. When there is a token-passing error, the flash pattern of the transmit LED (and possibly the receive LED) will change. With the JACE at the highest MAC address, it may go long periods without ever receiving the token, so the transmit LED might not flash for a while. This would be a strong indication that there are some type of token-passing errors.
Best Practices
In general, you should follow these practices:

1.
Whenever possible, BACnet MS/TP trunks should contain only devices from one vendor. This is simply a recommendation to reduce the likelihood of incompatibility between different vendors implementation of BACnet MS/TP. All MS/TP master devices should be MAC addressed consecutively starting at zero (0). For optimum performance, there should not be any gaps between MAC addresses, as these gap addresses will be scanned for the existence of newly added master nodes. Token problems can occur during this poll for master sequence, because devices are waiting for a full timeout for a response from a potential device, and other devices might jump in. The JACE station should be at MAC address zero (0), property mstpNAddress. This allows the JACE to be the first device to recover a lost token. In the presence of token-passing errors, it also allows the JACE to be more likely to remain in the token-passing loop during the bus-recovery process. The highest master node should have its Max_Master property set to the highest master node address possible on the network. This will be equal to that nodes MAC address. If you will be potentially adding devices to the trunk, it may be desirable to set the Max_Master property a few numbers (or one) higher than its address, to allow for easy discovery of a new device as when added. However, leaving the Max_Master set at 127 (default for most MS/TP devices) will slow token passing, as this node will periodically scan all addresses up to Max_Master for the existence of a newly added Master node.
2.
3.
4.
Exception CasesCertain exception cases may exist, where it might be better to configure the network differently. If other BACnet MS/TP devices do not allow configuration of the Max_Master property, it may be better to put the JACE station at the highest address. The JACEs Max_Master property is configurable, and can be set to its own address to truncate the scan range for new master nodes. Do this only if the token-passing is stable. If the JACE station is at the high end of the address range on an unstable trunk, it may be periodically excluded from the token passing whenever bus instabilities occur. This can cause data loss in polling, nuisance device status alarms, and can cause network and device learns to fail prematurely.
Caution
F16
Appendix F
Recommended MS/TP Learn Tips

Because BACnet MS/TP communications are typically much slower than with Ethernet-connected BACnet devices, it may be worthwhile to note the following when initially learning BACnet MS/TP devices:
1.
If learning multiple networks (to create BACnetDevice objects), it may be best to enable only one BACnetService link-layer tab at a time. This will not prevent devices on remote networks from being learned, but it will isolate only those devices on the one local network. You can then cut and paste (or move) those learned devices to another container you have specially made to group devices by network (before you start using the learnDevice command). Also, the instance limits option in a learnNetwork may also be useful to isolate devices on a particular network, providing some Device-object instance numbering scheme was used.
2.
When using the learnNetwork command, leave the Learn device contents option cleared (default). This advice generally applies to all BACnet link-layer types, but especially so for MS/TP networks. After you learn the master devices (containers) with this command, you can more selectively learn the types of child objects in each device with the learnDevice command, including instance limits to select object types and/or instance number ranges. Note that your entered limits remain effective during the JDE session, so if desired, you can learn all of the devices the same way. Be aware that slave devices cannot be discovered with learnNetwork or whoIs. See the next section Working with Slave Devices.
3.
When using the learnDevice command, the option Use lite objects is often the best choice for most BACnet MS/TP devices. Typically, these are simple devices, and objects in them are implemented without optional properties. Find out for a specific object type by manually copying a full child object in the workspace of the BACnetDevice, setting its instance number, and then performing an upload (from the property sheet of the object, select from the menu bar: Commands > upload). For example, you could do this for a BACnetBinaryInput object set to Instance Number 1. After the object upload, expand the status bar to see the Status Line History window, where you can look for Read failed...unknown property entries for alarm-related properties (or for a binary object, activeText and inactiveText).
4.
If there are identically-configured devices, you can learn the contents of one device (as needed using the learnDevice command), and then copy-and-paste the contents (Select All in the Workspace Editor) into a like learned (but still empty) device. After pasting in copied contents, issue an uploadAll command at the BACnetDevice to ensure child objects have current values. Alternatively, you can just copy and paste an entire learned BACnetDevice container. However, with this method you then need to re-enter proper device address values (only device ID Instance Number if a master device, upon applying it should receive network number and MAC address automatically).
F17
Then for the copied BACnetDevice object, in addition to issuing an uploadAll command, you would also want to rename it.
Working with Slave Devices

BACnet MS/TP slave devices do not respond to broadcast messages such as Who-Is, therefore they cannot be discovered by the BACnetUtilitys whoIs and learnNetwork commands. You must manually add a BACnetDevice object for each slave device. When adding a BACnetDevice object for a slave, you must know three things:
1. 2. 3.
Its unique Device object identifier (Instance Number). Its network number (should correspond to the mstpnNetworkNumber). Its MAC address, in hexadecimal. (If you know its address in decimal, you can simply use the Windows calculator to convert to hex.) Device object instance number of 173. Network number 4 (example, from assignment for mstp2NetworkNumber). MAC address 162 decimal (A2 in hex).
For example, on your second MS/TP network you have a slave device as follows:
After copying a BACnetDevice object from the Local Library into your station (or a copy of another BACnetDevice object, even for a slave device previously learned), open its property sheet to the Config tab and enter these values (Figure F-6).
Figure F-6 Enter Device instance number, network number, and MAC address (in hex).
After applying these values, with this property sheet still displayed, select from the menu bar Commands > upload. This should upload other properties from the slave device, such as vendorName and modelName (Figure F-7).
F18
Appendix F
Figure F-7
Verify slave device object by seeing other Device object properties uploaded.
This verifies communication to the slave device. You can now select the device in the BACnetUtility to perform a learnDevice command, to automatically create child shadow objects in the station database.
F19
F20
INDEX
A
abbreviations, BACnet objects 3-16 Abort button, in learn 1-17, 2-2, 2-8 Acknowledged Transitions 2-14, 3-21 Alarm State 2-14 Alarms BACnet device (service type) 6-15 generating BACnet 5-1 receiving BACnet 5-7 AnalogInput shadow object 3-26 to 3-29 AnalogOutput shadow object 3-30 to 3-32 AnalogValue shadow object 3-33 to 3-34 AnalogValuePriority shadow object 3-35 to 3-37 APDU properties BACnetDevice 3-10 station 6-4 ASHRAE xii, xiv
commands 6-22 Debug properties 6-24, A-6 DeviceStatus properties 6-16 General properties 6-3 Poll properties 6-12 BACnet user (allowing write access) 4-8 BACnet workstation 1-7 bacnet.properties file 6-28 editing 6-29 read command 6-23 BACnet/Ethernet xii, 6-22 BACnet/IP xii, 1-11, 6-18 BACnetDevice object 1-18, 2-15, 3-5 to 3-14 useCOV 3-14 BACnetService commands 6-22 property sheet 6-1 to 6-27 BACnetTemp 1-18, 2-6, 2-13 BACnetUtility 1-16, 2-1 to 2-14 action buttons 2-2
B
BACnet xii BACnet client xii, 3-1 to 3-48 BACnet log objects 4-3, 4-9 to 4-12 collection time differences 4-11 BACnet MS/TP xii, F-1 to F-19 BACnet router 1-4, 1-15, 6-5 BACnet server xii, 4-1 to 4-9 BACnet service (Niagara) xii, 6-1 to 6-30 BACnet/Ethernet properties 6-22 BACnet/IP properties 6-18
getAlarmSummary command 2-13 learnDevice command 2-9 learnNetwork command 1-16, 2-6 opening 2-1 output options 2-2 status line history 2-2 whoHas command 2-5 whoIs command 2-3 bacnetx modules D-1 bacxNdio D-2 bacxNotifier D-3 BBMD xii, 1-6, 1-12, 6-19, 6-20, 6-21, E-3 to E-7
Index-1
Index
broadcast distribution table 6-20, E-4 configuration tips E-5 foreign device table 6-21, E-4 in network diagrams E-9, E-10 remote address 1-13, 6-19 BinaryInput shadow object 3-38 to 3-39 BinaryOutput shadow object 3-40 to 3-42 BinaryValue shadow object 3-43 to 3-44 BinaryValuePriority shadow object 3-45 to 3-47
readProperty 3-17 readPropertyMultiple 3-17 upload 3-17 BACnet service 6-22 BACnetDevice object disablePolling 3-7 downloadAll 3-7 enablePolling 3-7 fetch 3-7 getAlarmSummary 3-7 readProperty 3-7
C
cache, View 6-11 calculating poll cycle time 6-11 child objects xiii, 2-6, 3-15 to 3-24 AnalogInput 3-26 AnalogOutput 3-30 AnalogValue 3-33 AnalogValuePriority 3-35 BinaryInput 3-38 BinaryOutput 3-40 BinaryValue 3-43 BinaryValuePriority 3-45 MultistateInput 3-48 MultistateOutput 3-51 MultistateValue 3-54 MultistateValuePriority 3-56 NotifierBinaryValue D-4 writable input types 3-3 client xii clientDebugOn 6-26 color of objects and outputs A-2 commands BACnet child object download 3-17 fetch 3-17 pollRenew 3-17
readPropertyMultiple 3-7 upload 3-7 uploadAll 3-7 Common properties for child objects 3-20 Commonly Used Terms xii communications link layer C-2 troubleshooting A-1, D-3, E-9, E-10 verifying 1-13 confirmed COV 1-5 conformance, BACnet PICS B-1 COV 1-5, 3-16, 6-8, 6-10, 6-12 strategy notes 3-19 subscribing objects 3-18 cyan object color A-4 cycleTime property 6-14
D
Debug, using A-6 description property 3-20 device adapter name Windows 2000 C-4 Windows NT C-3 Device object xiii Device Status/Ping 3-23, 6-15 disablePolling command 3-7
Index-2
Index
displayDots property 6-14, 6-17, A-6, F-10 download command 3-17 downloadAll command 3-7 driver.properties 1-12, C-3, C-4, C-5 drivers.properties F-5 dumpIPTable command 6-23
I-Have message 2-5 inAlarm A-3 instance limits xiii, 2-10, 2-11, 2-13 Instance number 3-5, 3-16, 4-3 internetwork xiii, 1-4, 1-7, 1-14, 2-8, 3-8, 6-18, 6-22, E-1 to
E-8
IP 1-11, C-5
E
enablePolling 1-19, 2-6, 2-15 enablePolling command 3-7 endTime property 4-11, 4-12 error messages 6-25 Ethernet link layer PC setup C-2 eventEnable property 3-22 eventState property 3-21, D-4 extensions bacxNotifier D-3 Ndio D-2 extensions, bacnetx D-1
J
JACE-4 F-1 Ndio objects D-2 JACE-5 F-1 JDE xiii
L
learnDevice 2-9 Learning a BACnet network 1-15 learnNetwork 1-16, 2-6 license A-1, D-1 for MS/TP in JACE-4/5 F-4 link layer C-2
F
fault A-3 fetch command 3-2, 3-7, 3-17 foreign device 1-12, 6-19, 6-21, E-4, E-6 foreignAddress property 4-3, 4-5, D-2 full objects xiii, 3-3
linkDebugOn 6-26, 6-27 Lite objects xiii, 2-6, 2-10, 3-3 tip for usage 3-3, F-17 Local Library 2-15, 3-4, F-18 log objects, BACnet 4-3, 4-9 to 4-12
M G
getAlarmSummary 2-13, 3-7 MAC address 1-13, 3-8, F-9, F-18 manually adding BACnet shadow objects 2-14, 3-4, F-18 MS/TP F-1 to F-19 configuration guidelines F-14
I
I-Am message 2-4
JACE preparation F-3 licensing F-4
Index-3
Index
Niagara overview F-1 properties F-7 slave devices F-18 token passing F-13 mstpMaxInfoFrames property F-8, F-14 mstpMaxMaster property F-8, F-14 Multistate object notes 3-24 MultistateInput shadow object 3-48 to 3-50 MultistateOutput shadow object 3-51 to 3-53 MultistateValue shadow object 3-54 to 3-55 MultistateValuePriority shadow object 3-56 to 3-58
P
PC notes C-1 to C-5 PICS, BACnet B-1 ping mechanism 6-15 Poll Scheduler 6-9 Polling 3-2 calculating cycle time 6-11 MS/TP F-10 troubleshooting A-2 PollOnDemand 1-6, 1-8, 6-10 pollRenew command 3-17
N
name 2-5, 2-14, 4-7 Ndio 4-7, D-2 network number, about E-1 networkDebugOn 6-26 notificationClass property 3-22, 6-16 Notifier D-3 NotifierBinaryValue object D-4 notifyType property 3-22
presentValue property 3-2, 3-21 priorityArray property 3-2 property sheet, showing polled values 6-9 Protocol Implementation Conformance Statement B-1
R
readBACnetPropertiesFile command 6-23 readProperty command 3-7, 3-17 readPropertyMultiple command 3-7, 3-17 readPropertyMultipleSupported 3-10, 3-13, 3-14
O
object identifier, object ID xiii, 2-5, 2-14, 2-16 object name 2-5, 2-14, 4-7 Object status A-2 objectIdentifier property 3-21 objectName property 3-21 objectType property 3-20 on_demand_transient properties 3-2 one-hop (BBMD) E-4 orange object color A-3 outOfService 1-19, A-4 outOfService property 3-21
red object color A-3 reliability property 3-21 resetStatistics command 6-23 rewriteDelay property 3-25, 6-8 routers BACnet 1-4, 1-15, 6-5, E-2, E-7 IP (TCP/IP) E-4, E-9 routingEnabled property 6-3 RS-485 F-1 JACE port guide F-12
S
server xii
Index-4
Index
serverDebugOn 6-26 shadow objects xiii, 2-14, 3-1 shape information BACnet log objects 4-11 BACnet shadow (child) objects 3-16 BACnetDevice objects 3-5 slave MS/TP devices F-18 Standard Output 6-24, A-6 startTime property 4-11, 4-12 status device status/ping 6-16 of object 3-20, A-2 polling 6-13 service 6-3 statusFlags property 3-2, 3-20 SubscribeCOV 1-5, 6-12 strategy notes 3-19 subscribing objects 3-18 systemStatus 3-6, 3-8
communications A-1, D-2, E-7 debug and Standard Output A-6 object color A-2 polling A-2 two-hop (BBMD) E-4
U
UDP port 1-12, 1-13, 6-19 unsubscribing objects from COV 3-18 upload 2-15, 2-16 upload command 3-2, 3-7, 3-17 uploadAll command 3-7 UserAdmin, BACnet user 4-8 UTC 1-6, 6-8
V
verifying BACnet communications 1-13
T
table BACnet routers 6-5 broadcast distribution (BBMD) 6-20 foreign device (BBMD) 6-21 time synchronization 1-6, 6-8 timeDelay property 3-22 timeout messages 6-25 token passing, MSTP F-13 Trend Log object 4-9, 4-10 tridiumx folder 2-15, 2-16 Troubleshooting A-1 to A-7
W
Warning messages 6-24 whoHas 2-5 whoIs 2-3, 2-15, 6-7 writable input objects 3-3 write access 4-8 writePropertyEnabled 1-19, 3-10, 3-13, 3-14 writePropertyMultipleSupported 3-14
Y
yellow object color A-5
Index-5
Index
Index-6
You can help make this manual even better!

Please help us make our documentation as useful as possible. Use this form to advise us of errors, descriptions that are not clear, or provide any other helpful information. Mail this form to: Tridium, Inc. 3951 Westerre Parkway, Suite 350 Richmond, Virginia 23233 Attention: Tridium Documentation Team Or fax it to us at: (804) 747-5204 Or e-mail your comments to us at: documentation@tridium.com Thank you for taking the time to help us improve our documentation!
Documentation Comment Form

Document Title: Document Version:
BACnet Integration Reference Niagara Release 2.3.5
Page #
Problem Found or Suggested Change
Your Name: Your Company:

Bacne T Integration Ref

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bacne T Integration Ref

Uploaded by

Copyright:

Available Formats

Technical Publications

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

ix ix x x xi xi xii xiv xiv

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

5-1 5-1 5-2 5-3 5-5 5-7 5-8 5-8

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

6-24 6-24 6-25 6-28 6-29

A-1 A-1 A-2 A-2 A-6 A-7

C-1 C-1 C-2 C-2 C-3 C-5

Niagara bacnetx Modules

D-1 D-1 D-2 D-2 D-3 D-3 D-4

Internetworks and BACnet/IP

E-1 E-1 E-2 E-2 E-3 E-3

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

About BBMDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niagara BBMD Configuration Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Internetwork Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E-3 E-5 E-7

Niagara MS/TP Support

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

About This Document

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Preface Prerequisite Knowledge

About This Document

About This Document Formatting Conventions

Important Information Indicators

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Preface Commonly Used Terms

About This Document

Commonly Used Terms

BACnet service (Niagara) BBMD

BACnet/Ethernet or B/Eth BACnet/IP or B/IP

About This Document Commonly Used Terms

COV device object, Device object

object identifier, (object ID) shadow object

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Preface Related Documentation

About This Document

Supported BACnet Features

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Chapter 1 Supported BACnet Features

Client Support (Shadow Objects)

AnalogInput1 AnalogOutput AnalogValue AnalogValue (priority)

BinaryInput1 BinaryOutput BinaryValue BinaryValue (priority)

MultistateInput1 MultistateOutput MultistateValue MultistateValue (priority)

Getting Started Supported BACnet Features

Exposing Objects (Server Support)

AnalogInput (AI) AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)

Calendar Schedule MultistateInput (MSI) MultistateOutput (MSO)

Exposing Niagara Logs

BACnetAnalogLog BACnetBinaryLog BACnetIntegerLog BACnetMultistateLog BACnetStringLog

Server Support for BACnet Services