This page last changed on May 11, 2010 by kennym.
Thanks to the good information here in the knowledgebase, I've been able to decode some KNXnet/IP packets.
However I wonder if anyone can point me in the right direction to find information on decoding the cEMI frame within a TUNNELLING_REQUEST.
First of all, here's an example of the packet I receive from a KNXnet device:
06 10 04 20 00 15 04 02 00 00 29 00 bc e0 11 05 0a 00 01 00 81
Which I can decode like this:
06 - Header Length
10 - KNXnet version (1.0)
04 20 - Service type descriptor (TUNNELLING_REQUEST)
00 15 - Total length - 21 Bytes
04 - Structure length
02 - Comms Channel
00 - Sequence number
00 - Reserved
Then follows the cEMI frame:
I know the 0x29 means it is a L_Data.ind Data service, but I cannot find any more information on decoding the rest of this packet. Some of the bytes I can make an educated guess at, for example the 11 05 means KNX device 1.1.5, and I know that overall the command is a Group 1/2/0 Lamp ON command - but I do not know how to decode this information from the packet.
Is there somewhere I can get data on decoding cEMI frames ?
0x00 0xBC 0xE0 are additional info length and control fields 1 and 2 respectively.
0x00 means no additional info, control bits you can decode here Common EMI Frame Control Fields
Posted by juha at May 12, 2010 05:19
The next two bytes are source address (in 2 byte format) as you correctly deducted. The following two bytes are destination address (in 2 byte format, 0xA0 0x00 in your example).
The next byte (0x01 in your frame) is the data length of the following APDI bytes (the last two bytes in your frame).
This may help you visualize it: KNX Data Link Layer Data Service (L_Data)
Posted by juha at May 12, 2010 05:24
Finally APDU (the actual payload, last two bytes in your frame) is quite specific depending on the flags in the message frame, message type and the device data point type.
Bytes 0x80 and 0x81 are basically one bit on/off commands.
APCI/APDU is a somewhat convoluted structure, I don't have it well documented anywhere at the moment (the KNX spec itself is quite messy in this part).
Posted by juha at May 12, 2010 05:38
Thanks to all who replied.
This definitely helps.
Thanks to the replies above I can now successfully decode the BC E0 frame control fields.
Howvere there is still some ambiguity.
For example, in my exmaple frame above, I know the source address is in the bytes 11 05, which is KNX address 1.1.5, and I know the destination address is group 1/2/0 - what I don't know is how to decode the 0A 00 to 1/2/0 - is it simply (12 x BYTE1) + BYTE2 does that mena BYTE2 is always in the range 00-0C? It doesn't seem to be BCD - maybe if anyone knows what the maximum group address components are that would help.
Anyway, thanks for all the help it has been great.
Posted by kennym at May 13, 2010 10:09
Group address formatting on CEMI frame is an area where the KNX specification starts to break down vis-a-vis KNX tooling implementation.
By convention only, the two bytes can be interpreted as main/middle/sub levels (5/3/8 bits respectively) or main/sub levels (5/11 bits respectively).
Some additional detail here: KNX Group Address
Posted by juha at May 13, 2010 12:26