SIST EN 50090-4-4:2025

Home and Building Electronic Systems (HBES) - Part 4-4: HBES IoT Point API

This document lays down the requirements for the HBES Point API extension to the EN 50090 series, allowing vendor independent communication between smart home and building devices on IPv6 networks.

Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 4-4: ESHG IoT Point API

Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 4-4: API de Point IdO HBES

Le présent document définit les exigences relatives à l'extension de l'API de Point HBES à la série EN 50090 pour permettre une communication indépendante du fournisseur entre des dispositifs de maison intelligente et de bâtiment sur des réseaux IPv6.

Stanovanjski in stavbni elektronski sistemi (HBES) - 4-4. del: HBES IoT Point API

Ta dokument določa zahteve za razširitev vmesnika HBES Point API na skupino standardov EN 50090, ki omogoča komunikacijo med napravami za pametni dom in napravami v stavbah v omrežjih IPv6, neodvisno od dobavitelja.

General Information

• Status: Published
• Public Enquiry End Date: 30-Dec-2024
• Publication Date: 09-Jun-2025
• ICS: 35.240.67 - IT applications in building and construction industry
• ICS: 97.120 - Automatic controls for household use
• Technical Committee: ELI - Electrical and communication installations
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 06-Jun-2025
• Due Date: 11-Aug-2025
• Completion Date: 10-Jun-2025
• Ref Project: EN 50090-4-4:2025 - Home and Building Electronic Systems (HBES) - Part 4-4: HBES IoT Point API

Overview

SIST EN 50090-4-4:2025 - HBES IoT Point API - is the HBES (Home and Building Electronic Systems) extension that defines a vendor‑independent Point API for communicating smart home and building devices over IPv6 networks. Approved by CENELEC (16 April 2025), this European standard specifies architecture, resource models, security and runtime interworking to enable interoperable HBES IoT solutions across manufacturers and platforms.

Key Topics and Technical Requirements

The standard lays out requirements and API behaviours including:

• System entities and Device Model - definitions of devices, datapoints, channels, functional blocks, function points and group objects used in HBES IoT.
• Point API and Application Protocol - media‑independent application layer rules to exchange HBES point/state data on IPv6.
• Resource Model and Runtime Interworking - how datapoints and resources are represented and how devices interoperate at runtime.
• Device Bootstrapping and Configuration - procedures for secure onboarding and initial device configuration on HBES Installations.
• Security and Identity Management - device identity enrollment, domain certificates, certificate validation, access control and OSCORE application‑layer security.
• Software Update - standardized software update client resource and update modes.
• HBES IoT Router and Profiles - router specification, URI/URN formats and profile definitions for consistent deployment.
• Encoding and Examples - CBOR encoding, practical device examples and data encryption/decryption guidance.

Normative references include related EN 50090 parts and key IETF RFCs such as CoAP (RFC 7252), CBOR (RFC 8949), OSCORE (RFC 8613) and others relevant to IPv6, discovery and security.

Practical Applications and Who Uses It

This standard is directly relevant for:

• Device manufacturers building HBES‑capable sensors, actuators and controllers that must interoperate across vendors.
• System integrators and installers deploying smart home and building automation solutions that leverage IPv6 and standardized APIs.
• IoT platform developers and software engineers creating gateways, routers and cloud integrations that interact with HBES devices using CoAP/OSCORE and CBOR.
• Network architects and security teams responsible for device onboarding, certificate management, secure communication and software update workflows.
• Standards bodies and test labs implementing conformance and interoperability testing.

Key practical benefits: simplified multi‑vendor integration, improved security for device onboarding and operation, and standardized update and runtime behaviour for large‑scale HBES deployments.

Related Standards

• EN 50090-1:2011 (HBES structure)
• EN 50090-3-3 (HBES interworking model)
• EN 50090-4-1 / 4-2 (application/transport layers)
• EN 50090-7-1 (system management)
• IETF RFCs: CoAP, CBOR, OSCORE and related IPv6/discovery/security RFCs

For implementers, EN 50090-4-4:2025 is the authoritative reference to achieve vendor‑neutral, secure IPv6-based HBES IoT interoperability.

Standards Content (Sample)

