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);
}

[Turtle051987]

I have the same problem. Is there a solution in the meantime?

[barbudor]

Hello @Turtle051987 @pfisterer

ascillato has left the team to focus on personal things so we don't have any more a KNX specialist in the team.

Although I am not using KNX myself and I'm not owning ETS, I recently tried to help and made a couple of changes in the KNX driver.

I understand that you would like Tasmota to reply to the GetDeviceInfo request and answer with DeviceDescriptorRead

Could you point me to the proper specifications so I can understand what needs to be done ?

[pfisterer]

Hmm, good question. I'm not an expert either and I'm just using it. The maximum I could do (as the documentation is closed) is lookup the relevant code in related projects (see my post above). Maybe the guys at knxd (https://github.com/knxd/knxd) or OpenHab (https://www.openhab.org/addons/bindings/knx/) have code.

Best, Dennis