Home Alternatives Time-series basics Data Center & Infrastructure Telemetry Postgres basics Postgres guides Postgres best practices

Smart Building Analytics: Turning BMS Telemetry Into Occupancy, Energy, and HVAC Insight

By Tiger Data Team

Updated at Aug 27, 2026

A building management system captures the raw telemetry: HVAC setpoints, occupancy counts, submeter readings, damper positions, alarm states. A facilities team staring at that stream still can't answer which of 40 buildings wasted the most energy last month, or which floor has run at 20% occupancy for six months. Answering that takes a layer that queries, aggregates, and scores the telemetry a BMS already produces. That's smart building analytics, a different problem than storing the data.

This piece assumes storage and schema are already settled. If you haven't worked through BACnet and Modbus, the narrow-row schema, or a first hypertable and continuous aggregate, start with the building management system database guide and come back here. This page picks up where storage ends: occupancy, energy, and HVAC analytics, a real anomaly-detection query pattern, and the portfolio-level KPI dashboards a single continuous aggregate can't support.

Quick answer: A BMS or BAS controls a building's equipment in real time: setpoints, schedules, alarms. Smart building analytics is a separate layer that turns the resulting telemetry into decisions: occupancy patterns by floor, energy benchmarks across a portfolio, equipment faults before they become work orders, and KPIs a facilities team can act on. The two are complementary, not substitutes.

Tiger Data makes a Postgres-based time-series database, so this piece naturally leans toward that answer. The goal is an honest, engineering-first explanation of what the analytics layer needs to do, not a sales pitch.

The BMS/analytics split: "controls the building" vs. "understands how it's performing"

Building-analytics vendor CopperTree Analytics puts the distinction well: a BAS or BMS "controls the building," while analytics "understands how the building is performing." Teams often treat a BMS dashboard and an analytics dashboard as competing tools, when they're two layers of the same system. The BMS operates equipment against setpoints and schedules; analytics turns the resulting history into a decision a human has to make: consolidate this floor, replace that chiller, flag this sensor as drifting.

This piece covers the three domains a facilities or operations team asks about most: occupancy, energy, and HVAC efficiency, each fundamentally a query and aggregation problem on top of data the BMS is already producing, not a reason to stand up new infrastructure.

None of this requires a second database. The same Postgres instance storing raw BMS telemetry, running TimescaleDB as the extension that turns it into hypertables, can serve the rollups, KPIs, and anomaly queries below, with no separate analytics warehouse to build and keep in sync.

Occupancy analytics: from raw sensor counts to space utilization

Occupancy analytics computes a small set of things repeatedly: utilization rate by floor or zone over time, peak-versus-off-peak patterns, and identification of space that's consistently underused relative to capacity.

The underlying pattern is a time-bucketed rollup grouped by zone or floor. That's a query concern, not a storage one; the schema for occupancy counts, motion events, or badge swipes was already covered on the Building Management System Database webpage. What changes is what you compute on top of it: instead of "how many people are in Zone 3 right now," the question becomes "what fraction of business hours was Zone 3 above 50% capacity this quarter."

Occupancy data is noisier than a raw feed suggests. Motion sensors fire on movement, not headcount; weekends and holidays distort raw averages if not flagged; partial-day patterns, like a floor that fills at 10am and empties by 3pm, get washed out by a bucket that's too coarse or too fine. The right time bucket, typically hourly for operational detail and daily or weekly for reporting, smooths over that noise without hiding the pattern that matters.

Space utilization data is what lets a portfolio operator make a defensible case for consolidating two half-empty floors, or right-sizing a lease renewal, instead of guessing.

Energy analytics: benchmarking and normalization across a portfolio

A single building's raw kilowatt-hour number tells you almost nothing on its own. Energy analytics starts at the next step: portfolio-level benchmarking, comparing consumption across sites fairly.

The idea that separates a useful benchmark from a misleading one is normalization. A building that used less energy during a mild, low-occupancy month isn't necessarily performing better than one that used more during a heat wave at full occupancy. Weather- and occupancy-normalized consumption accounts for both before ranking sites, so the benchmark reflects operational performance rather than which building had an easier month.

ApexAnalytica, an AI-powered building intelligence platform, runs exactly this kind of hourly energy rollup across dozens of live sites for portfolio-wide reporting. The BMS webpage covers how it structures that storage layer; this piece focuses on what's built on top of it.

Keep energy analytics in perspective. Maintenance makes up a substantial share of the same operating budget alongside energy costs, per industry buyer-evaluation research, a reason to treat energy as one input alongside occupancy and HVAC/FDD, not the entire case for an analytics layer.

