KNX: Support answering DeviceDescriptorRead messages

[pfisterer]

Have you looked for this feature in other issues and in the docs?

Yes, we have briefly discussed this off-topic in another issue (sorry for that). But I'm not sure, if I explained this issue correctly over there - or if I'm misunderstanding something how KNX works. Sorry, @ascillato for bothering you again with this issue.

Is your feature request related to a problem? Please describe.

I'm using multiple Tasmota-based devices in KNX installations (KNX/IP and KNX/TP with a router). Everythings works as expected. E.g., I can switch a Tasmota/Gosund device using KNX/IP on and off via a Berker Switch which is connected KNX/TP. Every message sent on KNX/IP via multicast IP is forwarded to KNX/TP via this router and vice versa.

What is not working is that some KNX tools (e.g., ETS5 or GUIs) check the status of a device using GetDeviceInfo. This triggers a DeviceDescriptorRead message, which is answered by all KNX devices that I've used in different installations. However, Tasmota's KNX implementation does not send replies, which leads to the situation, that some KNX visualization systems report this device as OFFLINE.

There seem to be to different types, one using Group Communication and one not:

Describe the solution you'd like

Tasmota's KNX lib should answer these messages.

Describe alternatives you've considered
Ignoring offline devices from which I know that they are based on Tasmota.

Additional context

I've looked into this issue from multiple perspectives. I've seen this happening on OpenHab first, then I've used ETS5's bus monitor and then I tried sending those messages using ETS5's "Right click, get device info" feature.

Working message exchange between ETS5 and an KNX actor:

Request:

Response:

---

However, for my Tasmota-based devices, they don't send replies:

but I do see corresponding packets being sent on Wifi (using tcpdump -i enp3s0 -vvXSs 1514 -vvv host 224.0.0.251 and port 3671) and on the ETS5 bus monitor:

10:27:33.066671 IP (tos 0x0, ttl 1, id 6590, offset 0, flags [DF], proto UDP (17), length 45)
    brix.fritz.box.3671 > 224.0.0.251.3671: UDP, length 17
	0x0000:  4500 002d 19be 4000 0111 0c2e c0a8 b230  [email protected]
	0x0010:  e000 00fb 0e57 0e57 0019 53ff 0610 0530  .....W.W..S....0
	0x0020:  0011 2900 b050 11f9 111f 0143 00         ..)..P.....C.
10:27:33.111332 IP (tos 0x0, ttl 1, id 2604, offset 0, flags [none], proto UDP (17), length 28)
    led-bad.fritz.box.3671 > 224.0.0.251.3671: UDP, length 0
	0x0000:  4500 001c 0a2c 0000 0111 5bc5 c0a8 b23c  E....,....[....<
	0x0010:  e000 00fb 0e57 0e57 0008 8f4f 0000 0000  .....W.W...O....
	0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0030:  0000                                     ..
10:27:36.102259 IP (tos 0x0, ttl 1, id 6818, offset 0, flags [DF], proto UDP (17), length 45)
    brix.fritz.box.3671 > 224.0.0.251.3671: UDP, length 17
	0x0000:  4500 002d 1aa2 4000 0111 0b4a c0a8 b230  [email protected]
	0x0010:  e000 00fb 0e57 0e57 0019 53ff 0610 0530  .....W.W..S....0
	0x0020:  0011 2900 b050 11f9 111f 0143 00         ..)..P.....C.
[...]

---

To better understand what's happening, I found some source code, how Calimero's KNX implementation performs this check in function public boolean isAddressOccupied(final IndividualAddress devAddr).

It basically invokes

Destination dst = mc.createDestination(devAddr, true)
mc.readDeviceDesc(dst, 0);

The implementation of public byte[] readDeviceDesc(final Destination dst, final int descType) is as follows:

@Override
public byte[] readDeviceDesc(final Destination dst, final int descType)
	throws KNXInvalidResponseException, KNXDisconnectException, KNXTimeoutException,
	KNXLinkClosedException, InterruptedException
{
	if (descType < 0 || descType > 63)
		throw new KNXIllegalArgumentException("descriptor type out of range [0..63]");
	final byte[] apdu = sendWait2(dst, priority, DataUnitBuilder.createLengthOptimizedAPDU(
			DEVICE_DESC_READ, new byte[] { (byte) descType }), DEVICE_DESC_RESPONSE, 2, 14);
	final byte[] dd = new byte[apdu.length - 2];
	for (int i = 0; i < apdu.length - 2; ++i)
		dd[i] = apdu[2 + i];
	return dd;
}

Here is the code for sendWait2:

private byte[] sendWait2(final Destination d, final Priority p,
	final byte[] apdu, final int response, final int minAsduLen, final int maxAsduLen)
	throws KNXDisconnectException, KNXTimeoutException, KNXInvalidResponseException,
	KNXLinkClosedException, InterruptedException
{
	final long start = send(d, p, apdu, response);
	return waitForResponse(d.getAddress(), response, minAsduLen, maxAsduLen, start, responseTimeout);
}

[ascillato2]

Hi,

Thanks for all the information you post here.

This issue is being addressed at #9236. Let's continue there.

[ascillato2]

Hi, I'm working on the #9236 and while trying to check if the fix also solves your issue, I realize that this is different. The descriptor you mention is not implemented in the esp_knx_ip library that Tasmota uses. So, the descriptor won't be answered.

As this won´t be fixed by the patch for #9236, I'm moving this as a Feature Request. Sorry for the delay.