SLOVENSKI STANDARD
01-julij-2025
Stanovanjski in stavbni elektronski sistemi (HBES) - 4-4. del: HBES IoT Point API
Home and Building Electronic Systems (HBES) - Part 4-4: HBES IoT Point API
Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 4-4: ESHG IoT Point
API
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 4-
4: API de Point IdO HBES
Ta slovenski standard je istoveten z: EN 50090-4-4:2025
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 50090-4-4

NORME EUROPÉENNE
EUROPÄISCHE NORM May 2025
ICS 35.240.67; 97.120
English Version
Home and Building Electronic Systems (HBES) - Part 4-4: HBES
IoT Point API
Systèmes électroniques pour les foyers domestiques et les Elektrische Systemtechnik für Heim und Gebäude (ESHG) -
bâtiments (HBES) - Partie 4-4: API de Point IdO HBES Teil 4-4: ESHG IoT Point API
This European Standard was approved by CENELEC on 2025-04-16. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50090-4-4:2025 E
Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 10
4 HBES IoT Point API . 12
4.1 Introduction . 12
4.2 System entities . 13
4.3 Device Model . 14
4.4 Conventions used in this document . 16
5 Point API Standard . 16
5.1 Application Protocol . 16
5.2 Overview . 16
5.3 System Design . 19
5.4 Device Bootstrapping and Configuration . 22
5.5 Resource Model . 26
5.6 Runtime Interworking . 74
6 Security . 99
6.1 Introduction . 99
6.2 Device Identity Enrollment. 99
6.3 Device Identity Certificates . 104
6.4 Certificate Validation . 106
6.5 Device Access Control . 107
6.6 OSCORE Application Layer Security . 114
7 Software Update . 135
7.1 Introduction . 135
7.2 Software Update Client Resource (swu) . 136
7.3 Software Update Modes . 140
8 Profiles . 150
8.1 HBES IoT Point API Device . 150
8.2 CBOR Encoding . 156
9 Examples . 157
9.1 Device point list examples . 157
9.2 Device configuration example . 161
9.3 Data encryption/decryption example . 169
10 HBES IoT Router . 172
10.1 Introduction . 172
10.2 Conformance . 173
10.3 Number Format . 173
10.4 Uniform Resource Identifiers . 173
10.5 Uniform Resource Name . 173
10.6 HBES IoT Router Specification . 173
10.7 Runtime Interworking . 181
10.8 Profiles . 183
10.9 Security . 186
10.10 Examples . 186
Bibliography . 189
European foreword
This document (EN 50090-4-4:2025) has been prepared by CLC/TC 205 “Home and Building Electronic
Systems (HBES)”.
The following dates are fixed:
• latest date by which this document has to be (dop) 2026-05-31
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2028-05-31
conflicting with this document have to be
withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national committee. A complete
listing of these bodies can be found on the CENELEC website.
1 Scope
This document lays down the requirements for the HBES Point API extension to the EN 50090 series, allowing
vendor independent communication between smart home and building devices on IPv6 networks.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments) applies.
EN 50090-1:2011, Home and Building Electronic Systems (HBES) - Part 1: Standardization structure
EN 50090-3-3, Home and Building Electronic Systems (HBES) - Part 3-3: Aspects of application - HBES
Interworking model and common HBES data types
EN 50090-4-1, Home and Building Electronic Systems (HBES) - Part 4-1: Media independent layers -
Application layer for HBES Class 1
EN 50090-4-2, Home and Building Electronic Systems (HBES) - Part 4-2: Media independent layers - Transport
layer, network layer and general parts of data link layer for HBES Class 1
EN 50090-7-1, Home and Building Electronic Systems (HBES) - Part 7-1: System management - Management
procedures
EN ISO 22510, Open data communication in building automation, controls and building management - Home
and building electronic systems - KNXnet/IP communication (ISO 22510:2019)
RFC 7252, The Constrained Application Protocol (CoAP)
RFC 8949, Concise Binary Object Representation (CBOR)
RFC 6838, Media Type Specifications and Registration Procedures
RFC 6690, Constrained RESTful Environments (CoRE) Link Fomat
RFC 1035, Domain names – Implementation and specification
RFC 8323, CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
RFC 4291, IP Version 6 Addressing Architecture
RFC 6763, DNS-Based Service Discovery
RFC 8766, Discovery Proxy for Multicast DNS-Based Service Discovery
RFC 6762, Muticast DNS
RFC 3596, DNS Extensions to Support IP Version 6
RFC 8613, Object Security for Constrained RESTful Environments (OSCORE)
RFC 7959, Block-Wise Transfers in the Constrained Application Protocol (CoAP)
RFC 9175, Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
RFC 8516, “Too Many Requests” Response Code for the Constrained Application Protocol
RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses
RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses
RFC 6282, Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
RFC 9148, EST-coaps: Enrollment over Secure Transport with the Secure Constrained Applicatoin Protocol
RFC 8995, Bootstrapping Remote Secure Key Infrastructure (BRSKI)
RFC 5967, The application/pkcs10 Media Type
RFC 5273, Certificate Management over CMS (CMC): Transport Protocols
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 2818, HTTP Over TLS
RFC 7251, AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC 8392, CBOR Web Token (CWT)
RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
RFC 8747, Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
RFC 8152, CBOR Object Signing and Encryption (COSE)
RFC 3339, Date and Time on the Internet: Timestamps
RFC 6335, Internet Assigned Numbers Authority (IANA) Procedures for the Managmenet of the Service Name
and Transport Protocol Port Number Registry
RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 50090-1:2011 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
Actuator
Point performing an actuation in HBES IoT (executed by a specific procedure, with an expected result) that
changes an Installation state during Runtime
3.1.2
Advanced Message Queuing Protocol
open standard application layer protocol for message-oriented middleware with defining features such as
message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and
security
3.1.3
Application Function
set of Functions used to achieve the desired behavior of a technical system, typically using a combination of
devices exchanging information via their input and output Datapoints
Note 1 to entry: An Application Function may be split into several Functional Blocks (located in one or more devices) with
their input and output Datapoints that are logically connected to each other.
EXAMPLE “direct electrical heating”, “electrical heating with accumulators”, “warm water heating”, “fan coil air-
conditioning” …
3.1.4
Authorization and Group Manager
entity service that supports an authorized access so that a device can join to a specific communication channel
3.1.5
Channel
collection of Datapoints of a device that are logically related to each other typically by association with a
hardware feature or a specific function of that device
Note 1 to entry: These Datapoints may be derived from one or more defined Functional Blocks (as defined by KNXA) or may
be an expansion above and beyond defined Functional Blocks or may be independent of a NX Functional Block if none is
defined for the function associated with the channel.
3.1.6
Datapoint
representation of a logical input entity of a device acting as recipient of Installation state data, whereas a logical
output of a device acts as source of Installation state data
3.1.7
Device
physical element that is part of the network and an object a customer can buy
3.1.8
Domain CA
entity that issues operational certificates for the domain
3.1.9
Endpoint
interface to a service, a process, or a queue or topic destination in service-oriented architecture
3.1.10
Function
part of the intended behavior of a Functional Block in a building context
3.1.11
Functional Block
one or more Functions that belong together, that cannot be separated across two devices but is big enough that
a device with only one such entity could be marketed and that has a well-defined black box behavior
3.1.12
Function Point
runtime system state information of a specific Application Function shared by at least two datapoints and having
a unique identifier that addresses a group of controlled objects called a Group Address
EXAMPLE < Light Switch > in room living on/off, whereas the < … > is the Function Point name
3.1.13
Group Address
numerical identifier of a Function Point
3.1.14
Group Communication
communication model in which one sender communicates information to one and typically more receivers
Note 1 to entry: In HBES IoT, this can be realized by simple UDP communication or by using a message broker system or
other.
Note 2 to entry: In non-IoT HBES this is referred to as multicast or P2P based Group Communication, either with Group
Addresses or Interface Objects (Points) exchanging state data
3.1.15
Group Message
message exchanged between Group Objects using a specific group identifier, not necessarily expressing any
type of IP unicast or IP multicast communication pattern
3.1.16
Group Object
preferably foreseen for Group Communication using Group Address(es) - becoming a member of a Function
Point represented by the assigned Group Address – or accessible via P2P communication, if no Group Address
is assigned
3.1.17
HBES Installation ID
ID used to separate HBES Installations from each other, specified as a random, unique ID
3.1.18
HBES IoT
protocol suite/framework for transport of HBES data on the Internet of Things with IPv6
3.1.19
rd
HBES IoT 3 Party API
the set of requirements and regulations through which partial access to an Installation can be gained by offering
a collection of Endpoints
Note 1 to entry: It offers an access at the level of the Installation and supports more sophisticated queries to (history) values
of installation state data or specific elements of the Installation, such as location, Application Function and Datapoints.
3.1.20
HBES IoT Router
gateway between HBES IoT and non-IoT HBES
3.1.21
HBES IoT Point API
set of requirements and regulations through which devices directly exchange information with each other based
on HBES IoT
3.1.22
HBES System
system which ncompasses HBES standards and definitions, allowing the creation of an Installation, and
including aspects such as topology constraints for devices, device configuration procedures and runtime
interworking principles, Functional Blocks, with Application behavior specified in FBs and more
3.1.23
Installation
assembly of materials and components (devices) placed in position to provide a service, a deployed system
consisting of equipment and Functions that are used for a particular purpose
EXAMPLE A deployed Installation may be a HVAC system or a fire protection system.
3.1.24
Management Client
means to configure and commission Devices, as well as to plan, design and diagnose an entire Installation
Note 1 to entry: Is also responsible to write specific configuration data such as Device parameters or group tables to the
Devices.
3.1.25
MaC Project
Project created by a Management Client documenting the Configuration of an Installation
3.1.26
Message Broker
entity that is receiving messages from publishers and providing it to interested subscribers, the defining
characteristic is that the broker itself is a discrete service
3.1.27
MQTT
Message Queuing Telemetry Transport publish-subscribe-based messaging Protocol, standardized as ISO/IEC
3.1.28
Non-IoT HBES
HBES TP, RF, PL and KNXnet/IP protocol for transport of HBES data, in this document colloquially also used
as synonym for an HBES System without any HBES IoT Devices
3.1.29
Ontology
conceptual descriptions of things that have a real-world commonality sharing the knowledge of a domain, mainly
expressed with OWL
Note 1 to entry: Are a structured way to describe the meaning of data in ontology classes and should not be mixed up with
common data model structures.
3.1.30
OWL
Web Ontology Language, informally OWL 2, specified by the World Wide Web Consortium (W3C), mainly
serialized with XML syntax for RDF (RDF/XML)
Note 1 to entry: In this specification the abbreviation OWL is always an explicit reference to OWL 2.
3.1.31
Point
represents an interface to data in the system
Note 1 to entry: In this document the term Point is used as an umbrella for data that can be accessed from outside the
Device, for instance to interact with other Points from other Devices, hence the term is a generic superset of the term
Datapoint (describing more precisely the technics how the “data” in the system are structured and/or coded).
3.1.32
Point API
simple RESTful (CoAP or HTTP) application programming interface designed for, but not limited to, constrained
class 2 devices [RFC 7228] supporting device individualization, device linking and accessing device runtime
data (e.g., Functional Block or Channel Datapoints)
3.1.33
Publisher
entity that is sending messages to a Message Broker
3.1.34
Recipient
entity that is receiving messages from a Publisher
Note 1 to entry: If the Recipient is not Subscriber at the same time, then the Recipient endpoint needs to be a fixed
configuration in the Publisher group table.
3.1.35
RDF
framework to represent information in the web by using triples, which can be serialized and stored in many
formats
Note 1 to entry: Fomats such as the TURTLE or JSON(-LD) are described under https://www.w3.org/TR/rdf11-concepts/
3.1.36
Registrar
entity that is a service representative of a certain domain, configured to decide whether a new device is allowed
to join the domain
3.1.37
Runtime
process-to-process communication of data between Devices, opposing to Configuration
Note 1 to entry: Concerns mainly the communication of Datapoint values (control and status information).
3.1.38
Security Zone
group of devices that all make use of the same Trust Anchor
3.1.39
Sensor
Point in HBES IoT, performing an observation (executed by a specific procedure, triggered by a stimulus),
responding a result as an Installation state during Runtime
3.1.40
Subscriber
HBES IoT device receiving messages from a Message Broker
3.1.41
Tag
kind of annotation term used to extend available data with (in most cases) well known standardized information
from a dictionary (in contrast to user defined, arbitrary term)
3.1.42
Thing Description
semantic metadata model to describe (abstract or physical) things, as specified by the thing description
https://www.w3.org/TR/wot-thing-description/ and thing Ontology https://www.w3.org/2019/wot/td
3.1.43
Trust Anchor
authoritative entity for which trust is assumed and not derived (e.g. an X.509 root certificate)
3.1.44
X.509
certificate format
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AEAD Authenticated Encryption with Additional Data
AL Application Layer
AMQP Advanced Message Queuing Protocol
AP Access Point
API Application Programming Interface
BLE Bluetooth Low Energy
BRSKI Bootstrapping Remote Secure Key Infrastructure
C Conditional
CBOR Concise Binary Object Representation
CoRE Constraint RESTful Environments
COSE CBOR Object Signing and Encryption
CRL Certificate Revocation List
CSR Certificate Signing Request
CWT CBOR Web Token
DAD Duplicate Address Detection
DNS Domain Name System
DNS-SD Domain Name System Service Discovery
DB Database
DER Distinguished Encoding Rules
DTLS Datagram Transport Layer Security
EST Enrollment over Secure Transport
FQDN Fully Qualified Domain Name
GA Group Address
GO Group Object
FB Functional Block
FP Function Point
HBES Home and Building Electronic Systems
HKDF Hash-based Key Derivation Function
HMAC Hash-Based Message Authentication Code
IANA Internet Assigned Numbers Authority
IOO Info On off
IO Input Output
IP Internet Protocol
IoT Internet of Things
JSON JavaScript Object Notation
KDC Key Distribution Center
KDF Key Derivation Function
KNXA KNX Association
KDC Key Distribution Center
LLA Link Local Address
LRI Logical Resource Identifier
LSM Load State Machine
LTE Logical Tag Extended
M Mandatory
MaC Management Client
MAC media access control address
MQTT Message Queuing Telemetry Transport
NB Narrow Band
NFC Near Field Communication
O Optional
OCSP Online Certificate Status Protocol
OID Object Identifier
OSCORE Object Security for Constrained RESTful Environments
OSV Out of Service
OT Operational Technology
PAKE Password Authenticated Key Exchange
PASE Password Authenticated Session Establishment
PBKDF Password-based Key Derivation Function
PSK Pre-shared Key
PTR Pointer
QR Quick Response
RD Resource Directory
RDF Resource Description Framework
RT Resource Type
SAN Subject Alternative Name
S-Mode System Mode
SP Sleep Period
SRP Service Registration Protocol
SSM Source-Specific Multicast
TCP Transport Control Protocol
TD Thing Description
TOFU Trust on First Use
UDP User Datagram Protocol
ULA Unique Local Address
URN Uniform Resource Name
URI Uniform Resource Identifier
REST Representational State Transfer
W3C World Wide Web Consortium
WoT Web of Things
WPAN Wireless Personal Area Network
4 HBES IoT Point API
4.1 Introduction
The HBES System Architecture is given in Figure 1.
HBES IoT uses Internet Protocol (IP) suite standards for the transmission of HBES IoT application layer data
across IP networks.
Physical media like Ethernet (IEEE 802.3), Wi-Fi (802.11), or WPAN (802.15.4) carry HBES IoT packets. These
may contain unicast TCP or UDP frames or multicast UDP frame transmission of HBES IoT application data.
HBES IoT application data is agnostic to the underlying communication layers. Hence, it is possible to send
HBES IoT messages over non-IP transport bindings such as NB IoT, or BLE. However, this is out-of-scope of
this document.
A typical (IP-based) interworking infrastructure allows heterogeneous data link media to work seamlessly with
each other. The Point API maps HBES AL data to a RESTful resource model, and CBOR/JSON-based data
representation is used to communicate over IP. Using this API, a client can read/write values or subscribe to
Point events (e.g., switch on/off). The HBES IoT Point API is based on the following building blocks:
• Discovery
Discovery (of resources, including devices) can be made with unicast or multicast. Resource discovery
in CoAP (CoRE) is accomplished using a "/.well-known/core" resource URI that returns a list of links about
resources (e.g., Functional Block Properties) hosted by that server that matches filter attributes.
• S-Mode Messaging
The S-Mode messaging uses a secure message-oriented communication pattern for group communication
where a producer sends a message to notify consumers of a change in the domain. A tool, or rather a
Management Client (MaC), configures group communication events via group tables.
• Point Read, Write, and Publish/Subscribe
Parameter and diagnostic Properties are used for sensor, actuator, parameter, and diagnostic values, such as
getting the current sensor value or setting a setpoint. They are addressed by URIs, can be directly accessed
with the corresponding standard CoAP access method GET (read values), and can be manipulated with
PUT/POST (write values). Additionally, also subscribing to Property values is possible.
• Security
Group communication and access to the parameter and diagnostic Properties are secured by OSCORE or
(D)TLS. OSCORE (application layer security) is used for S-Mode messaging, Point read, write, and
publish/subscribe. (D)TLS (transport layer security) is mainly used for mutually authenticated pre-shared key
distribution. The initial bootstrapping of pre-shared OSCORE keys and operational device certificates bases on
an out-of-band (QR code, NFC, or BLE, etc.) authentication code as a proof of possession.

