(317)516-7460 
KNXPROD vs EITT Explained: Key Differences in KNX IoT Device Description
As building automation evolves, KNX systems are transitioning from traditional KNX TP/IP architectures to modern IP-based frameworks such as KNX IoT. One of the most important changes in this transition is how devices are described, configured, and discovered.
This article explains the key differences between KNXPROD and EITT, and how they work together in real-world KNX IoT deployments.
What is KNXPROD?
KNXPROD is the traditional method used to define KNX devices. It is a device database file (.knxprod) imported into ETS, the official KNX engineering software.
What does KNXPROD include?
⚙️ Device Parameters
Configuration settings and adjustment points for device functionality
🔗 Group Objects
Communication interfaces for KNX datapoint exchange
📊 Datapoint Types
Standardized data structures for consistent device communication
🧠 Application Logic
Embedded functions and processing rules within the device
What is it used for?
In ETS, KNXPROD enables:
- Device recognition: ETS identifies and loads device specifications
- Configuration: Parameter adjustments and customization
- Group Address assignment: Mapping communication objects to KNX group addresses
- Application download: Programming device with configuration data
Key characteristics
📋 KNXPROD Characteristics
- Static: Offline file requiring manual import into ETS
- Predefined capabilities: Fixed functionality defined at manufacturing
- Mandatory in traditional KNX systems: Essential for KNX TP/IP compatibility
What is EITT in KNX IoT?
In KNX IoT, device description moves away from static files toward dynamic, network-based models. This is commonly referred to as EITT (Engineering Information Transfer / Table) or more broadly as the KNX IoT Resource Model.
Core concept
Instead of relying only on a file, the device itself exposes its capabilities via:
🌐 CoAP
Constrained Application Protocol for efficient IoT device communication
🔌 RESTful APIs
Web-based interfaces for device discovery and control
What does EITT describe?
- Datapoints: Functional elements (e.g., volume, switch, dimming)
- Endpoints: Functional nodes within the device
- Data types: Standard formats (boolean, float, percentage)
- Resource paths: Structured URLs (e.g.,
/p/volume)
How it works
Engineering tools or controllers can query the device:
/oic/res — Device resources
/p/... — Property endpoints
to dynamically discover its features.
Key characteristics
✨ EITT / KNX IoT Characteristics
- Dynamic: Online discovery through device queries
- Self-describing devices: Devices expose capabilities in real-time
- Aligned with IoT and web technologies: Built on modern IP standards
KNXPROD vs EITT: Key Differences
| Feature | KNXPROD | EITT (KNX IoT) |
|---|---|---|
| Type | File (.knxprod) | Network model |
| Behavior | Static | Dynamic |
| Configuration | Offline (ETS import) | Online (device query) |
| Architecture | KNX TP/IP | KNX IoT |
| Flexibility | Limited | High |
📊 Visual Comparison
KNXPROD (Traditional)
File-based approach
Device capabilities defined in .knxprod file
Imported into ETS for configuration
Suitable for KNX TP/IP systems
EITT (KNX IoT)
Network-based approach
Device exposes capabilities via APIs
Dynamic discovery through CoAP/REST
Ideal for modern smart building integration
Do KNXPROD and EITT Replace Each Other?
🤝 Complementary, Not Competing
No — they are complementary, not competing. In modern KNX IoT deployments, both methods often coexist to serve different purposes.
Real-world deployments
In many KNX IoT projects:
- KNXPROD is still used for ETS integration and initial device programming
- EITT / Resource Model is used for runtime interaction and dynamic control
Simple analogy
KNXPROD = Device Identity
“Who you are”
Defines the device’s fundamental structure and capabilities for engineering tools
EITT = Device Capability
“What you can do”
Exposes real-time functionality for runtime control and integration
Why KNX IoT Introduces EITT
1. Greater Flexibility
Devices can expose capabilities dynamically without updating files. New features can be added through firmware updates without requiring new .knxprod files.
2. Reduced Engineering Complexity
Less reliance on manual file imports and updates. Devices can be discovered and configured automatically through standard IoT protocols.
3. Native IP Integration
Built on modern technologies:
- REST APIs: Web-standard interfaces for easy integration
- CoAP: Lightweight protocol for IoT efficiency
- IoT standards: Alignment with broader smart building ecosystem
This enables easier integration with cloud platforms, third-party systems, and modern smart home solutions.
Example: Multi-Zone Audio Amplifier
Consider a multi-room streaming amplifier in a commercial environment, such as AmpVortex 16060 series.
With KNXPROD
You define in the .knxprod file:
Zone1 Volume
Zone1 Mute
Zone2 Volume
…
With KNX IoT (EITT)
The device exposes:
/zone/1/volume
/zone/1/mute
/zone/2/volume
…
✅ Real-Time Discovery & Control
This allows real-time discovery and control through standard IoT APIs, enabling dynamic multi-zone streaming integration with platforms like Google Cast and AirPlay 2.
Common Misunderstandings
❌ Common Misconceptions
❌ EITT is a file
Incorrect — it is a data model/API structure, not a static file like KNXPROD
❌ KNX IoT does not need KNXPROD
Not always true — many systems still rely on ETS for initial configuration, requiring KNXPROD files
❌ They are interchangeable
They serve different roles — KNXPROD for engineering, EITT for runtime interaction
Conclusion
The transition from KNXPROD to EITT represents a shift from:
Static Engineering
File-based device definition
Manual configuration processes
Traditional KNX workflows
Dynamic, Connected Systems
Network-based device discovery
Real-time capability exposure
Modern IoT ecosystem integration
In modern KNX IoT deployments:
- KNXPROD ensures compatibility with ETS and traditional KNX workflows
- EITT enables flexible, scalable device interaction for modern smart building systems
🎯 Essential Knowledge
Understanding both is essential for building future-proof smart building systems. Whether you’re deploying AmpVortex 16060, 16060A, 16060G, or 16100 multi-zone amplifiers, grasping these device description methods is crucial for successful KNX integration.
AmpVortex website：https://www.ampvortex.com
