Energy management
Energy Management for Buildings
How building energy management connects metering, baselines, PV, storage, EV charging and tariffs to one control platform — and what it can and cannot do.
What building energy management covers
Building energy management starts with a map of where energy enters, where it is converted and where it is used. Main meters, sub-meters, heat and gas meters, PV inverters, battery systems and EV charge points each contribute a different view. The platform brings those streams into one model, so a facility team can compare a floor, a tenant, a plant item or a whole building on the same basis. Metering is not the goal. The goal is a reliable account of consumption that can be questioned, normalised and acted on. Without that account, every saving claim is a guess and every tariff decision is made on last month's bill. A useful platform also records the operating context: opening hours, occupancy, production shifts and plant schedules. Consumption without context cannot be interpreted, and a chart that cannot be interpreted rarely changes how a building is run.
- Main, sub-, heat, gas and water meters on one data model
- Consumption by building, floor, tenant and plant item
- Operating context recorded alongside the readings
Metering architecture and data quality
A metering architecture decides how much of the building can be explained. A single main meter reports the total but cannot separate tenants, plant items or after-hours use. Sub-metering should follow the questions the operator needs to answer: by tenant, by floor, by major plant and by special load. Each meter needs a defined point name, unit, multiplier, interval and quality flag. Pulse outputs are inexpensive but lose resolution and cannot report power quality; Modbus and BACnet meters give richer data but depend on a correct register or object map. Current transformers must be sized and fitted on the right conductor. Data quality belongs in the design: missing intervals, meter resets, clock drift and estimated reads should be flagged rather than smoothed away. A platform that presents every reading as equally valid will produce confident reports that are wrong. The metering plan should also record who owns each meter, who reads it and who is called when it fails.
- Sub-metering follows the questions the operator must answer
- Every meter has a name, unit, multiplier and quality flag
- Gaps, resets and estimated reads are flagged, not hidden
Baselines, normalisation and verification
A baseline is only useful if it reflects the conditions the building actually operated under. Weather, occupancy, opening hours and production schedules all change consumption. Degree-day normalisation, occupancy profiles and floor-area allocation let a team compare periods without arguing about the weather. The method should be agreed before any change is made, not selected afterwards to fit the result. Data quality matters as much as the analysis: missing intervals, meter resets, time-zone errors and estimated reads distort every comparison. The platform should hold the last valid value with a quality tag, show the gap and record any correction. A baseline that cannot be defended will not survive a budget review, an energy audit or a tenant dispute. The baseline period, the normalisation method, the excluded periods and the data completeness belong in the handover pack.
- Weather and occupancy normalisation before comparison
- Method agreed before the change, not after the result
- Baseline, exclusions and completeness documented at handover
Solar, storage and EV charging
Distributed energy assets turn a passive consumer into an active operator. PV inverters report generation, battery systems report state of charge and available power, and EV chargers report session demand. Integration is usually through Modbus, a vendor API or a dry contact for status only. Once those points are on the platform, control becomes possible: charge vehicles when generation is high, hold battery discharge for a tariff peak, or limit export at the point of connection. The control sequence must respect the asset manufacturer's limits and the site's electrical protection. The platform coordinates; it does not replace the inverter's own safety functions. A typical commercial scheme might pair a roof array of a few hundred kWp with a battery sized for peak shaving, but the ratio depends on the load profile, the tariff and the export rules. Sizing belongs to an energy study, not to the control platform.
- PV yield, self-consumption and export monitoring
- Battery state of charge and discharge scheduling
- EV charging shifted toward generation or off-peak tariffs
Tariffs, peak demand and load control
Time-of-use tariffs, capacity charges and demand charges reward a building for shifting load, not only for using less. The platform can rank flexible loads, apply schedules, stage setpoint changes and shed non-critical demand before a peak is reached. Lighting, ventilation, domestic hot water, pool pumps and EV charging are common candidates, provided comfort and service levels are protected. Every shed command needs a release condition, a maximum duration and an operator override. Load control should be visible in the same interface as the meters that justify it; otherwise the building reacts to a number nobody can explain. The sequence also needs a manual mode, because a demand-response event, a generator test and a genuine overload look similar in the data. Operators should be able to see which loads are available, which are locked out and why, before they intervene. Tariff logic changes with contracts, so the rules should be configurable, versioned and reviewed whenever the supply agreement changes.
- Peak demand forecasting and staged load shedding
- Release conditions and operator override on every shed
- Tariff rules versioned and reviewed with the contract
Reporting, allocation and tenant billing
Reporting is where energy data becomes accountable. Tenant allocation needs accurate sub-metering, an agreed set of common-area charges and a published reconciliation method. A dashboard can show consumption, but a statement that can be issued, queried and corrected needs a data model behind it. The platform should separate consumption from generation, cost from carbon, and measured data from estimated data. Reports should state the period, the boundaries, the tariff applied and the completeness of each account. Alarm handling belongs here too: a meter that stops reporting is a data fault, not a saving. Trends should be exportable at a known interval and retained for the period agreed with the client. Where a tenant disputes a charge, the operator should be able to show the meter, the multiplier, the allocation rule and the correction history without leaving the platform.
- Separate measured, estimated and generated data
- Allocation rules and reconciliation method published
- Every charge traceable to meter, multiplier and rule
Commissioning, operation and handover
Commissioning proves that meters, interfaces and calculations agree. Each meter should be checked against its own display, the utility bill or a portable meter; each multiplier and unit should be verified; each data gap should be explained. The baseline should be recalculated with real data, and the first month of reporting reviewed with the operator before it is issued. Handover includes the metering schematic, the point list, the tariff configuration, the report templates, the allocation rules and the data retention policy. Operators need training on how to read a gap, how to correct a reading and who to call when a meter fails. The system should also survive staff changes: a report that depends on one person's spreadsheet is not a system. A quarterly review of data quality and tariff changes keeps the platform honest.
- Each meter verified against a second reference
- First reporting month reviewed before release
- Data quality and tariff reviewed each quarter
Energy functions, interfaces and data checks
14 rows| Function | Typical source | Interface | Platform role and data check |
|---|---|---|---|
| Main incomer metering | Utility meter or current transformers | Pulse, Modbus, BACnet | Trend demand, compare tariff periods, verify against the bill |
| Sub-metering by floor or tenant | kWh meters | Modbus RTU/TCP | Allocate consumption, detect anomalies and confirm multipliers |
| Heat metering | Heat or BTU meter | Pulse or Modbus | Normalise heating by weather and check flow and return temperatures |
| Gas and water metering | Utility or pulse meters | Pulse or Modbus | Track fuel and water intensity, flag standing use |
| Power quality and demand | Power analyser or multifunction meter | Modbus | Record peaks, power factor and voltage excursions |
| PV generation | Inverter | Modbus or vendor API | Track yield, self-consumption and export; check availability |
| Battery storage | Battery controller | Modbus or API | Monitor state of charge and schedule discharge within limits |
| EV charging | Charge point management | API or Modbus | Shift sessions, cap site demand and report energy delivered |
| Tariff and demand response | Tariff schedule and meter data | Platform configuration | Forecast peaks, stage shedding and record each event |
| Load shedding and staging | BAS loads and setpoints | Local I/O or field bus | Shed and restore with release conditions and override |
| Tenant allocation and billing | Sub-meters and floor areas | Platform data model | Apply allocation rules and reconcile before issue |
| Carbon and intensity reporting | All metered data | Platform data model | Report intensity and verify the baseline method |
| Data quality and alarms | All metered points | Platform data model | Flag gaps, resets, stale values and estimated reads |
| Export and retention | Historian or database | API or file export | Provide interval data, audit trail and retention control |
Project images
3 images
Frequently asked
01How does a building energy management system collect data?
Through meters and gateways already on site, or through new meters where none exist. The platform reads pulse, Modbus, BACnet or vendor APIs, normalises the points and stores interval data locally. The design should state the interval, the retention period and how gaps are flagged, because those choices determine what can later be reported and verified.
02Can you integrate the meters we already have?
Often, yes. A survey confirms the protocol, the register map, the multiplier and the data quality first. Meters with only a pulse output can still be integrated, but estimated or missing intervals must be flagged and excluded from any baseline. Very old meters with no readable output may need replacement if billing or verification depends on them.
03Do we need battery storage to benefit?
No. Metering, baselines, scheduling and load control deliver value on their own. Storage adds flexibility, but it is an investment decision that should follow the load profile, the tariff and the export rules, not precede them. A building that cannot explain its consumption will not operate a battery well, and a battery will not fix a data problem.
04How are energy savings verified?
Against an agreed baseline, with the same normalisation method before and after the change. The report states data completeness and any adjustments, so the result can be reviewed rather than accepted on trust. Verification should be planned with the measurement boundary, the adjustment rules and the review period written down before the first measure is implemented.
05Can the platform control PV and EV charging?
It can coordinate them where the inverter and charge point expose a suitable interface. Safety limits, export limits and the manufacturer's operating restrictions stay in force. Control is usually limited to setpoints, start and stop commands and current limits; protection settings remain with the electrical installation and the asset controllers.
06Does energy management require a cloud connection?
No. Control and interval data can run locally. Cloud services are optional for remote reporting or multi-site roll-up, and should not sit on the critical path. If a cloud service is used, the contract should state where data is stored, how long it is retained and what happens when the connection is lost.
07Can tenants be billed from the same data?
Where sub-metering is accurate and the allocation rules are agreed, yes. Billing adds a reconciliation process, so the data model, the common-area method and the dispute procedure should be defined before the first invoice. The platform supplies evidence; the lease and the local rules decide what may be charged.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.