HVAC efficiency and fault detection & diagnostics (FDD)

Fault detection and diagnostics flags specific, recognizable failure modes: simultaneous heating and cooling calls on the same air handler (a valve stuck in the wrong position), short-cycling equipment (a compressor or fan cycling far more often than its duty cycle allows), and sensor drift (a reading that slowly diverges from reality until a room feels wrong).

ASHRAE Guideline 36 is the industry standard for HVAC control sequencing and fault detection that serious platforms build to, a useful reference point for judging how rigorous a given FDD approach is.

Monitoring frequency matters more than it might seem. An interval that's too coarse, such as 15-minute smart-meter data, can miss short-cycling and similar fast-developing faults entirely, because the fault resolves within the gap between readings. Diagnostics like this need higher-frequency data than a monthly energy read provides.

Soundsensing, an AI-and-sensor-based predictive maintenance platform for HVAC units in commercial real estate, built on the same query-over-telemetry pattern as the previously mentioned use case, applied to equipment health rather than occupancy or energy.

Anomaly detection: a real query pattern

The common objection is that anomaly detection requires a full machine-learning platform before it's worth doing. It doesn't. A lightweight statistical check, flagging hourly readings that fall more than a few standard deviations from a rolling baseline, is a real, working starting point that catches a meaningful share of operational anomalies.

ApexAnalytica's production pattern combines a statistical anomaly count and a model-based anomaly count in the same join against an hourly energy rollup, returning one combined anomaly count per hour, the practical middle ground between no anomaly detection and a full MLOps pipeline.

Here's a simplified, illustrative version of the statistical half, simply a starting point to adapt (not a drop-in production query):

WITH baseline AS (
  SELECT
    bucket,
    building_id,
    kwh,
    avg(kwh) OVER (
      PARTITION BY building_id
      ORDER BY bucket
      ROWS BETWEEN 24 PRECEDING AND 1 PRECEDING
    ) AS rolling_avg,
    stddev(kwh) OVER (
      PARTITION BY building_id
      ORDER BY bucket
      ROWS BETWEEN 24 PRECEDING AND 1 PRECEDING
    ) AS rolling_stddev
  FROM energy_hourly
)
SELECT
  bucket,
  building_id,
  kwh,
  round(rolling_avg::numeric, 2) AS baseline_kwh,
  round(rolling_stddev::numeric, 2) AS baseline_stddev
FROM baseline
WHERE kwh > rolling_avg + (3 * rolling_stddev)
ORDER BY bucket DESC;

This flags any hour where consumption jumped more than three standard deviations above its trailing 24-hour baseline, per building. It's deliberately generic: swap in your own window or threshold, or add a second CTE with a model-based score and join the two the way ApexAnalytica's production query does.

Once you're flagging anomalies, IPMVP (the International Performance Measurement and Verification Protocol) is the standard for validating that a detected anomaly, and the savings from fixing it, is measured consistently.

Building portfolio KPIs and dashboards: beyond one hourly rollup

The BMS webpage’s schema section showed one hourly continuous aggregate. A real smart building dashboard at portfolio scale needs more: hourly detail for operations, daily and monthly rollups for benchmarking.

Hierarchical continuous aggregates are the mechanism. In TimescaleDB, you build a continuous aggregate on top of another instead of the raw hypertable: a daily rollup on the hourly one, a monthly rollup on the daily one. Each layer refreshes cheaply from the one below it, reusing calculations already done instead of re-scanning raw data. Each rollup's aggregated rows land in a materialized hypertable, so it scales and compresses like any other hypertable.

CREATE MATERIALIZED VIEW energy_daily
WITH (timescaledb.continuous) AS
SELECT
  building_id,
  time_bucket('1 day', bucket) AS day,
  avg(avg_kwh) AS avg_kwh,
  max(max_kwh) AS max_kwh
FROM energy_hourly
GROUP BY building_id, time_bucket('1 day', bucket);

SELECT add_continuous_aggregate_policy('energy_daily',
  start_offset => INTERVAL '3 days',
  end_offset => INTERVAL '1 day',
  schedule_interval => INTERVAL '1 day');

A monthly rollup stacks on the daily one the same way. One restriction to know: you can't stack a fixed-width bucket on a variable-width one, but a calendar month on a fixed-width daily aggregate works fine.

CREATE MATERIALIZED VIEW energy_monthly
WITH (timescaledb.continuous) AS
SELECT
  building_id,
  time_bucket('1 month', day) AS month,
  avg(avg_kwh) AS avg_kwh,
  max(max_kwh) AS max_kwh
