> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/akenza-building-edge/akenza-building-edge.md). # Overview Akenza Building Edge connects an existing building management system to the akenza platform, to read its data and to write values back to it. **Akenza Building Edge** is an edge connector for building management systems. It brings data from an existing, wired BMS into akenza, covering readings such as temperature, energy consumption, HVAC performance, and occupancy. That data is stored in the same format as the data from your wireless IoT devices. The connector can run purely read-only, or be configured to write a selected subset of points back to the BMS, so that the platform can also configure the building. See [Writing back to the BMS](#writing-back-to-the-bms). The result is a single view of a building. Instead of reading HVAC and metering data on a workstation in the basement and battery-powered sensor data in a separate cloud tool, both live in the same platform, on the same dashboards, and flow through the same rules and connectors. ## Supported systems Building Edge connects to building management systems over the standard building automation protocols: * **BACnet** * **KNX** * **Modbus** It is based on the [Niagara Framework](https://www.tridium.com/), which is widely deployed in building automation and provides the driver layer for these protocols. ## How it works {% stepper %} {% step %} ### An akenza plugin runs on Niagara Building Edge is delivered as an akenza plugin for a Niagara controller on site. The controller already speaks the protocols your BMS uses, so no change to the BMS itself is required. {% endstep %} {% step %} ### You select the data points to publish Rather than pushing everything the BMS knows, you choose which data points should be available in the cloud. This keeps the cloud model focused on what you actually want to monitor and controls how much data leaves the building. {% endstep %} {% step %} ### Data is published to akenza over MQTT The plugin sends the selected data points to akenza using [MQTT](/device-management/your-data-flow/device-connector/mqtt.md), a lightweight messaging protocol. Where write access is configured, the same connection carries those writes in the opposite direction. {% endstep %} {% step %} ### The BMS appears as a device in akenza In akenza, the connected BMS is represented as a set of devices. Data passes through a [data flow](/device-management/your-data-flow.md) like any other uplink, and is decoded and stored in the same structure as IoT device data. {% endstep %} {% endstepper %} ## What you can do with BMS data in akenza Once BMS data points are in the platform, they are ordinary akenza data. That means you can: * **Visualize them** alongside IoT sensor data in the [Dashboard Builder](/dashboard-builder/dashboard-builder.md), including on [floorplans](/dashboard-builder/components/floorplan-component.md) and [signage screens](/dashboard-builder/signage-screens.md). * **Act on them** with the [rule engine](/device-management/rule-engine.md), for example to raise an alert when a plant reading crosses a threshold, or to combine BMS values with wireless sensor readings in a single rule. * **Forward them** through [output connectors](/device-management/your-data-flow/connectors.md) to your own database, data warehouse, or streaming service for long-term analysis. * **Contextualize them** with the [Data Fusion Layer](/data-fusion-layer/data-fusion-layer.md), which places BMS systems and IoT sensors in a shared model of sites, floors, and zones. * **Query them** in natural language with [Genio](/genio/genio.md). * **Write back to them**, for the subset of points the connector is configured to allow. ## Writing back to the BMS Write access is part of the deployment configuration, and it is granted per data point. A connector can be set up in either mode: * **Read-only.** Building Edge only publishes data to akenza, and nothing in the cloud can change the building. * **Selected points writable.** A defined subset of points, typically a few setpoints, accepts writes. Everything else stays read-only. Where a point is writable, writing to it is an ordinary [downlink](/device-management/your-data-flow/device-type/device-type/downlink.md), because the BMS is represented in akenza as a set of devices. Dashboards, [rules](/device-management/rule-engine.md), and the [REST API](/reference/api-documentation.md) can all drive it. {% hint style="warning" %} Writing to a BMS changes how a building physically behaves. Keep the writable subset as small as the use case allows, and keep safety logic and interlocks in the BMS, where they continue to work if the connection to akenza is interrupted. {% endhint %} ## Why it matters A traditional BMS is typically reachable only from the local environment, which makes every question about building performance depend on someone being on site. Wireless IoT sensors, meanwhile, are easy to deploy but cover only what they were installed to measure and often end up in a separate tool. Building Edge removes that split: the wired and the wireless side of a building report into one platform, so facility teams get a holistic view of their facilities and can monitor building performance remotely. Where write access is configured, that view is something they can act on rather than only read. ## Getting started Building Edge is installed on site, on a Niagara station, and is typically set up together with a building automation partner who knows the BMS in question. {% hint style="info" %} To scope a Building Edge deployment for your building, get in touch through the [Service Desk](/faq/service-desk.md), or read more at [akenza.io](https://akenza.io/solutions/smart-building/bms). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akenza.io/akenza-building-edge/akenza-building-edge.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.