KNX IoT testing

With the Light Switch Actuator and Light Switch Sensor installed, you will be able to test a simple KNX IoT system consisted of two Thread-based devices.

Starting Thread network

The devices enable the Thread interface during startup automatically. They are configured to create and join Thread network with the following parameters:

Parameter	Value
PAN ID	0xabcd
Channel	11
Network name	KNX
Extended PAN ID	dead00beef00cafe
Network key	00112233445566778899aabbccddeeff

To verify Thread devices status, do the following:

1. Check active data.

   uart:~$ ot dataset active
   Active Timestamp: 1
   Channel: 15
   Channel Mask: 0x07fff800
   Ext PAN ID: 3b78ce629cbc8e23
   Mesh Local Prefix: fdd7:9fa0:468:ba1b::/64
   Network Key: 00112233445566778899aabbccddeeff
   Network Name: OpenThread-7cf7
   PAN ID: 0x7cf7
   PSKc: b2e04e90cef89d25981a7dd8f3c16db5
   Security Policy: 672 onrc
   Done
   

2. Verify devices’ roles.

• Check if one of devices is set as a Thread leader.

  uart:~$ ot state
  leader
  Done
  

• Check if another device is either a Thread child or leader:

  uart:~$ ot state
  child
  Done
  

  uart:~$ ot state
  leader
  Done
  

Connecting Light Switch Sensor to Light Switch Actuator

KNX IoT devices, just as the classic KNX devices, consist of one or many Functional Blocks. Functional Block contains one or more Datapoints which are its inputs, outputs, and parameters.

The most important feature of Datapoint’s description is its type. The type specifies how the Datapoint is encoded, its supported range, units, an so on. All Datapoints of a given Functional Block and featured types are described in the KNX Specification page.

Both Light Switch Actuator and Sensor - depending on the boards used - are built with 1, 3, or 4 Functional Blocks with a single Switch On/Off Datapoint (type name: DPT_Switch, id: 1.001). Every Datapoint either controls a single LED (Actuator) or is controlled by a single button (Sensor). For communication between KNX IoT Point API, devices send s-mode messages over the CoAP protocol. A board that is the recipient of the s-mode message checks its Group Object Table to confirm if the message can be processed.

The following tables present configuration of Datapoints for Light Switch Actuator and Light Switch Sensor devices:

• Light Switch Actuator Datapoints:

  LED	Path	GET	SET	Comment
  LED1	/p/1	Yes	Yes
  LED2	/p/2	Yes	Yes
  LED3	/p/3	Yes	Yes
  LED4	/p/4	Yes	Yes	Not available for Thingy:53

• Light Switch Sensor Datapoints:

  Button	Path	GET	SET	Comment
  BUTTON1	/p/1	Yes	No
  BUTTON2	/p/2	Yes	No	Not available for Thingy:53
  BUTTON3	/p/3	Yes	No	Not available for Thingy:53
  BUTTON4	/p/4	Yes	No	Not available for Thingy:53

Location of LEDs and buttons

Pictures below present locations of LEDs (yellow rectangles) and buttons (green rectangles) used in the samples.

Image: Location of LEDs (yellow rectangle) and buttons (green rectangle) of nRF52840 DK.

Image: Location of LEDs (yellow rectangle) and buttons (green rectangle) of nRF5340 DK.

Image: Location of RGB LEDs (yellow rectangle) and the button (green rectangle) of Thingy:53.

Sniffing KNX IoT Point API communication

In order to inspect the packets exchanged between KNX devices, the 802.15.4 sniffer can be used. To capture CoAP messages sent through a default port (5683), set up the Wireshark as described in sniffer configuration with regard to default configuration specified in the Starting Thread Network section.

Figure: Capture of CoAP messages.

Figure: Content of CoAP message.

Sample cases

Configure Actuators and Sensors based on the following cases:

Subpages:

• Case 1 - one button mapped to four LEDs
• Case 2 - one button mapped to one LED
• Case 3 - mixed configuration