@mega-yfue/eufy-sdk 0.0.4 → 0.1.0-beta.0

package/dist/model/capabilities/access.d.ts

@@ -0,0 +1,127 @@
+import type { Capability } from "../types.js";
+import type { ActionSpec, AvailabilityContext, CommandContext, CapabilityStateReader } from "./types.js";
+import type { Command, ScalarForm } from "../../core/contracts.js";
+/**
+ * Capability param access — the shared surface capability modules use to WRITE a param (the
+ * command-intent builders) and to READ one (the typed read extractors at the bottom of this file).
+ *
+ * **Write:** a capability states *what* to change (param id + already-polarity-resolved value) and,
+ * when the firmware pins it, *which wire form* the data takes. It never picks an encryption level or
+ * assembles a P2P frame: the transport resolver ({@link module:index} `resolveScalar`) does that,
+ * session-first for `"auto"`. Adding or changing a capability = call these helpers; the transport
+ * stays untouched.
+ *
+ * **Read:** the `readNum`/`readBool`/`readStr` extractors narrow a live property to a typed value for
+ * the fluent read getters (`dev.battery()?.level`) — the dual of the write builders.
+ *
+ * @module model/capabilities/access
+ * ## `ScalarForm`
+ * - `"auto"` — a scalar int whose encryption level the **session** decides: L2 direct-binary when a
+ *   level-2 key is negotiated, else L1 int-string. Correct for params that are the same bytes either
+ *   way (camera power 1035 — verified live on standalone T8410 = L1 and HomeBase T8114 = L2).
+ * - `"int-string"` — force the L1 int+string frame. For params the firmware only accepts as level-1
+ *   even on a HomeBase (status LED 1045; the Cam2C/2/3 floodlight switch 1400).
+ * - `"direct-binary"` — force the L2 binary "direct" frame (spotlight brightness/color-temp/enable).
+ *
+ * ({@link ScalarForm} is declared in `./types` to keep the Command union self-contained.)
+ */
+/**
+ * Set a scalar (integer) param. `form` defaults to `"auto"` — let the session decide the level.
+ * Pass an explicit form only when the firmware pins the wire (see {@link ScalarForm}).
+ */
+export declare function setScalar(param: number, value: number, ctx: CommandContext, form?: ScalarForm): Command;
+/**
+ * Set a param carried as a JSON control-payload (`{commandType:param, data}` under the 1700 wrapper).
+ * The transport picks L1 (standalone, ECB) vs L2 (HomeBase, GCM) by session — the capability just
+ * describes the payload.
+ */
+export declare function setJson(param: number, data: Record<string, unknown>, ctx: CommandContext): Command;
+/**
+ * Set a param carried as BARE JSON, no envelope at all — the wire's outer P2P command IS `cmd`
+ * itself, GCM signCode 8, plaintext exactly `{account_id,...data}` (the sink injects `account_id`).
+ * Distinct from {@link setJson}, which always wraps in the `1700` CONTROL_PAYLOAD `{commandType,data}`
+ * shape. Reversed from a live capture of the app's own SET_SNOOZE_TIME (1271) frame.
+ *
+ * `channel` overrides the device channel — pass it for a station-scoped bare write (e.g. the
+ * alarm-delay config 1255, which rides the station broadcast channel 255, not `ctx.channel`).
+ */
+export declare function setJsonRaw(cmd: number, data: Record<string, unknown>, ctx: CommandContext, channel?: number): Command;
+/**
+ * Set a param carried in the `SET_PAYLOAD` (1350) envelope — `{account_id,cmd,mChannel,mValue3:cmd,
+ * payload}`, GCM signCode 8 — NOT the bare `{commandType,data}` 1700 wrapper `setJson` uses. The wire
+ * eufy uses for a few doorbell controls (status-LED 1716 `{light_enable}`). Level-2 by default; the
+ * sink resolves the session/account_id and replays the frame. Pass `form: "auto"` when the envelope is
+ * also valid at level 1, so a STANDALONE device — which never negotiates a level-2 key — can receive it
+ * instead of failing outright.
+ */
+export declare function setPayload(cmd: number, payload: Record<string, unknown>, ctx: CommandContext, mValue3?: number, channel?: number, form?: ScalarForm): Command;
+/**
+ * Set a station-scoped scalar (132-byte body, no channel field) on an EXPLICIT channel — for the
+ * HomeBase's own controls on the station broadcast channel 255 (alarm/speaker volume 1235).
+ */
+export declare function setStationScalar(cmd: number, value: number, channel: number): Command;
+/**
+ * A one-line device descriptor for error messages — carries every identifier needed to reproduce or
+ * triage from a log later (deviceType, model T-code, full serial, channel, codec), so a "capability
+ * detected but this device's wire is unknown / unsupported" throw is self-contained instead of naming
+ * a bare `deviceType`.
+ */
+export declare function describeDevice(ctx: CommandContext): string;
+/** True for a camera-codec device (a camera or a doorbell) — the video / two-way-audio family. */
+export declare function isCameraCodec(ctx: AvailabilityContext): boolean;
+/** True for a station/hub codec (a HomeBase OR an NVR — use `isHomeBase` from device-family to exclude NVRs). */
+export declare function isStationCodec(ctx: AvailabilityContext): boolean;
+/** True when the device's RESOLVED capability set includes `cap` — the same gate `buildCommand` authorizes on. */
+export declare function hasCapability(ctx: AvailabilityContext, cap: Capability): boolean;
+/**
+ * Attach a description to an action, at the one place the action is declared.
+ *
+ * The alternative — a table of descriptions beside `actions()` — restates every method name, which is
+ * one rename away from describing a method that no longer exists. Here the object key IS the name, so
+ * the two cannot come apart. The description is then readable only off a BUILT action object.
+ *
+ * See {@link ActionSpec} for what may be described — the value-taking method rather than its aliases,
+ * and only a wire confirmed on real hardware.
+ */
+export declare function describedAction<F extends (...args: never[]) => unknown>(spec: ActionSpec, fn: F): F;
+/** The {@link ActionSpec} attached to a built action, or `undefined` for one nothing describes. */
+export declare function actionSpecOf(fn: unknown): ActionSpec | undefined;
+/**
+ * `vacuum_clean` → `vacuumClean`, `smart_light` → `smartLight` — the fluent accessor name a capability
+ * is reached under.
+ *
+ * Lives here because two callers need the same answer: the barrel installs the accessors under these
+ * names, and the manifest publishes them, so a described capability names the accessor its object
+ * lives on. A second copy would be a rename away from naming an accessor that doesn't exist.
+ * @internal
+ */
+export declare function camelCase(cap: Capability): string;
+/**
+ * Narrow a capability's live property to a typed value for a fluent read getter (`dev.battery()?.level`).
+ * The value already arrives runtime-coerced to its `PropertySpec.type` (`device.ts` `coerceByType`), so
+ * this only guards the runtime type — returning `undefined` on a mismatch (or a missing/unbound reader)
+ * rather than lie-casting. Read a numeric property, or `undefined` when absent / not a number.
+ */
+export declare function readNum(read: CapabilityStateReader | undefined, name: string): number | undefined;
+/** Read a boolean property by name, or `undefined` when absent / not a boolean. */
+export declare function readBool(read: CapabilityStateReader | undefined, name: string): boolean | undefined;
+/** Read a string property by name, or `undefined` when absent / not a string. */
+export declare function readStr(read: CapabilityStateReader | undefined, name: string): string | undefined;
+/**
+ * Build a Tuya DP write intent — the clean-line wire for a single data-point value.
+ * Named for the wire mechanism (the AIoT "Tuya DP" protocol), not the capability that first
+ * uses it, so it is open to any future Tuya-DP device.
+ */
+export declare function aiotDp(dp: number, value: boolean | number | string): Command;
+/**
+ * Pick a capability's OWN data points out of a realtime report, for its `decodeState`.
+ *
+ * The transport unwraps the report's envelope into `id → value` without knowing what any id means;
+ * this is the other half — each capability names the ids it owns, so one clean-line module never
+ * claims another's points off the same message. `undefined` when the report carries none of them,
+ * which is what a `decodeState` returns to say "not mine".
+ *
+ * Values pass through untouched. A structured point stays the base64 its device sent, for the read
+ * getter to decode once a codec is in scope.
+ */
+export declare function pickDpParams(report: Record<number, string> | undefined, ids: readonly number[]): Record<number, string> | undefined;

