Device Function Point Tables

The Function Point Tables configure how a KNX IoT device sends and receives group messages at runtime. A Management Client (MaC) writes these tables during configuration download.

Commissioning Context

The MaC provisions Function Point Tables as part of device commissioning. For the full commissioning sequence and security bootstrapping, see Device Bootstrapping.

Access rules for Function Point Table resources:

GET is possible in any Load State Machine state.
POST and DELETE require state = loading.
The device evaluates the tables for runtime group communication only when the Load State Machine reaches loaded.

For message exchange patterns (multicast, direct unicast, endpoint subscription) and how the device uses these tables at runtime, see Group Communication. For resource-level support requirements, see Device Profile.

Table	Resource	Role
Group Object Table	`/fp/g`	Maps Group Addresses to datapoints
Recipient Table	`/fp/r`	Destinations for outgoing group messages
Publisher Table	`/fp/p`	Sources for incoming group messages

How the Tables Relate

The Group Object Table is the central binding. It connects a datapoint (href) to one or more Group Addresses (ga). The Recipient and Publisher Tables reference the same Group Addresses to define the network endpoints (multicast grpid or unicast ia). The receive-side multicast decision follows the Group Object cflag. If a datapoint has a receive-related flag such as Write (W), Update (U), or Read (R), the device treats the Group Address as an incoming multicast target. The device then registers the corresponding grpid in /fp/p.

The following diagram shows a single LSAB light actuator device. The actuator has two datapoints. One datapoint, soo, receives commands via multicast. The other datapoint, ioo, transmits status via unicast. The left side shows the incoming command path. The right side shows the outgoing status path.

    LSAB Light Actuator (single device)

    /p/lsab/soo (command)       /p/lsab/ioo (status)
             ^                         |
             | write value             | value changed
             |                         v
  ┌------------------------------------------------┐
  │ Group Object (fp/g) │    │ Group Object (fp/g) │
  │ id=0, ga=[2304]     │    │ id=1, ga=[2305]     │
  │ cflag=144 (W+U)     │    │ cflag=72 (R+T)      │
  └------------------------------------------------┘
             ^                         |
             | ga=2304                 | ga=2305
             |                         v
  ┌----------------------┐  ┌----------------------┐
  │ Publisher Tbl (fp/p) │  │ Recipient Tbl (fp/r) │
  │ ga=[2304]            │  │ ga=[2305]            │
  │ grpid=2863267844     │  │ ia=12803 (3.2.3)     │
  └----------------------┘  └----------------------┘
             ^                         |
             |                         | at='1a'
             |                         v OSCORE encrypt
  ┌------------------------------------------------┐
  │            Access Tokens (/auth/at)            │
  │ Multicast: match kid (in) from OSCORE header   │
  │ Unicast:   "at" (out) in fp/r|fp/p = token id  │
  └------------------------------------------------┘
             ^ kid match               |
             | OSCORE decrypt          |
             |                         v
        ┌---------┐               ┌---------┐
        │ Network │               │ Network │
        │ (recv)  │               │ (send)  │
        └---------┘               └---------┘

Value flow at runtime:

Incoming (soo, Write): A multicast message with GA 2304 arrives. The device decrypts with OSCORE (kid in header matches an Access Token in /auth/at). fp/p matches grpid 2863267844 to GA 2304. fp/g id=0 (cflag W+U) marks this datapoint as an incoming multicast target, so the device registers the corresponding multicast group and writes the value to /p/lsab/soo.
Outgoing (ioo, Transmit): The actuator status changes on /p/lsab/ioo. fp/g id=1 (cflag R+T) selects sending GA 2305. fp/r resolves the destination (ia=12803 / 3.2.3, at='1a') and encrypts with OSCORE. The device sends a unicast CON POST to the light switch.

Access Token linkage:

Multicast (grpid in fp/r or fp/p): On the sender side, the device looks up /auth/at entries whose scope covers the GA. This provides the encryption key. On the receiver side, the OSCORE sender ID in the message header identifies the Access Token via cnf.osc.id for decryption. The device also verifies that the scope covers the GA.
Unicast (at in fp/r or fp/p): On the sender side, the at text string references the Access Token whose id matches in /auth/at. The device verifies that the scope covers the GA before encrypting. On the receiver side, the OSCORE sender ID in the message header identifies the Access Token via cnf.osc.id for decryption.

Access Token Format and Scope

The Function Point Tables reference Access Tokens by at. For token structure, credential types, and examples see Device Access Control.

Group Object Table (`/fp/g`)

Maps each Group Object (logical input/output) to Group Addresses and a datapoint resource path.

Group Object CBOR Keys

CBOR Key	Name	Type	M/O	Description
0	`id`	unsigned	[m]	Group Object identifier (unique per device).
7	`ga`	unsigned array	[m]	Group Addresses. First item is the sending GA.
8	`cflag`	unsigned	[m]	Group Object Configuration Flags bit mask.
11	`href`	text string	[m]	Datapoint resource path (for example, `/p/rts/temproom`).

Group Object Configuration Flags (`cflag`)

Bit	Value	Flag	Description
7	0x10	Write (W)	Accept incoming Group Value Write messages.
6	0x40	Transmit (T)	Send Group Value Write on value change triggered by the application.
5	0x20	Init (I)	Send Group Value Read on startup.
4	0x80	Update (U)	Accept incoming Group Value Response messages.
3	0x08	Read (R)	Respond to Group Value Read requests.

