1. BACnet

Note: BACnet functionality is only supported on TKG (gateway running TKL) and TKE (edge server), the cloud platform does not support BACnet.

If the user's BMS (Building Management System) requires formal deployment, a standard BACnet point list file typically needs to be provided to facilitate system integration and commissioning. Before generating the BACnet point list, BACnet fields must be configured in the thing model. Please refer to Section 7.1 for relevant descriptions about BACnet fields.

1. Enter operation and maintenance management → BACnet module.
2. Click incremental generation button.
3. Select the target in the pop-up window object Model.
4. Generate configured fields for devices bound to the selected model with BACnet enabled.

The generated table contains key information such as object type, object instance number, object name, attribute description, data type, company, read and write permissions, and can be delivered to third-party systems for docking.

The list also supports reordering object IDs and importing or exporting the point table. In the 2.00.077 frontend, there is no separate Apply Point Table button. The matching backend automatically synchronizes point-table writes with a running BACnet service. Saving the table does not start a stopped service; start it from Server Configuration. Reordering IDs changes the identifiers used by BMS clients, so provide an updated point table to integrators.

Built-in BACnet/IP Service (since 2.00.077)

The platform includes a BACnet/IP service without requiring a separately installed bridge. It supports analogInput, analogOutput, analogValue, binaryInput, binaryOutput, and binaryValue, plus COV (change-of-value) subscriptions. Input objects are read-only; Output and Value objects are writable. Actual device control requires a bound RPC.

With BACnet enabled on the device and its thing-model fields mapped to points, new telemetry updates BACnet objects directly. BMS writes to writable objects are dispatched through the point's bound device RPC. A successful BACnet write does not prove device execution; check the device response or subsequent telemetry.

Starting the Service and Updating Points

1. Ask the system administrator to allow BACnet in System Config.
2. Enable BACnet on the target device. Configure model fields for telemetry, or add attribute-source objects directly.
3. Generate or maintain the point table. Check EUI, thing model, field, object type, and object ID; bind RPCs for control points.
4. Open System Management → Server Configuration → BACnet, enter network and device settings, click Submit, then Restart. Check the running status and any error message.
5. Verify discovery, reading, COV, and control using the BMS client, then export the point table for handover.

Saving, deleting, importing, generating, or reordering points automatically synchronizes a running service; there is no Apply Point Table action. Changes to service listening parameters still require Submit and Restart. Synchronization failures are logged and retried. Check final status and BMS readings rather than relying only on a successful save message.

One organization's BACnet service per process

Starting BACnet for another organization stops the previous organization's instance. Different ports do not allow multiple organizations to run concurrently in one process. Switching organizations in the browser without starting a service does not replace the instance.

On application startup, recovery is attempted for the most recently running/restarting organization service. The service retries after an unexpected exit. Manual stop or global disable prevents automatic revival; deleting an organization cleans up its instance and retries. After allowing BACnet again, click Restart manually.

See Upgrade Notes for related feature changes.

Attribute Sources and Online Status Mapping (2.00.085)

Object lists/editors, thing-model BACnet fields, model-based generation, and Excel import/export support data_from. It is a free string (varchar(32) in the database), not a fixed enum. Suggested values are telemetry_data, server_attrs, and shared_attrs; other source names can be entered. This is distinct from the device's own data_from describing LoRaWAN or other ingestion paths.

data_from	Reading and configuration
telemetry_data	Default for old records, old model configuration, and requests omitting the source. Requires thing_model; reads fields from device.telemetry_data[thing_model]
server_attrs	Reads paths from device.server_attrs; no model selection required, and the backend stores thing_model as ""
shared_attrs	Reads paths from device.shared_attrs; stores thing_model as ""
Other strings	Reads paths from the device's corresponding own property; stores thing_model as "". An absent source uses default_value

Attribute paths support _online, status.value, and other dotted paths. Telemetry first tries an exact full field-name match, then path traversal, preserving old literal dotted names. Unknown sources, missing/null values, and empty/whitespace strings fall back to default_value. Numeric 0 and boolean false are preserved before object-type conversion. Defaults are not evidence of real device state.

The business unique key is (eui, data_from, thing_model, field_name). Thing-model BACnet configuration uses a source-plus-field key while accepting old keys. Identical field names from different sources can coexist; do not deduplicate by field name alone. Object editors submit units; selecting a model field maps its unit to that property.

Direct attribute objects require no model. Model-based generation still covers only devices bound to the selected model with BACnet enabled; it does not automatically create status objects for every device.

Configure a Read-only Status Point

1. Enable notify_offline="TRUE" for the target device, set its actual heartbeat, and confirm the status source.
2. Add a BACnet object with the real EUI and an available object ID/name. Select server_attrs, field _online, type binaryInput, and units noUnits.
3. Save, verify synchronization with the running service, and test online, timeout, and recovery using the BMS. Existing service permissions, start steps, and organization-instance restrictions still apply.

This fragment contains key fields only; creation also requires EUI, object identifiers, and other mandatory fields:

{
  "data_from": "server_attrs",
  "thing_model": "",
  "field_name": "_online",
  "object_type": "binaryInput",
  "units": "noUnits",
  "default_value": 0
}

A default 0 does not prove detected offline status: a missing attribute can return the same value. Disabling notifications can freeze _online at its last state. API online differs in heartbeat fallback, deadline boundary, and switch semantics; see Status Definitions.

Attribute Updates and Write Feedback

Cache addition/replacement, message activity, RPC attribute changes, and attribute persistence queueing trigger notifications, including timing-wheel offline detection. The manager reads the configured source, updates only the running organization, and filters unchanged values. This does not produce extra generic server_attrs MQTT forwarding.

Input objects are read-only. Output/Value writes retain the bound RPC chain, called one by one with { _eui, [field_name]: value } and source bacnet_server. A dotted field path is a literal parameter key, not an automatically expanded nested object. Cache synchronization suppresses Worker write callbacks to prevent recursive RPCs. After RPC failure or device feedback of the old value, later attribute notifications can restore the actual cached value. Verify write acceptance, device execution, and persistence separately.