/**
 * @license
 * Copyright 2022-2026 Matter.js Authors
 * SPDX-License-Identifier: Apache-2.0
 */
/*** THIS FILE IS GENERATED, DO NOT EDIT ***/
import { PartsBehavior } from "../behavior/system/parts/PartsBehavior.js";
import { IndexBehavior } from "../behavior/system/index/IndexBehavior.js";
import { BridgedDeviceBasicInformationServer as BaseBridgedDeviceBasicInformationServer } from "../behaviors/bridged-device-basic-information/BridgedDeviceBasicInformationServer.js";
import { PowerSourceConfigurationServer as BasePowerSourceConfigurationServer } from "../behaviors/power-source-configuration/PowerSourceConfigurationServer.js";
import { PowerSourceServer as BasePowerSourceServer } from "../behaviors/power-source/PowerSourceServer.js";
import { AdministratorCommissioningServer as BaseAdministratorCommissioningServer } from "../behaviors/administrator-commissioning/AdministratorCommissioningServer.js";
import { EcosystemInformationServer as BaseEcosystemInformationServer } from "../behaviors/ecosystem-information/EcosystemInformationServer.js";
import { MutableEndpoint } from "../endpoint/type/MutableEndpoint.js";
import { DeviceClassification } from "@matter/model";
import { Identity } from "@matter/general";
/**
 * This defines conformance for a Bridged Node root endpoint. This endpoint is akin to a "read me first" endpoint that
 * describes itself and any other endpoints that make up the Bridged Node. A Bridged Node endpoint represents a device
 * on a foreign network, but is not the root endpoint of the bridge itself.
 *
 * ### Device Type Requirements
 *
 * This device type shall only be indicated on endpoints which are listed in the Descriptor cluster PartsList of another
 * endpoint with an Aggregator device type.
 *
 * ### Endpoint Composition
 *
 * A Bridged Node endpoint shall support one of the following composition patterns:
 *
 *   - Separate Endpoints: All application device types are supported on separate descendant endpoints, and shall NOT be
 *     hosted on the Bridged Node endpoint. The Bridged Node endpoint's Descriptor cluster PartsList attribute shall
 *     indicate a list of all endpoints representing the functionality of the bridged device, including the endpoints
 *     supporting the application device types, i.e. the full-family pattern defined in the System Model specification.
 *     This is used for the following cases:
 *
 *     - Exposing a compound device - the child endpoints each have a part of the functionality of the bridged device.
 *       See endpoints 31-34 in the example below; the bridged device is a PIR sensor which also has temperature and
 *       illuminance measurement. Endpoints 32-34 host the associated application device types and clusters. Endpoint 31
 *       (the endpoint with the Bridged Node device type) functions as parent for these endpoints and has no application
 *       device types.
 *
 *     - Exposing a composed device type - a child endpoint of the endpoint with the Bridged Node device type has the
 *       composed device type; this endpoint with the composed device type has child endpoints for the device type(s)
 *       that are mandatory or optional for the composed device type. See endpoints 41-43 in the example below; this is
 *       a refrigerator, which is a composed device type, hosted on endpoint 42, with the associated temperature
 *       controlled cabinet device type on child endpoint 43. Endpoint 41 (the endpoint with the Bridged Node device
 *       type) functions as parent for the endpoint hosting the composed device type and has no application clusters.
 *
 *     - Combinations of the above.
 *
 *   - One Endpoint: Both the Bridged Node and one or more application device types are supported on the same endpoint
 *     (following application device type rules). The PartsList attribute in the Descriptor cluster shall be empty.
 *     Since compound devices and composed device types each need more than one endpoint to expose their functionality,
 *     they cannot use the "One Endpoint" pattern and need to use the "Separate Endpoints" model described above.
 *
 *     - Example in the figure below: endpoint 21 hosts the Bridged Node utility device type, plus the application
 *       device type for a dimmable light on same endpoint. Since the dimmable light device type is a superset of on/off
 *       light, that subset device type may be added here as well.
 *
 * In all these composition patterns, endpoint composition shall conform to the application device type(s) definition.
 *
 * @see {@link MatterSpecification.v161.Device} § 2.5
 */
export interface BridgedNodeEndpoint extends Identity<typeof BridgedNodeEndpointDefinition> {
}
export declare namespace BridgedNodeRequirements {
    /**
     * The BridgedDeviceBasicInformation cluster is required by the Matter specification.
     *
     * We provide this alias to the default implementation {@link BridgedDeviceBasicInformationServer} for convenience.
     */
    const BridgedDeviceBasicInformationServer: typeof BaseBridgedDeviceBasicInformationServer;
    /**
     * The PowerSourceConfiguration cluster is optional per the Matter specification.
     *
     * We provide this alias to the default implementation {@link PowerSourceConfigurationServer} for convenience.
     */
    const PowerSourceConfigurationServer: typeof BasePowerSourceConfigurationServer;
    /**
     * The PowerSource cluster is optional per the Matter specification.
     *
     * We provide this alias to the default implementation {@link PowerSourceServer} for convenience.
     */
    const PowerSourceServer: typeof BasePowerSourceServer;
    /**
     * The AdministratorCommissioning cluster is optional per the Matter specification.
     *
     * We provide this alias to the default implementation {@link AdministratorCommissioningServer} for convenience.
     */
    const AdministratorCommissioningServer: typeof BaseAdministratorCommissioningServer;
    /**
     * The EcosystemInformation cluster is optional per the Matter specification.
     *
     * We provide this alias to the default implementation {@link EcosystemInformationServer} for convenience.
     */
    const EcosystemInformationServer: typeof BaseEcosystemInformationServer;
    /**
     * An implementation for each server cluster supported by the endpoint per the Matter specification.
     */
    const server: {
        mandatory: {
            Parts: typeof PartsBehavior;
            Index: typeof IndexBehavior;
            BridgedDeviceBasicInformation: typeof BaseBridgedDeviceBasicInformationServer;
        };
        optional: {
            PowerSourceConfiguration: typeof BasePowerSourceConfigurationServer;
            PowerSource: typeof BasePowerSourceServer;
            AdministratorCommissioning: typeof BaseAdministratorCommissioningServer;
            EcosystemInformation: typeof BaseEcosystemInformationServer;
        };
    };
}
export declare const BridgedNodeEndpointDefinition: MutableEndpoint.With<import("../index.js").EndpointType.For<{
    readonly name: "BridgedNode";
    readonly deviceType: 19;
    readonly deviceRevision: 3;
    readonly deviceClass: DeviceClassification.Utility;
    readonly requirements: typeof BridgedNodeRequirements;
    readonly behaviors: {
        readonly parts: typeof PartsBehavior;
    } & {
        readonly index: typeof IndexBehavior;
    } & {
        readonly bridgedDeviceBasicInformation: typeof BaseBridgedDeviceBasicInformationServer;
    };
}>, {
    readonly parts: typeof PartsBehavior;
} & {
    readonly index: typeof IndexBehavior;
} & {
    readonly bridgedDeviceBasicInformation: typeof BaseBridgedDeviceBasicInformationServer;
}, {}>;
export declare const BridgedNodeEndpoint: BridgedNodeEndpoint;
//# sourceMappingURL=bridged-node.d.ts.map