FROM energy_daily
GROUP BY building_id, time_bucket('1 month', day);

SELECT add_continuous_aggregate_policy('energy_monthly',
  start_offset => INTERVAL '3 months',
  end_offset => INTERVAL '1 day',
  schedule_interval => INTERVAL '1 day');

Refresh policy is the lever for freshness, not a fixed rule. An occupancy dashboard checked all day wants a short schedule_interval; a monthly benchmarking report finance reviews once a period doesn't. Set each level's refresh policy to match who's looking and how often.

Compression is new territory past the pillar, which only compressed raw chunks. A continuous aggregate can go cold the same way: once a rollup stops being actively refreshed for a range, it's a candidate for the columnstore, via add_columnstore_policy, or by setting compress_after_refresh on the refresh-policy job so newly refreshed chunks convert automatically:

ALTER MATERIALIZED VIEW energy_monthly SET (
  timescaledb.enable_columnstore = true
);

CALL add_columnstore_policy(
  'energy_monthly',
  after => INTERVAL '4 months'
);

Keep the columnstore after interval larger than the refresh policy’s start_offset, so the policy never compresses a range that’s still being actively refreshed. See compression on continuous aggregates for the full sequencing rules.

If you already have bms_hourly or a similar single rollup from the pillar's example, this is additive: layer a daily and monthly aggregate on top of it without touching ingestion.

Decision framework: which analytics layer should you build first?

Most teams can't build occupancy, energy, and HVAC/FDD analytics at once. Here's how to pick a starting point.

Start with occupancy analytics if:

Space planning or right-sizing drives the need, and occupancy data already flows into your BMS.
You want a fast, low-complexity win: a single rollup grouped by zone is enough.

Start with energy analytics if:

Cost reduction and portfolio benchmarking drive the need, across more than one site where a normalized comparison matters.
Energy rollups are also the most common base for the anomaly-detection pattern above.

Start with HVAC efficiency and FDD if:

Equipment reliability or comfort complaints are the pain point, you have higher-frequency HVAC data rather than monthly meter reads, and you're ready to invest in anomaly detection first.

Invest in hierarchical continuous aggregates now if:

You manage more than a handful of buildings and need daily and monthly reporting on top of hourly detail, or dashboard freshness differs by audience.

A single continuous aggregate is probably enough if:

You manage one building or a few sites with no cross-portfolio reporting need, and one hourly rollup already answers your questions.

What this looks like in production

ApexAnalytica is worth a closer look on the analytics-layer side. The platform runs Ask Apex, an AI agent built on pgvector in the same Postgres instance that stores the building telemetry, reasoning over building documentation and live telemetry together, pairing an analytics and AI layer with the underlying data in one database instead of a separate stack.

ApexAnalytica's stated roadmap includes evaluating continuous aggregates with incremental refresh policies to replace a custom refresh service, and columnstore compression on cold chunks, both the kind of "go deeper than one hourly rollup" work described above. The platform also states it targets ASHRAE Guideline 36-aligned fault detection and IPMVP-compliant measurement and verification, the same two standards referenced earlier.

If you arrived without the storage and schema fundamentals, start with the building management system database guide for BACnet and Modbus, the narrow-row schema, and a first continuous aggregate.

For the same rollup-and-benchmark pattern applied to grid and utility data, see Tiger Data's energy and utilities time-series use cases. For the same pattern applied to a different vertical, the fleet telemetry database guide covers vehicle sensor data at scale. For implementation detail on building a dashboard on top of a rollup like the ones here, see the guide to setting up a real-time energy data analytics dashboard.

A companion piece on building energy management system databases is planned as a further follow-up, going deeper into energy-specific reporting than this guide covers.

FAQ

What's the difference between a building management system and building analytics?

A BMS or BAS operates equipment in real time: setpoints, schedules, alarms. Building analytics turns the resulting telemetry history into occupancy, energy, and maintenance decisions. They work together, not as substitutes.

What is building analytics?

Querying and aggregating the telemetry a BMS or sensor network already produces to answer occupancy, energy, and equipment-performance questions across one building or a whole portfolio.

What is an HVAC analytics platform?

Software that monitors HVAC telemetry for efficiency and fault patterns, including simultaneous heating and cooling calls, short-cycling, and sensor drift, surfacing them before they become costly repairs or comfort complaints.

What is fault detection and diagnostics (FDD) in building analytics?