package/dist/model/capabilities/arming.d.ts

@@ -0,0 +1,201 @@
+import { type Surface } from "./members.js";
+import type { CapabilityModule, CommandContext } from "./types.js";
+import type { Command } from "../../core/contracts.js";
+/**
+ * The guard modes {@link ArmingActions} can SET — the three whose write was captured byte-exact against a
+ * real station. `ArmingMode` is both the const value-object (`ArmingMode.home`) and the union type of its
+ * values, so callers pass the named constant: `setMode(ArmingMode.home)`.
+ *
+ * Deliberately NARROWER than the set a device may report. The other six modes are ones the app itself
+ * defines and the `mode` read still names them, but no capture shows one being SENT — and
+ * on a fire-and-forget wire a wrong one looks exactly like success. Leaving them out of this union is the
+ * compile-time half of the refusal; `mode`'s published argument and the generated rejection are the
+ * runtime half.
+ */
+export declare const ArmingMode: {
+    /** Armed — full protection, nobody home (wire value 0). */
+    readonly away: "away";
+    /** Armed for occupancy — reduced/perimeter protection while home (wire value 1). */
+    readonly home: "home";
+    /** Disarmed — no alarms; sensors still report state (wire value 63). */
+    readonly disarmed: "disarmed";
+};
+export type ArmingMode = (typeof ArmingMode)[keyof typeof ArmingMode];
+/**
+ * The P2P **feature-command ids** this arming capability drives. Capability-owned wire vocabulary
+ * (transport forwards `cmd.param` opaquely; full id→name catalog in the generated
+ * `transport/p2p/commands.ts`).
+ */
+export declare const ARMING_CMD: {
+    /**
+     * Guard/arming mode (app `GUARD_MODE`). ✅ Wire ENVELOPE verified live on a T8030 (
+     * 2026-07-23), cycling Away→Disarmed→Home in the
+     * real app: `1350` SET_PAYLOAD, cmd 1224 (SAME id as the read param), mChannel 0, explicit
+     * mValue3:0, `payload:{mode_type:<int>, user_name:<string>}`.
+     *
+     * ⚠️ Only 3 of the 9 modes were exercised in that capture — `mode_type` 0 (away), 63 (disarmed), 1
+     * (home), all confirmed byte-exact, and those three are the whole of {@link ArmingMode}. Re-confirmed
+     * live 2026-08-05: each reported its own MODE_SWITCH push within ~5s of the write. The remaining six are
+     * named by the app but never observed leaving it, so this capability reads them and refuses to send
+     * them. See `ARMING_MODE_WIRE` for the per-value breakdown.
+     */
+    readonly SET_ARMING: 1224;
+    /**
+     * The per-mode alarm/arm-delay configuration write. ✅ WIRE CAPTURED live on a T8030 (
+     * 2026-07-23, both directions): a **bare
+     * JSON frame, no `1350`/`1700` envelope** — outer P2P cmd IS `1255` itself, station channel 255,
+     * plaintext `{account_id, count_down_alarm:{channel_list,delay_time},
+     * count_down_arm:{channel_list,delay_time}, devices:[{action,device_channel}], mode_id,
+     * siren_sensor_action:[{action,device_channel}]}`.
+     *
+     * **Disambiguated from a live-countdown-state echo** (2026-07-23): a full arm→wait-through-exit-
+     * delay→disarm cycle produced ZERO traffic on this cmd, while every edit of the app's "Alarm Delay"
+     * screen did — so this is a genuine settings WRITE, not a realtime push.
+     *
+     * **Why `setAlarmDelayConfig` takes the FULL config, not just a duration**: `channelList` identifies
+     * WHICH sensor channels get the delay (confirmed: setting 45s on one specific sensor produced
+     * `channel_list:[<that sensor's channel>], delay_time:45`) — it is not a simple on/off. The
+     * corresponding GET command (`1310`/inner cmd `40003`, sent by the app right before editing) always
+     * replied `{count:0,data:null}` in every capture — genuinely empty, not a decrypt failure (confirmed
+     * via the same bidirectional decrypt this finding used) — so the app does NOT read the current
+     * config this way; how it does is still unknown. Without a working GET, safely PATCHING just one
+     * channel in or out of an existing list isn't possible without risking clobbering the rest — so
+     * this ships as a caller-supplies-everything write instead of guessing a merge.
+     * `devices`/`siren_sensor_action` are even less understood (raw per-device action codes, meaning
+     * unconfirmed) and MUST come from a value independently read/captured for the target mode —
+     * see `AlarmDelayConfig`'s field docs.
+     */
+    readonly ALARM_DELAY_CONFIG: 1255;
+};
+/**
+ * Alarm-delay durations the app's OWN picker UI offers — `AlarmDelaySeconds` is both the const
+ * value-object (`AlarmDelaySeconds.sec45`) and the union type of its values, so callers pass the
+ * named constant: `{delaySeconds: AlarmDelaySeconds.sec45}`.
+ *
+ * **NOT a wire constraint** — the device itself does NOT validate against this list: a live test sent
+ * `50` (off this list) and the app reflected it correctly, no rejection. Typed as a closed set anyway
+ * so `setAlarmDelayConfig` callers get the same choices a human editing the same setting in the app
+ * would see, rather than an arbitrary int that could silently diverge from every value the real UI
+ * can actually produce.
+ */
+export declare const AlarmDelaySeconds: {
+    readonly off: 0;
+    readonly sec15: 15;
+    readonly sec30: 30;
+    readonly sec45: 45;
+    readonly sec60: 60;
+    readonly min3: 180;
+    readonly min5: 300;
+};
+export type AlarmDelaySeconds = (typeof AlarmDelaySeconds)[keyof typeof AlarmDelaySeconds];
+/** One `channelList`+`delaySeconds` countdown pair — see {@link AlarmDelayConfig}. */
+export type AlarmDelayCountdown = {
+    /** Device channels this countdown applies to. */
+    channelList: number[];
+    /** Delay duration — one of {@link AlarmDelaySeconds}, shared across every channel in `channelList`. */
+    delaySeconds: AlarmDelaySeconds;
+};
+/** One device's participation entry in {@link AlarmDelayConfig.devices} / `.sirenSensorAction`. */
+export type AlarmDelayDeviceAction = {
+    deviceChannel: number;
+    /** Raw per-device action code. Meaning NOT independently confirmed — pass through verbatim from a
+     * value read/captured for this exact mode, never invented. */
+    action: number;
+};
+/**
+ * The FULL per-mode alarm/arm-delay configuration the device accepts as one write — see the
+ * `setAlarmDelayConfig` doc for why this is a caller-supplies-everything shape rather than a simple
+ * `setEntryDelay(seconds)` toggle.
+ */
+export type AlarmDelayConfig = {
+    /** Per-sensor ENTRY/alarm delay — the app's "Alarm Delay" UI setting. Confirmed on-device: a delay
+     * set on one sensor lands as that sensor's channel plus the chosen duration. */
+    countDownAlarm: AlarmDelayCountdown;
+    /** A second, distinct countdown carried alongside `countDownAlarm`. It stayed empty across every
+     * observed `countDownAlarm` edit, so its own trigger condition is UNCONFIRMED. */
+    countDownArm: AlarmDelayCountdown;
+    /** Every device's participation + action for THIS mode. UNCONFIRMED semantics (the action code's
+     * meaning is unknown) — it stayed identical across every `countDownAlarm`-only edit within the same
+     * mode, so pass through exactly what was read back for that mode; never invent a value. */
+    devices: AlarmDelayDeviceAction[];
+    /** Siren behavior per device for this mode. Same caveat as `devices`. */
+    sirenSensorAction: AlarmDelayDeviceAction[];
+};
+/**
+ * Bound guard-mode controls — the object returned by `dev.arming()`.
+ *
+ * Everything is DERIVED from `ARMING_MEMBERS`. `setMode` is the mode member's own derived setter;
+ * `setAlarmDelayConfig` is a `method` because it takes TWO arguments (a mode and a whole config),
+ * which no value setter can express.
+ */
+export type ArmingActions = Surface<typeof ARMING_MEMBERS>;
+/**
+ * Every `arming` feature, declared once.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const ARMING_MEMBERS: {
+    /**
+     * The one member whose write domain is NARROWER than its read: `enumValues` names all nine modes a
+     * station can report, and the argument's `values` publishes only the three whose wire was captured. That
+     * argument IS the domain the derived setter enforces and the refusal names, so an uncaptured mode is
+     * refused by naming the three that work — nine labels for the read and three for the write, off one
+     * declaration.
+     *
+     * `armingCommand` may also throw synchronously (missing account identity) and `bindMembers` turns that
+     * into a rejection, so the builder stays plain.
+     *
+     * The setter takes either vocabulary — see `armingModeOf` — because the getter answers the wire integer,
+     * and a value a caller just read has to be one it can write back.
+     *
+     * MODE_SWITCH carries no value. Live qualification on a standalone camera showed that authoritative
+     * readback requires a bounded cloud-list refresh, and that its P2P session must be reset after
+     * convergence before a following mode write; an attached device must never reset its shared HomeBase.
+     */
+    readonly mode: {
+        readonly accepts: ArmingMode;
+        readonly param: 1224;
+        readonly property: "armingMode";
+        readonly type: "enum";
+        readonly kind: "enum";
+        readonly enumValues: Record<number, string>;
+        readonly provenance: "verified";
+        readonly args: readonly [{
+            readonly name: "mode";
+            readonly kind: "enum";
+            readonly values: readonly number[];
+        }];
+        readonly description: string;
+        readonly observation: {
+            readonly event: "armingModeChanged";
+            readonly reflects: (value: string | number | boolean) => {
+                param: 1224;
+                expected: number;
+            };
+            readonly resetStandaloneSession: true;
+            readonly timeoutMs: 20000;
+        };
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command | undefined;
+    };
+    /**
+     * Write the FULL per-mode alarm/arm-delay configuration. The device accepts the whole config as one
+     * write, not a single duration field, so a partial update is not possible. An expert/advanced API: the
+     * caller is responsible for supplying `devices`/`sirenSensorAction` (and the `countDownAlarm`/
+     * `countDownArm` entries they are NOT changing) from a value they have independently read/captured for
+     * this mode — there is no known GET to fetch it automatically, and a wrong guess here can silently
+     * misconfigure which sensors arm/trigger for real.
+     *
+     * Takes {@link ArmingMode}, so a delay can only be configured for a mode whose `mode_id` integer is
+     * captured. The frame carries that same integer, so a schedule/custom mode would be the identical guess
+     * `setMode` refuses.
+     */
+    readonly setAlarmDelayConfig: import("./members.js").MethodMember<(mode: ArmingMode, config: AlarmDelayConfig) => Promise<void>>;
+};
+/**
+ * `arming` — guard/arming mode. `armingMode` (see {@link ARMING_CMD.SET_ARMING}) has a verified
+ * read/write MECHANISM, but only 3 of its 8 {@link ArmingMode} values (away/home/disarmed) are
+ * wire-captured — see `ARMING_MODE_WIRE` for which 5 are still unverified third-party integers.
+ */
+export declare const ARMING: CapabilityModule;