Figure 1 — HBES IoT Point API
4.2 System entities
Figure 2 — System entities
The Key Distribution Center (KDC) enables and enforces the authorized access of joining HBES IoT devices
to access the related KNX Group Communication. Multiple installations can be associated with the same
Authorization and Group Manager, which might be a service entity part of a MaC (Management Client) or an
independent service.
The Message Broker is an intermediary that can provide data marshaling, routing, message translation, and
persistence. It receives messages from a Publisher and delivers them to all related Recipients. An HBES Classic
to HBES IoT Router (see also Clause 10) is an example of a Message Broker.
Publishers and Subscribers are HBES IoT devices that are loosely coupled and often do not know each other.
Their primary relationship is that they are configured with the same Group Address. In HBES IoT:
• the Publisher sends Group Messages to Subscribers (e.g., via Message Broker). It represents a particular
information source, for example, a light switch status;
• the Subscriber is the consumer of Group Messages from a Publisher. They are CoAP Clients but are Group
Message Recipients;
• the Publishers and Subscribers use CoAP to communicate;
• A Recipient is a device that receives Group Messages from a Publisher. If the Recipient is not a Subscriber
simultaneously, then the Recipient endpoint is a static configuration in the Publisher Function Point table.
The Registrar decides whether a new HBES IoT device can join the domain; it:
• might be a part of the MaC (Management Client), containing a mixture of Backlist rules, Whitelists (for
known installed devices), and stateful tracking to protect the HBES System;
• subsequently configures domain CA certificates followed by the operational device certificate on HBES IoT
devices.
An overview of the system entities is given in Figure 2.
4.3 Device Model
Figure 3 depicts the HBES IoT Device Model, which is, from a high-level perspective, the same as the classic
HBES Device Model.
Figure 3 — HBES IoT Device Model
An HBES IoT device may have physical inputs and/or outputs.
• A physical input may be internal to the device or have an external sensor connected via a terminal block.
• A physical output may be internal to the device or have an external actuator connected via a terminal.
An HBES IoT device has at least one logical input and/or output. Such a logical input or output is called Group
Object (GO). The Group Object has a unique identifier with reference to the device. When a Group Address is
assigned to a Group Object, the Group Object becomes a member of that Function Point identified by the Group
Address. A Group Address is the instantiation of a Function Point and is unique in an installation.
An input Group Object can be assigned to one or more Function Points.
An output Group Object can be assigned to one or more Function Points but can only send information to one
Function Point.
For configuration purposes, an HBES IoT device may have parameters to determine specific behavior
concerning the whole device or a device Channel. Each Parameter Property has a unique identifier with
reference to the device.
For diagnostic purposes, an HBES IoT device may provide diagnostic information concerning the whole device
or a device Channel. Each Diagnostic Property has a unique identifier with reference to the device.
Parameter and diagnostic Properties use the same communication mechanisms and are not differentiated, and
both are named Property in the following.
A Group Object is a specialization of a Property. A Group Object is designed for runtime communication in a
Brokerless or Broker-based system (see 5.3). A simple property is only designed and intended for configuration
or diagnostic purposes, and it supports only simple point-to-point communication methods (read-, write- and
subscription-commands).
An HBES IoT device may have Group Objects and parameter and diagnostic Properties that belong together.
Where Group Objects and Properties belong together, these may be declared as a Channel.
A device may have Channels with different sets of Group Objects and Properties and/or Channels that have
identical sets of Group Objects and Properties. Devices may have one or more Channels that are functionally
identical and have the same type of Group Objects and Properties.
Apart from Channels, an HBES IoT device may have Group Objects, parameter, and diagnostic Properties that
apply to the whole device. These are associated with the control function of the whole device.
If and how Group Objects and Properties are declared as a Channel is up to the manufacturer designing the
device.
A Channel may be declared to include at least one Functional Block describing the function of that Channel
(see EN 50090-6-2).
Functional Blocks for different applications are defined by KNXA. Functional Blocks encompass inputs and
outputs as well as parameter properties with generic names and identifiers.
The Functional Blocks determine the Interworking between products of different manufacturers. More than one
Functional Block type may be required to describe the functionality of a Channel.
An HBES IoT device has a unique identifier called Individual Address. The Individual Address is assigned and
is unique with respect to the project.
An HBES IoT device shall have a globally unique identifier assigned by the manufacturer called Serial Number.
The hardware (MAC-) or network (IP-) address of the device shall not be used as Individual Address.
Table 1 summarizes the above-mentioned core elements and their associated unique identifiers.
Table 1 — Core elements and identifiers
Unique Identifier
Core element Name Scope
Device Serial Number globally unique