The automated process of flagging abnormal equipment behavior from telemetry data. Serious platforms align their FDD logic with ASHRAE Guideline 36, the named industry framework for HVAC control sequencing and fault detection.

How do you calculate space or occupancy utilization from sensor data?

Occupied time, or occupant count, divided by available time or capacity for a given zone and period, typically computed with a time-bucketed rollup grouped by zone or floor.

Does building analytics software control equipment, or just provide visibility?

Primarily visibility and decision support. It surfaces what's happening and what needs attention; equipment control stays with the BMS or BAS, though some platforms feed recommendations back into that loop.

Can I run building analytics directly on the same database that stores my BMS telemetry?

Yes. Continuous aggregates, hierarchical rollups, and anomaly queries can all run on the same Postgres instance, running TimescaleDB, that stores the raw telemetry, with no second analytics database required.

Do I need a full machine-learning platform before anomaly detection is worth doing?

No. A simple statistical flag, such as an hourly reading several standard deviations outside its rolling baseline, is a real starting point before any ML investment. Production platforms often add a model-based score later in the same query.

How much does a smart building analytics platform cost to implement?

Industry sources put implementation in the range of a few cents to roughly a dime per square foot up front, plus a low-single-digit-cents-per-square-foot annual subscription. Figures vary widely by scope and vendor; treat this as a rough planning benchmark, not a quote.

What's the ROI of smart building analytics?

Energy-savings claims vary by source and building type; studies suggest significant savings are achievable, though exact figures depend heavily on baseline conditions. Maintenance-cost reduction and faster fault detection are additional, harder-to-quantify components of ROI beyond energy alone.

Am I providing a healthy indoor environment for occupants?

Indoor air quality data, such as CO2, particulates, and humidity, can be rolled up and benchmarked the same way occupancy and energy data are, giving a portfolio operator a defensible answer rather than a guess.

What's the difference between an HVAC analytics platform and a general building analytics platform?

An HVAC-analytics platform focuses specifically on heating, cooling, and ventilation equipment and its fault detection. A general building analytics platform typically spans occupancy, energy, and HVAC together across a portfolio; the concepts here apply to both.

Smart Building Analytics: Turning BMS Telemetry Into Occupancy, Energy, and HVAC Insight

By Tiger Data Team

Updated at Aug 27, 2026

The BMS/analytics split: "controls the building" vs. "understands how it's performing"

Occupancy analytics: from raw sensor counts to space utilization

Space utilization data is what lets a portfolio operator make a defensible case for consolidating two half-empty floors, or right-sizing a lease renewal, instead of guessing.

Energy analytics: benchmarking and normalization across a portfolio

A single building's raw kilowatt-hour number tells you almost nothing on its own. Energy analytics starts at the next step: portfolio-level benchmarking, comparing consumption across sites fairly.

HVAC efficiency and fault detection & diagnostics (FDD)

Anomaly detection: a real query pattern

Here's a simplified, illustrative version of the statistical half, simply a starting point to adapt (not a drop-in production query):

WITH baseline AS (
  SELECT
    bucket,
    building_id,
    kwh,
    avg(kwh) OVER (
      PARTITION BY building_id
      ORDER BY bucket
      ROWS BETWEEN 24 PRECEDING AND 1 PRECEDING
    ) AS rolling_avg,
    stddev(kwh) OVER (
      PARTITION BY building_id
      ORDER BY bucket
      ROWS BETWEEN 24 PRECEDING AND 1 PRECEDING
    ) AS rolling_stddev
  FROM energy_hourly
)
SELECT
  bucket,
  building_id,
  kwh,
  round(rolling_avg::numeric, 2) AS baseline_kwh,
  round(rolling_stddev::numeric, 2) AS baseline_stddev
FROM baseline
WHERE kwh > rolling_avg + (3 * rolling_stddev)
ORDER BY bucket DESC;

Building portfolio KPIs and dashboards: beyond one hourly rollup

CREATE MATERIALIZED VIEW energy_daily
WITH (timescaledb.continuous) AS
SELECT
  building_id,
  time_bucket('1 day', bucket) AS day,
  avg(avg_kwh) AS avg_kwh,
  max(max_kwh) AS max_kwh
FROM energy_hourly
GROUP BY building_id, time_bucket('1 day', bucket);

SELECT add_continuous_aggregate_policy('energy_daily',
  start_offset => INTERVAL '3 days',
  end_offset => INTERVAL '1 day',
  schedule_interval => INTERVAL '1 day');

