• Home
• Our Offer
• KNX Devices
  • KNX USB Interface 310 (REG)
  • KNX USB Interface 320 (Board)
  • KNX USB Adapter 350 (RS232)
  • KNX ENO 610/612
  • KNX ENO 620/622
  • KNX DEKI Interface 710
  • KNX IP Interface 730
  • KNX IP Interface 740 wireless
  • KNX IP Router 750
  • KNX IP LineMaster 760
  • KNX IP BAOS 770
  • KNX IP BAOS 771
  • KNX IP BAOS 772
  • KNX BAOS Gadget
  • KNX jumper wire
• KNX Development
  • KNX Stack Twisted Pair (TP)
  • KNX Stack TP System B
  • KNX Stack RF
  • KNX Stack IP
  • KNX Stacks for Linux
  • KNX TinySerial Interface 810
  • KNX BAOS Module 820
  • Software Development Kits
  • Net'n Node Developer
  • PEI-Driver
  • MSP-Programmer
  • KNX BasicLine / KNX StartupLine
• Services
• References
• Contact Us
  • Arrival
  • Hotels
  • List of our distributors

KNX Stacks for Linux

SW usage

The majority of KNX devices are developed on small hardware platforms incorporating either 8-bit or 16-bit microcontrollers. Increasingly however, more complex devices are being used in home and building automation which need to be connected to the KNX network. Complex devices typically are based on 32-bit microcontrollers and benefit from the usage of an operating system like Linux. The advantage is high performance and built-in support for a wide range of hardware interfaces, for example displays, memory-cards etc.

A ‘KNX Stack for Linux’ is the implementation of KNX system software for devices running the Linux operation system. It encapsulates the complete KNX communication for runtime and for device configuration. An application inside the device has access to the group objects and parameters of the KNX system.

The software is implemented as a user-space Linux application (console application, without a user interface) and acts as a communication server to the KNX system. Client applications can start the software and communicate with the KNX stack using a simple binary messaging protocol (similar to a Remote Procedure Call RPC). The internal configuration of the KNX stack SW can be set and retrieved by the client via the API configuration interface (see below). The stack SW is typically terminated only for shut down.

Connection to the KNX network

A KNX device for Linux requires a physical connection to the KNX bus. A connection to twisted pair (TP) is the preferred choice for small installations without an IP backbone. For more complex installations (which typically have an Ethernet/IP backbone) a direct IP connection results in optimal performance at low cost.

Connection to KNX TP

Typical Linux platforms have no direct connection to KNX TP and require a dedicated hardware interface. In principle all external KNX interfaces (RS-232, USB or IP) can be used to provide bus access to the data link layer. In practice however single device solutions are generally preferred in order to reduce costs.

A simple and low cost solution is to incorporate the KNX TinySerial Interface 810 module from Weinzierl Engineering.

This interface provides standard serial bus access based on the TP-UART protocol and all bus acknowledgement decisions are handled automatically by the module. In this way the time critical path between the KNX stack and the hardware is removed. The standard serial driver from Linux can be used and the stack can be implemented without a dedicated kernel driver. The hardware interface can be designed on a small PCB containing a KNX bit transceiver, a small microprocessor with a UART interface and galvanic isolation.

Connection to KNX IP

Creating a connection to the KNX network using the medium KNX IP does not require dedicated hardware. The stack SW uses the KNXnet/IP protocol, which is based on UDP/IP. The runtime communication uses multicast addressing. As most Linux hardware platforms have support for Ethernet and a TCP/UDP/IP network stack connecting to the KNX Bus via IP is often the most effective in terms of development time and cost.

Device configuration

Most KNX networks are configured in system mode (S-Mode) using the ETS tool (KNX Engineering Tool Software). The representation and handling of a Linux based device in ETS is the same as for all other KNX devices. Each KNX device must support a programming mode controlled via a hardware button or alternatively via a “virtual” button on a screen. The device configuration is loaded into the device via the KNX network.

The Linux device configuration is stored internally in a data buffer. To achieve a persistent configuration the device data can be read and written via the stack API. It is the task of the client to read the data and store it e.g. on a hard disk on shut-down. On startup the client can launch the KNX stack process and copy the configuration from non-volatile memory to the KNX stack.

Device model

To build a KNX compliant device you need more than the pure KNX stack (the layers of the OSI/ISO reference model). For ETS compatibility a device model has to be implemented. A device model in KNX specifies which services must be supported and what functions they perform. It describes the memory map and the management procedures, than means which telegram sequences are used to configure a device.

In the KNX specifications, different device models are defined with named profiles for various media. For Linux based devices there is no difference in the specification.

Each KNX stack for Linux from Weinzierl Engineering GmbH corresponds to one of these device models and is accordingly certified by the KNX Association.

• Device models for KNX TP
• Device models for KNX IP

API via Socket Connection

The KNX stack SW runs as a server application and exposes a programming interface (API) which can be accessed via a TCP/IP socket connection. The stack SW is typically started and controlled by a client program. For data exchange between a client and the server on the same machine a localhost socket connection is used. It is also possible to have the client on a remote machine.

RPC Protocol

Communication between the client (user application) and server (KNX Stack) is performed as a request/response protocol. The protocol is encapsulated internally within a client library (RPC-Client-API). The API implements for example:

• BOOL RPC_KnxAl_SetValue(UINT nCoNo, UCHAR* pBuffer, UINT nDataLength);
• BOOL RPC_KnxAl_GetValue(UINT nCoNo, UCHAR* pBuffer);
• BOOL RPC_KnxMem_GetData(UINT nAddr, UCHAR* pData, UINT nCount);
• BOOL RPC_KnxMem_SetData(UINT nAddr, UCHAR* pData, UINT nCount);

All communication is initiated by the client. The next diagram presents an overview of an RPC call from the Client Application.

The User Application invokes one of the RPC functions in the RPC-Client-API and passes in the appropriate parameters. The RPC Client is responsible for creating the data packet and marshalling the data parameters (request). A socket send function is called from within the RPC Client to transfer the request to the Server. The Server unpacks the request, calls its local API, and generates a response. The RPC client calls the receive function of the socket to obtain the response from the Server. Once received it unpacks the response and returns the corresponding function return value.

To connect a client application via the RPC protocol on socket level a complete reference implementation is available for Windows and Linux environments. An individual implementation is possible as well.

Server Indications

In addition to the RPC API the KNX Stack implements an Indication Event Notification for the following asynchronous events:

• CONNECT
• DISCONNECT
• MGM_WRITE
• RESET
• GROUP_OBJ

These indications are sent over a second TCP connection. The server listens for a connection. As soon as the client establishes the connection, the indications will be sent completely unrelated to the RPC request/response protocol. A sample is provided in the software package for receiving and displaying indications.

• Contact