Individual Address unique within a project
Functional Block Functional Block ID unique per functionality
Function Point Group Address unique within a project
Group Object (GO) GO identifier unique per device
Parameter / Diagnostic Property Property identifier unique per device

4.4 Conventions used in this document
4.4.1 Conformance
For all resources, their expected request/ response document formats and content are not described to the full
extent in this document. Whether an element is mandatory or optional can be found in the JSON-schema
description as an electronic document. The URL https://schema.knx.org allows retrieval of the most recent
electronic documents of the HBES IoT Point API. Older versions are also available.
4.4.2 Number Format
All numbers in this document are assumed to be decimal unless indicated with a prefix. Hexadecimal numbers
are prefixed with the designation "0x", and binary numbers are prefixed with the designation "0b". Binary
numbers are defined as successive groups of 4 bits, separated by a space character from the most significant
bit to the least significant bit (0b1111 1111). Byte strings are notated in one of the base encodings, without
padding, enclosed in single quotes, prefixed by >h< for base16, >b32< for base32, >h32< for base32hex, >b64<
for base64. For example, the byte string 0x12345678 could be written as h'12345678'.
4.4.3 Uniform Resource Identifiers
A Uniform Resource Identifier (URI) identifies a logical resource. This document uses the CoAP URL for link
formats which comprises scheme, authority, path, and query values: scheme ":" ["//" authority] path ["?" query].
The authority part shall contain either an FQDN or an IP address.
The following link formats are used in this document:
• Absolute Link with schema and authority: coap://{ip-address or fqdn}:{port}/base-path/path1?query
• Absolute path that starts at the root path ("/"): /base-path/path?query
• Relative path that starts after a base path (without "/" at the beginning): path?query
4.4.4 Uniform Resource Name
A Uniform Resource Name (URN) identifies a logical resource in a permanent way, even after that resource
does not exist anymore. This document uses the URN format as defined in RFC 2141, which comprises the
namespace identifier "knx" and namespace-specific identifiers: "urn:knx" [":" namespace-specific-identifier].
The following URN formats are used in this document:
— URN with the namespace identifier: urn:knx:namespace-specific-identifier;
— Truncated URN without namespace identifier (with ":" at the beginning): :namespace-specific-identifier.
5 Point API Standard
5.1 Application Protocol
This version of the HBES IoT Point API standard solely considers the use of CoAP as an application protocol.
The below standards and examples, therefore, focus on CoAP. Indications for other application protocols may
be added in future versions.
5.2 Overview
5.2.1 Common Data Model
The following clauses describe a standard data model and API for HBES IoT devices that represent a contract
for the interworking between devices and, in addition, between devices and infrastructure (e.g., Management
Client, Message Broker, etc.). For a semantic description of instances of the API (project export), HBES IoT
adopts the W3C WoT interactions model for Points that exchange data via IP interworking infrastructure. The
Thing Description [TD] is a central building block in the W3C Web of Things (WoT). The TD provides a
framework for semantic metadata for the device itself, an interaction model based on WoT's
PropertyAffordances, ActionAffordances, and EventAffordances paradigm, a semantic schema to make data
models machine-processable and features for Web Linking to express relations among devices and Points. For
example, the "/.well-known/core" URI is an ActionAffordance with a default entry point for discovery purposes,
or EventAffordances and PropertyAffordances are usually mapped to a Parameter and Diagnostic Property.
The TD is the glue between HBES IoT device data and the domain model (see EN 50090-6-2).
An overview of the Point Interactions is given in Figure 4.