CREATE MATERIALIZED VIEW energy_monthly
WITH (timescaledb.continuous) AS
SELECT
  building_id,
  time_bucket('1 month', day) AS month,
  avg(avg_kwh) AS avg_kwh,
  max(max_kwh) AS max_kwh
FROM energy_daily
GROUP BY building_id, time_bucket('1 month', day);

SELECT add_continuous_aggregate_policy('energy_monthly',
  start_offset => INTERVAL '3 months',
  end_offset => INTERVAL '1 day',
  schedule_interval => INTERVAL '1 day');

ALTER MATERIALIZED VIEW energy_monthly SET (
  timescaledb.enable_columnstore = true
);

CALL add_columnstore_policy(
  'energy_monthly',
  after => INTERVAL '4 months'
);

If you already have bms_hourly or a similar single rollup from the pillar's example, this is additive: layer a daily and monthly aggregate on top of it without touching ingestion.

Decision framework: which analytics layer should you build first?

Most teams can't build occupancy, energy, and HVAC/FDD analytics at once. Here's how to pick a starting point.

Start with occupancy analytics if:

Space planning or right-sizing drives the need, and occupancy data already flows into your BMS.
You want a fast, low-complexity win: a single rollup grouped by zone is enough.

Start with energy analytics if:

Cost reduction and portfolio benchmarking drive the need, across more than one site where a normalized comparison matters.
Energy rollups are also the most common base for the anomaly-detection pattern above.

Start with HVAC efficiency and FDD if:

Equipment reliability or comfort complaints are the pain point, you have higher-frequency HVAC data rather than monthly meter reads, and you're ready to invest in anomaly detection first.

Invest in hierarchical continuous aggregates now if:

You manage more than a handful of buildings and need daily and monthly reporting on top of hourly detail, or dashboard freshness differs by audience.

A single continuous aggregate is probably enough if:

You manage one building or a few sites with no cross-portfolio reporting need, and one hourly rollup already answers your questions.

What this looks like in production

If you arrived without the storage and schema fundamentals, start with the building management system database guide for BACnet and Modbus, the narrow-row schema, and a first continuous aggregate.

A companion piece on building energy management system databases is planned as a further follow-up, going deeper into energy-specific reporting than this guide covers.

FAQ

What's the difference between a building management system and building analytics?

What is building analytics?

Querying and aggregating the telemetry a BMS or sensor network already produces to answer occupancy, energy, and equipment-performance questions across one building or a whole portfolio.

What is an HVAC analytics platform?

What is fault detection and diagnostics (FDD) in building analytics?

How do you calculate space or occupancy utilization from sensor data?

Occupied time, or occupant count, divided by available time or capacity for a given zone and period, typically computed with a time-bucketed rollup grouped by zone or floor.

Does building analytics software control equipment, or just provide visibility?

Can I run building analytics directly on the same database that stores my BMS telemetry?

Do I need a full machine-learning platform before anomaly detection is worth doing?

How much does a smart building analytics platform cost to implement?

What's the ROI of smart building analytics?

Am I providing a healthy indoor environment for occupants?

What's the difference between an HVAC analytics platform and a general building analytics platform?

Smart Building Analytics: Turning BMS Telemetry Into Occupancy, Energy, and HVAC Insight

The BMS/analytics split: "controls the building" vs. "understands how it's performing"

Occupancy analytics: from raw sensor counts to space utilization

Energy analytics: benchmarking and normalization across a portfolio

HVAC efficiency and fault detection & diagnostics (FDD)

Anomaly detection: a real query pattern

Building portfolio KPIs and dashboards: beyond one hourly rollup

Decision framework: which analytics layer should you build first?

Start with occupancy analytics if:

Start with energy analytics if:

Start with HVAC efficiency and FDD if:

Invest in hierarchical continuous aggregates now if:

A single continuous aggregate is probably enough if:

What this looks like in production

Related reading

FAQ

Smart Building Analytics: Turning BMS Telemetry Into Occupancy, Energy, and HVAC Insight

The BMS/analytics split: "controls the building" vs. "understands how it's performing"

Occupancy analytics: from raw sensor counts to space utilization

Energy analytics: benchmarking and normalization across a portfolio

HVAC efficiency and fault detection & diagnostics (FDD)

Anomaly detection: a real query pattern

Building portfolio KPIs and dashboards: beyond one hourly rollup

Decision framework: which analytics layer should you build first?

Start with occupancy analytics if:

Start with energy analytics if:

Start with HVAC efficiency and FDD if:

Invest in hierarchical continuous aggregates now if:

A single continuous aggregate is probably enough if:

What this looks like in production

Related reading

FAQ