@mega-yfue/eufy-sdk 0.2.0-beta.1 → 0.2.0-beta.11

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

@@ -2,25 +2,58 @@ 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
+ * 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)`.
  *
- * 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.
+ * 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}, which stays NARROWER — evidence for one command is
+ * not evidence for the other, and 1255 still has no capture beyond its byte-captured three.
+ *
+ * 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";
 };
 export type ArmingMode = (typeof ArmingMode)[keyof typeof ArmingMode];
+/**
+ * The modes the alarm-delay write (cmd 1255) accepts a `mode_id` for — the three guard modes whose wire
+ * integer is byte-captured.
+ *
+ * A domain of its own, because the two mode integers ride different commands: `setMode` writes `mode_type`
+ * on cmd 1224, and cmd 1255 carries `mode_id`. Neither wire validates the integer, so each union IS its
+ * command's gate, and evidence for one is not evidence for the other. `custom1` is confirmed on 1224 only;
+ * 1255 has no capture carrying mode 3, and no known GET to read one back — the app's own replies
+ * `{count:0,data:null}` — so it is absent here. Narrower than {@link ArmingMode} by exactly that value.
+ */
+export declare const AlarmDelayMode: {
+    /** 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 AlarmDelayMode = (typeof AlarmDelayMode)[keyof typeof AlarmDelayMode];
 /**
  * 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
@@ -34,10 +67,11 @@ export declare const ARMING_CMD: {
      * 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.
+     * (home), all confirmed byte-exact. Re-confirmed live 2026-08-05: each reported its own MODE_SWITCH push
+     * 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.
      */
     readonly SET_ARMING: 1224;
     /**
@@ -138,11 +172,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 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.
+     * 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.
@@ -162,11 +195,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";
@@ -187,15 +215,17 @@ export declare const ARMING_MEMBERS: {
      * 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.
+     * Takes {@link AlarmDelayMode}, not {@link ArmingMode}: a delay is configurable only for a mode whose
+     * integer is captured on THIS command, and `custom1` is confirmed on cmd 1224 only. The frame carries
+     * that integer in `mode_id` with no runtime validation and no readback, so a mode outside this union
+     * would be the same unverified guess `setMode` refuses.
      */
-    readonly setAlarmDelayConfig: import("./members.js").MethodMember<(mode: ArmingMode, config: AlarmDelayConfig) => Promise<void>>;
+    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 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.
+ * `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/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";
@@ -74,10 +75,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
@@ -385,7 +388,7 @@ export interface DeviceActionMap {
     lock: LockActions;
     /** Siren: reads `active`, `volume`, `alarmDuration`, `doNotDisturb`; writes `setVolume`, `setAlarmDuration`, `test`, `stop` (config setters present when the param is reported). No direct "sound the alarm" wire — a real alarm is driven by the `arming` system; `test` is the on-demand trigger. */
     siren: SirenActions;
-    /** Guard mode: `setMode(ArmingMode)` + `setAlarmDelayConfig(mode, config)`. Of the 8 `ArmingMode` values only `away`/`home`/`disarmed` are confirmed on-device. */
+    /** Guard mode: `setMode(ArmingMode)` + `setAlarmDelayConfig(mode, config)`. Of the 9 modes a station reports, only `away`/`home`/`custom1`/`disarmed` are confirmed as writes (`ArmingMode`); the alarm-delay write takes the narrower byte-captured `AlarmDelayMode`. */
     arming: ArmingActions;
     /** Doorbell: `playQuickResponse(voiceId)` (the canned voice replies). */
     doorbell: DoorbellActions;
@@ -411,6 +414,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 +534,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,12 +556,12 @@ 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";
 export type { PtzPresetActions, ZoomRegion, PtzPreset, PtzPresetImage } from "./ptz.js";
-export { ArmingMode } from "./arming.js";
+export { AlarmDelayMode, ArmingMode } from "./arming.js";
 export type { AlarmDelayConfig, AlarmDelayCountdown, AlarmDelayDeviceAction, AlarmDelaySeconds } from "./arming.js";
 export { PtzDirection } from "./ptz.js";
 export { AiDetectType, encodeAiDetectType, decodeAiDetectType, type AiDetectFlags } from "./motion.js";

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

@@ -0,0 +1,75 @@
+/**
+ * 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, declared once. Only the ONE confirmed tag→name binding is a member:
+ * `meterVoltageL1` (ff09 tag `0xAC`), confirmed against a live single-phase frame. The evidence gate
+ * (`bindMembers`) installs its getter only once a frame carrying tag `0xAC` has landed and answers
+ * `undefined` before.
+ *
+ * The meter reports many more quantities (per-line power/current/voltage, totals, import/export energy),
+ * but their tag→name bindings are a structural inference not yet pinned to a known-load capture. Rather
+ * than assert a name that could mislabel a live float, those stay reachable raw as `channel_<hex>` from
+ * the device's telemetry (a static members table cannot enumerate dynamic hex tags); each is promoted to
+ * a member here, one line, as a capture confirms its binding.
+ *
+ * @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` — the ONE confirmed meter binding, matched against a live
+     * single-phase frame (a nominal mains voltage). Read-only; the evidence gate installs its getter only
+     * once a frame carrying `0xAC` has landed, so it is absent (not a fabricated `0`) until then.
+     */
+    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.";
+    };
+};
+/** 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). */
+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): A1790 = Solarbank E1600 gen-1, A17C* = Solarbank 2 / 3.
+ */
+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. */

