Skip to main content
Cloud BMS is the cloud building management product in KODE OS. It connects building management systems, IoT devices, and operational tools into one layer. You monitor, analyze, and command equipment across your portfolio regardless of manufacturer. Cloud BMS includes core operations tools plus analytics modules. Those modules include Building BI, Fault Detection and Diagnostics (FDD), and the Functional Testing Tool (FTT). Related KODE OS apps such as AssetOps, EnerG, and the mobile app extend the same data foundation.
Cloud BMS Sites view with building list on the left and portfolio map on the right

Start at the portfolio Sites view, then open a building to reach site-level tools

​
How Cloud BMS fits together

Cloud BMS sits above your existing building systems. Connectors bring data in. Discovery finds equipment. Ontology and device templates make every site look the same. Graphics, schedules, FDD, Building BI, and other modules then work from that shared model. Unlike read-only analytics platforms, Cloud BMS supports write-back command and control. You can change setpoints, override schedules, and command equipment from one interface. Sites can run different BMS vendors. See Command and control points.

​
What you can do

Many tools in Cloud BMS are open-ended. After equipment is modeled, you can build the graphics, trends, dashboards, routines, and metrics your portfolio needs. You are not limited to the defaults shipped with each module. Common use cases include:
  • Monitor and control HVAC, lighting, fire, electrical, and other systems from devices, points, and graphics
  • Visualize live and historical data with floor plans, system graphics, and trends
  • Automate equipment schedules and Optimized Start/Stop (OSS)
  • Detect faults and commission equipment with FDD and FTT
  • Build dashboards and metrics with Building BI
  • Scale across vendors with device templates so VAVs, AHUs, and meters behave the same in every building
Cloud BMS connects to 200+ building systems. Supported protocols include BACnet, Modbus, DALI, MQTT, OPC, and RESTful APIs. Browse the integrations catalog for connector details.

​
Who uses Cloud BMS

Building operators monitor equipment, respond to alarms, and command points from the web app or mobile app. Controls and commissioning teams connect data sources, run discovery, apply templates, and validate equipment with FTT. Portfolio and analytics teams compare sites, build Building BI dashboards, and track faults across the estate. Energy and sustainability teams use the same normalized data in EnerG for usage, emissions, and capital planning. Administrators provision products, users, and buildings in Launchpad, then work in Cloud BMS day to day.

​
Portfolio and building

Cloud BMS organizes operations and analysis at two scopes: portfolio and building.
  • Portfolio — Cross-building view of your estate. Open analytics, mass operations, documents, and settings before you select a site.
  • Building — Site-level operations after you select a building from Sites.
Many modules work at both scopes. Building BI, FDD, FTT, and Documents use the same features at each level. The difference is data scope: portfolio spans sites; building focuses on one site. Portfolio-only tools include Sites, Mass Write, and portfolio Settings. Building-only tools include Systems, Areas, Devices, Points, Data Sources, Graphics, Trends, Schedules, and OSS. When you open Cloud BMS, you start at the portfolio level. Select a building from Sites to enter the building level.

​
Building structure

Inside a building, Cloud BMS organizes the site as a hierarchy:
  1. Areas — Floors, rooms, and other locations
  2. Systems — Logical groups such as HVAC or lighting
  3. Devices — Equipment and controllers
  4. Points — Sensor values, setpoints, and commands
That hierarchy is how you navigate the sidebar and how analytics attach to real equipment.

​
Key concepts

These ideas show up across Cloud BMS. They follow the order you typically encounter them when a building comes online. For full definitions, see the glossary.

​
Data sources and discovery

A Data Source is a connector to an external system. Device discovery finds devices, points, and schedules from that connection so you do not configure every entity by hand. The shows how reliably a data source stays connected and delivers data.

​
Ontology and device templates

maps manufacturer-specific labels to a shared vocabulary. applies those standards. Analytics and control then work across buildings and brands. Device templates capture those mappings once. Apply a template to similar equipment across the portfolio. A VAV from one vendor and a VAV from another then look and behave the same in graphics, FDD, FTT, and Building BI.

​
Command and control

Writable points accept commands from Cloud BMS. You adjust setpoints and overrides from device details or floor plans without switching to the underlying BMS. See Command and control points.

​
Open analytics and operations modules

With modeled data in place, modules share the same foundation. Build custom Building BI dashboards, FDD routines, and FTT workflows without re-integrating each site.

​
Explore the platform

Use these links when you know which area you need. Prefer Next steps if you are choosing a starting path.

​
Core platform

​
Analytics and operations modules

These modules live in Cloud BMS and have their own documentation sets.

​
Next steps

Pick the path that matches what you need to do first.

Operate a live building

Open Sites, enter a building, and move into graphics, points, and schedules.

Connect and model equipment

Add a data source, run discovery, then standardize devices with templates.

Build analytics or monitor faults

Create a Building BI dashboard, or jump to FDD when you are ready to monitor faults.

Look up a term

Find definitions for Cloud BMS, ontology, discovery, and related product terms.
Last modified on August 18, 2026