Design: Hub Model about powered-up HOT 2 CLOSED

Hub Discovery

A central module PoweredUpHost handles the discovery of Hubs using the provided IPoweredUpBluetoothAdapter. The host instantiates the specific hub but does not perform a Hub.ConnectAsync. This decision is left with the invoking consumer (based on e.g. filtering by name/bt address of the hub).

Rationale: Discovery is required but specific to the LEGO protocol. Therefore, a module is required handling it independent of the utilized BT stack. The Hub provides a method ConnectWithBluetoothAdapter which allows alternatives to Bluetooth connections, e.g. for mocking etc.

Hub

A Hub is essentially a handler for ports. It manages a list of Ports which then can be used to retrieve the connected device. The hub itself has built-in devices exposed via known ports. Derived classes (e.g. TechnicMediumHub) of the base hub can be used to simplify access to known external ports (e.g. A-D). The hub does not understand or expose functionality for individual devices. This is outsourced to devices.

Rationale: To keep the Hub maintainable, the device logic is isolated into specific device classes.

Devices

Devices are convenience modules collecting conversions from and to protocol messages. It is connected to the rest of the library using the IPoweredUpProtocol (which may be filtered to the given port).

Devices have cached static information retrieved using PortInformation and PortModeInformation messages. These cached messages allow a much faster setup of the protocol decoding.

Rationale: Keep devices simple while at the same time keep the hub focused on managing ports and connection.

from powered-up.

Hub, Port and Device are virtual representations of physical object. This allows a simple mental transfer.

from powered-up.