Closed savage8811 closed 7 years ago
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
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.
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
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
hi
sorry for the delay
are you able to provide a dump from ets sending the values: 0, 20, 80, 100 ?
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!
hi, sure, here you'll find the wireshark dump. 100% to 0%, 20% steps. knx100-80-60-40-20-0.zip
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
package is submitted https://www.nuget.org/packages/KNX.net?NormalizedVersion=1.1.9 (might take a few minutes to show up)
Hi,
if I send a write command (5.001) to my dimmer with a value <24%, my actuator ignore the command:
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:
Do you have any idea why this behavior happens?