package/dist/model/capabilities/vacuum-clean.d.ts

@@ -192,35 +192,27 @@ export declare const ModeCtrlMethod: {
     readonly STOP_SMART_FOLLOW: 18;
     readonly START_GLOBAL_CRUISE: 20;
 };
-/**
- * The methods that carry a `Param` oneof — room, zone, goto, schedule, cruise and scene cleans.
- *
- * Deliberately absent from {@link ModeCtrlMethod}. Each needs an argument the caller has to supply and
- * this SDK cannot yet answer: a room or zone id comes from map data, which is not decodable here, and a
- * coordinate is signed centimetres in a frame no capture has pinned. Listing their numbers beside the
- * parameterless ones would invite a caller to send one with an empty payload, which is a valid frame
- * meaning something nobody intended.
- */
-/**
- * Encode a `ModeCtrlRequest` protobuf (DP 152) as a DP value: `varint(bodyLen) ++ {method:1, seq:2}`.
- *
- * Built on {@link RawDpWriter} rather than hand-rolled bytes. The frame is unchanged and the existing
- * byte-level test is what proves it — that test was written against a live T2351 capture, so it holds
- * the writer to the wire rather than to this function's own idea of the wire.
- *
- * Method 0 (START_AUTO_CLEAN) is omitted rather than written as an explicit zero, per the proto3
- * default-field rule and confirmed on that same capture. The writer deliberately does not apply that
- * rule itself: whether an explicit zero and an absent field mean the same thing is the
- * message's business, not the encoder's.
- * @internal
- */
 /**
  * The area-selecting `ModeCtrlRequest` methods, and the `Param` field each one's payload rides in.
  *
  * Kept apart from {@link ModeCtrlMethod} because these are a different kind of thing: a parameterless
  * verb is complete on its own, whereas each of these is meaningless without an argument the caller has
  * to supply. Sending one with an empty payload is a well-formed frame that means something nobody
- * intended, which is exactly why the numbers do not sit beside the others.
+ * intended, which is exactly why the numbers do not sit beside the others. Each verb built on one takes
+ * its argument in the signature: {@link VACUUM_CLEAN_MEMBERS.startScene},
+ * {@link VACUUM_CLEAN_MEMBERS.cleanRooms} and {@link VACUUM_CLEAN_MEMBERS.cleanZones}.
+ *
+ * The outer frame these ride in is byte-verified on a live T2351, and `SCENE`, `SELECT_ROOMS` and
+ * `SELECT_ZONES` have each since been RUN on a T2351 and did what they name — so their numbers rest on
+ * observed behaviour rather than on the vendor's definition alone.
+ *
+ * That distinction is the whole point of checking, and this is the one place it is argued: an AIoT
+ * data-point write is fire-and-forget, so a wrong number would be a different command arriving and
+ * looking exactly like success, which no frame check could catch. Watching the number is the only thing
+ * that rules it out.
+ *
+ * `GOTO` carries no encoder because a goto point is a coordinate no read on this SDK supplies, where a
+ * scene id and a map id both arrive on DP 180.
  */
 export declare const ModeCtrlParamMethod: {
     /** `START_SELECT_ROOMS_CLEAN` — clean the named rooms of a named map. */
@@ -267,7 +259,7 @@ export interface VacuumZoneTarget {
  * `mapId` is required and has no default, deliberately. The obvious shortcut is to assume the map a
  * single-floor home would have; on a two-floor home that silently sends the robot's ids against the
  * wrong floor's map. A caller that cannot name the map cannot safely make this call, and saying so is
- * better than picking for them.
+ * better than picking for them. {@link VACUUM_CLEAN_MEMBERS.cleanRooms} dispatches this.
  * @internal
  */
 export declare function encodeSelectRoomsClean(mapId: number, rooms: readonly VacuumRoomTarget[], cleanTimes?: number): string;
@@ -276,8 +268,25 @@ export declare function encodeSelectRoomsClean(mapId: number, rooms: readonly Va
  * @internal
  */
 export declare function encodeSelectZonesClean(mapId: number, zones: readonly VacuumZoneTarget[]): string;
-/** Build a scene clean, which needs only the scene's own id. @internal */
+/**
+ * Build a scene clean, which needs only the scene's own id — `VacuumScene.id`, as DP 180 reports it.
+ * {@link VACUUM_CLEAN_MEMBERS.startScene} dispatches this.
+ * @internal
+ */
 export declare function encodeSceneClean(sceneId: number): string;
+/**
+ * Encode a `ModeCtrlRequest` protobuf (DP 152) as a DP value: `varint(bodyLen) ++ {method:1, seq:2}`.
+ *
+ * Built on {@link RawDpWriter} rather than hand-rolled bytes. The frame is unchanged and the existing
+ * byte-level test is what proves it — that test was written against a live T2351 capture, so it holds
+ * the writer to the wire rather than to this function's own idea of the wire.
+ *
+ * Method 0 (START_AUTO_CLEAN) is omitted rather than written as an explicit zero, per the proto3
+ * default-field rule and confirmed on that same capture. The writer deliberately does not apply that
+ * rule itself: whether an explicit zero and an absent field mean the same thing is the
+ * message's business, not the encoder's.
+ * @internal
+ */
 export declare function encodeModeCtrl(method: number, seq: number): string;
 /**
  * Every value {@link VacuumActivity} can take, as data — the read's declared domain, so the schema a
@@ -1941,6 +1950,46 @@ export declare const VACUUM_CLEAN_MEMBERS: {
     readonly pauseCleaning: import("./members.js").MethodMember<() => Promise<void>> & {
         available: (ctx: import("./types.js").CommandContext) => boolean;
     };
+    /**
+     * Run a saved cleaning scene by its id (ModeCtrlRequest method 24 over DP 152).
+     *
+     * The id is the device's own, as {@link VACUUM_CLEAN_MEMBERS.scenes} reports it — `VacuumScene.id`
+     * off the `SceneResponse` on DP 180. A scene the device reports invalid stays reportable and running
+     * it is still a well-formed request; `VacuumScene.invalidReason` says why the device will refuse.
+     *
+     * Frame shape is byte-proven against the shared outer `ModeCtrlRequest`, and method 24 has been
+     * WATCHED: run on a T2351, it started the named scene.
+     */
+    readonly startScene: import("./members.js").MethodMember<(sceneId: number) => Promise<void>> & {
+        available: (ctx: import("./types.js").CommandContext) => boolean;
+    };
+    /**
+     * Clean the named rooms of a named map (ModeCtrlRequest method 1 over DP 152).
+     *
+     * `mapId` has no default and that is deliberate: room ids are per map, so assuming the map a
+     * single-floor home would have sends a two-floor home's ids against the wrong floor. `SceneInfo.mapid`
+     * on DP 180 and a scheduled rooms-clean's `map_id` are the two real map ids the device reports.
+     *
+     * `cleanTimes` is how many passes to make over the set; rooms with no `order` are visited in the
+     * order given.
+     *
+     * Frame shape is byte-proven against the shared outer `ModeCtrlRequest`, and method 1 has been
+     * WATCHED: run on a T2351, it cleaned the rooms named.
+     */
+    readonly cleanRooms: import("./members.js").MethodMember<(mapId: number, rooms: readonly VacuumRoomTarget[], cleanTimes?: number) => Promise<void>> & {
+        available: (ctx: import("./types.js").CommandContext) => boolean;
+    };
+    /**
+     * Clean the given rectangles of a named map (ModeCtrlRequest method 2 over DP 152).
+     *
+     * Corners are SIGNED centimetres in the map's own frame, whose origin sits wherever the robot first
+     * mapped from — negative coordinates are ordinary and are ZigZag-encoded, not written as plain
+     * varints. Same `mapId` reasoning as {@link VACUUM_CLEAN_MEMBERS.cleanRooms}, and the same evidence:
+     * method 2 was run on a T2351 and cleaned the rectangles given.
+     */
+    readonly cleanZones: import("./members.js").MethodMember<(mapId: number, zones: readonly VacuumZoneTarget[]) => Promise<void>> & {
+        available: (ctx: import("./types.js").CommandContext) => boolean;
+    };
 };
 /** `vacuum_clean` — core RoboVac scalar state + decoded activity: power, activity, volume, battery. */
 export declare const VACUUM_CLEAN: CapabilityModule;

package/dist/model/index.d.ts

@@ -30,3 +30,6 @@ export * from "./capabilities/index.js";
  */
 export type { FamilyContext } from "./device-family.js";
 export { CusPushEvent, CusPushAlarmType, CusPushMode, DoorbellPushEvent, IndoorPushEvent, HB3PairedDevicePushEvent, LockPushEvent, SmartDropPushEvent, NotificationStyle, detectionName, } from "./push-events.js";
+export { SolixDevice, discoverSolixDevices, type SolixDeviceReader, type SolixDeviceRecord, type SolixIdentity, type SolixConnectivity, type SolixEnergyMeter, type SolixDeviceOptions, } from "./solix-device.js";
+export { SOLIX_ENERGY_METER_MEMBERS, type SolixCapability, type SolixEnergyMeterReads } from "./capabilities/solix.js";
+export { buildModelIndex, type SolixProduct, type SolixProductCategory } from "./solix-catalog.js";

package/dist/model/param-dictionary.d.ts

@@ -26,3 +26,27 @@ export interface ParamDef {
 export declare const SECURITY_PARAMS: Record<number, ParamDef>;
 /** RoboVac Tuya DP space (ids ~150-180), from get_product_data_point. */
 export declare const CLEAN_PARAMS: Record<number, ParamDef>;
+/**
+ * eufy Smart Display (T87Ax) param space — ids 8001-8006.
+ *
+ * Its own table rather than a corner of {@link SECURITY_PARAMS}: nothing in the 8000s carries a security
+ * meaning, so reading these ids there would decode a future security param assigned in this range as
+ * whatever it means on a camera.
+ *
+ * Every id here was reported by a live T87A0 (captured 2026-09-04). That the device SENT an id is what
+ * earns it a place in this table; the provenance label beside each one rates something narrower — how far
+ * its NAME is trusted. `modelName` and `modelCode` are `mega`, their values matching what the cloud
+ * record already carried. `battery` is `verified`: the id is real and the reading consistent, 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.
+ *
+ * A dictionary entry is what makes a param readable by name off `getProperties()`. `capabilities/display.ts`
+ * decides separately which of them reach the typed surface, and only `battery` does.
+ *
+ * **8002 (`"1"`) and 8004 (a serial-shaped string) are absent, deliberately.** Neither meaning is
+ * legible from one value: `1` fits any enum or flag, and a serial could be the display's own or the
+ * station's it is bound to. They arrive as `unknown_8002` / `unknown_8004`, which is the measure of this
+ * list: it holds what is unknown, not what is unknowable. What would settle them: the vendor app's own
+ * display settings screen, one control at a time, params diffed after each.
+ */
+export declare const DISPLAY_PARAMS: Record<number, ParamDef>;

package/dist/model/param-namespace.d.ts

@@ -14,7 +14,7 @@
 import type { Codec } from "./types.js";
 import { type ParamDef } from "./param-dictionary.js";
 /** The param id spaces this SDK models. */
-export type ParamNamespace = "security" | "clean" | "life" | "print";
+export type ParamNamespace = "security" | "clean" | "life" | "print" | "display";
 /** Look up a param def in the given namespace. */
 export declare function paramDef(ns: ParamNamespace, paramType: number): ParamDef | undefined;
 /** The param namespace a device's ids live in, from its codec, via the module-local `NAMESPACE_BY_CODEC` table. */

package/dist/model/solix-catalog.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Anker Solix product catalog — the vendor's pairable-product registry (categories → products),
+ * used to label a discovered device's model code with a marketing name + category.
+ *
+ * This is model-layer vocabulary: pure data shapes + a lookup builder, with no wire/transport
+ * dependency. The catalog itself is fetched from the cloud by the client layer (`SolixClient`), which
+ * feeds it here via {@link buildModelIndex}; keeping the shapes and the index in the model layer lets
+ * `SolixDevice` resolve a name/category without reaching across the capability↔transport boundary.
+ */
+export type { SolixProduct, SolixProductCategory } from "../core/solix-types.js";
+import type { SolixProductCategory } from "../core/solix-types.js";
+/**
+ * Flatten a product catalog into a `product_code → { name, category }` lookup for labelling
+ * discovered devices. Every variant code in `p_codes` maps to its parent product too, so a device
+ * reporting a sub-model resolves to the same marketing name.
+ */
+export declare function buildModelIndex(categories: SolixProductCategory[]): Map<string, {
+    name: string;
+    category: string;
+}>;