homebridge/dist/matter/server/AccessoryManager.d.ts

HomeKit support for the impatient

/**
 * Accessory Manager
 *
 * Handles registering/unregistering accessories, building custom behaviors,
 * detecting cluster features, creating endpoint options, creating accessory parts,
 * and restoring cached state.
 */
import type { ServerNode } from '@matter/main';
import type { MatterAccessoryCache } from '../accessoryCache.js';
import type { BehaviorRegistry, RegistryManager } from '../behaviors/index.js';
import type { MatterServerConfig } from '../sharedTypes.js';
import type { InternalMatterAccessory, MatterAccessory } from '../types.js';
import { Endpoint } from '@matter/main';
export interface AccessoryManagerDeps {
    config: MatterServerConfig;
    accessories: Map<string, InternalMatterAccessory>;
    behaviorRegistry: BehaviorRegistry;
    registryManager: RegistryManager;
    accessoryCache: MatterAccessoryCache | null;
    getServerNode: () => ServerNode | null;
    getAggregator: () => Endpoint<typeof import('@matter/main/endpoints').AggregatorEndpoint> | null;
    getIsRunning: () => boolean;
    getMonitoringEnabled: () => boolean;
    isCommissioned: () => boolean;
}
export declare class AccessoryManager {
    /**
     * Register a single Matter accessory
     * The first two arguments are unused, but kept to keep consistency with the HAP accessory registration function signature.
     */
    registerAccessory(_pluginIdentifier: string, _platformName: string, accessory: MatterAccessory, deps: AccessoryManagerDeps): Promise<void>;
    /**
     * Unregister a Matter accessory
     */
    unregisterAccessory(uuid: string, deps: AccessoryManagerDeps): Promise<void>;
    /**
     * Restore cached state for an accessory
     */
    private restoreCachedState;
    /**
     * Work out the endpoint's final device type: compose the feature-gated
     * clusters it needs, fix up any state that would fail conformance, and
     * attach the Homebridge behaviors that route commands to plugin handlers.
     *
     * ⚠️ Shared by the parent accessory AND by every part. Child endpoints used
     * to run a cut-down version of this that only looked up behaviors by name,
     * so a composed part quietly lost anything decided here — its battery was
     * never composed, a thermostat part had no thermostat cluster at all
     * (matter.js gates it behind features, so the base device type carries
     * none), and a dimmable part declaring the once-documented `minLevel: 0`
     * still failed to register. Anything added here must therefore stay free of
     * parent-only assumptions; the caller handles what genuinely differs
     * (bridged info, the composed-parent labels, the child tag list).
     */
    private prepareDeviceType;
    /**
     * Present a part as an accessory so it can go through {@link prepareDeviceType}.
     *
     * Parts carry the same `deviceType`/`clusters`/`handlers` shape as their
     * parent, just without the bridge-level identity fields — which nothing in
     * the preparation pipeline reads. `clusters` is passed by reference on
     * purpose: the pipeline edits it (electrical defaults, the battery charge
     * state seed, the LevelControl floor) and those edits have to land on the
     * part object that is about to be registered.
     */
    private partAsAccessory;
    /**
     * Detect cluster features for an accessory
     */
    private detectClusterFeatures;
    /**
     * Build custom behaviors for an accessory based on handlers
     */
    private buildCustomBehaviors;
    /**
     * Create endpoint options for an accessory
     */
    private createEndpointOptions;
    /**
     * Register command handlers for an accessory
     */
    private registerAccessoryHandlers;
    /**
     * Create and register child endpoints (parts) for an accessory
     *
     * Parts are added as sub-endpoints of the parent endpoint, creating a composed
     * device per the Matter spec. Children are plain device types with no
     * BridgedDeviceBasicInformation — only the parent has that.
     * See: https://github.com/matter-js/matter.js/blob/main/docs/MIGRATION_GUIDE_08.md
     */
    private createAccessoryParts;
    /**
     * Advertise the ElectricalSensor utility device type (0x0510) in the
     * endpoint's descriptor. Controllers discover power/energy metering through
     * the device type list, not just the clusters, so an outlet that carries
     * the measurement clusters must also list ElectricalSensor. matter.js
     * dedupes the entry, so this is safe when the base device type already is
     * an ElectricalSensor.
     */
    private advertiseUtilityDeviceType;
    /**
     * Finalize accessory registration (store, emit events, save cache)
     */
    private finalizeAccessoryRegistration;
    /**
     * Notify controllers that the parts list has changed
     */
    private notifyPartsListChanged;
    /**
     * A single attempt at pushing the parts-list change to controllers: update the
     * aggregator's parts list and bump the bridge ConfigurationVersion. Both bump
     * once per successful call, so retrying the whole thing after a mid-way lock
     * failure does not double-count (the parts-list set is idempotent and only a
     * successful `increaseConfigurationVersion()` mutates the version).
     */
    private applyPartsListNotification;
}
//# sourceMappingURL=AccessoryManager.d.ts.map