> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.kodelabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data sources
> Add, configure, optimize, and preview data sources that power Building BI dashboards and calculations.
Data sources supply the underlying data for Building BI dashboards. Each data source defines the columns, metrics, and calculations available to your charts and widgets.
For data model context, see [Physical vs virtual data sources](/products/building-bi/concepts/physical-vs-virtual-data-sources), [Point time series hierarchy](/products/building-bi/data-sources#polling-and-data-structure), [Data source types](/products/building-bi/reference/data-source-types), [calculated fields](/products/building-bi/reference/calculated-fields), and [table structures](/products/building-bi/reference/table-structures).
## In this guide
Compare physical, virtual, and key time-series sources.
Preview columns, samples, and toolbar actions.
Create columns, metrics, and URL fields.
Optimize sources, check usage, and apply point bounds.
Navigate to `Building BI` and select `Data Sources` in the left navigation panel.
Changes to data sources, calculated columns, and metrics are portfolio-wide. Any modification affects all dashboards across the entire portfolio, not just a single building.
## Data source types
Building BI supports two data source types:
* **Physical** -- Maps directly to a database table managed by the backend. Physical data sources reflect the raw data stored in your connected database.
* **Virtual** -- Built from SQL queries (views) on top of physical tables. Virtual data sources give you flexibility to create custom datasets without modifying the underlying database. You can edit a virtual table's SQL by clicking the three-dot menu on its row.
Both types expose columns and metrics that you can use when building dashboard charts. When you select a chart in edit mode, the `Chart Configuration` panel lets you pick a data source and drag its metrics into the X-Axis, Y-Axis, and Legend fields.
The Data Sources page provides two tabs: `All Datasources` lists every data source in your portfolio, and `Favorites` shows only data sources you have starred. Select the star icon on any row to add it to your favorites.
Select the three-dot menu on any row in the data sources list to access `Edit Details` or `Delete`.
Never delete a data source unless you are certain no dashboards rely on it. Deleting a data source instantly breaks every dashboard and chart that references it across the entire portfolio.
### Virtual table considerations
Virtual tables recompute on every query. Use them for light, real-time reshapes. Prefer physical tables when historical trending or heavy aggregation must stay fast.
* You can create virtual tables on ClickHouse and PostgreSQL data sources.
* You cannot create virtual tables on BigQuery.
## Database types
Building BI connects to three database engines. Each stores a specific category of data, and each requires its own SQL dialect for calculated columns and metrics.
| Database | Purpose | Virtual table support |
| -------------- | -------------------------------------------------- | --------------------- |
| **ClickHouse** | Real-time sensor data (Point Time Series tables) | Yes |
| **PostgreSQL** | Non-sensor multidimensional data with many columns | Yes |
| **BigQuery** | Module data (FTT, FDD, OSS) | No |
Tables do not join across database types. You cannot combine a ClickHouse table with a BigQuery table in a single query.
When writing calculated columns or metrics, use the SQL syntax that matches the database type of the data source. ClickHouse, PostgreSQL, and BigQuery each follow different SQL dialects.
## Key data sources
While many tables exist, two primary sources cover the majority of sensor-related use cases:
| Choose Real-Time when… | Choose Last Value when… |
| -------------------------------------- | --------------------------------------------- |
| You plot trends or history | You show current status or "now" tiles |
| Time alignment across readings matters | You compare sensors with different poll rates |
| You need every reading in a range | You only need the latest value per point |
### Point Time Series Real-Time
The core sensor table where every reading creates a new row. This is the source of truth for building sensor data. Slight variants exist that poll less frequently — use those only when loading time is a concern.
Point Time Series Real-Time runs on ClickHouse, so all calculated columns and metrics on this table must use ClickHouse SQL syntax.
### Point Time Series Last Value
Returns only the most recent recorded value per sensor. Search `Last Value` in the data sources list to find this table.
Last Value rows are not a synchronized snapshot. Each row is the most recent reading for that sensor, regardless of timestamp. Do not use them for time-sensitive math that assumes every sensor sampled at once.
### Aggregated tables
Some data sources aggregate readings at fixed intervals (15-minute, hourly, daily, or monthly). Aggregated tables return summary values (average, sum, maximum, minimum, count, or delta) for each point during the polling period.
Aggregation is valuable for some sensor types. Hourly average air temperature shows how a space generally felt, while an hourly average of elevator floor level is less meaningful.
### Polling and data structure
Each point time series table contains one row per data point at a given time period, along with context columns identifying the device, area, and building. You may see multiple rows from the same device at the same timestamp if they come from different points.
Prefer ID columns over name columns for filters and calculations. Names are editable and not guaranteed unique.
Each row carries nested layers of context around the data point, from the building level down to the individual sensor value:
```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"github-dark"}}
---
config:
theme: neutral
layout: dagre
---
flowchart TB
subgraph building["Building Level"]
B1["building_id / building_name"]
B2["building_region · building_type\nbuilding_sqft · building_timezone"]
end
subgraph area["Area (Floor) Level"]
A1["area_id / area_name"]
end
subgraph device["Device (Equipment) Level"]
D1["device_id / device_name"]
D2["device_mechanical_type\ndevice_class · device_zone"]
end
subgraph point["Point (Sensor) Level"]
P1["point_id / point_name"]
P2["point_kind · point_unit · point_enum"]
end
subgraph data["Data"]
V1["date_time · date_time_local"]
V2["number_value · string_value\nboolean_value · enum_mapping"]
V3["cur_status · cur_state · point_writable"]
end
B1 --> A1 --> D1 --> P1 --> V1
classDef Sky stroke-width:1px, stroke-dasharray:none, stroke:#374D7C, fill:#E2EBFF, color:#374D7C
classDef Peach stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D
classDef Rose stroke-width:1px, stroke-dasharray:none, stroke:#FF5978, fill:#FFDFE5, color:#8E2236
classDef Green fill:#B0E4CC, color:#285A48, stroke:#285A48
class B1,B2 Sky
class A1 Sky
class D1,D2 Peach
class P1,P2 Rose
class V1,V2,V3 Green
linkStyle 0,1,2,3 stroke:#00C853,fill:none
```
Two common polling patterns exist:
* **Change of value (COV)** -- A new row is created only when the value changes beyond the COV threshold, with a maximum interval of one hour between rows.
* **Structured polling** -- A new row is created at every polling interval (every 1, 2, 5, 10, or 15 minutes) regardless of whether the value changed.
Check the `Point` page and `Device` page in the left navigation bar to understand which points and devices exist in the building before building queries against point time series tables.
## Data source schema
Selecting any data source name opens its schema view. The schema reveals the building blocks available for your dashboards across five tabs: `Columns`, `Calculated`, `Metrics`, `URLs`, and `Actions`.
| Tab | Description |
| ------------ | --------------------------------------------------------------------- |
| `Columns` | Native database columns that exist in the underlying table |
| `Calculated` | Custom single-row logic columns you create with SQL expressions |
| `Metrics` | Aggregate-level calculations that recalculate based on chart grouping |
| `URLs` | Internal or external links generated from row data |
| `Actions` | Actionable operations available on the data source |
### Schema toolbar actions
From the top of the schema view, you can:
* **`Sync Datasource`** -- Pull in the latest columns if the underlying KODE table was updated.
* **`+ Add Column`** -- Create a new calculated column, metric, or URL.
* **Three-dot menu** -- Access `Check Column Usage` to see which dashboards reference specific columns, `Check Optimization` to review virtual table performance, or `Edit Details` to change basic parameters.
### Samples tab
The `Samples` tab previews a subset of records from the data source before you build charts. Use it to validate fields, confirm virtual table SQL, and inspect example values without creating a report first.
Navigate to `Building BI` > `Data Sources` and select a data source name.
Next to the `Schema` tab, select `Samples`.
The table shows available columns and example values. The preview is read-only and limited to approximately 20 rows for performance. Changes you make to the data source are reflected automatically when you return to **Samples**.
Native columns and calculated columns appear together in the preview. Calculated columns show an `i` icon in the column header. Select the icon to open the column's query. Use that when you are writing other calculated columns or metrics from the same source.
Both **physical** and **virtual** data sources support sample preview across ClickHouse, PostgreSQL, and BigQuery dialects.
Calculated columns appear at the end of the sample table. Look for the `i` icon in the header to confirm a column is calculated, then select it to inspect the expression.
| Scenario | What you see |
| ---------------------------- | -------------------------------------------------------------------------- |
| **Structure with no rows** | Column headers display with a **No results** message |
| **Calculated column errors** | Invalid calculated columns are omitted from the preview to avoid confusion |
| **After schema changes** | Reopen **Samples** or sync the data source to refresh the preview |
Sample preview is for validation, not full data exploration. Use dashboards and charts for analysis workflows.
## Calculated columns, metrics, and URLs
Calculated columns, calculated metrics, and URLs extend your data sources beyond raw columns. Use this section for SQL patterns and examples. For create steps, field options, data-type limits, and columns-versus-metrics graphics, see [Calculated fields](/products/building-bi/reference/calculated-fields).
| Feature | Calculated columns | Calculated metrics |
| ------------ | ------------------------------------------------ | ------------------------------------------------ |
| **Scope** | Single row | Multiple rows |
| **Function** | Applies logic to create a new virtual data field | Aggregates data (for example, SUM, AVG, COUNT) |
| **Behavior** | Independent; does not aggregate | Dynamically recalculates based on chart grouping |
Editing a calculated column, metric, or URL affects all dashboards portfolio-wide. Always validate your logic before saving. Changing a calculation can break multiple live dashboards.
### Calculated columns
Calculated columns apply row-level logic to produce a new value for each row independently, similar to a spreadsheet formula. Each calculated column contains a single SQL expression.
Use calculated columns to:
* Extract time components for filtering (for example, `toHour(date_time_local)` returns the hour as an integer).
* Isolate a specific sensor's values using conditional logic (for example, return `number_value` only when `ontology_point_field` matches a target, otherwise return null).
* Plot multiple sensor readings side-by-side in a single chart.
The examples below use the Point Time Series Real-Time table, which runs on ClickHouse. All calculated columns and metrics on this table must follow ClickHouse SQL syntax. Match the dialect of your source: [PostgreSQL](https://www.postgresql.org/docs/current/), [ClickHouse](https://clickhouse.com/docs/sql-reference), or [BigQuery](https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax).
#### Column rules
* Each calculated column must have a unique name within the data source.
* Column names must use the exact database field names (for example, `building_name`, not "Building Name").
* You cannot edit a calculated column's SQL expression from the chart `fx` editor. Edit it in `Data Sources` directly.
#### Metadata syntax on Real-Time tables
When referencing metadata fields (such as `building_name`, `device_name`, or `ontology_point_field`) on the Point Time Series Real-Time table, you must wrap them in the `dictGetString` pattern:
```sql Real-Time metadata example theme={"theme":{"light":"github-dark","dark":"github-dark"}}
if (
dictGetString(
'point_time_series.metadata_dictionary',
'ontology_point_field',
tuple(point_id)
) = 'discharge_air_pressure_setpoint',
number_value,
null
)
```
Replace `discharge_air_pressure_setpoint` with any `ontology_point_field` value. Use the appropriate payload column (`number_value`, `string_value`, or `boolean_value`) depending on the point's data type.
#### Simplified syntax on Last Value tables
The Last Value table is pre-processed, so you can reference metadata columns directly without `dictGetString`:
```sql Last Value metadata example theme={"theme":{"light":"github-dark","dark":"github-dark"}}
if (
ontology_point_field = 'discharge_air_pressure_setpoint',
number_value,
null
)
```
### Calculated metrics
Calculated metrics perform aggregate calculations across multiple rows. Unlike columns, metrics dynamically recalculate based on your chart's grouping. If a chart is grouped by hour, the metric produces one value per hour. If grouped by device, it produces one value per device.
Use aggregate functions like `sumIf`, `countIf`, or `avgIf` to filter rows before aggregating. You can combine multiple functions to build complex logic.
**Example: net occupancy metric**
This metric calculates occupancy by subtracting people leaving from people entering:
```sql Net occupancy (Real-Time table) theme={"theme":{"light":"github-dark","dark":"github-dark"}}
sumIf(
number_value,
dictGetString(
'point_time_series.metadata_dictionary',
'ontology_point_field',
tuple(point_id)
) = 'people_entering_counter'
) - sumIf(
number_value,
dictGetString(
'point_time_series.metadata_dictionary',
'ontology_point_field',
tuple(point_id)
) = 'people_leaving_counter'
)
```
Columns operate on a single row. Metrics aggregate across multiple rows. Use a column when you need a per-row value (for dimensions or filters). Use a metric when you need an aggregated result (for chart values).
### URLs
URL columns turn data into navigation actions in your dashboards.
#### Internal URLs
Internal URLs follow the pattern `/buildings/{building_id}` and navigate within Cloud BMS on both desktop and mobile. Building BI validates the IDs automatically.
Add a `Device URL` to table widgets for a quality-of-life improvement. In the widget style settings, set the URL option on the device name column to `Device URL`. Each device name cell becomes a hyperlink to that device's page, letting users jump directly from a dashboard finding to the relevant device.
#### External URLs
External URLs open in a new browser tab, allowing users to navigate to resources outside KODE OS such as a CMMS system or a specific work order.
For URL behavior on chart widgets, data-type limits on metrics, and `Hidden` or `Sensitive Values` options, see [Calculated fields](/products/building-bi/reference/calculated-fields).
## Add a data source
Navigate to `Building BI` > `Data Sources`.
Select `+ Add Data Sources` and choose `Physical` or `Virtual`.
On the `Details` tab, complete the required fields:
| Field | Description |
| ----------------- | ----------------------------------------------------------------------------------------------------------- |
| **Database Type** | The database engine for the source connection (ClickHouse, PostgreSQL, or BigQuery) |
| **Database** | The target database name (consult support, a data analyst, or copy from an existing client) |
| **Schema** | The database schema for the source table (consult support, a data analyst, or copy from an existing client) |
| **Name** | The internal identifier for the data source |
| **Display Name** | A human-readable name shown in dashboard configuration panels |
| **Description** | Optional summary of the data source's purpose |
For virtual tables, switch to the `SQL Expression` tab to define the query. The `Source Tables` field lists the tables referenced in your SQL. Write the SQL expression using the syntax that matches the selected database type (PostgreSQL or ClickHouse).
Review existing virtual tables for SQL syntax examples. You can also consult the database engine documentation or use an LLM for query construction. LLMs handle standard ClickHouse and PostgreSQL syntax well, though they may not know KODE OS-specific table structures.
Select `Save` to add the data source to your list. A confirmation toast appears.
Creating new data sources is uncommon. Try to solve problems with existing data sources first. If a table exists at another client but is missing from yours, add it using the same connection details.
## Optimize virtual data sources
Unoptimized virtual data sources load slower and can produce errors with large datasets. A warning banner reading "Not Optimized" appears at the top of any unoptimized data source. See [dashboard performance](/products/building-bi/concepts/dashboard-performance) for broader optimization guidance.
### Optimize from the data source page
Navigate to `Data Sources` and select the virtual data source you want to optimize.
Select the three-dot menu and choose `Edit Details`. Switch to the `SQL Expression` tab to review and modify the query. An `Optimize your Virtual Datasource` section appears at the bottom with suggestions.
Expand the `Optimize your Virtual Datasource` section. The system generates AI-powered filter suggestions to limit the data retrieved from the source. Review the suggestion and apply it to improve query performance.
Select `Save` to apply the optimization.
### Identify unoptimized sources from a dashboard
You can also check optimization status while editing a dashboard. Click `Edit Dashboard`, select a chart, and open the `Setup` panel. The `Data Source` dropdown flags any unoptimized sources so you can address them directly.
## Check column usage
Unused columns add overhead to your data sources. Use the column usage check to identify and remove them.
From the data source schema view, select the three-dot menu and choose `Check Column Usage`.
Choose which categories to scan: `Check Columns`, `Check Calculated`, and `Check Metrics`. Each category shows the total number of items. Select `Check` to run the scan.
Review the results. Columns marked "Unused" can be safely deleted to reduce source overhead.
## Point bounds and unit conversion
KODE OS stores **point high/low bounds** and a **unit conversion foundation** in the platform data model. These capabilities support analytics and diagnostics workflows in Building BI. They do not change displayed point values or trend charts by default.
Bounds and unit conversion are foundation capabilities. End-user value comes from dashboards, metrics, and filters your team builds on top of the platform data.
### Point high/low bounds
The platform applies default minimum and maximum bounds per **ontology field** based on sensor or measurement type. Admins can review and adjust bounds per point in [Point modeling](/products/kode-os/devices/device-templates#point-modeling).
When an incoming value exceeds configured bounds, the platform flags the reading with an **Out of Range** state. Use this in Building BI to:
* Filter point time series data to exclude bad readings from KPIs and rollups
* Build sensor health dashboards that list points currently out of range
* Group counts by device, system, floor, or area for calibration prioritization
* Replace dashboards that rely on static ontology bounds with platform bounds logic
After bounds are enabled for your portfolio, run **Sync Datasource** on affected tables to pull the latest columns into Building BI.
### Unit conversion foundation
The unit conversion layer normalizes compatible units within the same measurement type in the background. Use it in calculated columns and metrics when you aggregate data across buildings where the same point field may report in different units (for example, `°C` vs `°F`).
| Applies to | Does not apply yet |
| ------------------------------------------- | --------------------------------------- |
| Bounds evaluation across mixed units | Raw stored values in the database |
| Metric calculations and normalization in BI | End-user displayed values in KODE OS UI |
| Portfolio comparisons in dashboards | Trend chart display units |
[Dynamic units](/products/building-bi/widget-customization#style-tab-reference) in widget **Style** settings control chart label formatting. They are separate from the platform unit conversion foundation used in data and metrics logic.
### Build cleaner metrics
Use bounds and unit conversion together for more reliable KPIs:
1. **Normalize units** in calculated metrics when rolling up the same ontology field across sites with different `point_unit` values.
2. **Exclude out-of-range readings** so a small set of failing sensors does not skew portfolio averages or space-level rollups.
3. **Filter dashboards** on **Out of Range** in `cur_state` or related status fields to surface sensors that need calibration or replacement.
Check the **Data Quality** global template in [Templates](/products/building-bi/templates#global-templates) as a starting point for sensor health dashboards, then extend it with bounds-aware filters and metrics.
## Limitations
Calculated columns and metrics do not support window functions or aggregations of aggregations (nesting aggregate functions). This is a calculated field limit, not a ClickHouse limit. Two workarounds exist:
* **Virtual tables** -- Perform a window function or one level of aggregation in the virtual table SQL, then use the result as a regular column in your charts.
SQL dialect differs per database type. A ClickHouse expression does not work on a PostgreSQL or BigQuery data source without modification. Always verify the database type before writing or copying SQL expressions.
Thousands of calculations have been written across KODE deployments. If you are stuck, review existing calculated columns and metrics in other data sources for working examples, or ask your team for help.
## Column reference
The Point Time Series tables (Real-Time and Last Value) share a common column structure. Use this reference when building calculated columns, metrics, or filters.
| Column | Display name | Type | Description |
| ----------------- | --------------- | ------------- | ---------------------------------------------------------------------------------------------------- |
| `date_time_local` | Date Time Local | Date and Time | Localized timestamp adjusted to the building's timezone. Use for dashboards and user-facing visuals. |
| `date_time` | Date Time | Date and Time | UTC timestamp from the backend. This is the source-of-truth timestamp. |
| Column | Display name | Type | Description |
| ----------------- | --------------- | ------ | ----------------------------------------------------------------------------------------- |
| `building_id` | Building Id | String | Unique building identifier. Prefer this over `building_name` to avoid duplication issues. |
| `building_name` | Building Name | String | Building name. Can be duplicated across clients. |
| `datasource_id` | Datasource Id | String | Unique identifier for the data source providing this data. |
| `datasource_name` | Datasource Name | String | Name of the data source connection (for example, BMS or API integration). |
| `device_id` | Device Id | String | Unique identifier for the device (equipment) associated with the point. |
| `device_name` | Device Name | String | Device name (for example, AHU-1 or Pump-3). Editable and may not be unique. |
| `area_id` | Area Id | String | Unique identifier for the area (typically a floor level). |
| `area_name` | Area Name | String | Area name (usually a floor name). Aligns with floor plans if configured. |
| `point_id` | Point Id | String | Unique sensor or point identifier. Always prefer this over `point_name` for accuracy. |
| `point_name` | Point Name | String | Sensor or reading name. Can vary by naming convention. |
| Column | Display name | Type | Description |
| ---------------- | -------------- | ------- | ----------------------------------------------------------------------------------------- |
| `point_kind` | Point Kind | String | Data type of the point: Number, Boolean, or String. Determines which value column to use. |
| `point_unit` | Point Unit | String | Unit of measurement (for example, degrees F, %, or kW). |
| `point_enum` | Point Enum | String | Mapping for categorical values (for example, 1 = ON, 0 = OFF). |
| `point_writable` | Point Writable | Boolean | Indicates if the point can be overridden (true = writable from BI). |
| Column | Display name | Type | Description |
| --------------- | ------------- | ------- | ---------------------------------------------------------------------------------- |
| `number_value` | Number Value | Double | Numeric sensor reading. The most commonly used value field. |
| `string_value` | String Value | String | String-based value for points with multiple states (for example, modes or alarms). |
| `boolean_value` | Boolean Value | Boolean | Boolean value (true/false or 1/0). Often paired with enum mapping. |
| `enum_mapping` | Enum Mapping | String | Human-readable mapping of boolean or coded values. Prefer this over raw boolean. |
| Column | Display name | Type | Description |
| ------------------------------ | ---------------------------- | ------ | ----------------------------------------------------------------------------------- |
| `ontology_canonical_type` | Ontology Canonical Type | String | Standardized device type across all buildings (for example, AHU or Pump). |
| `ontology_canonical_type_name` | Ontology Canonical Type Name | String | Human-readable version of the canonical device type. |
| `device_mechanical_type` | Device Mechanical Type | String | Raw mechanical type assigned to the device (can vary by building or client). |
| `device_mechanical_type_name` | Device Mechanical Type Name | String | Display-friendly version of the mechanical type. |
| `ontology_entities` | Ontology Entities | String | Grouping field for organizing related components (less commonly used in BI). |
| `ontology_point_field` | Ontology Point Field | String | Standardized field name for the point. Normalizes inconsistent naming across sites. |
| `ontology_point_field_name` | Ontology Point Field Name | String | Human-readable version of the ontology point field. |
| `ontology_prefix` | Ontology Prefix | String | Prefix component of the ontology naming convention. |
| `ontology_suffix` | Ontology Suffix | String | Suffix component of the ontology naming convention. |
| `ontology_measurement` | Ontology Measurement | String | Measurement type (for example, Temperature or Pressure). |
| `ontology_aggregation` | Ontology Aggregation | String | Suggested aggregation type for the point (for example, avg or sum). |
| `ontology_descriptor` | Ontology Descriptor | String | Additional descriptive tag for the point within ontology. |
| Column | Display name | Type | Description |
| --------------------- | -------------------- | ------ | -------------------------------------------------------------------------- |
| `building_region` | Building Region | String | Region metadata assigned at the building level (configured in Launchpad). |
| `building_type` | Building Type | String | Type of building (for example, Office or Retail). Configured in Launchpad. |
| `building_sqft` | Building Square Feet | Double | Total square footage of the building (Launchpad metadata). |
| `building_timezone` | Building Timezone | String | Timezone of the building. Used for localization of timestamps. |
| `building_brand` | Building Brand | String | Brand or ownership grouping of the building (Launchpad metadata). |
| `building_identifier` | Building Identifier | String | Additional identifier for grouping or referencing buildings. |
| `building_district` | Building District | String | District grouping for the building (Launchpad metadata). |
| `building_zone` | Building Zone | String | Zone grouping at the building level (Launchpad metadata). |
| Column | Display name | Type | Description |
| ------------------- | ----------------- | ------- | ----------------------------------------------------------------- |
| `device_tenant` | Device Tenant | String | Tenant grouping of the device (client-specific usage). |
| `device_class` | Device Class | String | Device classification (custom metadata set in the device module). |
| `device_zone` | Device Zone | String | Zone grouping of the device within the building. |
| `device_site_level` | Device Site Level | Boolean | Indicates if the device is site-level equipment. |
| `device_location` | Device Location | String | Physical or logical location of the device within the building. |
| Column | Display name | Type | Description |
| ----------------- | ---------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cur_status` | Cur Status | String | Connectivity status of the point (OK, Fault, Disabled, or No Value). |
| `cur_state` | Cur State | String | Array of active states such as **Override**, **FDD**, **Stale**, and **Out of Range**. Requires parsing in BI. Use **Out of Range** to identify readings outside configured point bounds. |
| `datasource_type` | Datasource Type | String | Type of data source (API, BMS, AI). |
| `api_axslot_path` | Api Ax Slot Path | String | Backend reference path for API/BMS integration (primarily for engineering use). |
| `api_point_name` | Api Point Name | String | Original point name from the source system before normalization. |
## Related reading
Compare direct tables with derived virtual sources.
Choose Real-Time or Last Value Point Time Series sources.
Understand ClickHouse, PostgreSQL, and BigQuery trade-offs.
Look up column names for calculations and filters.
## Next steps
Create and configure interactive dashboards with charts, tables, and widgets.
Customize chart styles, colors, and layouts for your dashboard widgets.