Figure 4 — Point Interactions
5.2.2 Application Layer Service Mapping
The Application layer provides many application services to the application process. Application processes in
different devices interoperate by using services from the application layer. Depending on the communication
mode, various application layer services are available. HBES IoT only takes over the core functionality of a
subset of existing Application layer services. These service functionalities are mapped to REST calls which can
be described as PropertyAffordances, ActionAffordances, or EventAffordances, for example, for a semantic
project export or device descriptions (see EN 50090-6-2). The following clause explains how existing Application
layer services are mapped to service discovery, PropertyAffordances, ActionAffordances, and
EventAffordances in HBES IoT.
The A_IndividualAddress_Read- and A_IndividualAddress_Write-services, for example, are used to find a
device within a system and to change the device address. These services are used with broadcast
communication, and the communication partner is not identified in this service., i.e., the partner device is
enabling its Programming Mode, e.g., by pressing a programming button on that device. In HBES IoT, the
service is split into a discovery ActionAffordance (discovery phase: DNS or GET coap://{ipv6-multicast}/.well-
known/core?if=urn:knx:if.pm) and a second subsequent authorized ActionAffordance call to change the device
address (POST coap://{ipv6-unicast}/.well-known/knx/ia).
PropertyAffordances expose the internal state of a device that can be directly accessed (read) and optionally
manipulated (write) on parameter and diagnostic Properties. Devices can also choose to make parameter and
diagnostic Properties subscribable (observe) by pushing the new state after a change. PUT and GET on
Properties are used instead of the Property services, such as A_PropertyValue_Read or
A_PropertyValue_Write as described in EN 50090-4-1.
ActionAffordances offer device functions, and these functions may manipulate the internal state of a device in
a way that is impossible through setting Properties. Examples are changing internal state that is not exposed
as PropertyAffordances (e.g., A Restart-PDU), changing multiple Properties, or changing Properties over time.
An EventAffordance describes event sources that asynchronously push messages. Hence, event-oriented
runtime communication is mapped to EventAffordances in the sending device and ActionAffordances in the
receiving device. Here not state, but state transitions (events) are communicated (e.g., "light switch ON").
Events may be triggered by an internal state change that is not exposed as PropertyAffordance, e.g., a push
button event to switch from Off to On. POST is used for Group Objects instead of A_GroupValue services as
described in EN 50090-4-1.
5.2.3 Application Protocol
This document uses CoAP [RFC 7252] as a mandatory application protocol. CoAP is a reliable transport that
can preserve packet ordering and handles message duplication. However, the Point API standard is not limited
to CoAP. Some device profiles may implement a CoAP and an HTTP interface. This enables an HTTP client to
access data on an HBES IoT device without implementing a CoAP communication stack. However, how an
HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response
is out-of-scope of this document, but an HTTP implementation should follow the guidelines described in
RFC 8075.
5.2.4 Content-Format
HBES IoT device resources shall support the application/link format, the application/octet-stream format, or the
Concise Binary Ob
...