@mega-yfue/eufy-sdk 0.2.0-beta.2 → 0.2.0-beta.21

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/display.d.ts

@@ -0,0 +1,85 @@
+import type { CapabilityModule } from "./types.js";
+import { type Surface } from "./members.js";
+/**
+ * `display` — a eufy Smart Display's charge.
+ *
+ * One typed read, and the smallness is the finding rather than a gap. The captured unit (a T87A0,
+ * 2026-09-04) connects over secure MQTT with no `p2p_did`, so it speaks no P2P at all, and it reported
+ * six params in an id range no other line uses. Only one of them tells a caller something it could not
+ * get another way:
+ *
+ *  - 8005 and 8006 restate the model's retail name and code, which `info` already answers from the
+ *    curated registry and the cloud record. Their evidence IS that agreement, so a getter beside `info`
+ *    would offer a caller a second spelling of what it just read. They are named in the display param
+ *    dictionary, which is what makes them readable off `getProperties()`.
+ *  - 8003 is version-shaped and nothing confirms what it means, so it is `unexposed`: in the schema with
+ *    its type and its `guessed` label, reachable through `getProperty`, no typed getter.
+ *
+ * Nothing is writable. No capture pins a write for any display param, and an AIoT write is
+ * fire-and-forget, so a wrong frame to a device that acknowledges nothing looks exactly like success. A
+ * screen, a volume, an assistant: the device plainly has all three and reports none of them in anything
+ * captured, which means the reads have to arrive before a control can be honest about what it moves.
+ *
+ * @module model/capabilities/display
+ */
+/** Smart Display param ids this capability reads. The rest of the range is named in the dictionary. */
+export declare const DISPLAY_PARAM: {
+    readonly BATTERY: 8001;
+    readonly SOFTWARE_VERSION: 8003;
+};
+/**
+ * The `display` reads. Read-only; see the module note for why there is no write.
+ *
+ * Exported but NOT published: the entries state their wire ids and what each claim rests on, which the
+ * reference site does not carry.
+ * @internal
+ */
+export declare const DISPLAY_MEMBERS: {
+    /**
+     * Battery level, 0-100.
+     *
+     * **On this capability rather than on `battery`, and that is the line partition doing its job.** The
+     * security-line `battery` capability reads param 1101 and a Smart Display's charge is 8001 in its own
+     * id space — two wires that happen to mean the same thing. One capability reading both would be a claim
+     * that the two ecosystems share a param space, so a consumer reads a display's charge through
+     * `dev.display()` and a camera's through `dev.battery()`.
+     *
+     * `verified` rather than `mega`: the id is in the device's cloud record, but the NAME came from the
+     * maintainer's own knowledge of the hardware rather than from the cloud data-point list, and `"100"`
+     * fits brightness, volume or charge equally.
+     *
+     * The scale is `percent` on the reading itself, not on convention alone: a full charge reads `255` on a
+     * 0-255 scale and `1000` on a 0-1000 one, so `"100"` on a charged unit is positive evidence for 0-100
+     * rather than merely consistent with it. What nobody has done is watch it MOVE, which is why a value
+     * frozen at 100 would not yet be distinguishable from a healthy one.
+     */
+    readonly battery: {
+        readonly param: 8001;
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly provenance: "verified";
+        readonly description: "Battery level, 0-100 (param 8001).";
+    };
+    /**
+     * Version-shaped, and that shape is the whole of the evidence — hence `guessed`, and hence no typed
+     * getter: a caller reading this off a bound object cannot see the label.
+     *
+     * `unexposed` rather than absent, so the schema still carries its type and that label and
+     * `getProperty("softwareVersion")` still answers. `dev.info()?.firmwareVersion` is the field to trust
+     * where the cloud record carries one; on this display it does not, which is the only reason 8003 is
+     * named at all.
+     */
+    readonly softwareVersion: {
+        readonly param: 8003;
+        readonly type: "string";
+        readonly kind: "text";
+        readonly provenance: "guessed";
+        readonly unexposed: true;
+        readonly description: "Version-shaped string (param 8003), meaning unconfirmed — prefer `info.firmwareVersion`.";
+    };
+};
+/** `display` — a eufy Smart Display (T87Ax). Read-only; no display write is captured. */
+export declare const DISPLAY: CapabilityModule;
+/** Bound Smart Display reads — the object returned by `dev.display()`. Read-only. */
+export type DisplayActions = Surface<typeof DISPLAY_MEMBERS>;

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

@@ -40,6 +40,7 @@ import type { KeypadActions } from "./keypad.js";
 import type { RtspActions } from "./rtsp.js";
 import type { VacuumCleanActions } from "./vacuum-clean.js";
 import type { VacuumDockActions } from "./vacuum-dock.js";
+import type { DisplayActions } from "./display.js";
 import type { SuctionActions } from "./suction.js";
 import type { LocateActions } from "./locate.js";
 import type { DeviceInfo } from "./info.js";
@@ -53,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.
  *
