search

ascillato / Tasmota_KNX

Alternative Firmware for 'ESP8266, ESP8285 and ESP32 based devices' like Itead Sonoff, Shelly or NodeMCU, with Web, Timers, OTA, MQTT, KNX, Rules and Sensors' Support, to be used on Smart Home Systems. Written for PlatformIO. Documentation at
http://tasmota.com
GNU General Public License v3.0
45 stars 11 forks source link

Some Telegrams are lost in some routers #78

Closed ascillato closed 6 years ago

ascillato commented 6 years ago

Some Telegrams are lost in some routers

When using KNX IP on Multicast, I found that some Wifi Routers drop some packages.

So, for testing the communication between devices, can be configured a button on one device to toggle the relay on other, and test it several times. With this simple test you will see if you could have a loss of communication with your router.

Root of this issue:

In KNX IP multicast, there is no ACK. KNX-IP is not as KNX-TP. An ACK Telegram is an acknowledge from the receiver to the sender, that the message was received ok.

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 for reliability.

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:

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

KNX-IP Multicast is intended to be used between devices and there is another called KNX-IP Tunneling that uses TCP direct to a KNX Router. This one is more reliable but it has a direct communication to that router (hardware or software router - knxd) and there is a limited number of connection to the router. This last one is intended to be used between a Computer and a Router for configuration.

Sonoff-Tasmota KNX Driver uses the esp-knx-ip library. This issue is also explained on https://github.com/envy/esp-knx-ip/issues/2

So, I'm going to add this reliability options in few days to enhance communication.

ascillato commented 6 years ago

@sisamiwe

Any other Ideas for this issue?

sisamiwe commented 6 years ago

No, I don't have any further idea. The issue has also been reported in other forums. Some did a workaround to use a tunnel instead of multicast. But this brings other disavantages.

ascillato commented 6 years ago

Did you found anyone that have accomplish a KNX tunneling?

ascillato commented 6 years ago

Found this brief explanation in Support.KNX.org about ACK Telegram and they explain about multicast ACK Telegram

ACK Telegram https://support.knx.org/hc/en-us/articles/115003188269-LL-acknowledgement

ACK Telegram on multicast https://support.knx.org/hc/en-us/articles/115003805665-Multiple-LL-acknowledgements

So, this feature (ACK Telegram on Multicast) can be turned on for some KNX Gateways?

In this Router seems that can be done.

@sisamiwe

Can you test if your KNX Gateway send a ACK telegram to KNXnet/IP ? Or if it has some sort of configuration for that?

sisamiwe commented 6 years ago

The tunnel version you can find here It seems to be more stable in terms of loss telegrams, but it has other disadvantages.

sisamiwe commented 6 years ago

I'm using an ABB KNX Router IPR/S2.1. Within the ETS configuration for that device, I can set to get Telegram Ackowledgement for group telegrams. Thats it.

For knxd I've no idea, but I can ask.

smurfix commented 6 years ago

ACK telegrams are used on KNX-TP. On multicast there is no ACK. There is no way to do that and it wouldn't make sense in any case because what you want to know is whether all devices saw a given telegram, which is something you can't accomplish without protocol overhead (like a neighbour list, sequence counters, and whatnot) for which KNX-IP has no provisions whatsoever.

If you need reliable transmission, use tunnel mode. There is no other way.

ascillato commented 6 years ago

Hi,

Thanks a lot for your comment. It is very welcome and also it gave me an idea.

I understand your point. KNX tunneling is a standarized solution for the KNX IP multicast issue. But it supports very few channels. So, for using several devices it is a limitation.

So, what can we do? We wait for KNX.org to release a KNXnet/IP enhacement? Or now we can make together a third party solution as GIRA KNX Routers is doing.

They use 3 telegrams for each communication (but it just work between GIRA Routers). The extra 2 are XOR constructions that are used to reconstruct the telegram if 1 of the 3 is missing.

Their approach is not conflicting with the actual KNX Standard because those extra telegrams are ignored by the non GIRA devices. Personally, I think this actually increase reliability, but the sender still don't know if the telegram arrives at destination.

So, what about just adding an ACK telegram as KNX-TP and KNX-PL are doing? All the definitions for that are settled.

From the side of this firmware (Sonoff-Tasmota_KNX), one idea could be to have this Multicast Enhacement as an option for device to device communications, and if KNXD also supports this third party solution, the whole solution will be complete. So, with this, WIFI ESP Based devices with KNX firmware will be able to communicate with an existing KNX Network in a reliable setup.

So, what do you think? We add this? As I admire your work, any comment will be take into account.

smurfix commented 6 years ago

Umm, tunneling doesn't support "very few channels", that's a limitation of many routers but not inherent to the protocol, which uses one byte for that, thus can accommodate up to 255 clients. if you need more than that, bridge two networks on different ports.

ACK telegrams on KNX-IP -multicast do not make sense IMHO. On TP they are trivial because if you receive one ACK you can be reasonably sure that all listeners got the original packet; it's a single wire, after all. The situation is a lot more complicated with IP multicast. Gira's XOR idea is interesting but doesn't protect you against the most common fault, which is that you have a switch somewhere on your network that forgets its multicast table for whatever reason.

@ascillato Where in that PDF do you see any option to ACK IP multicast packets? I don't.

ascillato commented 6 years ago

here: https://support.knx.org/hc/en-us/articles/115003805665-Multiple-LL-acknowledgements

ascillato commented 6 years ago

On TP they are trivial because if you receive one ACK you can be reasonably sure that all listeners got the original packet

Exactly, so, for multicast, one idea, could be using the following scheme:

Case 1:

Case 2

Case 3

Case 4

So, What do you think of an approach like this?

smurfix commented 6 years ago

The multicast protocol doesn't have sequence numbers, so you don't know which packet the ack is for. Slowing down the whole system to wait for one slow (or dead) receiver doesn't work particularly well. There is no "repeated flag as 2", it's a single bit.

And lastly, there are quite a few open bugs and related sorely-needed improvements on KNXD which I don't have time to work on. Personally, I'd prefer that people spend their time on some of these (not to mention the fact that there's still no free version of ETS) instead of trying to marginally improve something that already works.

smurfix commented 6 years ago

@ascillato That "multiple LL ack" link is for multicast-as-on-the-TP-wire. It's entirely unrelated to multicasts on UDP/IP.

ascillato commented 6 years ago

Ups, you are right. Thanks :+1: