BACnet Protocol Adapter
This section presents the capabilities and configuration options of the BACnet Protocol Adapter, which translates the BACnet communication protocol into objects understandable by the Gateway Agent.
For a step-by-step guide on how to install the BACnet Protocol Adapter, see the Installation Guide.
Configuring the BACnet Protocol Adapter
There are two configuration files of the BACnet Protocol Adapter:
Deployment configuration file - Configuration of the MQTT connection, PMQ connection and health monitoring.
Application configuration file - Configuration of connections, global adapter properties and device data (measurements, alerts, configuration parameters and metadata).
When you modify the BACnet Protocol Adapter configuration, restart the adapter to apply the changes by means of the following command:
systemctl restart gwa-bacnet-adapter-c
The adapter configuration is then updated.
For an example of the BACnet Protocol Adapter configuration files, see here.
Deployment Configuration File
The deployment configuration file of the BACnet Protocol Adapter is located at:
/etc/relayr/gwa-bacnet-adapter-c/gwa-bacnet-adapter-config.json
To modify the file, edit it in a text editor.
The following configuration settings are available:
transport
- Communication channel used by the adapter. Available options:mqtt
orpmq
. By default,mqtt
.mqtt_connection
- Connection settings of the MQTT message broker:
Configuration Setting | Description | Default Value |
---|---|---|
host | IP address of the MQTT message broker. | localhost |
port | Port number for connecting to the MQTT broker. | 1883 |
keepalive | Keepalive value of the MQTT connection. | 20 |
max_inflight_messages | Maximum number of QoS 1 or 2 messages that can be in the process of being transmitted simultaneously. This includes messages currently going through handshakes and messages that are being retried. If set to 1 , it guarantees an in-order delivery of messages. | 100 |
qos_levels | Quality of Service level for each traffic type. | measurements: 0 , alerts: 1 . configuration: 1 , metadata: 1 |
health_monitor
- Health monitoring settings:
Configuration Setting | Description | Default Value |
---|---|---|
heartbeat_interval | Time interval at which the periodic heartbeat messages are sent, given in seconds. | 60 |
pmq_connection
- Configuration of the High Speed Bus (PMQ) connection. Configure this section to use thepmq
transport
:
Configuration Setting | Description | Default Value |
---|---|---|
output_queues | List of output PMQ queues, where the adapter reports all data, except for health monitoring messages, which are always reported via MQTT. Queue names must begin with / . | ["/bacnet_out_queue"] |
input_queues | List of PMQ queues to monitor for inbound messages, e.g. configuration update tasks. Queue names must begin with / . | ["/bacnet_in_queue"] |
message_size | Maximum size of a PMQ message, given in bytes. | 8192 |
message_count | Maximum number of messages in a PMQ queue. | 10 |
For an example of the deployment configuration file, see here.
Application Configuration File
The application configuration file of the BACnet Protocol Adapter is located at:
/etc/relayr/gwa-bacnet-adapter-c/gwa-bacnet-adapter-application-config.json
If you have the Configuration Manager installed, it becomes the primary way of editing application configuration files. If you do not have the Configuration Manager, edit the application configuration file in a text editor.
See sections below for information on:
Connections – List of connections to devices.
Global Adapter Properties – Configuration of a global sampling interval and a custom prefix.
Devices - List of connected devices and their measurements, alerts, configuration parameters and metadata.
For an example of the application configuration file, see here.
Configuring BACnet Connections
The connections
section of the configuration file allows you to define a list of device connections with the following configuration options:
Configuration Setting | Description |
---|---|
id | Unique connection identifier, which is then used to identify a device connection. See the Configuring a Device Connection section for more information. |
dev_id | BACnet device ID in the local network. |
Here is an example of the connections
configuration:
"connections":
[
{
"id": "conn_1",
"dev_id": 866018
}
],
Global Adapter Properties
You can configure the following global settings that refer to the whole Protocol Adapter configuration:
Configuring Sampling Interval
The sampling interval determines how often the Agent gathers data from devices. It is a global setting that refers to retrieving data from all the connected devices.
The interval value is defined in milliseconds:
"sampling_interval" : 4000
Optionally, you can also define a local sampling interval for each object defined in the devices
section of the configuration file. In such a case, a local sampling interval overrides the global one.
The global sampling interval is set to
4000
and the sampling interval for a temperature measurement object is2000
, so the Agent retrieves data about this temperature object every two seconds.
If you configure a local sampling interval for each object defined in the
devices
section, you do not need to configure a global sampling interval. However, if at least one object has no local sampling interval defined, the global one must be provided. Otherwise, the adapter configuration is invalid.
Configuring Custom Prefix
The custom prefix determines where to report data. If not defined, all data is reported to v1/sb
, by default.
The custom_prefix
option enables setting a different prefix to publish data e.g. to a custom MQTT topic for local data processing, or directly to the Gateway Agent northbound interface.
It is a global setting that refers to all data retrieved from devices.
Example:
"custom_prefix": "v1/nb"
Optionally, you can also define a local custom prefix for each measurement, alert, configuration parameter and metadata configured in the devices section of the configuration file. In such a case, a local custom prefix overrides the global one.
Instead of the
custom_prefix
option, you can also use thecustom_mqtt_prefix
option, which was implemented in the older adapter versions. However, it is recommended to usecustom_prefix
.
Configuring a List of Devices
In the devices
section of the configuration file, you can configure a list of devices. For each device, the following configuration sections are available:
connection - Selecting a device connection.
measurements - List of measurements that can be reported by a device.
alerts - List of alerts that can be reported by a device.
configuration - Configuration parameters of a device.
metadata - List of metadata of a device.
The devices
section has the following structure:
"devices" :
[
{
"connection" : { ... },
"measurements" : [ ... ],
"alerts" : [ ... ],
"configuration" : [ ... ],
"metadata" : [ ... ]
}
]
Configuring a Device Connection
In the connection.id
field, enter the connection identifier for a given device. Possible ID values are defined in the connections
section of the configuration file. See the Configuring BACnet Connections section for details.
It is mandatory to configure a connection ID for each device.
Here is an example of the device connection configuration:
"devices": [
{
"connection": {
"id": "dev"
},
You can also configure a local connection ID for a specific measurement, alert, configuration parameter and metadata. If defined, the local connection ID overrides the global one, set in the
connection.id
field.
Configuring Measurements
You can define multiple measurements for a device, such as: temperature, humidity, pressure, etc.
To configure a measurement, define the following mandatory settings:
Configuration Setting | Description |
---|---|
id | Measurement identifier. A value provided here must match the measurement ID set in the device model version created in the relayr Cloud. For more information on creating device models and versions in the relayr Cloud, refer to the relayr Cloud API documentation. |
object | Protocol-specific object definition. See the BACnet Object Definition section for details. |
Optionally, you can define the following advanced settings for a measurement:
Configuration Setting | Description |
---|---|
filters.cov | Change of value functionality. If it is set to enabled , measurements are reported by a device only if their value differs from the latest reported value by at least a cov_delta value. |
filters.cov_delta | Delta for the change of value functionality. It specifies the minimum change of value (in relation to the latest reported value) that is required to report the measurement to the Agent. |
sampling_interval | Local sampling interval value, given in milliseconds, that overrides the global sampling interval. |
custom_prefix | Prefix of the MQTT topic that the object is reported to. An option to publish data to a custom MQTT topic for a local data processing or directly to the northbound interface. For example, if it is set to analytics for a temperature measurement, all data is published to the topic analytics/{did}/measurements/temperature . It overrides the global custom prefix. |
connection | Local connection ID used for a given measurement. It overrides the global connection set for the device. Possible ID values are defined in the connections section of the configuration file. See the Configuring BACnet Connections section for details. |
complex | Add this configuration section to configure a complex measurement. Specify how many data samples a complex measurement contains and, optionally, a collection_interval . For more information, see the Configuring Complex Measurements section. |
Here is an example of the measurement configuration:
{
"id" : "temperature",
"object" : { ... },
"sampling_interval" : 4000,
"filters" : {
"cov" : "enabled",
"cov_delta" : 0.04
}
},
In the example presented above, the temperature reading is reported by the device every four seconds (as defined in the
sampling_interval
field). The change of value (cov
) is enabled, and thecov_delta
is set to0.04
. It means that the temperature is reported only if it is different from the latest reported value by at least0.04
.
Configuring Complex Measurements
A complex measurement is a batch of measurement data, in which several samples of collected data values are published as a single message.
Complex measurements can be consumed by the Rule Engine and the GWA Analytics for further data processing and can be stored in the Storage Service. The Cloud Adapter supports publishing complex measurements to the relayr Cloud.
You can configure the size of a complex measurement by specifying how many data samples each batch contains. Optionally, you can also specify a collection interval. If specified, the adapter starts collecting data at every collection interval (e.g. 1h) and publishes a complex measurement when a configured number of samples are collected (e.g. 1000). Then, the adapter waits for the next collection interval and starts to acquire data again.
To configure a complex measurement, add the complex
section to the measurement configuration with the following settings:
Configuration Setting | Description |
---|---|
samples | Number of collected data samples in a complex measurement. For complex measurements, this setting is mandatory. |
collection_interval | Optional setting. Time interval, given in seconds, at which the adapter starts to acquire data for a complex measurement. |
Example:
{
"object": {},
"complex":
{
"samples": 10,
"collection_interval": 3600
}
}
If the
collection_interval
is lower than needed to collect the configured number of samples, the adapter collects data continuously. It starts to acquire data immediately after publishing the previous complex measurement.
If sensors stop sending data in the middle of data collection, e.g. due to connectivity problems, the adapter waits until the required number of samples are collected, despite the collection intervals. It publishes a complex measurement that contains data points not evenly distributed in time, e.g. with a 5h gap. Such a complex measurement may be considered as incorrect and may be discarded by the Rule Engine and/or the GWA Analytics, based on the
startTs
andendTs
values.
Complex Measurement Message
The collected data samples of a configured complex measurement are published as a complex measurement message. The Protocol Adapters support acquiring and publishing complex measurements in the time domain, but you can also use complex measurement messages to publish measurements in other domains, e.g. the frequency domain.
Complex measurements in the frequency domain may be reported by the Pico Adapter, or you may use the Rule Engine or the GWA Analytics to calculate them from the time-based measurements.
In a complex measurement message:
startTs
is a moment when data acquisition begins.endTs
is a moment when data acquisition finishes.xStart
is the first value on the X axis. ThexStart
unit depends on the measured value. For measurements in the time domain, it is a timestamp indicating the moment when the first data sample is collected. For measurements in the frequency domain, it is the first frequency on the X axis.xStep
represents a resolution of data on the X axis. For measurements in the time domain,xStep
is a time interval between consecutive data samples, given in milliseconds (you configure this interval in thesampling_interval
setting of the Protocol Adapters' configuration). ThexStep
value allows you to know the precise moment when each data sample was collected. For measurements in the frequency domain,xStep
represents the frequency resolution of data representation on the X axis.yValues
is an array of ordered measurement values.
Example 1: time-based measurement:
v1/sb/{UUID}/complex_measurements/temperature {
“id”:“temperature”,
“startTs”: 1492515087123,
“endTs”: 1492515092123,
“xStart”: 1492515087123,
“xStep”: 1000,
“yValues”: [42, 43, 39, 37, 40, 48, 45, 40, 38, 33, 30, 31...]
}
In this example,
temperature
is a time-based measurement. ThexStart
value is1492515087123
, which shows the moment when the first data sample (42
) was collected. ThexStep
value is1000
, which means that consecutive data samples were collected at the interval of 1000 milliseconds.
Example 2: frequency-based measurement:
v1/sb/{UUID}/complex_measurements/acceleration_xaxis_fft {
“id”:“acceleration_xaxis_fft”,
“startTs”: 1492515087123,
“endTs”: 1492515092123,
“xStart”: 90,
“xStep”: 10,
“yValues”: [3, 12, 48, 579, 644, 689, 711, 647, 78, 644, 669, 112, 638, 652, 617, 48...]
}
In this example,
acceleration_xaxis_fft
is a frequency-based measurement. ThexStart
value is90
, which shows that the first frequency on the X axis is 90 Hz. ThexStep
value is10
, which means that the frequency step on the X axis, between consecutive data samples, is 10 Hz.
Configuring Alerts
In the alerts
configuration section, you can define alerts for the configured devices.
To configure an alert, define the following mandatory settings:
Configuration Setting | Description |
---|---|
id | Alert identifier. A value provided here must match the alert ID of the device model created in the relayr Cloud. For more information on creating device models and versions in the relayr Cloud, refer to the relayr Cloud API documentation. |
measurement_id | Identifier of a measurement associated with the alert. The ID provided here must be configured in the measurements section of the configuration file. See the section above for details. Alternatively, you can configure the object section for an alert. See here for details. |
threshold_set | Threshold value based on which the alert is activated. |
logic_set | Logical relation for alert activation. Possible values are: "<", ">", "==", "">=", "<=". |
message_set | Message sent when the alert is activated. It is a free-form string. |
threshold_clear | Threshold value based on which the alert is cleared. |
logic_clear | Logical relation for clearing the alert. Possible values are: "<", ">", "==", "">=", "<=". |
message_clear | Message displayed when the alert is cleared. It is a free-form string. |
If both the
logic_clear
andlogic_set
conditions are fulfilled at the same time, the alert is set.
Optionally, you can define the following advanced settings for an alert:
Configuration Setting | Description |
---|---|
sampling_interval | Local sampling interval value, given in milliseconds, that overrides the global sampling interval. |
custom_prefix | Prefix of the MQTT topic that the object is reported to. An option to publish data to a custom MQTT topic for a local data processing or directly to the northbound interface. For example, if it is set to analytics for a temperature-based alert, all data is published to the topic analytics/{did}/alerts/alert_temp_high . It overrides the global custom prefix. |
connection | Local connection ID used for a given alert. It overrides the global connection set for the device. Possible ID values are defined in the connections section of the configuration file. See the Configuring BACnet Connections section for details. |
Here is an example of the alert configuration:
{
"id" : "alert_temp_high",
"measurement_id" : "temperature",
"threshold_set" : 38.5,
"logic_set" : ">=",
"message_set" : "TEMPERATURE IS TOO HIGH",
"threshold_clear" : 36.5,
"logic_clear" : "<=",
"message_clear" : "ALERT IS CLEAR",
"sampling_interval" : 4000
},
In the example presented above, the alert is activated if the temperature reaches a level defined in the
threshold_set
andlogic_set
fields, that is: if it is greater than or equal to 38.5. The message "TEMPERATURE IS TOO HIGH" is sent to the relayr Cloud when the alert is set.
When the temperature decreases and it is smaller than or equal to 36.5 (as specified in thethreshold_clear
andlogic_clear
fields), the alert is deactivated and the message "ALERT IS CLEAR" is sent to the relayr Cloud when the alert is deactivated.
The value provided in thesampling_interval
field means that the system verifies the alert data every four seconds.
Configuring Configuration Parameters
In the configuration
section, you can define the device configuration parameters.
To define a configuration parameter, define the following mandatory settings:
Configuration Setting | Description |
---|---|
id | Configuration object identifier. |
object | Protocol-specific object definition. See the BACnet Object Definition section for details. |
Optionally, you can define the following advanced settings for a configuration parameter:
Configuration Setting | Description |
---|---|
ro | This setting determines if a given configuration parameter is read-only (if set to true ) or the read/write permissions are granted to it (if set to false ). If no ro value is defined, the object has read/write permissions, by default. |
sampling_interval | Local sampling interval value, given in milliseconds, that overrides the the global sampling interval. |
custom_prefix | Prefix of the MQTT topic that the object is reported to. An option to publish data to a custom MQTT topic for a local data processing or directly to the northbound interface. For example, if it is set to analytics for a configuration parameter xyz , all data is published to the topic analytics/{did}/configuration/xyz . It overrides the global custom prefix. |
connection | Local connection ID used for a given configuration parameter. It overrides the global connection set for the device. Possible ID values are defined in the connections section of the configuration file. See the Configuring BACnet Connections section for details. |
Here is an example of the configuration settings:
{
"id" : "parameter2045",
"object" : { ... },
"sampling_interval" : 4000,
"ro" : true
},
You can change the configuration parameters of BACnet devices remotely. For more information, see the Remote Control of BACnet Devices section.
Configuring Metadata
The metadata
section of the configuration file allows you to define device attributes, such as the device ID, model, version, location, owner's email address, etc.
There are two ways to configure metadata:
Static metadata - metadata is an
id
andvalue
pair. It is sent only once, at the application startup.Dynamic metadata - metadata has a defined
object
. It is reported not only at the application startup, but also when the metadata value changes.
Static Metadata
Static metadata is configured as an id
and value
pair.
Static metadata is reported only once, at the application startup. To provide support for reporting a changing metadata value, configure dynamic metadata.
To configure the device static metadata, define the following values:
Configuration Setting | Description |
---|---|
id | Metadata identifier. |
value | Metadata value. |
Optionally, you can configure the following metadata settings:
Configuration Setting | Description |
---|---|
custom_prefix | Prefix of the MQTT topic that the object is reported to. An option to publish data to a custom MQTT topic for a local data processing or directly to the northbound interface. For example, if it is set to analytics for metadata serial_number , all data is published to the topic analytics/{did}/metadata/serial_number . It overrides the global custom prefix. |
It is mandatory to define the device ID (
did
) for each device. Thedid
value must match the UUID of the device created in the relayr Cloud.
For more information on creating devices in the Cloud, refer to the relayr Cloud API documentation.
The device
did
cannot contain spaces and plus (+) characters.
Here is an example of the device static metadata:
"metadata": [
{
"id": "did",
"value": "f33c6bah-b31e-4f5a-964h-13a935a8b25f"
}
]
Dynamic Metadata
Dynamic metadata is configured with a protocol-specific object
.
Dynamic metadata is published only if its value changes.
To report a metadata value dynamically, configure the following settings:
Configuration Setting | Description |
---|---|
id | Metadata identifier. |
object | Protocol-specific object definition. See the BACnet Object Definition section for details. |
Optionally, you can configure the following dynamic metadata settings:
Configuration Setting | Description |
---|---|
custom_prefix | Prefix of the MQTT topic that the object is reported to. An option to publish data to a custom MQTT topic for a local data processing or directly to the northbound interface. For example, if it is set to analytics for metadata serial_number , all data is published to the topic analytics/{did}/metadata/serial_number . It overrides the global custom prefix. |
sampling_interval | Local sampling interval value, given in milliseconds, that overrides the global sampling interval. |
connection | Local connection ID used for given metadata. It overrides the global connection set for the device. Possible ID values are defined in the connections section of the configuration file. See the Configuring BACnet Connections section for details. |
Here is an example of the device dynamic metadata:
"metadata": [
{
"id" : "serial_number",
"object" : { ... },
"sampling_interval" : 4000,
"custom_prefix" : "v1/nb"
},
BACnet Object Definition
For each configured measurement, configuration parameter and dynamic metadata, there is a protocol-specific object
configuration section.
In the BACnet Protocol Adapter, the following fields are mandatory to define an object
:
Configuration Setting | Description |
---|---|
obj_type | Type of the object. See here for a list of possible values. |
obj_inst | Object instance (0-based). |
prop_id | Property ID. See here for a list of possible values. |
tag_type | Value type specified for write-enabled configuration of numeric parameters (integers or floating point numbers) and strings. If no tag_type is provided, the default one is chosen: int for integers, single for floating point numbers and string for strings. Possible values: enum , uint , int , double , single , real , string . |
cov | Change of value (COV) subscription. Possible values are: confirmed - for the confirmed change of value subscription, or unconfirmed - for the unconfirmed change of value subscription. |
If you want to enable the
sampling interval
function (by specifying how often data is gathered from devices, given in milliseconds), do not specify thecov
. If specified, thecov
overrides thesampling_interval
setting.
Here is an example of a measurement object configuration:
"measurements":
[
{
"id": "bin0_val",
"object":
{
"obj_type": 3,
"obj_inst": 0,
"prop_id": 85,
"cov": "confirmed"
}
}
Remote Control of BACnet Devices
You can change the configuration parameters of BACnet devices remotely by sending configuration tasks to your devices.
A recommended way of handling register value changes is by using configurable business parameters. To do so, implement a Rule Engine's rule that detects if the business parameters have changed and generates a configuration task. See here for a rule example.
The configuration task is then handled by the Task Executor. See here for a script example that publishes configuration tasks to the southbound interface. When the BACnet Protocol Adapter receives the task, it changes the device configuration values. Then, it publishes the the task result message.
In the BACnet Protocol Adapter configuration, you must define the same configuration parameters as you set using configurable business parameters. Remember that the device UUID you set in the adapter's metadata must also match the device ID in the configuration of business parameters.
BACnet Communication
By default the adapter uses the standard BACnet port: udp/47808(0xBAC0) for communication. If you want to change the port, use the BACNET_IP_PORT
environment variable set to a decimal integer (0..65534).
Here is an example:
BACNET_IP_PORT=47809 ./gwa-bacnet-adapter
In this case, the adapter communicates over 47809(0xBAC1) port.
The following environment variables control the communication timeout and retries:
BACNET_APDU_TIMEOUT
- set this value in milliseconds to change the APDU timeout. The APDU Timeout determines how much time the adapter waits for a response from a BACnet device. The default value is 3000ms.BACNET_APDU_RETRIES
- it indicates the maximum number of times that an APDU shall be retransmitted. The default value is 3.
BACnet Device Detection
BACnet uses broadcasting over the local network to detect connected devices. Since the node where the Protocol Adapter is running may be connected via network interfaces to more than one network, there is a need to indicate the broadcasting network.
The BACnet Stack API (used under the hood by the Protocol Adapter) uses the following algorithm to find the network:
If the
BACNET_IFACE
environment variable is defined and set to an interface name (eth0
,eth1
etc.), it is used as the broadcasting interface. In other cases, theeth0
interface is used.Next, the IP address and the network mask associated with the chosen interface is identified (e.g.
eth0
as192.168.1.10/24
).Based on the IP address and the mask, the broadcasting network address is detected (e.g.
192.168.1.255/24
).In case of an error in the previous steps (e.g. no specified interface found or no IP address associated with the interface), the address
255.255.255.255
is used for broadcasting.
If you want to select
eth1
as a broadcasting interface, launch the Protocol Adapter as follows:
BACNET_IFACE=eth1 ./gwa-bacnet-adapter
BACnet Broadcast Management Device (BBMD) Support
To enable BBMD support, set the following environment variables:
BACNET_BBMD_PORT
- UDP/IP port number (0..65534) used for Foreign Device Registration. The default value is 47808 (0xBAC0).BACNET_BBMD_ADDRESS
- dotted IPv4 address of the BBMD or Foreign Device Registration.BACNET_BBMD_TIMETOLIVE
- a number of seconds used in Foreign Device Registration (0..65535). The default value is 60000 seconds.
Running Multiple Adapter Instances
It is possible to launch many adapter instances, running on the same host, using software emulated BBMD being part of BACnet Stack SDK.
Multiple adapter instances must be started with different deployment configuration files to prevent the instances from having the same instance ID.
Run the BBMD service on the default udp/47808(0xBAC0) port:
./bacnet-stack-0.8.4/bin/bacserv <bbmd_id>
The bbmd_id
is a BACnet device ID which is assigned to the BBMD service being created. Take any number which is not used by any BACnet device in your network. Since the BBMD service is responsible for broadcasting in the network ,set BACNET_IFACE
if required.
Assuming bbmd_ip
as an IP address of the host where BBMD service was launched, start two BACnet adapters on 47809(0xBAC1) and 47810(0xBAC2) UDP ports:
BACNET_IP_PORT=47809 BACNET_BBMD_ADDRESS=<bbmd_ip> BACNET_BBMD_PORT=47808 \
./gwa-bacnet-adapter <options>
BACNET_IP_PORT=47810 BACNET_BBMD_ADDRESS=<bbmd_ip> BACNET_BBMD_PORT=47808 \
./gwa-bacnet-adapter <options>
You can also launch more adapters on consecutive UDP ports: 47811, 47812 etc.
Supported BACnet Object Types
The table below lists the object types supported by the BACnet protocol. A suitable ID value is provided in the obj_type
field in the
BACnet object definition.
Object | Type ID |
---|---|
ANALOG INPUT | 0 |
ANALOG OUTPUT | 1 |
ANALOG VALUE | 2 |
BINARY INPUT | 3 |
BINARY OUTPUT | 4 |
BINARY VALUE | 5 |
CALENDAR | 6 |
COMMAND | 7 |
DEVICE | 8 |
EVENT ENROLLMENT | 9 |
FILE | 10 |
GROUP | 11 |
LOOP | 12 |
MULTI STATE INPUT | 13 |
MULTI STATE OUTPUT | 14 |
NOTIFICATION CLASS | 15 |
PROGRAM | 16 |
SCHEDULE | 17 |
AVERAGING | 18 |
MULTI STATE VALUE | 19 |
TRENDLOG | 20 |
LIFE SAFETY POINT | 21 |
LIFE SAFETY ZONE | 22 |
ACCUMULATOR | 23 |
PULSE CONVERTER | 24 |
EVENT LOG | 25 |
GLOBAL GROUP | 26 |
TREND LOG MULTIPLE | 27 |
LOAD CONTROL | 28 |
STRUCTURED VIEW | 29 |
ACCESS DOOR | 30 |
TIMER | 31 |
ACCESS CREDENTIAL | 32 |
ACCESS POINT | 33 |
ACCESS RIGHTS | 34 |
ACCESS USER | 35 |
ACCESS ZONE | 36 |
CREDENTIAL DATA INPUT | 37 |
NETWORK SECURITY | 38 |
BITSTRING VALUE | 39 |
CHARACTERSTRING VALUE | 40 |
DATE PATTERN VALUE | 41 |
DATE VALUE | 42 |
DATETIME PATTERN VALUE | 43 |
DATETIME VALUE | 44 |
INTEGER VALUE | 45 |
LARGE ANALOG VALUE | 46 |
OCTETSTRING VALUE | 47 |
POSITIVE INTEGER VALUE | 48 |
TIME PATTERN VALUE | 49 |
TIME VALUE | 50 |
NOTIFICATION FORWARDER | 51 |
ALERT ENROLLMENT | 52 |
CHANNEL | 53 |
LIGHTING OUTPUT | 54 |
BINARY LIGHTING OUTPUT | 55 |
NETWORK PORT | 56 |
Supported BACnet Properties
The table below lists the properties supported by the BACnet protocol. A suitable ID value is provided in the prop_id
field in the the
BACnet object definition.
Property | ID |
---|---|
ACKED TRANSITIONS | 0 |
ACK REQUIRED | 1 |
ACTION | 2 |
ACTION TEXT | 3 |
ACTIVE TEXT | 4 |
ACTIVE VT SESSIONS | 5 |
ALARM VALUE | 6 |
ALARM VALUES | 7 |
ALL | 8 |
ALL WRITES SUCCESSFUL | 9 |
APDU SEGMENT TIMEOUT | 10 |
APDU TIMEOUT | 11 |
APPLICATION SOFTWARE VERSION | 12 |
ARCHIVE | 13 |
BIAS | 14 |
CHANGE OF STATE COUNT | 15 |
CHANGE OF STATE TIME | 16 |
NOTIFICATION CLASS | 17 |
BLANK 1 | 18 |
CONTROLLED VARIABLE REFERENCE | 19 |
CONTROLLED VARIABLE UNITS | 20 |
CONTROLLED VARIABLE VALUE | 21 |
COV INCREMENT | 22 |
DATE LIST | 23 |
DAYLIGHT SAVINGS STATUS | 24 |
DEADBAND | 25 |
DERIVATIVE CONSTANT | 26 |
DERIVATIVE CONSTANT UNITS | 27 |
DESCRIPTION | 28 |
DESCRIPTION OF HALT | 29 |
DEVICE ADDRESS BINDING | 30 |
DEVICE TYPE | 31 |
EFFECTIVE PERIOD | 32 |
ELAPSED ACTIVE TIME | 33 |
ERROR LIMIT | 34 |
EVENT ENABLE | 35 |
EVENT STATE | 36 |
EVENT TYPE | 37 |
EXCEPTION SCHEDULE | 38 |
FAULT VALUES | 39 |
FEEDBACK VALUE | 40 |
FILE ACCESS METHOD | 41 |
FILE SIZE | 42 |
FILE TYPE | 43 |
FIRMWARE REVISION | 44 |
HIGH LIMIT | 45 |
INACTIVE TEXT | 46 |
IN PROCESS | 47 |
INSTANCE OF | 48 |
INTEGRAL CONSTANT | 49 |
INTEGRAL CONSTANT UNITS | 50 |
ISSUE CONFIRMED NOTIFICATIONS | 51 |
LIMIT ENABLE | 52 |
LIST OF GROUP MEMBERS | 53 |
LIST OF OBJECT PROPERTY REFERENCES | 54 |
LIST OF SESSION KEYS | 55 |
LOCAL DATE | 56 |
LOCAL TIME | 57 |
LOCATION | 58 |
LOW LIMIT | 59 |
MANIPULATED VARIABLE REFERENCE | 60 |
MAXIMUM OUTPUT | 61 |
MAX APDU LENGTH ACCEPTED | 62 |
MAX INFO FRAMES | 63 |
MAX MASTER | 64 |
MAX PRES VALUE | 65 |
MINIMUM OFF TIME | 66 |
MINIMUM ON TIME | 67 |
MINIMUM OUTPUT | 68 |
MIN PRES VALUE | 69 |
MODEL NAME | 70 |
MODIFICATION DATE | 71 |
NOTIFY TYPE | 72 |
NUMBER OF APDU RETRIES | 73 |
NUMBER OF STATES | 74 |
OBJECT IDENTIFIER | 75 |
OBJECT LIST | 76 |
OBJECT NAME | 77 |
OBJECT PROPERTY REFERENCE | 78 |
OBJECT TYPE | 79 |
OPTIONAL | 80 |
OUT OF SERVICE | 81 |
OUTPUT UNITS | 82 |
EVENT PARAMETERS | 83 |
POLARITY | 84 |
PRESENT VALUE | 85 |
PRIORITY | 86 |
PRIORITY ARRAY | 87 |
PRIORITY FOR WRITING | 88 |
PROCESS IDENTIFIER | 89 |
PROGRAM CHANGE | 90 |
PROGRAM LOCATION | 91 |
PROGRAM STATE | 92 |
PROPORTIONAL CONSTANT | 93 |
PROPORTIONAL CONSTANT UNITS | 94 |
PROTOCOL CONFORMANCE CLASS | 95 |
PROTOCOL OBJECT TYPES SUPPORTED | 96 |
PROTOCOL SERVICES SUPPORTED | 97 |
PROTOCOL VERSION | 98 |
READ ONLY | 99 |
REASON FOR HALT | 100 |
RECIPIENT | 101 |
RECIPIENT LIST | 102 |
RELIABILITY | 103 |
RELINQUISH DEFAULT | 104 |
REQUIRED | 105 |
RESOLUTION | 106 |
SEGMENTATION SUPPORTED | 107 |
SETPOINT | 108 |
SETPOINT REFERENCE | 109 |
STATE TEXT | 110 |
STATUS FLAGS | 111 |
SYSTEM STATUS | 112 |
TIME DELAY | 113 |
TIME OF ACTIVE TIME RESET | 114 |
TIME OF STATE COUNT RESET | 115 |
TIME SYNCHRONIZATION RECIPIENTS | 116 |
UNITS | 117 |
UPDATE INTERVAL | 118 |
UTC OFFSET | 119 |
VENDOR IDENTIFIER | 120 |
VENDOR NAME | 121 |
VT CLASSES SUPPORTED | 122 |
WEEKLY SCHEDULE | 123 |
ATTEMPTED SAMPLES | 124 |
AVERAGE VALUE | 125 |
BUFFER SIZE | 126 |
CLIENT COV INCREMENT | 127 |
COV RESUBSCRIPTION INTERVAL | 128 |
CURRENT NOTIFY TIME | 129 |
EVENT TIME STAMPS | 130 |
LOG BUFFER | 131 |
LOG DEVICE OBJECT PROPERTY | 132 |
ENABLE | 133 |
LOG INTERVAL | 134 |
MAXIMUM VALUE | 135 |
MINIMUM VALUE | 136 |
NOTIFICATION THRESHOLD | 137 |
PREVIOUS NOTIFY TIME | 138 |
PROTOCOL REVISION | 139 |
RECORDS SINCE NOTIFICATION | 140 |
RECORD COUNT | 141 |
START TIME | 142 |
STOP TIME | 143 |
STOP WHEN FULL | 144 |
TOTAL RECORD COUNT | 145 |
VALID SAMPLES | 146 |
WINDOW INTERVAL | 147 |
WINDOW SAMPLES | 148 |
MAXIMUM VALUE TIMESTAMP | 149 |
MINIMUM VALUE TIMESTAMP | 150 |
VARIANCE VALUE | 151 |
ACTIVE COV SUBSCRIPTIONS | 152 |
BACKUP FAILURE TIMEOUT | 153 |
CONFIGURATION FILES | 154 |
DATABASE REVISION | 155 |
DIRECT READING | 156 |
LAST RESTORE TIME | 157 |
MAINTENANCE REQUIRED | 158 |
MEMBER OF | 159 |
MODE | 160 |
OPERATION EXPECTED | 161 |
SETTING | 162 |
SILENCED | 163 |
TRACKING VALUE | 164 |
ZONE MEMBERS | 165 |
LIFE SAFETY ALARM VALUES | 166 |
MAX SEGMENTS ACCEPTED | 167 |
PROFILE NAME | 168 |
AUTO SLAVE DISCOVERY | 169 |
MANUAL SLAVE ADDRESS BINDING | 170 |
SLAVE ADDRESS BINDING | 171 |
SLAVE PROXY ENABLE | 172 |
LAST NOTIFY RECORD | 173 |
SCHEDULE DEFAULT | 174 |
ACCEPTED MODES | 175 |
ADJUST VALUE | 176 |
COUNT | 177 |
COUNT BEFORE CHANGE | 178 |
COUNT CHANGE TIME | 179 |
COV PERIOD | 180 |
INPUT REFERENCE | 181 |
LIMIT MONITORING INTERVAL | 182 |
LOGGING OBJECT | 183 |
LOGGING RECORD | 184 |
PRESCALE | 185 |
PULSE RATE | 186 |
SCALE | 187 |
SCALE FACTOR | 188 |
UPDATE TIME | 189 |
VALUE BEFORE CHANGE | 190 |
VALUE SET | 191 |
VALUE CHANGE TIME | 192 |
ALIGN INTERVALS | 193 |
INTERVAL OFFSET | 195 |
LAST RESTART REASON | 196 |
LOGGING TYPE | 197 |
RESTART NOTIFICATION RECIPIENTS | 202 |
TIME OF DEVICE RESTART | 203 |
TIME SYNCHRONIZATION INTERVAL | 204 |
TRIGGER | 205 |
UTC TIME SYNCHRONIZATION RECIPIENTS | 206 |
NODE SUBTYPE | 207 |
NODE TYPE | 208 |
STRUCTURED OBJECT LIST | 209 |
SUBORDINATE ANNOTATIONS | 210 |
SUBORDINATE LIST | 211 |
ACTUAL SHED LEVEL | 212 |
DUTY WINDOW | 213 |
EXPECTED SHED LEVEL | 214 |
FULL DUTY BASELINE | 215 |
REQUESTED SHED LEVEL | 218 |
SHED DURATION | 219 |
SHED LEVEL DESCRIPTIONS | 220 |
SHED LEVELS | 221 |
STATE DESCRIPTION | 222 |
DOOR ALARM STATE | 226 |
DOOR EXTENDED PULSE TIME | 227 |
DOOR MEMBERS | 228 |
DOOR OPEN TOO LONG TIME | 229 |
DOOR PULSE TIME | 230 |
DOOR STATUS | 231 |
DOOR UNLOCK DELAY TIME | 232 |
LOCK STATUS | 233 |
MASKED ALARM VALUES | 234 |
SECURED STATUS | 235 |
ABSENTEE LIMIT | 244 |
ACCESS ALARM EVENTS | 245 |
ACCESS DOORS | 246 |
ACCESS EVENT | 247 |
ACCESS EVENT AUTHENTICATION FACTOR | 248 |
ACCESS EVENT CREDENTIAL | 249 |
ACCESS EVENT TIME | 250 |
ACCESS TRANSACTION EVENTS | 251 |
ACCOMPANIMENT | 252 |
ACCOMPANIMENT TIME | 253 |
ACTIVATION TIME | 254 |
ACTIVE AUTHENTICATION POLICY | 255 |
ASSIGNED ACCESS RIGHTS | 256 |
AUTHENTICATION FACTORS | 257 |
AUTHENTICATION POLICY LIST | 258 |
AUTHENTICATION POLICY NAMES | 259 |
AUTHENTICATION STATUS | 260 |
AUTHORIZATION MODE | 261 |
BELONGS TO | 262 |
CREDENTIAL DISABLE | 263 |
CREDENTIAL STATUS | 264 |
CREDENTIALS | 265 |
CREDENTIALS IN ZONE | 266 |
DAYS REMAINING | 267 |
ENTRY POINTS | 268 |
EXIT POINTS | 269 |
EXPIRATION TIME | 270 |
EXTENDED TIME ENABLE | 271 |
FAILED ATTEMPT EVENTS | 272 |
FAILED ATTEMPTS | 273 |
FAILED ATTEMPTS TIME | 274 |
LAST ACCESS EVENT | 275 |
LAST ACCESS POINT | 276 |
LAST CREDENTIAL ADDED | 277 |
LAST CREDENTIAL ADDED TIME | 278 |
LAST CREDENTIAL REMOVED | 279 |
LAST CREDENTIAL REMOVED TIME | 280 |
LAST USE TIME | 281 |
LOCKOUT | 282 |
LOCKOUT RELINQUISH TIME | 283 |
MASTER EXEMPTION | 284 |
MAX FAILED ATTEMPTS | 285 |
MEMBERS | 286 |
MUSTER POINT | 287 |
NEGATIVE ACCESS RULES | 288 |
NUMBER OF AUTHENTICATION POLICIES | 289 |
OCCUPANCY COUNT | 290 |
OCCUPANCY COUNT ADJUST | 291 |
OCCUPANCY COUNT ENABLE | 292 |
OCCUPANCY EXEMPTION | 293 |
OCCUPANCY LOWER LIMIT | 294 |
OCCUPANCY LOWER LIMIT ENFORCED | 295 |
OCCUPANCY STATE | 296 |
OCCUPANCY UPPER LIMIT | 297 |
OCCUPANCY UPPER LIMIT ENFORCED | 298 |
PASSBACK EXEMPTION | 299 |
PASSBACK MODE | 300 |
PASSBACK TIMEOUT | 301 |
POSITIVE ACCESS RULES | 302 |
REASON FOR DISABLE | 303 |
SUPPORTED FORMATS | 304 |
SUPPORTED FORMAT CLASSES | 305 |
THREAT AUTHORITY | 306 |
THREAT LEVEL | 307 |
TRACE FLAG | 308 |
TRANSACTION NOTIFICATION CLASS | 309 |
USER EXTERNAL IDENTIFIER | 310 |
USER INFORMATION REFERENCE | 311 |
USER NAME | 317 |
USER TYPE | 318 |
USES REMAINING | 319 |
ZONE FROM | 320 |
ZONE TO | 321 |
ACCESS EVENT TAG | 322 |
GLOBAL IDENTIFIER | 323 |
VERIFICATION TIME | 326 |
BASE DEVICE SECURITY POLICY | 327 |
DISTRIBUTION KEY REVISION | 328 |
DO NOT HIDE | 329 |
KEY SETS | 330 |
LAST KEY SERVER | 331 |
NETWORK ACCESS SECURITY POLICIES | 332 |
PACKET REORDER TIME | 333 |
SECURITY PDU TIMEOUT | 334 |
SECURITY TIME WINDOW | 335 |
SUPPORTED SECURITY ALGORITHM | 336 |
UPDATE KEY SET TIMEOUT | 337 |
BACKUP AND RESTORE STATE | 338 |
BACKUP PREPARATION TIME | 339 |
RESTORE COMPLETION TIME | 340 |
RESTORE PREPARATION TIME | 341 |
BIT MASK | 342 |
BIT TEXT | 343 |
IS UTC | 344 |
GROUP MEMBERS | 345 |
GROUP MEMBER NAMES | 346 |
MEMBER STATUS FLAGS | 347 |
REQUESTED UPDATE INTERVAL | 348 |
COVU PERIOD | 349 |
COVU RECIPIENTS | 350 |
EVENT MESSAGE TEXTS | 351 |
EVENT MESSAGE TEXTS CONFIG | 352 |
EVENT DETECTION ENABLE | 353 |
EVENT ALGORITHM INHIBIT | 354 |
EVENT ALGORITHM INHIBIT REF | 355 |
TIME DELAY NORMAL | 356 |
RELIABILITY EVALUATION INHIBIT | 357 |
FAULT PARAMETERS | 358 |
FAULT TYPE | 359 |
LOCAL FORWARDING ONLY | 360 |
PROCESS IDENTIFIER FILTER | 361 |
SUBSCRIBED RECIPIENTS | 362 |
PORT FILTER | 363 |
AUTHORIZATION EXEMPTIONS | 364 |
ALLOW GROUP DELAY INHIBIT | 365 |
CHANNEL NUMBER | 366 |
CONTROL GROUPS | 367 |
EXECUTION DELAY | 368 |
LAST PRIORITY | 369 |
WRITE STATUS | 370 |
PROPERTY LIST | 371 |
SERIAL NUMBER | 372 |
BLINK WARN ENABLE | 373 |
DEFAULT FADE TIME | 374 |
DEFAULT RAMP RATE | 375 |
DEFAULT STEP INCREMENT | 376 |
EGRESS TIME | 377 |
IN PROGRESS | 378 |
INSTANTANEOUS POWER | 379 |
LIGHTING COMMAND | 380 |
LIGHTING COMMAND DEFAULT PRIORITY | 381 |
MAX ACTUAL VALUE | 382 |
MIN ACTUAL VALUE | 383 |
POWER | 384 |
TRANSITION | 385 |
EGRESS ACTIVE | 386 |
Examples of Configuration Files
Deployment Configuration File
{
"transport": "mqtt",
"mqtt_connection": {
"host": "localhost",
"port": 1883,
"keepalive": 20,
"max_inflight_messages": 100,
"qos_levels": {
"measurements": 0,
"alerts": 1,
"configuration": 1,
"metadata": 1
}
},
"health_monitor": {
"heartbeat_interval": 60
},
"pmq_connection":
{
"output_queues": ["/bacnet_out_queue"],
"input_queues": ["/bacnet_in_queue"],
"message_size": 8192,
"message_count": 10
}
}
Application Configuration File
{
"connections":
[
{
"id": "conn_1",
"dev_id": 1
}
],
"sampling_interval": 5000,
"devices":
[
{
"connection":
{
"id": "conn_1"
},
"metadata":
[
{
"id": "did",
"value": "simul_1"
},
{
"id": "model_id",
"value": "simul"
},
{
"id": "model_version",
"value": "1"
}
],
"measurements":
[
{
"id": "analog0_oos",
"object":
{
"obj_type": 0,
"obj_inst": 0,
"prop_id": 81
}
},
{
"id": "analog0_val",
"object":
{
"obj_type": 0,
"obj_inst": 0,
"prop_id": 85,
"cov": "confirmed"
}
}
],
"configuration":
[
{
"id": "analog0_highlimit",
"object":
{
"obj_type": 0,
"obj_inst": 0,
"prop_id": 45
}
},
{
"id": "analog0_lowlimit",
"object":
{
"obj_type": 0,
"obj_inst": 0,
"prop_id": 59
}
}
],
"alerts": []
}
]
}