@mega-yfue/eufy-sdk 0.2.0-beta.8 → 0.2.0

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

@@ -50,9 +50,28 @@ export declare function setJsonRaw(cmd: number, data: Record<string, unknown>, c
  * 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.
+ * sink resolves the session/account_id and replays the frame.
+ *
+ * ## When this envelope takes `form: "auto"`
+ *
+ * Left at the default the frame is level-2 ONLY, and on a station holding no level-2 key that does not
+ * fail — it WAITS: the transport spends the full level-2 grace, re-prompts, spends it again, and only
+ * then throws. Every caller with a shorter bound sees a hang rather than a refusal, so a control on a
+ * device that may be its own keyless station is effectively unreachable. `"auto"` hands the choice to
+ * the session (`sendBySessionLevel`), which seals level-2 wherever a key exists — unchanged for a
+ * HomeBase — and level-1 where none does.
+ *
+ * Two conditions, and BOTH have to hold:
+ *
+ *  1. **`mValue3` is passed explicitly as 0.** The level-1 form of this envelope writes `mValue3:0`
+ *     itself, while the level-2 form defaults it to the sub-command — so a command that passes 0 sends
+ *     byte-identical JSON either way and `"auto"` only changes the seal. A command that OMITS `mValue3`
+ *     would send a DIFFERENT object at level 1 than the one captured at level 2; that is a new wire
+ *     needing its own evidence, not a downgrade, and it stays pinned until something captures it.
+ *  2. **The device can be its own station.** A camera or doorbell may be standalone; a HomeBase, and an
+ *     accessory whose session IS its HomeBase's, always holds a key. Where a key is structurally
+ *     guaranteed, staying pinned is the honest behaviour: a keyless station there is an anomaly, and
+ *     throwing says so where a silently-ignored level-1 frame would look like success.
  */
 export declare function setPayload(cmd: number, payload: Record<string, unknown>, ctx: CommandContext, mValue3?: number, channel?: number, form?: ScalarForm): Command;
 /**

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

@@ -2,27 +2,35 @@ import { type Surface } from "./members.js";
 import type { CapabilityModule, CommandContext } from "./types.js";
 import type { Command } from "../../core/contracts.js";
 /**
- * The guard modes `setMode` can SET — the four whose write is confirmed against a real station. Three are
- * byte-exact captures and `custom1` is a live confirmation; `ARMING_MODE_WIRE` carries the per-value
- * evidence. `ArmingMode` is both the const value-object (`ArmingMode.home`) and the union type of its
+ * The guard modes `setMode` can SET — every mode a station reports, all nine confirmed against real
+ * hardware. `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)`.
  *
  * The domain of `setMode` (cmd 1224) alone. The alarm-delay write (cmd 1255) carries its own mode integer
- * on a separate wire and takes {@link AlarmDelayMode}.
+ * on a separate wire and takes {@link AlarmDelayMode}, which stays NARROWER — evidence for one command is
+ * not evidence for the other, and 1255 still has no capture beyond its byte-captured three.
  *
- * Deliberately NARROWER than the set a device may report. The remaining five 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.
+ * A mode belongs here only once its write is confirmed against real hardware, because a fire-and-forget
+ * wire makes a wrong mode look exactly like success; `ARMING_MODE_WIRE` carries the per-value evidence.
+ * The union is also what `ARMING_MODE_WIRE` is keyed by, so the table cannot name a mode this does not.
  */
 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";
+    /** Scheduled — the station follows the timetable configured in the app (wire value 2). */
+    readonly schedule: "schedule";
     /** Custom 1 — a user-defined posture configured in the app (wire value 3). */
     readonly custom1: "custom1";
+    /** Custom 2 — a user-defined posture configured in the app (wire value 4). */
+    readonly custom2: "custom2";
+    /** Custom 3 — a user-defined posture configured in the app (wire value 5). */
+    readonly custom3: "custom3";
+    /** Off — the station's alarm system is switched off entirely (wire value 6). */
+    readonly off: "off";
+    /** Geofenced — the station follows the app's location-based rules (wire value 47). */
+    readonly geo: "geo";
     /** Disarmed — no alarms; sensors still report state (wire value 63). */
     readonly disarmed: "disarmed";
 };
