Complete bridge feature set

[Apollon77]

The current bridge feature set is very basic. For real programmatic bridges there are some features missing:

• remember assigned endpoint ids by using serial number or uniqueid to rebuild the bridge “the same” on next start
• Allowing to modify bridge devices also during runtime. The requires specification check what to consider for this to work and how controllers get infos on such updates (also like adding/removing devices)
• Check and consider more bridge best practices from specs.

[Controlhaus]

How is this approach of rebuilding the bridge accurately?

Require an ID string for each device.

addBridgedDevice(device: Device, bridgedBasicInformation?: AttributeInitialValues<typeof BridgedDeviceBasicInformationCluster.attributes>): void
becomes
addBridgedDevice(id: string, device: Device, bridgedBasicInformation?: AttributeInitialValues<typeof BridgedDeviceBasicInformationCluster.attributes>): void

The first time addBridgedDevice is called, an object is created to remember the id and array index of each device.

Then in the constructor, call a new function before devices.forEach(device => this.addBridgedDevice(device)); that arranges the devices array properly based on data in the new object. New id's go at the end of the array.

[Apollon77]

I read through specs and in fact as planned. As unique if I would propose to use serialNumber or uniqueId that already exists optionally on the basic info and bridged basic info. If this is not enough (need to validate later if that also fits composed devices) we might need an own id as you state. My idea would be to ideally use existing fields because inventing new unique ids might be not helpful for devs. But yes we then remember the endpoint assignments in storage based on these ids.

This is one part. Second part is that we need to change the way/place we generate the structural information (mainly partsList attribute). Right now this is done when "starting" the device - we need to change it to be also done "incrementally"/updated when bridged devices are added or updated. (Same for composed or other devices, so that's a generic change).

Should not be too hard to achieve but requires some internal restructurings.

[Apollon77]

Additionally I would enhance the api to allow to specify labels to automatically configure the endpointList on the ActionsCluster to allow to add new endpoints or devices to this automatically.

[Apollon77]

Additionally I would enhance the api to allow to specify labels to automatically configure the endpointList on the ActionsCluster to allow to add new endpoints or devices to this automatically.

[Apollon77]

Additionally I would enhance the api to allow to specify labels to automatically configure the endpointList on the ActionsCluster to allow to add new endpoints or devices to this automatically.

[Apollon77]

PR #187 should solve this one