EZ Gateway KNX to BACnet (1,000 point)

The EZ Gateway KNX to BACnet (FS-EZX-KNX-BAC) is an easy-to-use, high-performance building and industrial automation protocol gateway for integrators to interface KNX certified products to BACnet management systems in commercial buildings, campuses, and industrial facilities. KNX-certified products encompass a wide range of applications such as lighting control, heating, ventilation and air conditioning control, shutter/blind and shading control, alarm monitoring, energy, gas, and water metering, and audio and video distribution. The EZ Gateway KNX to BACnet integrates such KNX-based devices and systems to BACnet-based management systems over BACnet MS/TP or BACnet/IP protocols.

The EZ Gateway KNX to BACnet combines field-hardened KNX and BACnet protocol drivers with an easy to use configuration interface. The EZ Gateway’s KNX interface is compatible with all KNX-certified products, while the EZ Gateway’s BACnet interface has been certified by BACnet Test Laboratory (BTL), at Version 12. The intuitive web-based interface allows configurations to be built in the field or in the office, thereby simplifying the commissioning and integration process.

Sierra Monitor’s unique FieldServer DeviceProxy™ feature allows each KNX device to be presented as a corresponding virtual BACnet device within the EZ Gateway, thereby providing granular visibility and control over each KNX device from within a BACnet management framework. For example, offline/online status is visible at the individual KNX device.

With the EZ Gateway KNX to BACnet, the integrator or contractor does not need to be a protocol expert and can minimize configuration and commissioning time, while also reducing ongoing operating and maintenance costs.  

The BACnet/IP driver allows the FieldServer to transfer data to and from devices over Ethernet using BACnet/IP protocol. The FieldServer can emulate either a Server or Client.

All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability.

BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.

Every BACnet device must have a Device Object, which provides details about the device and its functionalities to other networked devices. Before engaging in control communications, a BACnet device must acquire pertinent information from the Device Object of the target device. Unlike other Objects, the Instance number of the Device Object must be unique across the entire BACnet internetwork, serving as the device's distinct identifier. This uniqueness facilitates easy identification of the BACnet device during installation and operation.

Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input. See Appendix D.1 for abbreviation list.

Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties.

The BACnet Master-Slave/Token-Passing (MS/TP) driver implements a data link protocol that uses the services of the RS-485 physical layer. See the FieldServer BACnet PIC statement for the level of conformance that this driver implements.

All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability. BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.

BACnet requires one Device Object to be present in every BACnet device. The Device Object makes information about the device and its capabilities available to other devices on the networks. Before one BACnet device starts control-related communications with another, it needs to obtain some of the information presented by the other device's Device Object. Unlike other Objects, the Device Object's Instance number must be unique across the entire BACnet internetwork because it is used to uniquely identify the BACnet devices. It may be used to conveniently identify the BACnet device from other devices during installation.

Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input.

Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties. The Analog Input Object is representative of the Objects involved directly with control elements and many of its Properties reflect this.

The KNX driver allows the FieldServer to transfer data to and from devices using KNX protocol. The Fieldbus connection is included with the FieldServer. The FieldServer can emulate a Passive Client.

The KNX driver enables data access from KNX networks to other FieldServer protocols. Most KNX data point types are supported, allowing communication to almost any kind of KNX device in the installation, such as temperature sensors, shutters, light switches, actuators, alarms etc. This allows BMS systems to access a KNX network using direct read and write of KNX configured groups. This setup does not require the use of ETS4 to configure the QuickServer KNX gateway.

The KNX protocol is a connectionless protocol and therefore supports multiple clients and multiple servers.

The QuickServer is intended to act as a Passive Client on the KNX bus and make information available to other protocols.