5.001 action

[savage8811]

Hi,

if I send a write command (5.001) to my dimmer with a value <24%, my actuator ignore the command:

byte[] b1 = _connection.ToDataPoint("5.001", 20); 
_connection.Action("3/1/38", b1);

If I look into ETS groupadress-monitor he shows a „False“ command ($14 False) instead of ($14 20%). All bigger than 24 values looking fine.

I created a workaround appending a 0 byte before:

byte[] b1 = _connection.ToDataPoint("5.001", 20); 
b1 = new byte[] { 0x00, b1[0] };
_connection.Action("3/1/38", b1);

Do you have any idea why this behavior happens?

[abelsilva]

hi martin

don't know what's happening... 5.001 DPT is an 8 bits unsigned (percentage), so it doesn't make sense to send 2 bytes

also, there is nothing on knx.net that would trigger a different behaviour: https://github.com/lifeemotions/knx.net/blob/877390fb8c07067966db1fc4a1030cd28acf9929/src/KNXLib/DPT/DataPoint8BitNoSignScaledScaling.cs#L70

can you please try this? Send the same commands using ETS and check if the behaviour is the same

[savage8811]

Correction: He shows a „False“ command because I selected the wrong datatype :), nevertheless it’s the same behavior, doesn’t respond on <24.

Here is a screen of my ETS monitor: line 1) Send a the command through your lib, no status update and light doesn’t flash. line 2,3,4) Send the command through ETS, light flash and statusupdate ok line 5,6,7) Disable the light again through java app (calimero), everthing’s fine line 8,9,10) Send the command again through your lib with the appended byte as I mentioned in the first post, and everthing work.

it’s crazy.

[abelsilva]

hi martin

I still have no idea what might be happening. Are you able to do a network dump using ETS when sending 20% and also using knx.net sending also 20% ?

I would like to see the difference in the network packet

thanks

[savage8811]

only diff in last line and NPDU length (first packet) from your lib:

Frame 78: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface 0 Ethernet II, Src: AsustekC_87:13:47 (70:4d:7b:87:13:47), Dst: SiemensA_00:61:39 (00:0e:8c:00:61:39) Internet Protocol Version 4, Src: 192.168.100.189, Dst: 192.168.100.250 User Datagram Protocol, Src Port: 3671, Dst Port: 3671 KNXnet/IP Header Header Length: 0x06 Protocol Version: 0x10 Service Type Identifier: TUNNELLING_REQUEST (0x0420) Total Length: 21 octets Body Structure Length: 4 octets Communication Channel ID: 66 Sequence Counter: 0 reserved: 00 cEMI messagecode: L_Data.req (0x11) add information length: 0 octets Controlfield 1: 0xac 1... .... = Frametype: 1 ..1. .... = Repeat: 1 ...0 .... = System-Broadcast: 0 .... 11.. = Priority: 0x3 .... ..0. = Acknowledge-Request: 0 .... ...0 = Confirm-Flag: 0 Controlfield 2: 0xf0 1... .... = Destination address type: 1 .111 .... = Hop count: 7 .... 0000 = Extended Frame Format: 0x0 Source Address 0.0.0 Destination Address 3/1/38 or 3/294 NPDU length: 1 octets 00.. .... = TPCI: UDT (Unnumbered Data Packet) (0x0) .... ..00 10.. .... = APCI: A_GroupValue_Write (0x0002) ..11 0011 = Data: 0x33

from ets

Frame 318: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0 Ethernet II, Src: AsustekC_87:13:47 (70:4d:7b:87:13:47), Dst: SiemensA_00:61:39 (00:0e:8c:00:61:39) Internet Protocol Version 4, Src: 192.168.100.189, Dst: 192.168.100.250 User Datagram Protocol, Src Port: 60447, Dst Port: 3671 KNXnet/IP Header Header Length: 0x06 Protocol Version: 0x10 Service Type Identifier: TUNNELLING_REQUEST (0x0420) Total Length: 22 octets Body Structure Length: 4 octets Communication Channel ID: 70 Sequence Counter: 0 reserved: 00 cEMI messagecode: L_Data.req (0x11) add information length: 0 octets Controlfield 1: 0xbc 1... .... = Frametype: 1 ..1. .... = Repeat: 1 ...1 .... = System-Broadcast: 1 .... 11.. = Priority: 0x3 .... ..0. = Acknowledge-Request: 0 .... ...0 = Confirm-Flag: 0 Controlfield 2: 0xe0 1... .... = Destination address type: 1 .110 .... = Hop count: 6 .... 0000 = Extended Frame Format: 0x0 Source Address 0.0.0 Destination Address 3/1/38 or 3/294 NPDU length: 2 octets 00.. .... = TPCI: UDT (Unnumbered Data Packet) (0x0) .... ..00 10.. .... = APCI: A_GroupValue_Write (0x0002) data: 33

but there are also differences in order of the datagrams, it seems that it's not waiting for ACKs. (I don't know if it does matter, I'm not an knx expert) your lib: from ets:

here is the wireshark excerp if you want it www.coderlabs.com/wireshark.zip

[abelsilva]

hi

sorry for the delay

are you able to provide a dump from ets sending the values: 0, 20, 80, 100 ?

[princeoffoods]

Hi, I'm just getting into knx and just wanted to let you know that I ran into the same problem. Strangely the workaround using the 0-byte prefix solves the problem with small values.

I ran into problem with missing status updates in some cases with a different datatype too. Will keep learning, investigating and get back to you.

For testing I'll rewrite my app using the Falcon library to see if it behaves differently.

Later, and thank you very much for this library!

[savage8811]

hi, sure, here you'll find the wireshark dump. 100% to 0%, 20% steps. knx100-80-60-40-20-0.zip

[abelsilva]

hi, sorry for the long time to get back at this

I'm applying the fix to this and submitting a new version of the package

[abelsilva]

package is submitted https://www.nuget.org/packages/KNX.net?NormalizedVersion=1.1.9 (might take a few minutes to show up)