Telegram is confirmed but not sent immediately #134
Comments
|
With trace log, you should see the tunneling messages of the KNXnet/IP connection layer (i.e. one layer lower), and compare if the delay for the indication also happens there. One reason I can think of why this is happening, is that your send logic is called from the notification thread? The notification you receive for a confirmation and indication runs in a dedicated thread. If that thread is not able to return from client code, this will delay the next notification. |
|
Thank you for your answer. For the trace logs I will do it a little later because I cannot currently carry out tests on the site due to the holidays. I don't think there is a difference in delay with KNXnet/IP connection layer and no thread blocking either because during the seconds delay I receive other telegrams on the tunnel including responses to previous read requests . Furthermore, I do not think that the telegram is sent at the time of confirmation and that there is then a slowness in receiving the indication because during a write request this is not carried out at confirmation but only when the telegram is received with a few seconds delay. We did the test on a lighting, when we try to turn it on by sending an ON, the confirmation arrives quite quickly but the transmission telegram arrives late and the lighting also turns on late so I infer that the telegram is not sent at the time of confirmation. I looked again at the logs that I have in debug mode of new application with 2.5 and the problem seems to come from what I thought. I could extend the timeout to 150ms instead of 50ms between requests to test if it works but that would be a lot of time wasted knowing that on average the time required is 20ms and that this time is only higher occasionally, and if a telegram takes more than 150ms to arrive the problem will arise again. I really don't understand why there is confirmation while the telegram is not sent. I also checked the logs again in the old application with 1.4.6, it also happens that the reception time of the retransmitted telegram is more than 20ms but in this case the confirmation is also delayed and it arrives at the same time. What do you think about this ? |
|
You are right, if other notifications are incoming at normal pace, it's not a delay in the local notification thread. From the log I would also say that the delay is not introduced by the first router, but by the second after that. One thing I notice (don't know if it is related): did you set a source address with your old application when sending a request, or did you also use 0.0.0? Because the received frames (.con and also .ind) contain 15.15.255, which usually means that there are uninitialized devices, or that the responding device has been reset. |
|
yes, the old application also uses source address 0.0.0 I also wondered about the address 15.15.255 for routers. What is surprising is that when we do a discover, we find the physical address (example: 3.9.0, in my first message) but using tunneling the address is always 15.15.255 for every routers. However, this does the same thing in the old application and does not prevent it from functioning. However, on other projects that we have, the physical address is really that of the router, for example 2.1.0. I saw in the code of version 1.4.6 and the CEMI_Connection.java file the passage above: I see that there is an "ack" sent but I did not find this part in version 2.5. The code being a little more complex, maybe I didn't find it. Is there this ack in version 2.5? |
|
The ack is here. |
|
Thank you. I redid some tests with the old version, it seems that I manage to reproduce more or less the same problem, again when requests are sent before the telegram is received. I will do tests with the new version by delaying the requests a little more when possible (late August or early September) and I will post the results. |
Good morning,
I'm using an application developed with calimero 2.5 and I'm currently experiencing a problem that I don't have with my old application developed with calimero 1.4.6.
The KNX/IP routers are Siemens N146 for which here is the discover report:
["IP Router N146", KNX address 3.9.0, KNX medium TP1, Installation 0 - Project 0 (ID 0), KNX IP multicast address 224.0.23.12, MAC address 00:0e:8c:01:25:a5, S/N 0001:1003fba1d, Core (v1), Device Management (v2), Tunneling (v1), Routing (v1), Remote Configuration Diagnosis (v1), Object Server (v1)]The problem occurs for IP routers that are set to transmit telegrams.
Example there are 5 IP routers (R1, R2, R3, R4 and R5).
The application simply connects to router R1 and reads and writes to group addresses located on lines of routers 1 to 5.
With the old version 1.4.6, the application sends the read request and when it receives the confirmation, it also receives at the same time the telegram that was retransmitted by the router.
On the other hand with version 2.5, when the application receives the confirmation, the telegram that is retransmitted by the router is not received immediately.
Both apps work the same way: once confirmation is received, there is a 50 millisecond pause before a new reading is requested. With version 2.5, the more readings we do in a sequence, the longer it takes to receive the telegram retransmitted by the router and therefore the reading response lengthens, this can go up to 5 seconds or more.
It's like this the IP router confirmed but the telegram is not sent immediately so I think it ends up saturating.
With version 1.4.6 when a new read request is sent, we are certain that the previous one was sent.
I specify that there are a lot of telegrams sent because there is a lot of material and users.
We have several tunneling connections on several IP routers at the same time in the application.
Only those that are set in the manner explained above pose a problem with version 2.5.
The others for which the telegram setting is "filter" and for which we only request the reading of group addresses found on the line of the router itself, this works.
This the method used with 1.4.6 :
This the method used with 2.5 :
Do you know where the problem comes from ?
Thank you !
The text was updated successfully, but these errors were encountered: