homebridge-unifi-protect/dist/nvr/event-dispatch.d.ts

Homebridge UniFi Protect plugin providing complete HomeKit integration for the entire UniFi Protect ecosystem with full support for most features including HomeKit Secure Video, multiple controllers, blazing fast performance, and much more.

import type { AuthMethod, ProtectEventMetadata } from "unifi-protect";
import type { ProtectCamera } from "../devices/cameras/camera.ts";
import type { ProtectDevice } from "../devices/device.ts";
import type { ProtectNvr } from "./nvr.ts";
/**
 * The controller's typed event surface, projected onto HomeKit. A thin router over the classified event firehose, plus the HomeKit delivery methods that router
 * drives. Controller-state merge, packet re-emit, and per-id fan-out belong to the unifi-protect library's reducer and observe loops; what lives here is purely the
 * routing and delivery.
 *
 *   - `run()` is one controller-level consumer of `client.events()` - the typed, classified firehose. It switches on the discriminated `kind` and dispatches each
 *     activity occurrence (smart detection, doorbell ring, tamper, Access doorbell ring, doorbell auth) to the addressed accessory's delivery method. State transitions
 *     (deviceAdded/devicePatched/...) are the NVR observe loops' concern and are ignored here. Bare camera motion is NOT routed here: the controller signals it only as a
 *     `lastMotion` device-state advance with no occurrence packet, so the camera leaf observes that field directly, exactly as the sensor and light families do.
 *   - `publishTelemetry()` is the controller telemetry republisher: every raw frame off `client.rawPackets()` is mirrored to MQTT when the user opts in.
 *   - the delivery methods (`motionEventHandler`, `doorbellEventHandler`) own the HomeKit-facing behavior - the characteristic writes, the reset timers, and the MQTT
 *     side-channels - while `accessEventHandler` maps a UniFi Access intercom doorbell press onto that same doorbell ring delivery rather than owning a path of its own.
 *     Their *trigger* is the typed firehose: each delivery fires on a discriminated event kind.
 *
 * A plain class, not an EventEmitter: nothing here emits. The accessory leaves call the delivery methods directly through `nvr.events`, and the router and telemetry
 * publisher are spawned as NVR observe loops, so no event bus survives. The controller's systemInfo is consumed the same way, through a narrow `client.state.observe`
 * loop over that slice rather than through an event subscriber.
 */
export declare class ProtectEventDispatch {
    private hap;
    private log;
    private nvr;
    private readonly eventTimers;
    private readonly smartDetectLoggedAttributes;
    constructor(nvr: ProtectNvr);
    run(signal: AbortSignal): Promise<void>;
    private cameraFor;
    private publishDispatch;
    private withoutMotionThumbnails;
    clearEventTimersForDevice(id: string): boolean;
    hasInflightMotion(id: string): boolean;
    retireDevice(protectDevice: ProtectDevice): void;
    motionEventHandler(protectDevice: ProtectDevice, detectedObjects?: string[], metadata?: ProtectEventMetadata): void;
    private motionEventDelivery;
    doorbellEventHandler(protectDevice: ProtectCamera): void;
    accessEventHandler(protectDevice: ProtectCamera, action: string): void;
    authEventHandler(protectDevice: ProtectCamera, method: AuthMethod, metadata?: ProtectEventMetadata): void;
    tamperEventHandler(protectDevice: ProtectCamera): void;
    buttonEventHandler(protectDevice: ProtectDevice, button: string, pressType: string): void;
    private pressValue;
    publishTelemetry(signal: AbortSignal): Promise<void>;
}
//# sourceMappingURL=event-dispatch.d.ts.map