package/dist/model/capabilities/audio.d.ts

@@ -0,0 +1,154 @@
+import { isHomeBase } from "../device-family.js";
+import { isCameraCodec } from "./access.js";
+import { type Surface } from "./members.js";
+import type { AvailabilityContext, CapabilityModule, CommandContext } from "./types.js";
+import type { Command } from "../../core/contracts.js";
+/**
+ * The P2P **feature-command ids** this audio capability drives — the outer-cmd IS the param id on the
+ * camera side (direct-binary struct), or the inner cmd of a `1350` SET_PAYLOAD on the station side.
+ * Capability-owned wire vocabulary (transport forwards `cmd.param` opaquely; full id→name catalog in
+ * the generated `transport/p2p/commands.ts`). All ✅ wire-verified live — see the module JSDoc below.
+ */
+export declare const AUDIO_CMD: {
+    /**
+     * Microphone on/off (app `AUDIO_MICROPHONE_SWITCH`). ✅ Wire verified live on T8214: direct-binary
+     * 136-byte struct, signCode 8, 1=on/0=off (a switch, not a mute).
+     */
+    readonly AUDIO_MICROPHONE: 1240;
+    /** Speaker on/off (app `AUDIO_SPEAKER_SWITCH`). ✅ Wire verified live on T8214 — direct-binary, 1=on/0=off. */
+    readonly AUDIO_SPEAKER: 1241;
+    /** Speaker volume 0..100 (app `DOORBELL_AUDIO_VOLUME`). ✅ Same direct-binary wire; write verified live on T8214 (set 60 → param 60). */
+    readonly SPEAKER_VOLUME: 1230;
+    /**
+     * Audio recording on/off (app `DOORBELL_AUDIO_RECORDING_SWITCH`) — whether the camera records audio
+     * with video. Reported by every camera. ✅ Wire reversed from a live outbound capture + L2 decrypt on
+     * T8425 (ch3): `1350` SET_PAYLOAD on the device channel (mChannel = device ch, mValue3 0), payload
+     * `{channel:<deviceCh>, record_mute:0|1}`. The key is `record_mute` and it is **INVERTED** —
+     * `record_mute:1` = muted (recording OFF), `record_mute:0` = recording ON.
+     */
+    readonly AUDIO_RECORDING: 1288;
+    /**
+     * Doorbell ringtone/chime volume 0..100 (app `DOORBELL_RINGTONE_VOLUME`). ✅ Wire verified live on
+     * T8214 — same direct-binary 136-byte struct, signCode 8. Doorbell-only: this capability adds it when
+     * the device is a doorbell.
+     */
+    readonly DOORBELL_RINGTONE_VOLUME: 1708;
+    /**
+     * HomeBase voice **prompt** volume 0..100 (app `APP_CMD_SET_PROMPT_VOLUME`). ✅ Wire verified live on
+     * T8030 (audible): the `1350` SET_PAYLOAD wrapper on ch0 with `payload:{value}`. Station-only.
+     */
+    readonly HUB_PROMPT_VOLUME: 1292;
+};
+/**
+ * Bound audio controls — the object returned by `dev.audio()`.
+ *
+ * Everything is DERIVED from `AUDIO_MEMBERS`. Which methods a device has depends on its FAMILY, so
+ * every write is optional and a caller checks: a **camera/doorbell** gets `setMicrophone`/`setSpeaker`/
+ * `setVolume`/`setAudioRecording` (+ `setRingtoneVolume` on a doorbell); a **HomeBase/station** gets
+ * `setPromptVolume`. Alarm-output configuration belongs to the `siren` capability.
+ */
+export type AudioActions = Surface<typeof AUDIO_MEMBERS>;
+/**
+ * Every general audio feature, declared once and family-gated across cameras, doorbells, and HomeBases.
+ *
+ * Camera side (Doorbell T8214): outer-cmd = the param id
+ * (1240/1241/1230/1708), signCode 8, device channel, 168B→136B direct-binary struct
+ * `[u32 channel][u32 value][account_id pad→128]`; polarity is 1=on. HomeBase prompt volume `1292`
+ * rides the `1350` SET_PAYLOAD wrapper on channel 0 with `payload:{value}` and is not cloud-reflected.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const AUDIO_MEMBERS: {
+    /**
+     * A SWITCH, not a mute: `true` powers the mic, so the polarity reads the same way round on the wire
+     * (1 = on) with no `invert`. Camera-family only — a HomeBase has no microphone, so the getter and
+     * setter are both absent there and a caller must check.
+     */
+    readonly microphone: {
+        readonly param: 1240;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "verified";
+        readonly available: typeof isCameraCodec;
+        readonly description: "Microphone on/off (1240 AUDIO_MICROPHONE_SWITCH; 1=on/0=off). Wire verified live on T8214.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * The camera's own speaker switch — what talkback and the doorbell's responses play out of. Distinct
+     * from `volume`, which sets how loud it is: turning this off silences the camera whatever the level
+     * says. Camera-family only, like `microphone` above; HomeBase voice prompts use `promptVolume`.
+     */
+    readonly speaker: {
+        readonly param: 1241;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "verified";
+        readonly available: typeof isCameraCodec;
+        readonly description: "Speaker on/off (1241 AUDIO_SPEAKER_SWITCH; 1=on/0=off). Wire verified live on T8214.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * `volume` is the accessor a caller sees; the flat property has to be `speakerVolume` because three
+     * capabilities claim `volume`. Both names reach the same write through the intent path.
+     */
+    readonly volume: {
+        readonly param: 1230;
+        readonly property: "speakerVolume";
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly provenance: "verified";
+        readonly available: typeof isCameraCodec;
+        readonly min: 0;
+        readonly max: 100;
+        readonly intentNames: readonly ["volume"];
+        readonly description: "Speaker volume 0..100 (1230 DOORBELL_AUDIO_VOLUME). Write verified live on T8214 (set 60 → param 60).";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /** Raw param 1288 is `record_mute` (1 = muted / recording OFF), so audioRecording = NOT record_mute. */
+    readonly audioRecording: {
+        readonly param: 1288;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly invert: true;
+        readonly provenance: "verified";
+        readonly available: typeof isCameraCodec;
+        readonly description: string;
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Doorbell ring/chime loudness — WRITE-ONLY here on purpose. The READ property `ringtoneVolume` (1708)
+     * lives on the `doorbell` capability: 1708 leaks onto non-doorbell cameras, so it cannot be an `audio`
+     * property (which spans all cameras) without over-surfacing junk. Audio owns the write.
+     */
+    readonly ringtoneVolume: {
+        readonly param: 1708;
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly writeOnly: true;
+        readonly provenance: "verified";
+        readonly available: (ctx: AvailabilityContext) => boolean;
+        readonly min: 0;
+        readonly max: 100;
+        readonly description: "Doorbell ring/chime volume 0..100 (1708 DOORBELL_RINGTONE_VOLUME). Wire verified live on T8214.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /** HomeBase voice-prompt volume uses the 1350 SET_PAYLOAD wrapper on channel 0 and has no cloud readback. */
+    readonly promptVolume: {
+        readonly param: 1292;
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly writeOnly: true;
+        readonly provenance: "verified";
+        readonly available: typeof isHomeBase;
+        readonly min: 0;
+        readonly max: 100;
+        readonly description: "HomeBase voice-prompt volume 0..100 (1292 APP_CMD_SET_PROMPT_VOLUME). Verified audible on a T8030.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+};
+export declare const AUDIO: CapabilityModule;