Handling Sensor Units and Scaling in BMS Analytics

Build an analytics rule for one air handling unit and it works. Apply it across forty units from three manufacturers installed over fifteen years and it produces nonsense on a third of them. The usual diagnosis is that the rule needs tuning. The actual cause, most of the time, is that the same physical quantity is represented differently on different units, and the rule is comparing values that are not in the same units.

The message up front: pick one canonical unit per quantity for the whole estate, convert on the way in, and store the original alongside the converted value so the conversion is auditable. Capture the unit from the device rather than inferring it from a name. And resist the urge to normalise silently: a conversion that cannot be traced is indistinguishable from a bug, and analytics built on untraceable conversions cannot be debugged when it eventually disagrees with the building.

1. Where the meaning can change

Five places, each capable of altering the number without altering anything visible.

• The sensor. Its range and output characteristic determine what the raw signal means. A transmitter ranged for one span fitted where another was specified produces readings wrong in proportion.
• The controller input. Raw signal converted to an engineering value by a scaling configuration. A scaling that does not match the device fitted is the most common single error, and it is covered from the commissioning side in BMS points lists and field devices.
• The object's declared unit. What the controller says the value is in, which may or may not match what the scaling actually produces. The property exists and is described in BACnet objects and addressing.
• The integration. Any conversion applied in a gateway, middleware or collector, which may be configured per point and documented nowhere.
• The analytics or reporting layer. A final conversion, often applied because somebody noticed a value looked wrong and compensated rather than tracing the cause.

Each layer is defensible on its own. The failure is cumulative: a conversion applied twice, or in two layers that each assume the other did not, produces a value that is internally consistent and wrong.

2. The specific errors that recur

3. A canonical unit per quantity

The decision is less about which unit than about having exactly one, declared, for the whole estate.

• One unit per physical quantity, written down, applied without exception. Where an estate spans regions with different conventions, convert at presentation rather than storing both.
• Distinguish quantity types that share a unit. An absolute pressure and a differential pressure may both be reported in the same unit and must not be compared. The quantity type is a separate field from the unit.
• Record the sign convention for anything directional, because it is a convention rather than a property of the measurement.
• Treat dimensionless values carefully. Percentages, ratios and indices need a declared basis, because the number alone does not carry it.
• Store the canonical unit against the point in the register described in the BMS point dictionary, with effective dates, so a change of convention is visible in the history.

Meter points carry additional semantics beyond units, principally whether they report a rate or a quantity and whether that quantity is cumulative, and those are handled separately in validating meter units before energy reports.

4. Why analytics is where this surfaces

A single operator looking at a single graphic tolerates inconsistency easily, because they know their building and mentally adjust. Three properties of analytics remove that tolerance.

• Rules are written once and applied to many points. A threshold that is correct in one unit is wrong by a factor in another, and the rule has no way to know.
• Comparison across assets is the point. Benchmarking forty units against each other is meaningless if they are not in the same units, and the output looks like genuine variation between units rather than a data defect.
• Derived quantities multiply the error. Anything computed from two readings inherits both their unit assumptions, so an efficiency or a load calculation can be wrong in ways neither input reveals.
• Models learn the inconsistency. A statistical approach trained across mixed units will treat the unit difference as a real pattern, which is one of the prerequisites discussed in anomaly detection data readiness.

5. Finding the problems in existing data

• Group by quantity and compare distributions across points. Points measuring the same thing should have broadly similar ranges. Those sitting a clean factor away from the rest are the unit errors, and this is the single most productive check.
• Plausibility bands per quantity. Not alarm limits but physical possibility. Anything outside is a data problem whatever the plant is doing.
• Compare the declared unit against the observed range. A point declaring one unit while reporting values typical of another is self-evidently mis-scaled.
• Cross-point relationships. Values that must bear a physical relationship to each other, and do not, indicate one of them is in the wrong units. The consistency-check approach is in BACnet data quality flags.
• Audit where conversions are configured. The only way to find double conversion, and it is a documentation exercise rather than a query.

6. Preventing it on new work

• Require declared units in the points schedule, per point, as a deliverable rather than an optional column.
• Require the scaling configuration to be documented against the device actually fitted, with make, model and range.
• Verify units during acceptance, by comparing the declared unit against the object property and against the observed range, which is part of the set in the BACnet integration acceptance test checklist.
• State where conversion happens in the integration design, once, and require every other layer to pass values through unmodified.
• Make a unit or scaling change a recorded event with effective dates, because it creates a step in the history exactly as an instrument change does.

The idea to walk away with

Units are not presentation, they are part of the value. A number stored without its unit is incomplete, and a number converted without a record of the conversion is unverifiable.

So capture the unit from the device, convert once on ingestion to a canonical unit declared for the whole estate, keep the original alongside, and record the quantity type and sign convention separately because the unit alone does not carry them. Everything analytical becomes possible after that and remains unreliable before it.

Final thoughts

The most productive hour available here is a distribution comparison: group every point by the quantity it measures and plot the ranges side by side. Unit errors do not hide in that view, because they sit a clean factor away from their peers.

It is also the exercise that tends to change people's confidence in their own data, because the scale of the inconsistency across a mixed estate is usually larger than expected and entirely fixable once it is visible.

Related reading: Validating meter units, BACnet data quality flags, BMS point dictionary, BMS points lists and field devices, Sensor replacement and BMS history, BACnet objects and addressing.