Group communication and discovery

Group communication is how KNX IoT devices exchange application values at runtime, and discovery is how clients and devices find each other. Both are described here. For more information, see the KNX IoT device profile and KNX IoT function point tables.

S-Mode group communication

S-Mode (System Mode) is the standard KNX runtime messaging model, reused unchanged by KNX IoT. Instead of addressing a specific device, a sender transmits a message to a group address (GA), and every device bound to that GA reacts. This is the IP-native equivalent of a classic KNX group telegram, and it is what lets one switch control many lights, or many switches feed one light.

A sender does not expect a direct reply. If feedback is needed, it arrives indirectly as a separate group event (for example, an actuator announcing its new status on a status GA).

Function point tables

A device’s participation in group communication is defined by three tables, written during commissioning and described in KNX IoT function point tables:

  • Group Object Table (/fp/g) - The central binding: it maps each datapoint to one or more group addresses.

  • Recipient Table (/fp/r) - The destinations for outgoing group messages, either a multicast group or a specific unicast peer.

  • Publisher Table (/fp/p) - The expected sources of incoming group messages.

Together these tables decide what a device sends, where it sends it, and what it accepts.

Multicast and unicast

Group messages can be delivered in two ways:

  • Multicast - One message reaches all receivers of a group at once. It is efficient for one-to-many distribution. Link-local and mesh-local multicast stays within the local link or Thread mesh. Reaching devices on another link (for example, Wi-Fi or Ethernet) requires a larger multicast scope and a Thread Border Router that forwards it.

  • Unicast - A message is delivered point-to-point to each configured recipient using Confirmable (CON) CoAP messages, which are acknowledged and retransmitted if lost. Unicast is used when reliable delivery or delivery across routers is required.

Runtime message flow

The following diagram shows the basic flow when a switch (sensor) toggles a light (actuator) bound to the same group address, as in the KNX-IoT samples.

S-Mode group communication flow between a sensor and an actuator

At runtime, a device sends a group notification by POSTing to the /k resource of its targets (or to a multicast group), carrying the source address, target group address, service type (write, read, or response), and the datapoint value. Subscribers can also use CoAP Observe on /k to receive notifications.

Note

In the KNX-IoT samples, both devices share a single group address and a single group OSCORE key applied through hardcoded commissioning, so they exchange S-Mode messages directly without a commissioning tool. See Commissioning and the KNX-IoT samples.

Read, write, and subscribe

Besides group communication, a client can access a device’s datapoints directly through the Point API:

  • Read - GET a point resource under /p to obtain its current value and metadata.

  • Write - PUT a value to a point resource to change it.

  • Subscribe - Use CoAP Observe to receive a notification whenever a value changes, instead of polling.

These direct accesses are used for diagnostics, parameters, and integration with non-KNX systems, complementing the group-based S-Mode traffic.

Discovery

Discovery lets a client locate a device and its resources without prior configuration. KNX IoT uses two mechanisms.

DNS-SD

DNS-based service discovery (RFC 6763) advertises a device’s IPv6 address, CoAP port, and KNX attributes such as serial number, Individual Address, and programming-mode state. It can be implemented with different mechanisms, such as multicast DNS (RFC 6762) and SRP. On Thread, devices register their services with the Thread Border Router using SRP, and the border router acts as a DNS proxy that re-advertises them with mDNS on the infrastructure link, bridging the SRP and mDNS mechanisms (see Thread Border Router).

CoAP resource discovery

A client can also query a device directly through /.well-known/core, the CoAP resource discovery mechanism defined in RFC 7252. This returns a list of links to the device’s resources and supports filters, for example:

  • By serial number, to locate a specific (possibly unconfigured) device.

  • By programming mode, to find a device the installer has put into programming mode.

  • By resource type or by group address, to find devices that host a particular function or are bound to a particular GA.

These filters are what a commissioning tool uses to find and identify a device before configuring it; see Commissioning.