KNX Building Energy Management: Metering, Tariffs and Demand Response
A KNX building energy management system puts MID-certified meters on a Modbus RTU bus, maps active energy and power to KNX group addresses through a gateway, and layers time-of-use tariff scheduling and SG Ready demand response on top. This article covers the metering hardware, the group address schema, the gateway mapping and the two failure modes that most often break commissioning.
What a KNX energy management system actually has to do
A working installation does four things in a fixed order: it measures at the meter, it exposes each measured value as a KNX group object, it schedules load behaviour against the utility's tariff calendar, and it accepts an external demand-response signal without overriding the occupant's own commands. Skip the ordering and the dashboard fills with numbers nobody trusts.
For BREEAM Ene 01 or Ene 02 credits, the assessor wants sub-metering coverage of the main end-use categories and read access to the data from the building's own energy management system, not a spreadsheet exported once a year. Design the group address schema in the next section with that audit in mind.
Metering hardware: MID-certified meters on Modbus RTU
Specify MID Class B (or better) energy meters with a native RS-485 Modbus RTU output; ABB's B21/B23/B24 series direct-connected and CT-connected meters are a common choice for panel-mounted sub-metering because the same RS-485 trunk can carry every meter in the panel back to one gateway. Take the exact holding-register map from the ABB Modbus register table for the firmware revision you actually receive — addresses have shifted between revisions on some models, and a wrong offset silently returns the wrong phase.
The same RS-485 trunk, or a separate M-Bus segment bridged through an M-Bus-to-Modbus converter, can also carry heat meters (EN 1434, MID Class 2) and gas meters (MID Annex MI-002) with a pulse or M-Bus output, so electricity, heat and gas end up in the same gateway and the same group address block.
- Direct connection, typically up to 65 A per phase
- MID Class B accuracy
- RS-485 Modbus RTU, 2400–19200 baud
- S0 pulse output as a wired fallback
| Model | Connection | Typical rating | Output |
|---|---|---|---|
| ABB B21 | Single-phase, direct | up to 65 A | Modbus RTU / S0 |
| ABB B23 | Three-phase, direct | up to 65 A per phase | Modbus RTU / S0 |
| ABB B24 | Three-phase, CT | per CT ratio (5 A or 1 A secondary) | Modbus RTU |
Bus loading: Modbus RTU on RS-485 needs 120 Ω termination at both physical ends of the trunk and one common reference conductor; stub cables longer than about 0.3 m, or more than roughly 30 devices on an unterminated line, produce intermittent CRC errors that look like a meter fault but are actually reflection on the bus.
Mapping meter data to KNX group addresses
The gateway polls each meter's holding registers on its own schedule and republishes every value it reads as an independent KNX group write, so design the group address block before configuring the gateway, not after. Keep one middle group per meter and one sub-group per quantity, so adding a meter only adds a middle group instead of renumbering the installation.
Use DPT 13.010 (4-byte signed active energy, Wh) for cumulative import/export counters and DPT 14.056 (4-byte float active power, W) for the instantaneous power object; both are standard KNX datapoint types that every visualization, including BewO, already understands. There is no dedicated KNX tariff DPT, so document any repurposed byte object in the group address comments rather than relying on the DPT name to carry that meaning.
| Object | DPT | Notes |
|---|---|---|
| Active energy import | DPT 13.010 | Cumulative Wh, resettable only at the meter |
| Active power | DPT 14.056 | Instantaneous W; a 5–10 s refresh is enough for a dashboard |
| Active tariff | DPT 5.010 | Repurposed 1-byte counter: 0 off-peak, 1 standard, 2 peak |
| SG Ready state | DPT 5.010 | Decoded 4-state value, see the demand response section |
Give the gateway and every KNXnet/IP interface a static or DHCP-reserved address; BewO and most third-party dashboards poll over a KNXnet/IP tunnel and will silently stop updating for hours if the interface's address changes while the client still has the old one cached.
Gateway configuration and the BewO dashboard
The Modbus-to-KNX gateway is the only device that needs to speak both protocols; everything downstream, including the ARISTO BewO dashboard, only ever talks KNX. Configure one mapping row per register: source register and data type on the Modbus side, target group address and DPT on the KNX side, plus a scale factor if the meter's native unit does not match the DPT — some meters report Wh, others kWh ×10, so read the register's scale field rather than assume it.
# illustrative register-to-group-address mapping — adapt the syntax to your gateway reg=40001 len=2 type=uint32 scale=1 -> ga=3/1/1 dpt=13.010 # active energy import, Wh reg=40007 len=2 type=float32 -> ga=3/1/2 dpt=14.056 # active power, W reg=40015 len=1 type=uint16 -> ga=3/1/3 dpt=5.010 # active tariff, enumerated
BewO reads these group objects over a KNXnet/IP tunnelling or routing connection and republishes them as a multi-meter dashboard; it never reads Modbus directly, so a register you forget to map on the gateway simply never appears, with no error shown on either side.
Tariff scheduling: switching between day, night and peak rates
Drive the active-tariff object from a KNX time channel bound to a scene or logic function, not from a timer inside the meter, because the meter has no concept of the local tariff calendar. A typical three-rate schedule writes 0 (off-peak) late in the evening, 1 (standard) in the morning and 2 (peak) during the utility's declared window; loads elsewhere in the installation — water heater, EV charger, pool pump — read the same object and shift their own behaviour around it.
07:00 -> ga=3/1/3 value=1 # standard rate begins 17:00 -> ga=3/1/3 value=2 # peak rate begins 21:00 -> ga=3/1/3 value=1 # back to standard 23:00 -> ga=3/1/3 value=0 # off-peak begins
Clock drift: a schedule that lives only in one device's internal clock drifts by minutes a year and does not handle daylight-saving transitions correctly unless that device's time source is explicitly synced to NTP or a KNX time master; after a DST change an unsynced schedule can fire the peak tariff an hour early or late for months before anyone checks the utility bill.
Demand response and SG Ready integration
SG Ready is a two-relay, potential-free contact interface defined for heat pumps; decode both contacts together as one 4-state value rather than wiring them to two independent KNX switch objects, because the four combinations are mutually exclusive operating modes, not two independent flags.
| Contact 1 | Contact 2 | State | Meaning |
|---|---|---|---|
| Open | Open | 0 – Normal | Heat pump runs its own control loop |
| Closed | Open | 1 – Reduced | Utility requests a brief reduction; compressor may lock out |
| Open | Closed | 2 – Recommended | Surplus generation available; heat pump may run more |
| Closed | Closed | 3 – Forced on | Utility forces maximum consumption |
Contact race: decode the SG Ready pair through a single KNX logic object that reads both bits before switching outputs; wire the two contacts to independent 1-bit KNX inputs without that combined step, and a controller can see a transient 'reduced' state during the instant both relays change together, then lock out the compressor for its full minimum-off timer over a state that never actually existed.
Feed the decoded SG Ready state into the same load-shedding logic that reads the active-tariff object, and give demand-response requests priority over tariff-only scheduling — a request from the grid operator is a firm instruction, a tariff window is only a cost signal.
Frequently asked questions
Can a KNX system read a Modbus energy meter directly, without a gateway?
No. KNX and Modbus RTU are different physical and application layers, so a protocol gateway that polls the Modbus registers and republishes each value as a KNX group write is required; no native KNX device speaks Modbus RTU on the meter's RS-485 bus.
Which DPT should I use for active power on a KNX energy dashboard?
DPT 14.056, the standard 4-byte floating-point active power datapoint in watts. It is supported by every mainstream KNX visualization, including BewO, so use it for the instantaneous power object rather than a vendor-specific type.
How does SG Ready differ from a simple on/off demand response signal?
SG Ready uses two potential-free relay contacts that together encode four operating states — normal, reduced, recommended and forced on — not a single on/off command, so the receiving controller must decode both contacts as one combined value.
Does BREEAM accept a KNX energy management system for sub-metering credits?
BREEAM's Ene 01/Ene 02 criteria ask for sub-metering coverage of the main end-use categories with accessible read-out, which a correctly designed KNX group address schema satisfies; confirm the exact coverage percentage against the specific BREEAM scheme version the assessor is using.
What causes a KNX tariff schedule to fire at the wrong time after a clock change?
An unsynchronized real-time clock in the scheduling device. Bind the schedule to an NTP- or KNX-time-master-synced time source so daylight-saving transitions apply automatically instead of drifting.
Why do meter readings intermittently show CRC errors or freeze?
Almost always RS-485 bus loading: missing 120 Ω termination at the two physical ends of the trunk, a stub longer than roughly 0.3 m, or too many devices on one segment. Check termination and segment length before replacing a meter.
Need the metering and gateway pre-wired into the panel?
PanelCraft assembles and CE-certifies the distribution panel with the Modbus meters, the KNX gateway and the SG Ready interface already wired and labelled to your group address schema.
Request a quote →