KNX energy meter cross-check preview
The cross-check view keeps KNX meter objects and Control4 candidates visible together so units, DPTs, gateway visibility and reporting scope can be reviewed before export.
A meter is not a controllable device
A KNX energy meter usually publishes values rather than accepting user commands. Control4 may show those values, trigger notifications or feed a dashboard, but the mapping model is different from a switch, dimmer or blind.
The preflight should decide whether each object is instant power, accumulated energy, production, consumption, voltage, current, pulse count or diagnostic context.
Values to classify before handoff
Energy pages fail when every numeric group address is treated the same. A kWh total, a W load value and a voltage phase reading need different labels, units, refresh expectations and history decisions.
CoduWorks should keep the KNX source visible so the installer can classify values before Composer receives a reviewed package.
- Instant power in W or kW, total energy in Wh or kWh.
- Import, export, production and consumption counters.
- Voltage, current, frequency and per-phase values.
- Water, gas or pulse counters if they are exposed through KNX.
- Read flags, feedback behaviour and periodic read requirements.
DPT and unit assumptions
Metering data is sensitive to DPT and scaling. The same visible number can mean watts, kilowatts, watt-hours, kilowatt-hours, amps, volts or a raw pulse count.
Before export, the installer should confirm the DPT, unit, multiplier, reset behaviour and whether the value is cumulative or live.
Gateway visibility and reporting frequency
If a meter value is not routed through the KNX/IP path used by Control4, the dashboard or driver can look empty even when ETS sees the value. Filter tables, read flags and update frequency should be checked before blaming the Control4 side.
High-frequency values also need care. Pushing every fast-changing measurement into Composer can create noise; reporting scope should be deliberate.
Separate from the core build
Energy meters do not belong in the license count by themselves. The counted scope remains lights, blinds, thermostats and KNX/IP gateways. Metering values are reporting/add-on scope because the required UI, history and notification behaviour depends on the project.
A reviewed .codu package can still carry the meter context so the installer knows which values are ready, which are only reference data and which should stay out of the build.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Are KNX energy meters part of the core device count?
No. The counted scope remains lights, blinds, thermostats and KNX/IP gateways. Energy metering is reporting/add-on scope.
Can CoduWorks prepare KNX power meter values for Control4?
It can group and surface reviewable meter candidates, but the installer should confirm DPTs, units, scaling, gateway visibility and reporting behaviour before creation.
Which meter values should be reviewed?
Instant power, accumulated kWh, import/export counters, phase voltage/current, pulse counters, read flags and refresh frequency should be checked before export.
Can meter values trigger Control4 actions?
They can be used for notifications or automation if the project scope confirms reliable updates and Composer programming. That should be a deliberate add-on decision.
Review metering before Composer
Import ETS, classify energy and utility values, confirm DPTs and export .codu only after the reporting scope is clear.