@@ -60,10 +68,14 @@ export declare const ARMING_CMD: {
      *
      * ⚠️ Only 3 of the 9 modes were exercised in that capture — `mode_type` 0 (away), 63 (disarmed), 1
      * (home), all confirmed byte-exact. Re-confirmed live 2026-08-05: each reported its own MODE_SWITCH push
-     * within ~5s of the write. `custom1` 3 joined {@link ArmingMode} on a live confirmation rather than a
-     * capture, making four settable in total. The remaining five 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.
+     * within ~5s of the write. The remaining six are live confirmations rather than captures — `custom1` 3
+     * first, then `schedule` 2, `custom2` 4, `custom3` 5, `off` 6 and `geo` 47 — each sent as this exact
+     * frame and each observed to bring MODE_SWITCH back, so all nine are settable. `ARMING_MODE_WIRE` has
+     * the per-value evidence and the dates.
+     *
+     * The ENCRYPTION LEVEL is the session's to pick (`"auto"`), not this command's: the T8030 the envelope
+     * was captured on holds a level-2 key and seals it level-2, while an own-session camera that never
+     * negotiates one carries the same envelope level-1. See `armingCommand`.
      */
     readonly SET_ARMING: 1224;
     /**
@@ -164,11 +176,10 @@ export type ArmingActions = Surface<typeof ARMING_MEMBERS>;
  */
 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 four whose write is confirmed. That
-     * argument IS the domain the derived setter enforces and the refusal names, so an unconfirmed mode is
-     * refused by naming the four that work — nine labels for the read and four for the write, off one
-     * declaration.
+     * Read and write are the same nine modes, so `enumValues` is the whole domain: `writeDomain` falls back
+     * to it, and the derived setter, the refusal message and the offered argument all read from that one
+     * declaration. A member states an `args` entry only where the two sides DIFFER. See
+     * {@link ARMING_MODE_WIRE} for the per-value evidence.
      *
      * `armingCommand` may also throw synchronously (missing account identity) and `bindMembers` turns that
      * into a rejection, so the builder stays plain.
@@ -188,11 +199,6 @@ export declare const ARMING_MEMBERS: {
         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";
@@ -221,9 +227,9 @@ export declare const ARMING_MEMBERS: {
     readonly setAlarmDelayConfig: import("./members.js").MethodMember<(mode: AlarmDelayMode, config: AlarmDelayConfig) => Promise<void>>;
 };
 /**
- * `arming` — guard/arming mode. `armingMode` (see {@link ARMING_CMD.SET_ARMING}) has a verified
- * read/write MECHANISM, but only 4 of the 9 modes it reports (away/home/custom1/disarmed, the
- * {@link ArmingMode} union) are confirmed as writes — see `ARMING_MODE_WIRE` for which 5 are still
- * unverified third-party integers, and which of the 4 is live-confirmed rather than byte-captured.
+ * `arming` — guard/arming mode. `armingMode` (see {@link ARMING_CMD.SET_ARMING}) has a verified read/write
+ * MECHANISM, and all 9 modes it reports are now confirmed as writes — the {@link ArmingMode} union is the
+ * whole set. See `ARMING_MODE_WIRE` for which three are byte-captured and which six are live-confirmed.
+ * The alarm-delay write (cmd 1255) is unaffected and keeps its narrower {@link AlarmDelayMode}.
  */
 export declare const ARMING: CapabilityModule;

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

@@ -90,8 +90,33 @@ export type BatteryActions = Surface<typeof BATTERY_MEMBERS>;
  * The richer raw `APP_CMD_SET_POWER_SOURCE` blob is a separate param, surfaced as `powerSourceInfo`.
  */
 declare function decodePowerSource(raw: string | number | boolean): number | string;
-/** False for a mains camera that only reports 1101 as a sentinel — used to gate the physical reads. */
-declare const notMainsCamera: (ctx: AvailabilityContext) => boolean;
+/**
+ * The params whose subject IS the physical cell — so every member reading one must carry
+ * {@link notMainsCamera}.
+ *
+ * The ONE place that fact is declared. {@link cellGated} applies {@link notMainsCamera} from this list
+ * when the table is built, so a member never states the gate itself: adding a cell read is adding its
+ * param here, and there is no second place for it to be missing from. A per-member `available` was the
+ * alternative and is what the first two passes of this guard got wrong, in both directions — first by
+ * covering two of the seven, then by reading `unexposed` as covering a third.
+ *
+ * What is NOT here matters as much.
+ *
+ *  - `workingMode` and the three `record*` settings describe how hard the camera works, not what powers
+ *    it, and a mains camera genuinely has them. They are the reason the capability stays attached.
+ *  - `cameraInfo` (1103) is a number whose meaning is unevidenced. Gating it would assert it is a
+ *    battery fact, which is the kind of claim this guard exists to stop making.
+ *  - `powerSource` (1293) is the open one. Both values it names — `Battery` and `External Solar Panel` —
+ *    describe how a CELL is fed, so by this list's own rule it arguably belongs here. It is out because
+ *    every param above is one a live mains camera was observed to publish and 1293 was not among them,
+ *    and because it is `requires`-gated on its own param, so it appears only where the device reports
+ *    it. Gating it would also withhold a described WRITE rather than a read, which is a different class
+ *    of change. Unresolved rather than decided: see the note in the pull request.
+ *
+ * The two solar params ARE here: a panel exists to charge a cell, so a device without one has no solar
+ * harvest to report either.
+ */
+export declare const CELL_PARAMS: readonly number[];
 /**
  * Every `battery` feature, declared once — the property schema, the evidence-gated getters, the derived
  * setters, the intent routes and the descriptions all come out of this table. Order is schema order.
@@ -117,7 +142,6 @@ export declare const BATTERY_MEMBERS: {
         readonly unit: "%";
         readonly kind: "percent";
         readonly provenance: "verified";
-        readonly available: typeof notMainsCamera;
         readonly description: "Battery level 0-100 (verified: param 1101).";
     };
     /**
@@ -130,7 +154,6 @@ export declare const BATTERY_MEMBERS: {
         readonly type: "bool";
         readonly kind: "boolean";
         readonly provenance: "apk";
-        readonly available: typeof notMainsCamera;
         readonly coerce: (v: string | number | boolean) => boolean;
         readonly description: string;
     };
@@ -300,6 +323,11 @@ export declare const BATTERY_MEMBERS: {
      * Reported, so it stays in the schema and answers through `getProperty` — but given no typed getter:
      * the payload's fields have never been decoded, and a getter would hand back an opaque blob typed as
      * though it meant something.
+     *
+     * `unexposed` is NOT a substitute for the cell gate. It suppresses the fluent GETTER; `propertiesOf`
+     * filters `writeOnly` and `available` and deliberately not `unexposed`, because a schema entry
+     * reachable through `getProperty` is the whole point of the mark. So a cell param needs
+     * {@link CELL_PARAMS} either way, or a mains camera publishes "battery power history" and answers it.
      */
     readonly batteryPowerStats: {
         readonly param: 3100;

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

@@ -106,6 +106,10 @@ export declare const CONTACT_MEMBERS: {
      * `1350` SET_PAYLOAD, `mChannel` = the device channel, `mValue3` 0, payload carrying the channel and a
      * transaction stamp — the byte-shape of the app's own captured frame. Out of range is refused rather
      * than clamped: the app's slider has no values outside it, so one is a caller error, not a nudge.
+     *
+     * Level-2 only, though the `mValue3` 0 would allow `"auto"`: an entry sensor's session IS its
+     * HomeBase's, which always holds a key — the second of `setPayload`'s two conditions, not an oversight
+     * of the first.
      */
     readonly alarmVolume: {
         readonly param: 1508;

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

@@ -14,8 +14,9 @@ export declare const DOORBELL_CMD: {
      */
     readonly QUICK_RESPONSE: 1706;
     /**
-     * Mechanical (wired) chime enable/disable — whether the doorbell drives an existing wired chime box
-     * (as opposed to / in addition to the wireless indoor chime, param 1702 `chimeSwitch` above). Same
+     * Mechanical (wired) chime enable/disable — whether the doorbell drives an existing wired chime box,
+     * the app's "existing doorbell chime" (as opposed to / in addition to the HomeBase acting as the chime,
+     * param 1702 `chimeSwitch` above; toggling each switch alone wrote one parameter and named the pair). Same
      * 136-byte direct-binary shape as `QUICK_RESPONSE`/camera on-off: `[u32 channel][u32 value][account_id
      * ASCII, zero-padded to 128 bytes]`, outer P2P cmd = 1703 itself, signCode 8, on the device's own
      * channel. Reversed from a live capture (outer-cmd 1703, signCode 8, captured on the doorbell's
@@ -24,6 +25,19 @@ export declare const DOORBELL_CMD: {
      * App `APP_CMD_BAT_DOORBELL_MECHANICAL_CHIME_SWITCH`.
      */
     readonly MECHANICAL_CHIME_SWITCH: 1703;
+    /**
+     * Whether the HOMEBASE acts as the doorbell's chime — the app's "HomeBase as chime" switch, as opposed
+     * to the wired chime box {@link DOORBELL_CMD.MECHANICAL_CHIME_SWITCH} drives. The app constant reads
+     * `CHIME_SWITCH`, which is why this was long described as a separate plug-in chime; toggling that one
+     * switch alone on a T8210 behind a HomeBase wrote 1702 and nothing else, and the account has no
+     * plug-in chime at all. Same 136-byte direct-binary shape as
+     * that sibling: `[u32 channel][u32 value][account_id ASCII, zero-padded to 128 bytes]`, outer P2P cmd
+     * 1702 itself, signCode 8, on the device's own channel. Reversed from a live capture (outer-cmd 1702,
+     * signCode 8, on the doorbell's `device_channel` — 2 for that unit, NOT a wire constant, always use
+     * `ctx.channel`): turning OFF sent `value=0`, turning ON sent `value=1` — a plain boolean.
+     * App `APP_CMD_BAT_DOORBELL_CHIME_SWITCH`.
+     */
+    readonly CHIME_SWITCH: 1702;
     /**
      * Wide Dynamic Range (WDR) image switch — a video/image tone-mapping setting that widens the
      * exposure range in high-contrast scenes (bright sky behind a visitor, etc). SAME 136-byte
@@ -158,13 +172,10 @@ export declare function parseQuickResponses(voiceList: Array<{
 /**
  * Every `doorbell` feature, declared once.
  *
- * Three of the seven reads are read-ONLY here even though the device accepts a write, because the write
+ * Two of the seven reads are read-ONLY here even though the device accepts a write, because the write
  * does not belong to this capability or is not confirmed:
  *  - `ringtoneVolume` (1708) — the WRITE lives on `audio`, which owns every volume wire. 1708 leaks
  *    onto non-doorbell cameras, so `audio` gates its setter on the doorbell capability instead.
- *  - `chimeSwitch` (1702) — READ confirmed on a T8214, the WRITE wire never captured. Its 1703/1704
- *    siblings share the param range but that is NOT evidence of a shared frame, and a wrong guess on a
- *    fire-and-forget P2P write looks exactly like success.
  *  - `notificationMode` (1710) — a config JSON the device reports whole; no write is captured.
  *
  * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
@@ -173,19 +184,18 @@ export declare function parseQuickResponses(voiceList: Array<{
  */
 export declare const DOORBELL_MEMBERS: {
     /**
-     * The WIRELESS indoor chime — the separate plug-in unit, not the wired chime box
-     * `mechanicalChimeSwitch` drives. `unverified: true` with no `write` at all: the read is confirmed but
-     * the write frame has never been captured, so the setter is absent from the surface (a compile-time
-     * signal) and the intent path throws rather than reporting the doorbell as lacking the feature.
-     * Sharing the 1702-1719 range with its captured siblings is not evidence of a shared frame shape.
+     * The HOMEBASE as the doorbell's chime — the hub plays the ring, not the wired chime box
+     * `mechanicalChimeSwitch` drives. `provenance` is "verified" on our own decrypt of the app's frame,
+     * not merely the param id observed live: direct-binary `[ch][value][acct]`, 1=on/0=off, the same shape
+     * as its 1703 sibling — captured, not inferred from the shared param range.
      */
     readonly chimeSwitch: {
         readonly param: 1702;
         readonly type: "bool";
         readonly kind: "boolean";
-        readonly provenance: "mega";
-        readonly unverified: true;
+        readonly provenance: "verified";
         readonly description: string;
+        readonly write: (v: string | number | boolean, ctx: import("./types.js").CommandContext) => import("../../core/contracts.js").Command;
     };
     /**
      * `provenance` is "verified" not "mega": the actual write wire is confirmed (
@@ -197,7 +207,7 @@ export declare const DOORBELL_MEMBERS: {
         readonly type: "bool";
         readonly kind: "boolean";
         readonly provenance: "verified";
-        readonly description: "Mechanical chime enabled (1703; confirmed on T8214).";
+        readonly description: string;
         readonly write: (v: string | number | boolean, ctx: import("./types.js").CommandContext) => import("../../core/contracts.js").Command;
     };
     /** Same reasoning and the same capture session as {@link DOORBELL_MEMBERS.mechanicalChimeSwitch}. */

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

@@ -54,6 +54,15 @@ export declare function getCapabilityModule(cap: Capability): CapabilityModule |
  * @internal
  */
 export declare const CAPABILITY_MODULES: Record<Capability, CapabilityModule>;
+/**
+ * Every param these capabilities declare before any gate — the set a device's schema is a subset of.
+ *
+ * A param in here that a device's schema does NOT carry is one a gate withheld: the capability resolved,
+ * and its member decided the read does not describe this device — a cell reading on a mains model, a mode
+ * a family does not carry. Read-aliases count, since a member reads them under its own name.
+ * @internal
+ */
+export declare function claimedParams(caps: Capability[]): Set<number>;
 /**
  * Merge the property schemas of several capabilities into one flat, de-duplicated list.
  *
@@ -75,10 +84,12 @@ export declare function mergeProperties(caps: Capability[], ctx?: AvailabilityCo
  *  - a `modelHints` regex matches the model/category/name haystack,
  *  - `codecs` includes `codec`,
  *  - `detect(rec, codec)` returns true.
- * Never throws. Returns a de-duplicated array.
+ *
+ * An absent `codec` belongs to no line, so only the line-agnostic capabilities can match — the truthful
+ * answer for a device outside the eufy families entirely. Never throws. Returns a de-duplicated array.
  * @internal
  */
-export declare function detectCapabilities(rec: CloudRecord, codec: Codec): Capability[];
+export declare function detectCapabilities(rec: CloudRecord, codec?: Codec): Capability[];
 /**
  * The baseline capabilities a codec grants every device of that family — derived from the modules
  * that declare the codec in their {@link import("./types").DetectionSpec} `codecs`. Each capability
@@ -470,7 +481,7 @@ export declare function buildActions(caps: readonly Capability[], deps: MemberDe
  * @internal
  */
 export declare function describeCapabilities(bound: Partial<DeviceActionMap>, ctx?: AvailabilityContext): CapabilityDescriptor[];
-export type { CommandContext, CapabilityActions, CapabilityStateReader, CapabilityModule, DetectionSpec, CapabilityFrame, CapabilityEvent, InboundSignal, EventMapping, ProductLine, ActionArgSpec, DecodedState, } from "./types.js";
+export type { CommandContext, CapabilityActions, CapabilityStateReader, CapabilityModule, DetectionSpec, CapabilityFrame, CapabilityEvent, InboundSignal, EventClaim, EventMapping, ProductLine, ActionArgSpec, DecodedState, } from "./types.js";
 /**
  * The value-kind vocabulary a read is annotated with, re-exported from the barrel that publishes the
  * read itself, so the union a member's `kind` is drawn from is reachable from the same import.

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

@@ -66,32 +66,34 @@ declare const overP2p: (ctx: AvailabilityContext) => boolean;
  */
 export declare const LOCK_MEMBERS: {
     /**
-     * The lock's own state, and the weakest thing in this table: 1200 is a `guessed` placeholder because
-     * the lock announces (un)locking as a pushed event rather than holding a param, so the evidence gate
-     * will normally leave this getter uninstalled and `lockState` is the real read. `writtenElsewhere`
-     * points at the `lock`/`unlock` methods — a single `write` cannot express two verbs that carry no
-     * value.
+     * The lock's own state, verified on param 6000: "4" = locked, "3" = unlocked.
+     * `writtenElsewhere` points at the `lock`/`unlock` methods — a single `write` cannot express two
+     * verbs that carry no value.
      */
     readonly locked: {
-        readonly param: 1200;
+        readonly param: 6000;
         readonly type: "bool";
         readonly kind: "boolean";
-        readonly provenance: "guessed";
+        readonly provenance: "verified";
         readonly writtenElsewhere: true;
-        readonly description: "Lock state, true=locked. UNVERIFIED: no stable state param to key off; placeholder id pending verification.";
+        readonly coerce: (raw: string | number | boolean) => boolean;
+        readonly description: "Lock state, true=locked (verified: param 6000, 4=locked, 3=unlocked).";
     };
     /**
-     * Cell charge as a percentage, on the same param 1101 every battery device reports. Named `battery`
+     * Cell charge as a percentage, on param 1101 or smart-lock param 6001. Named `battery`
      * within this capability rather than deferring to the `battery` capability: a lock resolves as a lock,
      * so the accessor is `dev.lock().battery`.
      */
     readonly battery: {
         readonly param: 1101;
+        readonly readAliases: readonly [{
+            readonly paramType: 6001;
+        }];
         readonly type: "number";
         readonly unit: "%";
         readonly kind: "percent";
         readonly provenance: "verified";
-        readonly description: "Lock battery level 0-100 (verified: param 1101).";
+        readonly description: "Lock battery level 0-100 (verified: param 1101, alias 6001).";
     };
     /**
      * Link quality in dBm as the lock measures it, on the shared param 1141. Both actuation methods here
@@ -235,8 +237,9 @@ export declare const LOCK_MEMBERS: {
     };
 };
 /**
- * `lock` — smart lock. `locked` is the reported lock state, but there's no stable state param to
- * key off (only pushed via a CommandType-style event), so the param id here is a placeholder.
+ * `lock` — smart lock. `locked` reports lock state via verified param 6000 (4=locked, 3=unlocked);
+ * a device that reports no stable state param carries its transitions on the `lockState` event instead,
+ * whose payload names the decoded `locked`.
  */
 export declare const LOCK: CapabilityModule;
 export {};

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

@@ -199,8 +199,12 @@ export declare function savePresetCommand(id: number, ctx: CommandContext): [Com
  *
  * 6242 sets the default to the preset the camera is **currently parked on**. To move the default, park
  * the camera on `presetId` first — `preview(presetId)`, let the pan finish, then `setDefault(presetId)`.
- * Sent while the camera is elsewhere, it has no effect. The parser is topology-agnostic; the router
- * picks the encryption level (L1/L2) by topology.
+ * Sent while the camera is elsewhere, it has no effect.
+ *
+ * Level-2 only, unlike `zoom` beside it: this frame carries the envelope's DEFAULT `mValue3` (the
+ * sub-command), which the level-1 form cannot express — it writes 0. Downgrading it would send an
+ * object nothing has captured, so it stays pinned and is unreachable on a keyless standalone camera
+ * until one is. See `setPayload`'s two conditions.
  */
 export declare function setDefaultPositionCommand(presetId: number, ctx: CommandContext): Command;
 /**

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

@@ -0,0 +1,173 @@
+/**
+ * Anker **Solix** capability surface. Solix is a separate ecosystem — its own Anker account, backend
+ * and product catalog — so it keeps its own capability id union rather than joining eufy's `Capability`
+ * / `Codec` unions, and detection is by Anker catalog CATEGORY + product-code prefix (see
+ * {@link detectSolixCapabilities}) rather than eufy param ids.
+ *
+ * What it shares is the `members` engine: the one feature with a readable wire declares ONE `members`
+ * table, and its property schema, evidence gate and typed surface all derive from it through
+ * `members.ts` (`bindMembers` / `Surface`), exactly as a eufy capability does.
+ *
+ * @module model/capabilities/solix
+ */
+import type { Surface } from "./members.js";
+/** Every capability a Solix device may carry. Solix's OWN union (not eufy's `Capability`). */
+export type SolixCapability = "identity" | "firmware" | "connectivity" | "energyMeter" | "battery" | "solarInput" | "acOutput" | "evCharger" | "charger" | "cooler";
+/**
+ * The `energyMeter` surface — the electrical readings the vendor app names, as typed members. Each is
+ * read-only and evidence-gated: `bindMembers` installs a getter only once a frame that REPORTS that tag
+ * has landed, and answers `undefined` (not a fabricated `0`) before any has. The gate is "reported", not
+ * "non-zero": a single-phase / single-CT meter still reports its L2/L3 slots as `0.0`, so those members
+ * install and read `0` rather than staying absent — a caller sees `0` for an idle phase, not `undefined`.
+ *
+ * Provenance splits by what the evidence actually pins. The app's field VOCABULARY (these twelve names)
+ * is authoritative. For the tag→field binding, a live single-phase frame confirmed the L1 and total
+ * magnitudes (a nominal mains voltage, an equal line/total power pair, the line current), so those four
+ * positions are `verified`. The L2/L3 tags are never non-zero on a single-CT install and the app itself
+ * receives the meter as named JSON — there is no tag→phase decoder in the app binary — so their phase
+ * assignment is inferred from the block ordering and is marked `guessed`, not `apk`. The energy counters (`meterImportEnergy`/`meterExportEnergy`) are named
+ * on the wire but are NOT members here: their tag→name is confirmed, but their unit SCALE is not (a live
+ * reading is consistent with either Wh or kWh), so they stay raw named values via
+ * {@link SOLIX_METER_FIELD_NAMES} until a capture pins the scale, rather than ship a member with a guessed unit.
+ *
+ * @internal — the declaration `SolixEnergyMeterReads` derives from; exported (like the eufy `*_MEMBERS`
+ * tables) so it is a known symbol, but excluded from the rendered API reference.
+ */
+export declare const SOLIX_ENERGY_METER_MEMBERS: {
+    /** Line-1 voltage (V), ff09 tag `0xAC` — confirmed live (a nominal mains voltage). */
+    readonly meterVoltageL1: {
+        readonly param: 172;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "V";
+        readonly provenance: "verified";
+        readonly description: "Meter line-1 voltage (V) — ff09 tag 0xAC, confirmed against a live single-phase frame.";
+    };
+    /** Line-2 voltage (V), ff09 tag `0xAD` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterVoltageL2: {
+        readonly param: 173;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "V";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-2 voltage (V) — ff09 tag 0xAD; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Line-3 voltage (V), ff09 tag `0xAE` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterVoltageL3: {
+        readonly param: 174;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "V";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-3 voltage (V) — ff09 tag 0xAE; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Line-1 current (A), ff09 tag `0xAF` — confirmed live (the line's CT current). */
+    readonly meterCurrentL1: {
+        readonly param: 175;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "A";
+        readonly provenance: "verified";
+        readonly description: "Meter line-1 current (A) — ff09 tag 0xAF, confirmed against a live single-phase frame.";
+    };
+    /** Line-2 current (A), ff09 tag `0xB0` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterCurrentL2: {
+        readonly param: 176;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "A";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-2 current (A) — ff09 tag 0xB0; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Line-3 current (A), ff09 tag `0xB1` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterCurrentL3: {
+        readonly param: 177;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "A";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-3 current (A) — ff09 tag 0xB1; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Line-1 active power (W), ff09 tag `0xA8` — confirmed live; negative on export. */
+    readonly meterPowerL1: {
+        readonly param: 168;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "W";
+        readonly provenance: "verified";
+        readonly description: "Meter line-1 active power (W) — ff09 tag 0xA8, confirmed live; negative on export.";
+    };
+    /** Line-2 active power (W), ff09 tag `0xA9` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterPowerL2: {
+        readonly param: 169;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "W";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-2 active power (W) — ff09 tag 0xA9; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Line-3 active power (W), ff09 tag `0xAA` — the app's field; reads 0 until a multi-phase frame carries it. */
+    readonly meterPowerL3: {
+        readonly param: 170;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "W";
+        readonly provenance: "guessed";
+        readonly description: "Meter line-3 active power (W) — ff09 tag 0xAA; phase assignment inferred from block ordering (never observed non-zero), 0 on a single-phase install.";
+    };
+    /** Aggregate active power (W), ff09 tag `0xAB` — confirmed live; equals line-1 on a single phase. */
+    readonly meterPowerTotal: {
+        readonly param: 171;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly unit: "W";
+        readonly provenance: "verified";
+        readonly description: "Meter total active power (W) — ff09 tag 0xAB, confirmed live; equals L1 on one phase.";
+    };
+};
+/** Bound `energyMeter` reads (the members-derived half of `dev.energyMeter()`). Read-only. */
+export type SolixEnergyMeterReads = Surface<typeof SOLIX_ENERGY_METER_MEMBERS>;
+/**
+ * The capabilities each Anker catalog category implies. Category is a detection SIGNAL (like eufy's
+ * `deviceTypes`), not the model's identity — a device still resolves `energyMeter` from its product code
+ * even though its category is "Accessory", which is why that category maps to nothing on its own.
+ * Unlisted categories contribute nothing here.
+ */
+export declare const CATEGORY_CAPABILITIES: Readonly<Record<string, readonly SolixCapability[]>>;
+/**
+ * Product-code prefixes known to be grid/energy meters (detects `energyMeter` regardless of category).
+ * Keep in lockstep with `SOLIX_METER_PRODUCT_PREFIXES` in `transport/mqtt/solix-mqtt.ts` (the same meter
+ * prefixes, transport-side, that gate the tag→name table): a prefix added here but not there grants
+ * `energyMeter` to a device whose frames the decoder then refuses to name. Add a meter prefix to both.
+ */
+export declare const SOLIX_METER_MODELS: readonly string[];
+/**
+ * Product-code prefixes for the grid-tie Solarbank / home-battery family (detects `battery` +
+ * `solarInput` regardless of category, so a caller that builds a device without the catalog still gets
+ * them): `A1790` = Solarbank E1600 gen-1, `A17C*` = Solarbank 2 / 3, `AE10*` = Solarbank 4 E5000 Pro /
+ * SOLIX Power Dock.
+ *
+ * Grounded in the live `product_categories` catalog: `A17C0`–`A17C5` and `AE100` all list under
+ * category `"Plug-in Home Battery "`, and `AE103` by the device spec. `AE1X0`/`AE1R0` meters start
+ * `AE1X`/`AE1R`, so `AE10` does not catch them.
+ *
+ * The speculative `A17E` ("Solarbank Max AC") and `AE11` ("Solarbank Max") were dropped: neither is in
+ * the catalog, and the only `AE11x` product there — `AE113` "XE 6/8kW" — is a Residential Storage
+ * System, a different family whose telemetry is unverified, so granting it `battery`/`solarInput` would
+ * be an unevidenced false positive (exactly what this detection is otherwise careful to avoid).
+ */
+export declare const SOLARBANK_MODELS: readonly string[];
+/** The minimum device shape {@link detectSolixCapabilities} reads. */
+export interface SolixDetectionInput {
+    product_code: string;
+    device_sw_version?: string;
+    wifi_online?: boolean;
+    wifi_name?: string;
+    rssi?: string | number;
+}
+/**
+ * Resolve a Solix device's capability set from its record fields, catalog category, and product-code
+ * prefix — the Solix analogue of eufy's `detectCapabilities`, kept Solix-scoped so eufy detection is
+ * untouched. `identity` is universal; the rest are OR-ed evidence.
+ */
+export declare function detectSolixCapabilities(rec: SolixDetectionInput, category?: string): Set<SolixCapability>;