KNX Data Point Types, commonly called DPTs, define how information is represented and interpreted when it is exchanged between KNX devices. They are essential for understanding communication objects, group addresses and telegram data in ETS. A correct DPT ensures that two KNX devices interpret the same value in the same way. For integrators, understanding DPTs is therefore fundamental to reliable KNX programming and integration.
1. What Is a KNX Data Point Type?
A KNX Data Point Type defines the format, size and meaning of data transmitted through a KNX group address. It tells a device whether the information represents a switch command, temperature, percentage, time, energy value or another type of data. DPTs are particularly important when integrating products from different manufacturers because they provide a common data interpretation.
For example:
| Function | Typical DPT | Data |
|---|---|---|
| ON/OFF | DPT 1.xxx | 1-bit |
| Dimmer percentage | DPT 5.001 | 0–100% |
| Temperature | DPT 9.001 | °C |
| Date | DPT 11.001 | Date |
| Time | DPT 10.001 | Time |
| 32-bit value | DPT 12.xxx / 13.xxx | Various |
The exact DPT should always be selected according to the intended function and the manufacturer’s communication-object specification.
2. Why DPTs Are Important in KNX
DPTs allow devices from different KNX manufacturers to exchange information using a common data structure. Without a consistent data format, one device could send a value that another device interprets incorrectly. This becomes especially important when integrating lighting, HVAC, energy monitoring, DALI gateways and visualisation systems.
For example:
Temperature sensor → Group Address → HVAC controller
If the sensor sends a temperature using an appropriate DPT, the HVAC controller knows that the received value represents temperature rather than an unrelated numerical value.
This interoperability is one of the important strengths of KNX.
3. Understanding the KNX DPT Numbering Structure
KNX DPT numbers are organised into main data-type families and subtypes. A notation such as DPT 9.001 can be understood as a main type followed by a specific subtype. The main type describes the general data format, while the subtype defines the particular engineering meaning.
For example:
DPT 9.001
- 9 → 2-byte floating-point format
- 001 → Temperature
Similarly:
DPT 5.001
- 5 → 1-byte unsigned value
- 001 → Percentage
Therefore:
DPT 5.001 and DPT 9.001 are not simply different numbers—they represent different data structures and meanings.
4. The Most Common 1-Bit DPTs
1-bit DPTs are among the most frequently used data types in KNX projects. They are suitable for binary information where the value has two possible states. Lighting switching, enable/disable commands and status feedback commonly use this type of communication.
Some common examples include:
| DPT | Typical Function |
|---|---|
| DPT 1.001 | Switch |
| DPT 1.002 | Boolean |
| DPT 1.003 | Enable |
| DPT 1.009 | Open/Close |
| DPT 1.010 | Start/Stop |
| DPT 1.100 | Heat/Cool |
A typical lighting circuit might use:
Push Button
│
│ DPT 1.001
▼
Group Address
│
│
▼
Lighting ActuatorThe value is generally represented as:
0 = OFF
1 = ON
The exact semantics depend on the selected DPT.
5. DPTs for Dimming and Percentage Values
KNX uses several DPTs for values such as dimming levels, percentages and scaled values. One of the most common is DPT 5.001, which represents a percentage value from 0 to 100%.
For example:
| Value | Meaning |
|---|---|
| 0% | Minimum |
| 25% | 25% |
| 50% | 50% |
| 75% | 75% |
| 100% | Maximum |
A typical lighting application could be:
KNX Touch Panel
│
│ DPT 5.001
▼
Group Address
│
▼
KNX / DALI Gateway
│
▼
DALI LightingThis is especially useful when KNX is controlling dimmable DALI lighting.
6. DPTs for Temperature and Other 2-Byte Values
Two-byte floating-point DPTs are commonly used for physical measurements such as temperature. DPT 9.001 is widely used for temperature values and allows a KNX device to transmit a temperature measurement with an appropriate numerical representation.
Example:
Temperature Sensor
│
│ DPT 9.001
▼
Group Address
│
▼
HVAC ControllerA value such as:
23.5 °C
can therefore be transmitted as a KNX value that the receiving device interprets as temperature.
Other DPT 9 subtypes are available for different physical quantities.
7. DPTs for 32-Bit and Larger Numerical Values
Some KNX applications require more information than a 1-bit or 2-byte value can provide. Energy monitoring, counters and certain numerical measurements can use 4-byte data point types. These provide a larger numerical range and are useful when transmitting accumulated or high-resolution values.
Examples include:
| DPT Family | Typical Use |
|---|---|
| DPT 12.xxx | 4-byte unsigned value |
| DPT 13.xxx | 4-byte signed value |
| DPT 14.xxx | 4-byte floating-point value |
| DPT 7.xxx | 2-byte unsigned value |
For energy-related applications, always check exactly what the manufacturer’s KNX communication object represents.
For example:
Energy Meter
│
│ Energy Value
▼
Group Address
│
▼
VisualizationThe DPT must match between the transmitting and receiving objects.
8. DPTs for Date, Time and Date-Time
KNX installations often need to transmit scheduling and time information. Dedicated DPTs are available for date, time and combined date-time information. These can be used for functions such as scheduling, astronomical control, time-based lighting and visualisation.
Common examples include:
| DPT | Typical Function |
|---|---|
| DPT 10.001 | Time of day |
| DPT 11.001 | Date |
| DPT 19.001 | Date and time |
A typical system could be:
KNX Time Source
│
▼
Group Address
│
┌────┴────┐
│ │
Lighting HVAC
Schedule ControlThis allows multiple KNX devices to use a common time reference.
9. DPTs for HVAC and Building Automation
HVAC systems use many different types of values, including temperatures, setpoints, operating modes, fan speeds and control values. Selecting the correct DPT is particularly important because HVAC integration frequently involves communication between products from different manufacturers.
Typical examples include:
| Function | Example DPT |
|---|---|
| Room temperature | DPT 9.001 |
| Percentage setpoint | DPT 5.001 |
| HVAC mode | Appropriate DPT 20.xxx subtype |
| Fan speed | Manufacturer/application dependent |
| Heating/Cooling status | Appropriate 1-bit DPT |
| Setpoint shift | Manufacturer/application dependent |
The correct DPT should always be determined from the communication-object specification rather than assumed from the function name alone.
10. DPT and Communication Objects in ETS
DPTs are closely connected to communication objects in ETS. A communication object defines the information a KNX device can send or receive, while its associated data point type tells ETS and the KNX devices how that information should be interpreted.
For example:
KNX Push Button
│
└── Communication Object
│
└── Switch
│
└── DPT 1.001Another device may have:
KNX Actuator
│
└── Communication Object
│
└── Switch Status
│
└── DPT 1.001These compatible objects can then be linked through the appropriate group address.
11. DPT Compatibility Between KNX Devices
For reliable communication, the sending and receiving objects should use compatible data types. A common commissioning mistake is connecting two objects that appear functionally related but use incompatible DPTs. ETS may allow certain configurations, but the engineering intent and device specifications must always be checked.
For example:
Temperature Sensor
DPT 9.001
│
▼
Group Address
│
▼
HVAC Controller
DPT 9.001This is straightforward.
But:
Sensor
DPT 9.001
│
▼
Group Address
│
▼
Receiver expecting a different data formatcan produce incorrect behaviour or values.
Therefore:
Always verify the communication-object data type before linking devices.
12. DPTs and KNX Group Addresses
A group address is the logical communication path between KNX devices, while the DPT defines the type of information carried over that path. The two concepts should therefore be designed together when creating a KNX group-address structure. A well-organised project makes it clear what each group address represents and which DPT it uses.
Example:
| Group Address | Function | DPT |
|---|---|---|
| 1/1/1 | Living Room Light ON/OFF | 1.001 |
| 1/1/2 | Living Room Dim Level | 5.001 |
| 1/2/1 | Living Room Temperature | 9.001 |
| 1/3/1 | HVAC Mode | Appropriate HVAC DPT |
A group-address database should ideally document:
- Group address
- Function
- Sending object
- Receiving objects
- DPT
- Description
13. Troubleshooting DPT Problems in ETS
DPT-related problems can be difficult to identify because the telegram may appear to be transmitted successfully while the receiving device behaves incorrectly. When a KNX value appears wrong, the engineer should check the communication object, DPT, group address and telegram value together. ETS Group Monitor and Bus Monitor can be particularly useful during this process.
A practical troubleshooting sequence is:
1. Check the sending object
Confirm the object’s DPT and function.
2. Check the group address
Confirm that the correct address is being used.
3. Check the receiving object
Verify its expected data type.
4. Monitor the telegram
Use ETS Group Monitor to inspect the transmitted value.
5. Check the decoded value
Confirm that the displayed value matches the expected engineering quantity.
For example, if a temperature should be:
23.5 °C
but the receiving system shows an unexpected value, investigate the DPT and object configuration before assuming the sensor is defective.
14. KNX DPT Design Checklist and Best Practices
DPT selection should be treated as part of the KNX engineering process rather than something decided during final commissioning. Consistent DPT selection makes group-address design, third-party integration and troubleshooting easier. It also helps ensure that different KNX manufacturers interpret exchanged values consistently.
KNX DPT Checklist
- Identify the function of the communication object.
- Check the manufacturer’s specified DPT.
- Confirm the DPT of the receiving object.
- Use compatible DPTs on linked objects.
- Document the DPT against the group address.
- Avoid changing DPTs without understanding the consequences.
- Check numerical ranges and units.
- Verify values using ETS Group Monitor.
- Check DPTs when integrating third-party systems.
- Document special or manufacturer-specific DPT requirements.
Best Practice
When creating a KNX project database, maintain a consistent structure:
Group Address → Function → DPT → Sender → Receiver
This makes future commissioning and troubleshooting considerably easier.
Conclusion
KNX Data Point Types are one of the fundamental building blocks of KNX communication. They define how values such as switching commands, percentages, temperatures, times, energy values and other information are represented and interpreted.
Understanding DPTs allows KNX integrators to correctly connect:
Communication Objects → Group Addresses → KNX Devices
The most important principle is:
A group address defines where the information goes; the DPT defines what that information means.
For professional KNX projects, DPTs should therefore be considered during device selection, group-address design, ETS programming and system integration, not only during troubleshooting.
