Received packets are sometimes lost if they are recevied during handling of another one

[envy]

If we are currently handling a packet while another packet arrives, that packet is sometimes lost.
Don't know if it is a problem of the UDP library or my code.

Might be fixed by calling parsePacket() multiple times and saving multiple packets before working on them.
However, this increases the time we work on packets so might miss other ones again :/

[sauregurkenzeit]

Hi, I think introducing ROUTING_BUSY could resolve this issue.
KNXIP.pdf

[envy]

Hi,

while this is interesting, I don't think it will help much. The problem is the UDP stack of the ESP Arduino library. My library simply uses that and calls parsePacket() and the method simply returns no packets even though some were send. So somewhere inside the UDP stack is either a buffer to small or some other problem. I did not have the time to look into this in more detail.

I noticed that with v2.3.0 of the ESP libraries this happens very rarely for me. However, with v2.4.0, I experienced >50% packet loss while receiving, so at some point the changed some internal stuff and it got worse, at least in my case.

Maybe I'm simply missing a configuration option to tell the ESP to put packets into some buffer while I'm processing something.

[envy]

I have a second branch called async-udp that uses the ESPAsyncUDP library. With this I got 100% packet reception with v2.4.0 of the board libraries even when holding down the send button in the ETS.

However, answering/sending was kind of weird when I had IGMP snooping enabled on my switch as it took up to 5 minutes before the first packet was let through. I have to investige this further. But I think this is the right way, as ESPAsyncUDP directly talks to lwip. Maybe I can even integrate the code, its not that much code.

[ascillato]

Great! 👍

[envy]

GIRA IP Routers have a mode called "KNX Reliable Communication" especially for WiFi multicast.
I have not found any information about this other then that it can be turned on and off, this should be investigated.

[ascillato]

Looking forward to see ESPAsyncUDP on the library ! 👍

[ascillato]

Hi, I tested the branch async-udp and works really good.

I found that sometimes I lost some packets in both approaches (master and async-udp) but just because my overloaded wifi router. So, I think this losts can be mitigated using the ACK and the ACK response.

So, if ESP-KNX-IP sends a telegram and no ACK answer is received on a time-out time, ESP-KNX-IP can re sends the telegram.

What do you think?

[ascillato]

Hi @envy ,

I'm using a lot your library. Like it a lot!!! 👍

I'm just having a reliability issue due to some telegrams lost from time to time.

What do you think of adding the ACK for resend telegrams?

[envy]

Hi,

do you mean setting the ack field of cemi_service_t to 1?
I don't know if it actually does something or if it is only valid on the KNX TP side.
When I set it, I don't get any acks from my IP router, so same behavior as without setting the field.
Or do you mean something else?

[ascillato]

yep,

You are right. In KNX IP multicast, there is no ACK. I thought KNX-IP was like KNX-TP.

I found an explanation of this on https://knx.org/media/docs/Partners/scientific/events/Session%202.pdf

And also on the brochure of this KNX Router https://www.ekinex.com/media/fprod/MAEKBBC1TP_EN.pdf

I don't understand why is that. It could follow the same protocol structure than TP and PL.

So, How can be ensured the transmission of telegrams?

What I was thinking is to add (on the application layer side - i.e. Tasmota KNX Driver) an option to:

• Just send the telegram
• or Send 3 times the telegram
• or Send the telegram and wait for an specific telegram (like an ack - I have to look for a DPT for that). If don't receive that on x time, resend, up to 3 times.

But will be as a workaround the protocol issue and only for Tasmota_KNX to Tasmota_KNX device, or any KNX IP Device configured with some logic like that.

I made some listening on KNX Multicast and I found that sometimes my router don't send the packet. Does not happens often but sometimes happens. This problem is device independent. From your library or from HomeAssistant. Does not matter who.

So, What do you think. How can be ensured the transmission of telegrams?

[ascillato]

Hi @envy

Any ideas?

[envy]

So, How can be ensured the transmission of telegrams?

For KNXnet/IP via UDP multicast, you simply can't as there is no ACK.

What I was thinking is to add (on the application layer side - i.e. Tasmota KNX Driver) an option to:

• Just send the telegram
• or Send 3 times the telegram
• or Send the telegram and wait for an specific telegram (like an ack - I have to look for a DPT for that). If don't receive that on x time, resend, up to 3 times.

This is not really relevant for the library, as you said, you would do this at the application layer. The last option would be the best, but that implies a specific KNX setup and may not always be possible.

I personally would not think that much about it, UDP multicast is unreliable by design and KNXnet/IP made no improvement on that. So as long as the KNX people don't change something, I will not change anything. There is this GIRA IP Router I mentioned above that has "KNX Reliable Communication", whatever that is, but I couldn't find any documentation about this, whether it is proprietary or part of the KNX standard.

[ascillato]

A brief explanation of what GIRA Routers do with their Reliable KNX Communication is here.