Every group address with no datapoint type, and what it costs you later

The short answer

On the bus, nothing. A telegram carries bytes; the datapoint type is metadata that lives in ETS, and an actuator that has been told to treat object 5 as a 1-bit switch will do that whether or not anybody filled the field in.

Everywhere else, quite a lot — because the DPT is the only thing in the project that says what those bytes mean.

Where the cost lands

Anything that reads the project later. A visualisation, a gateway, a Home Assistant config, a logic server, a handover document, the next integrator’s import. All of them have to decide whether 5/2/14 carrying 0x80 is 50% brightness, a scene number, a mode, or half a setpoint. With a DPT they read it. Without one, somebody guesses — and a guess that is wrong produces a value that looks plausible, which is worse than one that fails.

The group monitor. Untyped addresses decode as raw bytes. The moment you are actually troubleshooting, at the moment you most need the log to be readable, it is hex.

You, on the callback. The classic is a 1-byte address that could be 5.001 (percent) or 5.010 (a counter, 0–255). Read as percent, a value of 200 becomes “78%” and nothing announces the error.

Whoever inherits it. This is the one that matters commercially. A project full of untyped addresses is a project the next person has to re-derive by hand, and they will price that into what they think of the work.

Why it happens

Not carelessness. ETS does not require it, nothing fails without it, and on a job where the addresses are being created quickly the field is simply the one that gets skipped. Projects that were extended in stages across years are the worst affected, because each stage had a different person in a different hurry.

Fixing it without guessing

The wrong repair is to infer the type from the address name. Names are the integrator’s own shorthand, they are inconsistent by the third stage of any project, and classifying on them is how a tool ends up confidently wrong.

The right repair is to read the ETS Function role, where one was declared. A role is a choice somebody explicitly made from a list — SwitchOnOff, DimValue, InfoSetpoint — so the datapoint type follows from it as a matter of definition rather than inference.

Here is what those roles were actually assigned in one real project, which is worth reading before you trust your instinct:

Role	Observed DPT	Count
SwitchOnOff	1.001	30
InfoOnOff	1.011	29
DimRelative	3.007	12
DimValue	5.001	12
InfoDimValue	5.001	11
FunctionUpDown	1.008	5
Stop	1.010	5
PositionValue / InfoPosition	5.001	5 / 5
SetpointValue / InfoSetpoint	9.001	17 / 17
HvacMode	20.102	17
InfoValve	5.001	12
FanSpeed	5.001	5

Note InfoOnOff. It is 1.011, DPT_State, not 1.001 — and the obvious guess is wrong twenty-nine times in that project alone. If you are repairing blank types by hand and working from memory, that is the one you will get wrong at scale.

(Counts are measured on our own reference installation, and we name the source because a table without one is a table you should not trust. It is consistent with the standard types, but it is offered as evidence rather than as an authority — and the principled way to widen it is to record what roles are actually assigned across many projects and promote a mapping once several agree.)

The role that cannot be repaired

ColourValue is deliberately absent from that table. In the same project it is assigned three different datapoint types: 232.600 (RGB), 251.600 (RGBW) and 7.600 (colour temperature in Kelvin).

A role that means three different things cannot be repaired from the role. Proposing one of the three would be wrong roughly two thirds of the time, so the correct behaviour is to leave it alone and tell you it needs a human. That is generally the difference between a tool you can use on a live project and one you have to check afterwards.

What the check does with this

Upload the project and the addressing issues list names every group address with no datapoint type, with the declared role beside it where there is one, and a proposed type where the role determines it unambiguously.

Proposals go into an ETS export you review as a diff before importing — the diff is free and reading is never charged for. Where the role is ambiguous, or where no role was declared, it says so and stops rather than filling the field with something that looks right.

On our reference installation the check reports 113 addressing issues across 668 group addresses. That is not an unusually bad project. It is a normal one, read properly for the first time.