Reference · built on requestConnectorIndustrial & building protocols

KNX

Datapoints, functions, and locations from a KNX installation through the KNX IoT 3rd Party API or a KNXnet/IP interface.

Request accessPricing ↗

About

KNX is a building control standard maintained by the KNX Association in Brussels. It is published as ISO/IEC 14543-3 and EN 50090 and covers twisted pair, powerline, radio, and IP media. Installers configure devices with ETS, the Association's planning and configuration tool: they define the topology, assign group addresses, and link group objects. KNX IP Secure is standardized as ISO 22510 and KNX Data Secure as EN 50090-3-4.

Through Fibric, a connector reads the installation over the KNX IoT 3rd Party API, an OpenAPI interface the Association publishes under the MIT license, or over a KNXnet/IP interface. An operator watches datapoint values and proposes a write, such as a setpoint or a switch command, for your approval.

This is a reference listing. It documents what Fibric would read from KNX and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Datapoints with their current values, read through GET /datapoints and GET /datapoints/{datapointId} on the KNX IoT 3rd Party API
  • Functions, devices, and locations of the installation from /functions, /devices, and /locations, with parent and child locations for the building structure
  • Time series of datapoint values through /datapoints/{datapointId}/timeseries where the server keeps history
  • Push updates on datapoint changes through HTTP callback subscriptions at /subscriptions or a WebSocket session at /messaging/ws
  • Server and API version information from the /.well-known/knx node resource
  • Group telegrams on the bus through a KNXnet/IP interface on UDP port 3671 where no 3rd Party API server exists

Proposed actions

  • Target capability: propose a datapoint value change through PUT /datapoints/values, sent once after your approval is recorded
  • Target capability: propose a group write over a KNXnet/IP tunnelling connection for a datapoint that ETS has linked to a group address

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a setpoint that drifted from schedule

    The connector reads room temperature setpoint datapoints each cycle. When one sits outside its schedule, the operator proposes the corrected value through PUT /datapoints/values and leaves a receipt naming the room and the old value.

    With Setpoint Drift

  • Turn lighting off after hours

    Lighting switch datapoints still on after the building closes are listed with their location. The operator proposes an off command for each, and you approve them as one batch.

    With After-Hours Audit, Occupancy Lighting

  • Find a schedule leak in HVAC

    Function and location data from the API let the operator group HVAC datapoints by zone and spot a zone that heats while its schedule says unoccupied.

    With Schedule Leak

Requirements

  • A KNX installation commissioned with ETS, with group addresses assigned and group objects linked
  • A KNX IoT 3rd Party API server for the installation, or a KNXnet/IP interface reachable from where the connector runs
  • An OAuth 2.0 client registered on the API server with the read scope, plus the write scope for proposals
Authentication
OAuth 2.0 on the KNX IoT 3rd Party API, using the Authorization Code or Client Credentials flow with read, write, and manage scopes; a KNXnet/IP interface uses its own device credentials and KNX IP Secure where the installer enabled it.

Limits

  • The KNX IoT 3rd Party API needs a server product that implements KNX Standard chapter 3/10/4; installations without one expose only KNXnet/IP
  • The KNX Specifications are free to download at version 3.0.0; the newer member version needs a MyKNX membership
  • Writes are gated by the scopes the API server grants; a datapoint the server does not allow writes on cannot be proposed
  • Twisted pair TP1 runs at 9600 bit/s, so reading many group addresses in bulk is paced by the bus

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request KNX ↗

Questions and answers

Does KNX have an HTTP API?
The KNX Association publishes the KNX IoT 3rd Party API, an OpenAPI 3.0.3 specification with endpoints for datapoints, functions, devices, locations, time series, and subscriptions. It corresponds to KNX Standard chapter 3/10/4. Without a server that implements it, an installation is reached over KNXnet/IP.
How does the connector learn about changes?
The 3rd Party API supports HTTP callback subscriptions under /subscriptions and a WebSocket session at /messaging/ws. Either delivers datapoint updates without polling. On a KNXnet/IP interface, the connector receives group telegrams as they pass on the bus.
Which standards define KNX?
KNX is standardized as ISO/IEC 14543-3 and EN 50090, as GB/T 20965 in China, and is approved as a US standard under ANSI/ASHRAE 135. KNX Data Secure is EN 50090-3-4 and KNX IP Secure is ISO 22510.
Ask about KNX

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with KNX through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy