Feature Request: Support for KNXnet/IP Device Management Connection

Currently ConnectRequest only supports tunnelling (basic or extended tunnel CRI), would it be possible to add support for opening device management connections?

Hi 👋!

This would require to pass that level of configuration down to the connection configuration.
I'm not how a device management connection should behave in comparison to a tunnel - maybe a subclass of Tunnel would be required.

What would you like to do with it?

Tbh this is not really on my list currently since there is no usecase for it from HA. But if you want to work it out I'm happy to help.

Hi 👋!

Hello👋!

This would require to pass that level of configuration down to the connection configuration. I'm not how a device management connection should behave in comparison to a tunnel - maybe a subclass of Tunnel would be required.

I was thinking to refactor the ConnectRequestInformation class to support both tunnelling and device management, I'm not fluent with xknx yet, so I would go from there.
Also I would add a ConnectResponseData (CRD) class similar to the CRI for the responses.

What would you like to do with it?

Test device management of an KNXnet/IP server.

Tbh this is not really on my list currently since there is no usecase for it from HA. But if you want to work it out I'm happy to help.

I could attempt to submit a draft PR somewhere down the road, but I don't have a lot of spare time atm.

CRI does support that. You'd have to pass it here

xknx/xknx/io/request_response/connect.py

Line 44 in 950bc95

cri = ConnectRequestInformation(individual_address=self.individual_address)

CRD in the same manner as CRI would make sense. I just did CRI last week as I was in a hurry.
Spare time shortage hits me too atm.

CRI does support that. You'd have to pass it here

xknx/xknx/io/request_response/connect.py

Line 44 in 950bc95

cri = ConnectRequestInformation(individual_address=self.individual_address)

The CRI for a Device Management Connection has no options (length 2), I could inherit from ConnectRequestInformation and override to_knx, but I would still be unable to parse it in from_knx.

I would propose to have a base class CRI with a member header containing the connection_type: ConnectRequestType and member body with the options. Similar to how class KNXIPFrame works.

This way we could have

class CRI:
    @staticmethod
    def from_knx(data: bytes) -> CRI:
        pass # insert implementation here

CRD in the same manner as CRI would make sense. I just did CRI last week as I was in a hurry. Spare time shortage hits me too atm.

I'll see what I can do.

Ah, I see.
from_knx is quite easy, as you have the length.
to_knx (or __init__ would have to check for the connection_type attribute and the precence of needed paramters. Unfortunately this would mean that we have to type all other attributes as Optional again (which, in the case of CRI is probably negligible, but I'd like to avoid that for KNXIPFrame - same for other parts - therefore the refactoring of APCI lately)

So I guess there is "basic", "extended" and now "very basic" CRIs... gotta love that specifications 🤣