Common combinations:

Combination	Value	Use case
R+T	72 (0x48)	Sensor: responds to reads, transmits on change.
T	64 (0x40)	Sensor: transmits only.
W+U	144 (0x90)	Actuator: accepts writes and response updates.

Example

# POST to /fp/g — LSAB actuator with two channels (soo + ioo each)
[
    {0: 0, 7: [2304], 8: 144, 11: "/p/lsab/0/soo"},  "/ W+U, ch0 command /"
    {0: 1, 7: [2305], 8: 72,  11: "/p/lsab/0/ioo"},  "/ R+T, ch0 status /"
    {0: 2, 7: [2306], 8: 144, 11: "/p/lsab/1/soo"},  "/ W+U, ch1 command /"
    {0: 3, 7: [2307], 8: 72,  11: "/p/lsab/1/ioo"},  "/ R+T, ch1 status /"
]

Multiple Group Addresses

A Group Object can have multiple GAs. The first GA is the sending address: when the device receives a Group Value Read on any of the GAs, it sends the Group Value Response on the first GA. Additional GAs enable receiving from multiple groups:

{0: 0, 7: [2304, 2560], 8: 216, 11: '/p/lsab/0/soo'}

If multiple Group Objects share the same href, the one with the lowest id contains the sending GA.

Recipient Table (`/fp/r`)

Defines destinations for outgoing group messages. Each item maps Group Addresses to either a multicast grpid or a unicast ia (one of grpid or ia SHALL be present).

Support column legend: [m] = mandatory, [c] = conditional (present depending on the chosen pattern), [o] = optional.

Recipient CBOR Keys

CBOR Key	Name	Type	M/O/C	Description
0	`id`	unsigned	[m]	Recipient item identifier.
7	`ga`	unsigned array	[m]	Group Addresses to send.
12	`ia`	unsigned	[c]	Recipient Individual Address. Use for unicast.
13	`grpid`	unsigned	[c]	Multicast Group ID (32-bit). Use for multicast.
14	`at`	text string	[c]	Access Token reference. Use for unicast.
25	`fid`	unsigned	[o]	Fabric ID (cross-fabric).
26	`iid`	unsigned	[o]	Installation ID (cross-installation).
"non"	`non`	boolean	[o]	Unicast non-confirmable CoAP (default: confirmable).

Multicast Example

# POST to /fp/r — LSAB actuator sends status via multicast
[{0: 0, 7: [2305, 2307], 13: 2863267844}]
#                        grpid = AAAA:0004

The device derives the IPv6 multicast address from grpid: MSB set (>= 0x80000000) -> unicast-prefix-based multicast address (pseudocode: FF3X:0030:<ULA prefix>::8000:<grpid>). MSB clear -> IANA permanent FF0X::0004:<grpid>.

Unicast Example

# POST to /fp/r — LSAB status unicast to light switch IA 3.2.3 (12803)
[{0: 0, 7: [2305], 12: 12803, 14: h'1a'}]
#                  ia=3.2.3   at="1a"

The device resolves the IA to an IPv6 address via mDNS or CoAP before sending a CON CoAP POST.

Publisher Table (`/fp/p`)

Defines sources for incoming group messages. Each item registers which GAs the device expects to receive and from which endpoint: multicast grpid (join group) or unicast ia (CoAP Observe subscription on /k). One of grpid or ia SHALL be present.

Publisher CBOR Keys

CBOR Key	Name	Type	M/O/C	Description
0	`id`	unsigned	[m]	Publisher item identifier.
7	`ga`	unsigned array	[m]	Group Addresses to receive.
12	`ia`	unsigned	[c]	Publisher Individual Address. Use for subscription.
13	`grpid`	unsigned	[c]	Multicast Group ID. Use for multicast listen.
14	`at`	text string	[c]	Access Token reference. Use for endpoint subscription.
25	`fid`	unsigned	[o]	Fabric ID (cross-fabric).
26	`iid`	unsigned	[o]	Multicast Group Installation ID (cross-installation).

Publisher Multicast Example

# POST to /fp/p — LSAB actuator receives commands via multicast
[{0: 0, 7: [2304, 2306], 13: 2863267844}]
#                        grpid = AAAA:0004

Subscription Example (Endpoint Subscription)

# POST to /fp/p — LSAB subscribes to switch IA 3.2.3 (12803) for commands
[{0: 0, 7: [2304], 12: 12803, 14: h'2b'}]
#                  ia=3.2.3   at="2b"

The device sends a CoAP Observe request to /k on IA 3.2.3 (12803) using OSCORE credentials from Access Token '2b'.

Which Tables Each Message Exchange Pattern Needs

The following matrix shows which tables each communication pattern requires on each device side.

Pattern	`fp/g`	`fp/r`	`fp/p`
Multicast	Both sides	Sender (`grpid`)	Receiver (`grpid`)
Direct unicast	Both sides	Sender (`ia`)	Not required
Endpoint subscription	Both sides	--	Subscriber (`ia`)

For unicast reception without a Publisher Table entry, the device uses the kid from the OSCORE header to find the matching Access Token. For endpoint subscription, the Publisher Table entry is on the subscriber (receiver) side.