KNX IoT Device Profile
The KNX IoT Point API specification is a large document. Developers building a compliant device need a concise checklist. For every feature it answers three questions: Is it mandatory?, Why does the device need it?, and How does it work at a protocol level?
Each section covers one functional area, opens with a short Why / How rationale, and then lists every resource, method, and protocol feature together with its support level. The document references the normative specification (Chapter 3/10/5 KNX IoT Point API) and the KNX Point API OpenAPI Schema.
The keywords [m] (mandatory / SHALL) and [o] (optional / MAY) follow the conventions of RFC 2119 as used in the specification.
Discovery
Why: A MaC cannot commission or control a device it has not discovered. Discovery is the entry point for every interaction: the MaC must locate a device before it can assign an Individual Address (IA), install credentials, or read and write device values.
How: DNS-SD / mDNS advertises the device's IP address, CoAP
port, and service subtypes (serial number, IA, Programming Mode) so
clients can browse without prior knowledge. In Thread networks this
works immediately because the Thread Border Router answers mDNS
queries as a proxy on behalf of Thread devices, including sleepy
devices that are not always reachable. CoAP Resource
Discovery (/.well-known/core) adds structured queries by resource
type and group address and is the only mechanism when no mDNS proxy
is available.
DNS-SD / mDNS
Zero-configuration browsing: devices advertise themselves with service subtypes so clients can find them without prior knowledge.
| Feature | Support | Notes |
|---|---|---|
mDNS service type _knx._udp |
[m] | Device or DNS-SD proxy SHALL advertise the service. |
| SRV record with CoAP port | [m] | Default port 5683. |
| AAAA record (IPv6 address) | [m] | Device SHALL publish all accepted IPv6 addresses. |
| A record (IPv4) | [o] | Only if the device supports IPv4 (for example, KNX IoT Router). |
Subtype _<serialnumber> |
[m] | Serial number as lowercase hex. |
Subtype _ia<iid>-<ia> |
[m] | After the MaC assigns the IA. |
Subtype _pm |
[m] | Only while device is in Programming Mode. |
Subtype _m<manufacturer> |
[o] | Manufacturer-specific service. |
TXT record SP=<ms> |
[m] (sleepy) | Required for sleepy devices only. |
| SRP client (Thread) | [m] (Thread) | Required for devices in Thread networks. |
CoAP Resource Discovery (.well-known/core)
Structured query interface: clients filter by serial number, resource type, or group address over unicast or multicast.
| Resource / Feature | Support | Notes |
|---|---|---|
/.well-known/core (GET) |
[m] | Unicast and multicast. |
Query ep=knx://sn.<sn> |
[m] | Device discovery by serial number. |
Query if=urn:knx:if.pm |
[m] | Programming Mode discovery. |
Combined ep + if.pm |
[m] | Device SHALL support this combination. |
Query rt=urn:knx:... |
[m] | Resource type filtering. |
Query d=urn:knx:g.s.<ga> |
[m] | Group Address discovery. |
| Multicast response suppression | [m] | No response on mismatch or error. |
Device Interface Object
Why: Before a MaC can configure a device, it needs to know what the device is (serial number, manufacturer, firmware version). The MaC must also control the device lifecycle: assign an Individual Address, trigger a reset, and manage the Load State Machine. These resources provide the identity and control plane.
How: Read /dev properties for device identity. POST to
/.well-known/knx/ia to assign the Individual Address. Use
/.well-known/knx POST with erase codes to factory-reset. Drive the
Load State Machine (/a/lsm) through unloaded -> loading -> loaded
to manage the configuration download lifecycle.
Device Commands (.well-known/knx)
Lifecycle control: reset, restart, assign Individual Address, and initiate the PASE handshake.
| Resource | Method | Support | Notes |
|---|---|---|---|
/.well-known/knx |
GET | [m] | Returns API version and base path. |
/.well-known/knx |
POST | [m] | Device reset (erase codes 0x2 and 0x7 mandatory) and restart. |
/.well-known/knx/f |
GET | [m] | Configuration fingerprint (loaded state only). |
/.well-known/knx/ia |
POST | [m] | Write Individual Address and Installation ID. |
/.well-known/knx/spake |
POST | [m] | SPAKE2+ PASE handshake (3 steps). |
/.well-known/knx/idevid |
GET | [o] | Read manufacturer device certificate. |
/.well-known/knx/ldevid |
GET | [m] | Read operational device certificate. |
Device Resources (/dev)
Device identity properties (read-only) and writable operational state, including serial number, firmware version, Programming Mode, and Individual Address components.
| Resource | Method | Support | Notes |
|---|---|---|---|
/dev |
GET | [m] | Link list of device properties. |
/dev/sn |
GET | [m] | KNX Serial Number (factory-set, read-only). |
/dev/mid |
GET | [m] | Manufacturer ID. |
/dev/hwt |
GET | [m] | Hardware type. |
/dev/model |
GET | [m] | Model identifier. |
/dev/fwv |
GET | [m] | Firmware version [major, minor, patch]. |
/dev/hwv |
GET | [o] | Hardware version. |
/dev/sna |
GET | [m] | Subnetwork address (high byte of the 2-octet Individual Address). |
/dev/da |
GET | [m] | Device address (low byte of the 2-octet Individual Address). |
/dev/pm |
GET, PUT | [m] | Programming Mode (boolean). |
/dev/hname |
GET, (PUT) | [m] | Hostname. |
/dev/ipv6 |
GET | [m] | Device IPv6 addresses. |
/dev/fid |
GET, (PUT) | [o] | KNX Fabric ID. |
/dev/iid |
GET, (PUT) | [m] | KNX Installation ID. |
/dev/mport |
GET | [m] | Multicast port (default 5683). |
/dev/port |
GET, (PUT) | [m] | Unicast port. |
Application Program Resources (/ap, /a/lsm)
Program metadata and the Load State Machine (LSM) that governs the configuration download lifecycle (unloaded / loading / loaded).
The LSM controls whether the device application runs. When the MaC
transitions the LSM to loading, the device stops its control
application, brings actuator outputs to a safe state, and accepts
new configuration data. Sleepy devices can shorten their wake-up
cycle during loading to speed up the download. Once the MaC
signals loaded, the device resumes normal operation with the new
configuration.
| Resource | Method | Support | Notes |
|---|---|---|---|
/ap |
GET | [m] | Application Program link list. |
/ap/pv |
GET, PUT | [m] | Application Program version / ID. |
/a/lsm |
GET, POST | [m] | Load State Machine. States: unloaded, loading, loaded (mandatory); loadcompleting, unloading (optional). |
Cybersecurity
Why: KNX IoT devices control physical infrastructure (lighting, HVAC, access). The device must authenticate and integrity-protect every CoAP message to prevent unauthorized actuation, eavesdropping, and replay attacks.
How: OSCORE (RFC 8613) provides message-level encryption and
authentication using pre-shared security contexts. Initial key
exchange uses SPAKE2+ / PASE, a password-authenticated handshake.
PASE uses password-derived static keys for authentication and derives
the shared OSCORE secret from ephemeral randomness contributed by
both parties. Access tokens (/auth/at) define per-client scopes
(admin, configuration, runtime). Optional TLS adds transport-layer
encryption for environments that require it.
OSCORE
Message-level encryption and authentication for every CoAP request and response, using pre-shared symmetric security contexts. OSCORE context identifiers are separate from the KNX Individual Address (IA), so a device updates the context independently (for example, after a reboot) while the IA stays unchanged. The Echo option (RFC 9175) verifies request freshness via challenge-response, allowing a receiver to accept messages after losing replay-window state without a full PASE handshake.
| Feature | Support | Notes |
|---|---|---|
| OSCORE unicast + multicast | [m] | Pre-shared key security context. |
| HKDF SHA-256 key derivation | [m] | Default KDF. |
| AES-CCM-16-64-128 cipher | [m] | Mandatory AEAD algorithm. |
| Replay protection (RFC 8613 §7.4) | [m] | Sequence number tracking per sender context. |
| Echo challenge-response (RFC 9175) | [m] | Sequence number sync between devices and third-party clients. |
PASE / SPAKE2+
Password-authenticated key exchange: bootstraps OSCORE credentials from the device password without exposing it on the wire.
| Feature | Support | Notes |
|---|---|---|
| SPAKE2+ over CoAP (P-256) | [m] | 3-step handshake on /.well-known/knx/spake. |
| PBKDF2 key derivation | [m] | Salt 16–32 bytes; iterations 1000–100000 (sufficient given high-entropy random passwords). |
| Responder key (temporary PASE token) | [m] | Scope limited to if.sec. |
| Brute-force lockout | [m] | Block after 10 invalid attempts; max 5 min timeout. |
| Device handover (new PASE password) | [o] | Lets another MaC take ownership of the device. |
Access Control Resources (/auth)
Token-based authorization: install, inspect, and revoke per-client access tokens that define allowed scopes and OSCORE parameters.
| Resource | Method | Support | Notes |
|---|---|---|---|
/auth |
GET | [m] | Link list of auth resources. |
/auth/at |
GET, POST | [m] | Access token list (create/read). |
/auth/at/{token-id} |
GET, DELETE | [m] | Read/delete individual token. |
/auth/crts |
GET, POST | [m] (if TLS) | Trust list (CA certificates). |
/auth/crts/{cert-id} |
GET, DELETE | [m] (if TLS) | Individual certificate. |
/auth/o |
GET | [m] | OSCORE settings link list. |
/auth/o/replwdo |
GET, (PUT) | [m] | Replay window size. |
/auth/o/osndelay |
GET, (PUT) | [m] | Echo response jitter delay. |
/auth/sen |
POST | [m] (if TLS, unless skg) |
LDevID simple enrollment (push LDevID). One of auth/sen or auth/skg is mandatory if TLS. |
/auth/skg |
POST | [m] (if TLS, unless sen) |
Server-side key generation (push LDevID) |
/a/sen |
POST | [o] | Trigger LDevID simple enrollment w/ EST. |
Access Scopes
Granular permission model: each token carries one or more scopes that restrict which interfaces and group addresses the client may access.
Every access token must specify one or more scopes. The specification defines the following scopes:
| Scope | Interface | Description | Support |
|---|---|---|---|
if.sec |
if.sec | Security configuration (admin / tool key) | [m] |
if.c |
if.c, if.ll | Device configuration (commissioning) | [m] |
if.p |
if.p, if.ll | Parameter read/write | [m] |
if.d |
if.d, if.ll | Diagnostic read | [m] |
if.g.s |
if.g.s | S-Mode group communication (all GAs) | [m] |
<ga> |
if.g.s | Per-group-address scope | [m] |
if.i |
if.i | Runtime input (write) | [m] |
if.o |
if.o | Runtime output (read/subscribe) | [m] |
if.swu |
if.swu | Software update | [m] |
if.a |
if.a | Hardwired actuator | [o] |
if.s |
if.s | Hardwired sensor | [o] |
TLS Transport Security
Optional transport-layer encryption using X.509 certificates for environments that require channel confidentiality beyond OSCORE.
| Feature | Support | Notes |
|---|---|---|
| TLS 1.2 (RFC 5246) | [m] (if TLS) | If supported, SHALL comply. |
| TLS 1.3 (RFC 8446) | [o] | MAY additionally support. |
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 | [m] (if TLS) | Mandatory cipher suite for TLS devices. |
| IDevID (manufacturer certificate) | [o] | Factory-imprinted; used for EST enrollment. |
| LDevID (operational certificate) | [m] (if TLS) | Issued by MaC or Registrar. |
| Mutual TLS authentication | [m] (if TLS) | Requires LDevID + trust list. |
| EST-CoAPS enrollment (RFC 9148) | [o] | Simple enrollment (pull certificate). |
| (D)TLS brute-force lockout | [m] (if TLS) | Max 1 attempt per 3000 s average in 24 h. |
Functional Block Resources (/f)
Why: A device may expose dozens of points. Functional Blocks group related points into logical units (for example, "room temperature sensor," "lighting actuator") so that tools and integrations can present a structured, human-readable device model.
How: GET /f returns a link list of all Functional Blocks. GET
/f/{fb-id-instance} returns the points belonging to that block.
The rt attribute uses urn:knx:fb.<id> to identify the block type
per KNX standard Volume 7.
| Resource | Method | Support | Notes |
|---|---|---|---|
/f |
GET | [m] | Link list of Functional Blocks. |
/f/{fb-id-instance} |
GET | [m] | Link list of Points in a Functional Block. |
Functional Blocks announced in /.well-known/core SHALL also appear
in /f. The rt attribute SHALL use urn:knx:fb.<id> format per
KNX standard Volume 7.
KNX IoT Router Functional Blocks
Why: A KNX IoT Router forwards group communication between a KNX IoT subsystem and a KNX Classic subsystem. It translates the CBOR payload of a KNX IoT message into a KNX Classic message, and back. CBOR keeps this encoding compact and self-describing, so a constrained device parses it with little memory and the format stays extensible for new fields. The router is also a cybersecurity zone boundary towards another KNX subsystem and towards a third-party system in a vertical integration. It terminates the security of each side, so no symmetric key leaves the KNX IoT area. The mapping table configures which data enters and leaves the KNX IoT subsystem.
How: The router keeps the Group Address Mapping Table under
/fp/gm and exposes the router-specific Functional Blocks under
/f. The KNX Classic medium of the device determines which blocks
exist, because netip applies to the KNXnet/IP profile only. For the
full resource tables, the coupler roles, and the two medium profiles,
see KNX IoT Router.
| Resource | Block | Support | Notes |
|---|---|---|---|
/fp/gm |
NA | [m] | Group Address Mapping Table between KNX IoT and KNX Classic. |
/f/datasec |
urn:knx:fb.17 |
[m] | KNX Data Security state for the KNX Classic side. |
/f/netip |
urn:knx:fb.11 |
[m] (KNXnet/IP) | KNXnet/IP configuration. Absent on the TP1/IoT Router. |
/f/coupling |
urn:knx:fb.6 |
[o] | Coupling functional block with the Segment Individual Address Table. Present in the Segment Coupler role only. |
Point Read, Write, and Publish/Subscribe
Why: Points are the actual application data, a temperature reading, a light-level setpoint, a commissioning parameter, or a diagnostic counter. Clients and peer devices need a uniform way to read, write, and subscribe to these values.
How: Every point lives under /p/ with a hierarchical path
(for example, /p/lsab/soo, or /p/1, etc.). GET retrieves the current value (CBOR key 1).
PUT writes writable points. Metadata queries (?m=dpt, ?m=ga)
expose the datapoint type, interface, and group address bindings.
Output points (if.o) support CoAP Observe for push-based
notifications when a value changes.
Datapoint Resources (/p)
RESTful access to individual datapoints: read values, write writable points, query metadata, and subscribe to changes.
| Resource | Method | Support | Notes |
|---|---|---|---|
/p |
GET | [m] | Link list of all properties (if.ll). |
/p/{property-path} |
GET | [m] | Read value. CBOR key 1 for value. |
/p/{property-path} |
PUT | [o] | Write value (if writable). |
/p/{property-path}?m=<meta> |
GET | [m] | Read metadata (for example, dpt, rt, unit). |
| CoAP Observe on output points | GET | [m] (if.o) | Points with if.o SHALL support observe. |
Datapoint Metadata
Self-describing points: each point exposes its datapoint type, interface role, group address bindings, and optional thresholds.
| Metadata | Support | Type | Description |
|---|---|---|---|
id |
[m] | unsigned | Point identifier. |
rt |
[m] | text string | Datapoint Annotation (for example, urn:knx:dpa.321.51). |
if |
[m] | text string | Interface type (if.i, if.o, if.p, if.d). |
dpt |
[m] (if Group Communication) | text string | KNX Datapoint Type. |
unit |
[o] | text string | Engineering unit. |
min / max |
[o] | varies | Value range constraints. |
ga |
[m] (if.g.s) | unsigned array | Assigned Group Addresses. |
cov |
[o] | varies | Change of Value threshold. |
mrt |
[o] | unsigned | Minimum repetition time (seconds). |
hbt |
[o] | unsigned | Heartbeat time (seconds). |
sns |
[o] | boolean | Sequence number synchronization required. |
Subscription Resources (/sub)
Bulk cleanup: delete all active CoAP Observe registrations on the device in a single request.
| Resource | Method | Support | Notes |
|---|---|---|---|
/sub |
DELETE | [m] (if subscriptions supported) | Delete all CoAP observe subscriptions. |
Z8 Status/Command Extension
Optional extended status flags (overridden, out-of-service, fault) that augment the standard point value.
| Feature | Support | Notes |
|---|---|---|
| Z8 status (overridden, out-of-service, fault) | [o] | Points MAY support Z8. Clients SHALL handle Z8 payloads. |
Group Communication (S-Mode)
Why: At runtime, devices must exchange sensor readings, actuator commands, and status updates efficiently. Group Communication mirrors the group telegram concept from classic KNX while running over IP. It supports both multicast (one-to-many) and unicast (point-to-point with responses). On IP networks unicast is especially important: multicast does not cross IP routers by default, so unicast recipients provide reliable delivery across Subnetworks and CoAP confirmable acknowledgement.
How: During commissioning, the MaC writes Function Point Tables
(/fp/g, /fp/r, /fp/p) that map each datapoint to one or more
Group Addresses and define the message direction (send / receive).
The Recipient Table (/fp/r) lists the unicast destinations for each
Group Address, and the Publisher Table (/fp/p) registers the
expected incoming sources. At runtime, a device POSTs a Group
Notification to the /k resource containing the source address,
target Group Address, service type (write / read / response), and
the datapoint value. The device sends the notification via multicast
to all local subscribers and via unicast to every configured
recipient, ensuring cross-router delivery and confirmed reception.
| Resource / Feature | Support | Notes |
|---|---|---|
/k resource (POST receive, CoAP Observe) |
[m] | rt=urn:knx:if.g.s. |
| Multicast S-Mode send (POST) | [m] | Unacknowledged multicast. |
| Unicast S-Mode send (POST) | [m] | Acknowledged unicast. |
CoAP Observe subscription on /k |
[m] | For brokers / routers. lt query mandatory. |
lt (lifetime) query parameter |
[m] | Min support 86400 s (24 h). |
non (non-confirmable) query parameter |
[o] | Default is confirmable. |
CoAP Observe on /k serves two additional purposes. First, a MaC
can subscribe for a limited time to monitor outgoing group messages
for diagnostics. Second, a controller can subscribe to a sensor's
/k resource to receive datapoint updates without configuring
unicast recipients in the Function Point Tables. See
Message Exchange Patterns below and
Group Communication for details.
Function Point Tables (/fp)
Configuration-time tables that map each datapoint to its Group Addresses, recipients, and publishers.
Function Point Tables configure the runtime communication links (Group Objects, Recipients, Publishers) on a device. A MaC writes these tables during the configuration download phase.
| Resource | Method | Support | Notes |
|---|---|---|---|
/fp/g |
GET, POST | [m] | Group Object Table. |
/fp/g/{id} |
GET, DELETE | [m] | Individual Group Object entry. |
/fp/r |
GET, POST | [m] | Recipient Table (outgoing destinations). |
/fp/r/{id} |
GET, DELETE | [m] | Individual Recipient entry. |
/fp/p |
GET, POST | [m] | Publisher Table (incoming sources). |
/fp/p/{id} |
GET, DELETE | [m] | Individual Publisher entry. |
Message Exchange Patterns
Transport options for delivering group messages: multicast, unicast, or broker-based endpoint subscription. For a detailed explanation, see Group Communication.
| Pattern | Support | Notes |
|---|---|---|
| Multicast (transport layer) | [m] | SHALL support multicast recipients and publishers. |
| Direct unicast | [m] | Point-to-point communication. |
Endpoint subscription (CoAP Observe on /k) |
[o] | Required for KNX IoT Router; optional for end devices. |
Software Update Interface Object (SWU)
Why: Deployed devices need security patches and feature updates without physical access. A standardized update mechanism ensures interoperability across manufacturers and prevents bricked devices through integrity verification and resume support.
How: The MaC reads /swu properties to check current firmware
version and supported modes. In PUSH mode (mandatory), the MaC
writes firmware chunks to /a/swu with offset and size query
parameters. The device tracks received bytes (/swu/pkgbytes) for
resume after interruption. After a complete download, the MaC
triggers activation via PUT to /swu/update. The device verifies
package integrity before applying.
Software Update Resources (/swu)
Status and control properties: firmware version, download state, supported update method, and activation trigger.
| Resource | Method | Support | Notes |
|---|---|---|---|
/swu |
GET | [m] | Link list of SWU properties. |
/swu/pkgname |
GET | [o] | Active/non-active package names. |
/swu/pkgurl |
GET, (PUT) | [o] | Package address for PULL mode. |
/swu/pkgbytes |
GET | [m] | Bytes successfully received (resume support). |
/swu/pkgv |
GET | [m] | Downloaded package version. |
/swu/update |
PUT | [m] | Trigger activation ({1: 0}). |
/swu/state |
GET | [m] | Current state (0=idle, 1=downloading, 2=downloaded). |
/swu/result |
GET | [m] | Last update result. |
/swu/lastupdate |
GET | [o] | Timestamp of last update. |
/swu/method |
GET, (PUT) | [m] | Supported method (1=PUSH, 2=PULL, 3=both). |
/swu/maxdefer |
GET, (PUT) | [o] | Maximum deferred activation time. |
/swu/protocol |
GET, (PUT) | [o] | Supported download protocols. |
/swu/mid |
GET | [m] | SWU manufacturer ID. |
/swu/hwref |
GET | [m] | SWU hardware reference. |
Software Update Transfer Resources (/a/swu)
Firmware payload endpoint: write chunks (PUSH), trigger download (PULL), or read chunks from an SWU server.
| Resource | Method | Support | Notes |
|---|---|---|---|
/a/swu |
PUT (with ?po=<offset>) |
[m] | PUSH mode: write firmware chunks. |
/a/swu |
POST (notification) | [o] | PULL mode: trigger download notification. |
/a/swu |
GET (with ?po=<offset>&ps=<size>) |
[o] | PULL mode: device reads from SWU server. |
Software Update Modes
Delivery strategies and reliability guarantees: PUSH vs PULL, resume after interruption, and integrity verification.
| Mode | Support | Notes |
|---|---|---|
| PUSH | [m] | MaC writes chunks to /a/swu. |
| PULL | [o] | Device fetches from configured address. |
| Resume after interruption | [m] | Via swu/pkgbytes offset. |
| Package integrity verification | [m] | Device SHALL verify before applying. |
CoAP Application Protocol
Why: CoAP is the mandatory application protocol for KNX IoT. Consistent transport, content format, and response code support across all devices provides interoperability. A client can talk to any compliant device without manufacturer-specific adaptation.
How: Devices run CoAP over UDP on IPv6 with mandatory multicast
support at three scopes (link-local, realm-local, site-local). All
structured data uses CBOR encoding (ct=60). Discovery uses
CoRE Link Format (ct=40). The device returns standard CoAP
response codes.
CoAP Content Formats
Media types for structured data (CBOR), resource listings (link-format), and binary transfers (octet-stream).
| Format | Support | Notes |
|---|---|---|
application/cbor (ct=60) |
[m] | Primary data format. |
application/link-format (ct=40) |
[m] | Discovery responses. |
application/octet-stream (ct=42) |
[m] | File transfer (SWU). |
application/json |
[o] | Device MAY also support this format. |
CoAP Response Codes
Standard CoAP success and error codes the device must return for consistent client error handling.
| Code | Support | Notes |
|---|---|---|
| 2.01 Created | [m] | Successful create (POST). |
| 2.02 Deleted | [m] | Successful delete. |
| 2.04 Changed | [m] | Successful write (PUT/POST). |
| 2.05 Content | [m] | Successful read/discover. |
| 4.00 Bad Request | [m] | Invalid syntax. |
| 4.01 Unauthorized | [m] | Authentication required (highest priority). |
| 4.02 Bad Option | [m] | Unrecognized critical option. |
| 4.03 Forbidden | [m] | Authenticated but not authorized. |
| 4.04 Not Found | [m] | Resource does not exist. |
| 4.05 Method Not Allowed | [m] | Method not allowed (for example, write in loaded state). |
| 4.06 Not Acceptable | [m] | Content negotiation failure. |
| 4.15 Unsupported Content-Format | [m] | Format not supported. |
| 4.29 Too Many Requests | [m] | Rate limiting (RFC 8516). |
| 5.00 Internal Server Error | [m] | Generic server error. |
| 2.03 Valid | [o] | ETag support. |
| 2.31 Continue | [o] | Block-wise transfer (RFC 7959). |
| 4.08 Request Entity Incomplete | [o] | Missing blocks. |
| 4.12 Precondition Failed | [o] | Conditional request failure. |
| 4.13 Request Entity Too Large | [o] | Request size limit. |
| 5.03 Service Unavailable | [o] | Temporary unavailability with Max-Age retry. |
Rate Limiting
Protect constrained devices from battery drain and denial-of-service by rejecting excessive requests.
| Feature | Support | Notes |
|---|---|---|
| Request rate limiting | [m] | Prevents battery drain and DoS. Response: 4.29. |
IPv6 Network Layer
Mandatory UDP/IPv6 transport with unicast and multicast at three scopes for discovery and group communication.
| Feature | Support | Notes |
|---|---|---|
| CoAP over UDP (RFC 7252) | [m] | Mandatory application protocol. |
| CoAP over TCP/TLS | [o] | If the device supports TLS. |
| IPv6 unicast | [m] | At least 3 routable addresses + link-local. |
| IPv6 multicast (link-local scope 2) | [m] | Discovery. |
| IPv6 multicast (realm-local scope 3) | [m] | Mesh networks (Thread). |
| IPv6 multicast (site-local scope 5) | [m] | Cross-network discovery. |
Summary: Mandatory vs Optional by Area
The table below condenses each section into its mandatory and optional features for quick reference during implementation or compliance review.
| Area | Mandatory Features | Optional Features |
|---|---|---|
| Discovery | mDNS _knx._udp, /.well-known/core with ep, if.pm, rt, d queries |
IPv4 A records, manufacturer subtypes, TXT records (except sleepy SP) |
| Device Interface Object | /dev properties (sn, mid, hwt, model, fwv, sna, da, pm, hname, ipv6, iid, mport, port), /.well-known/knx (reset, restart, IA, fingerprint, SPAKE) |
fid, hwv, idevid, ldevid |
| Security | OSCORE (unicast + multicast), SPAKE2+/PASE, access tokens (/auth/at), echo challenge, replay protection |
TLS 1.2/1.3 (if TLS: ldevid, /auth/crts, /a/sen, /auth/sen or /auth/skg), X.509 certificates (IDevID/LDevID), EST enrollment, trust list, device handover |
| Group Communication | /k resource, multicast + unicast S-Mode, CoAP Observe on /k, Write/Read/Response, Group Object Table (/fp/g), Recipient Table (/fp/r), Publisher Table (/fp/p) |
Endpoint subscription, non-confirmable notifications, configurable sequence number sync |
| Point r/w/pub/sub | /p link list, GET on all points, metadata (id, rt, if, dpt, ga), observe on if.o points |
PUT on parameter points, Z8 status/command, cov/mrt/hbt metadata |
| Functional Block | /f link list, /f/{fb-id-instance} |
Additional FBs beyond /.well-known/core |
| SWU | PUSH mode, /swu properties, /a/swu PUT, resume, integrity verification |
PULL mode, deferred activation, package address, protocol selection |
| KNX IoT Router | /fp/gm, /f/datasec, compliance with exactly one medium profile |
/f/coupling and /p/coupling/segment-iatbl (Segment Coupler role) |
References
- KNX IoT Point API Specification, Chapter 3/10/5, Version 1.4.0
- KNX IoT Point API OpenAPI Schema (
knxiot-point-api-scheme-openapi.yaml), Version 1.0.1 - RFC 7252, CoAP
- RFC 8613, OSCORE
- RFC 9175, Echo, Request-Tag, Token Processing
- RFC 9383, SPAKE2+
- RFC 6763, DNS-SD
- RFC 6762, mDNS
- RFC 7959, Block-wise Transfers
- RFC 5246 / 8446, TLS 1.2 / 1.3
- RFC 9148, EST-CoAPS