A mid-size office building's BMS may collect 300 to 1,000 data points every 15 seconds to five minutes. Zone temperatures, supply air, chilled water, fan speed, static pressure, occupancy, and metered electrical use all flow into a historian. The system records it continuously. Almost none gets reviewed. In commercial building energy management, the core problem is simple: the data and working sensors are present, but nobody is listening.
The BMS Was Built to Monitor, Not Act Alone
To see why BMS data often goes unused, start with its original purpose. Building management systems give trained operators a monitoring screen and manual controls. Alarms flag readings outside set thresholds. Trend logs preserve history for post-incident review. Controls let operators change setpoints, override schedules, and stage equipment by hand when required.
That design fit a period of more labor-intensive operations, when a trained operator was expected to review and respond to system data. It does not create autonomous optimization. The BMS asks, "Is anything beyond the alarm thresholds?" It does not ask, "Given everything I see, can this building be conditioned more efficiently right now?" Most energy waste sits between those questions.
Alarm Thresholds Leave Blind Spots
BMS alarms target conditions needing immediate human intervention. A summer zone temperature above 85F can signal equipment failure or lost cooling. A chiller offline is an alarm. So is a critical sensor sending an out-of-range value. These alerts support reliability and life safety, and they serve that role well.
Many efficiency losses never cross an alarm limit, so this architecture misses them. A zone 2F above setpoint for four hours because a VAV box is slightly undersized for the tenant configuration is not an alarm. Chilled water return temperature rising over three days as plant efficiency slowly declines is not an alarm when the delta remains in range. An AHU at 85% fan speed when 70% would meet the load is not an alarm if both settings remain within design limits.
The BMS stream shows every condition. None prompts action. The data exists, but alarm architecture was not built to address inefficiency below its thresholds.
The Unread Stream at Scale
The volume of data puts sub-threshold pattern review beyond practical manual work. A BMS collecting 500 data points at 30-second intervals produces 1,440 readings per point each day, or 720,000 readings daily. Searching those readings for efficiency patterns instead of alarms is a manual needle-in-a-haystack task.
Some facilities teams in early BMS deployments review trends by hand: zone temperatures once a week, supply air during peak load, and chiller performance in summer. Careful review can reveal useful information. It cannot scale to a 500-point historian, and the result arrives days or weeks after the period when real-time adjustment was possible.
In most facilities teams, the historian gathers months or years of records. People query it after an incident, once equipment has failed or a complaint has arrived. The history serves forensic review, not continuous prediction.
What Data-Driven Action Needs
Continuous BMS action needs three capabilities missing from historian-plus-manual review:
First comes real-time pattern detection. A zone 1F above setpoint for 20 minutes may be a normal high-load transient. The same 1F gap for four hours every weekday afternoon points to a recurring mismatch between zone demand and AHU capacity. Seeing that difference requires time-based pattern analysis, including comparison with historical norms for that zone, time, and weather.
Second is cross-system correlation. A zone that stays warm during the afternoon peak becomes actionable when matched with AHU fan speed, supply air temperature, and VAV damper position from the same window. An AHU at 100% fan speed with the zone's VAV damper 100% open indicates an HVAC capacity problem needing engineering attention. At 70% fan speed with the damper 45% open, the likely issue is control-related. The responses differ completely. The BMS holds both streams, but they are not being read together.
Third is automatic response within approved limits. Detecting a pattern and applying an adjustment closes the loop left open by BMS monitoring. If chilled water return temperature has climbed for 18 hours while the building's thermal model shows lower than typical cooling load, chilled water supply temperature can be reset upward. That reduces compressor work when the load can support warmer supply water. No human decision is needed, only a rule evaluated against current conditions and executed.
Start With Existing Sensors
We often hear that acting on BMS data demands sensor upgrades: more points, faster readings, or added instruments in under-metered zones. Some advanced applications do need that. In a typical commercial BMS, however, the facilities team already has more data than it uses. The limitation is the analysis layer, not sensor coverage.
That observation is where DomeSystems begins. Its BMS connection reads existing streams. The analysis layer creates thermal models and occupancy patterns from them. Control actions send setpoint changes through the same BMS interface, within limits set by the facilities team. No new sensors are needed to begin. The value comes from using data already accumulating quietly in the historian.
Why It Matters Now
Since 2022, commercial real estate energy costs have taken a larger place in operating budgets because of higher energy prices and mounting regulatory pressure in major metro areas. Buildings once comfortable with "BMS runs, alarms are answered, everything else is the quarterly utility bill" now face pressure to show operational efficiency gains.
The data needed for those gains has been present all along. Sensors run, but nobody listens. Better operations begin by reading what existing hardware already reports, not by installing new hardware.