short telegrams about knx-go

[telemac]

Oh great, i didn't know that the specifications were publicly available. I just downloaded the whole package. If i can't sleep at 2am this will be a powerful tool, for sure.
Thanks for the support, awesome !

[vapourismo]

There is no such thing as short telegrams. L_Data frames can be standard or extended frames. It could also refer to APDUs smaller than 7 bits.

Please attach a more verbose log. I need to see the frame's content.

[telemac]

knxtool groupwrite ip:localhost 1/1/1 01 :

Layer 2(7F88EB404110,59680C0F) Send L_Data low from 0.0.1 to 1/1/1 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 01 
Layer 1(7F88EB404110,59680C0F) SendTunnel(016): 04 2E 4D 00 11 00 BC D0 00 01 09 01 02 00 80 01
Layer 1(7F88EB404250,59680C0F) Send(016): 04 2E 4D 00 11 00 BC D0 00 01 09 01 02 00 80 01
Layer 0(7F88EB404250,59680C0F) Send(022): 06 10 04 20 00 16 04 2E 4D 00 11 00 BC D0 00 01 09 01 02 00 80 01
Layer 0(7F88EB404250,59680C0F) Recv(010): 06 10 04 21 00 0A 04 2E 4D 00
Layer 1(7F88EB404250,59680C0F) Recv(004): 04 2E 4D 00
Layer 0(7F88EB404250,59680C0F) Recv(022): 06 10 04 20 00 16 04 2E 4F 00 29 00 BC D0 00 01 09 01 02 00 80 01
Layer 1(7F88EB404250,59680C0F) Recv(016): 04 2E 4F 00 29 00 BC D0 00 01 09 01 02 00 80 01
Layer 1(7F88EB404250,59680C0F) Send(004): 04 2E 4F 00
Layer 0(7F88EB404250,59680C0F) Send(010): 06 10 04 21 00 0A 04 2E 4F 00
Layer 1(7F88EB404110,59680C0F) Recv L_Data low from 0.0.1 to 1/1/1 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 01 

knxtool groupswrite ip:localhost 1/1/1 01 :

Layer 2(7F88EB404110,59680C45) Send L_Data low from 0.0.1 to 1/1/1 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write (small) 01 
Layer 1(7F88EB404110,59680C45) SendTunnel(015): 04 2E 4E 00 11 00 BC D0 00 01 09 01 01 00 81
Layer 1(7F88EB404250,59680C45) Send(015): 04 2E 4E 00 11 00 BC D0 00 01 09 01 01 00 81
Layer 0(7F88EB404250,59680C45) Send(021): 06 10 04 20 00 15 04 2E 4E 00 11 00 BC D0 00 01 09 01 01 00 81
Layer 0(7F88EB404250,59680C45) Recv(010): 06 10 04 21 00 0A 04 2E 4E 00
Layer 1(7F88EB404250,59680C45) Recv(004): 04 2E 4E 00
Layer 0(7F88EB404250,59680C45) Recv(021): 06 10 04 20 00 15 04 2E 50 00 29 00 BC D0 00 01 09 01 01 00 81
Layer 1(7F88EB404250,59680C45) Recv(015): 04 2E 50 00 29 00 BC D0 00 01 09 01 01 00 81
Layer 1(7F88EB404250,59680C45) Send(004): 04 2E 50 00
Layer 0(7F88EB404250,59680C45) Send(010): 06 10 04 21 00 0A 04 2E 50 00
Layer 1(7F88EB404110,59680C45) Recv L_Data low from 0.0.1 to 1/1/1 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write (small) 01 

[telemac]

If i send one octet, 3F, i get 3F in ETS, but if i send 0x40, i get 0x00 in ETS, 3F is 111111 in binary.
And if i send 0x41 i get 0x01.

Does KNX imply a limit on what we can send in only one octet ? The format of the 5.xxx datapoint let me think that it is not the case.

[vapourismo]

29 00 BC D0 00 01 09 01 02 00 80 01
29 00 BC D0 00 01 09 01 01 00 81

Do you see the difference? The first one transmits 000000 00000001 whereas the second sends 000001

This has nothing to do with knxd, eibd or knx-go. This simply how the payload is encoded in a L_Data frame.

Please refer to the KNX System Specification to find out more.

If you can use Markdown to format your posts: https://guides.github.com/features/mastering-markdown/

[telemac]

Ok, i see.

I looked at the source code of knxd to understand what the difference between write and swrite is, here is a stripped down version of the interesting part :

...
 } else if (strcmp (prog, "write") == 0) {
      con = open_con(ag[1]);
      dest = readgaddr (ag[2]);
      buf[0] = 0;
      buf[1] = 0x80;
      buf[2] = readHex (ag[3]);
      len = EIBSendAPDU (con, 3, buf);
} else if (strcmp (prog, "swrite") == 0) {
      con = open_con(ag[1]);
      dest = readgaddr (ag[2]);
      buf[0] = 0;
      buf[1] = 0x80 | (readHex (ag[3]) & 0x3f);
      len = EIBSendAPDU (con, 2, buf);
} else if (strcmp (prog, "read") == 0)
...

To send a byte <= 0x3f you can add it to 0x80 on the second octet, and this is the notion of short write in knxd.

[vapourismo]

That is incorrect. Please refer to the KNX System Specification for more information. It is free now.

0x80 (10000000) is just a bitmask. It sets the 2nd bit of the APCI, which encodes the command. In the given example 0x80 ensures that it sends a GroupValueWrite command.

See 01 00 81 destructures as LLLLLLLL CNSSSSXX XXDDDDDD

• LLLLLLLL is the APDU length
• C indicates that this is a control packet
• N indicates that the communication is numbered
• SSSS is the sequence number (0 in case the comm is not numbered)
• XXXX is the APCI (GroupValueRead, GroupValueWrite and so on)
• DDDDDD is the first 6 bits of the payload