@@ -74,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
@@ -411,6 +423,8 @@ export interface DeviceActionMap {
     suction: SuctionActions;
     /** RoboVac locate (find-robot beep): `locating`; `locate(on?)`. */
     locate: LocateActions;
+    /** Smart Display (read-only): `battery`. No display write is captured. */
+    display: DisplayActions;
     /** Identity metadata (read-only): `{ manufacturer, model, serialNumber, name, deviceType?, firmwareVersion?, hardwareVersion? }`. */
     info: DeviceInfo;
 }
@@ -529,6 +543,7 @@ export { RTSP_MEMBERS } from "./rtsp.js";
 export { SIREN_MEMBERS } from "./siren.js";
 export { SMART_LIGHT_MEMBERS } from "./smart-light.js";
 export { SMOKE_MEMBERS } from "./smoke.js";
+export { DISPLAY_MEMBERS, type DisplayActions } from "./display.js";
 export { SUCTION_MEMBERS } from "./suction.js";
 export { VACUUM_CLEAN_MEMBERS } from "./vacuum-clean.js";
 export type { DeviceInfo } from "./info.js";
@@ -550,7 +565,7 @@ export { HubAlarmTone, type HubAlarmToneValue } from "./siren.js";
  * RoboVac activity and clean type are the declared returns of the public `dev.vacuumClean()` getters,
  * so both unions are published.
  */
-export type { VacuumActivity, VacuumCleanType, CarpetStrategy, CleanExtent } from "./vacuum-clean.js";
+export type { VacuumActivity, VacuumCleanType, CarpetStrategy, CleanExtent, VacuumRoomTarget, VacuumZoneTarget, } from "./vacuum-clean.js";
 /** The lists those unions are taken from — published because each union names its own. */
 export { VACUUM_ACTIVITIES, VACUUM_CLEAN_TYPES, CARPET_STRATEGIES, CLEAN_EXTENTS, MOP_LEVELS } from "./vacuum-clean.js";
 export { SuctionLevel, suctionLevelName, type SuctionLevelValue } from "./suction.js";

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>;

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

@@ -41,12 +41,19 @@ export interface DetectionSpec {
  *
  * eufy ships several ecosystems that share a cloud account and nothing else: `security` (cameras,
  * stations, locks, sensors — P2P plus the security-scoped broker), `life` (the T8L0x smart-lighting
- * line — its own credential and its own DP wire), and `clean` (robot vacuums — Tuya data points).
+ * line — its own credential and its own DP wire), `clean` (robot vacuums — Tuya data points) and
+ * `display` (the T87Ax Smart Display — secure MQTT, never P2P, its own 8001-8006 param space).
  * They overlap in retail vocabulary but share no wire, no param space and no semantics.
  *
+ * `display` is a line of its own for the second of those reasons rather than the first: without it,
+ * every security capability detected by a NAME regex is attachable to a Smart Display — measured at six,
+ * on a device that can answer for none of them because it speaks no P2P at all. A line holding one
+ * capability still buys that, which is why the count is not the measure of whether a line is worth
+ * declaring.
+ *
  * `any` is for the handful of capabilities that are genuinely line-independent (device identity).
  */
-export type ProductLine = "security" | "life" | "clean" | "print" | "any";
+export type ProductLine = "security" | "life" | "clean" | "print" | "display" | "any";
 /**
  * A structural subset of a P2P frame. Deliberately NOT `import`ed from `p2p/*` — keeping it
  * structural avoids a model→p2p cycle, and the real `P2PFrame` is assignable to it. It is the
@@ -162,8 +169,13 @@ export interface DecodedState {
  * the manifest path and the command path.
  */
 export interface AvailabilityContext {
-    /** Resolved codec/family. */
-    codec: Codec;
+    /**
+     * Resolved codec/family. Absent for a device outside the eufy device model entirely — the codecs are
+     * the eufy transport families, so an ecosystem with its own backend has no truthful value here and
+     * says so by omission rather than borrowing another family's. Every gate that reads it compares
+     * against a specific codec, so an absent one matches none.
+     */
+    codec?: Codec;
     /** eufy DeviceType, when known. */
     deviceType?: number;
     /** Model / T-code, when known. */
@@ -235,7 +247,11 @@ export interface CommandContext extends AvailabilityContext {
     adminUserId?: string;
     /** The acting member's short id (`member.short_user_id`, hex, e.g. `"0003"`) — the lock cmd `A5` field. */
     shortUserId?: string;
-    /** The logged-in account's display name (email local-part) — the lock cmd acting-username `A4` field. */
+    /**
+     * The acting name a command attributes itself to — the lock cmd acting-username `A4` field, and the
+     * `user_name` of the guard-mode and HomeBase-alarm writes. The logged-in account's display name
+     * (email local-part) unless the client pins a different label for it.
+     */
     accountName?: string;
     /**
      * Whether the device has a usable P2P endpoint (a non-empty `p2p_did`). A HomeBase-attached lock