@mega-yfue/eufy-sdk 0.2.0-beta.3 → 0.2.0-beta.30

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
@@ -129,6 +136,45 @@ export interface EventMapping {
      * capture. Return `{}` when this signal doesn't carry the field, so nothing is invented.
      */
     derive?(signal: InboundSignal): Record<string, unknown>;
+    /**
+     * Evidence that this device deals in the classification the id names, for an id whose presence in
+     * the wire vocabulary does not prove it.
+     *
+     * The AI-detection ids are shared verbatim across the camera families, so the id space says what an
+     * integer MEANS and never which units classify that way. A claim is how a mapping states the
+     * evidence that separates them, and it narrows the DESCRIPTION only: {@link EventMapping} stays in
+     * the dispatch index unclaimed, so a device that sends the push still gets the event. Under-reporting
+     * what a device is expected to emit is recoverable; dropping an event it did emit is not.
+     *
+     * Every field must hold — the AND to {@link DetectionSpec}'s OR, because a claim rules a family OUT
+     * rather than finding one more reason to say yes. A fact the context does not carry rules nothing
+     * out: only evidence that positively contradicts the claim withdraws the event.
+     */
+    claim?: EventClaim;
+}
+/**
+ * Evidence separating the families that share one inbound id.
+ *
+ * Both fields are optional and independent; an empty claim asserts nothing and is the same as none.
+ */
+export interface EventClaim {
+    /**
+     * The codecs whose devices issue the id. For an id drawn from a vocabulary one device family owns:
+     * the AI-detection ids belong to the camera families, and a standalone sensor announces its own
+     * motion under a different id entirely.
+     */
+    codecs?: readonly Codec[];
+    /**
+     * Member names whose INSTALLED getter is the evidence — the device reported the parameter behind
+     * the classification, which is the same bar every typed read is held to.
+     */
+    reads?: readonly string[];
+    /**
+     * The topology the id belongs to: `true` for an id only a station's attached device sends, `false`
+     * for one only a standalone unit sends. Compared against {@link AvailabilityContext.homeBaseAttached},
+     * and ignored where that is absent.
+     */
+    homeBaseAttached?: boolean;
 }
 /**
  * A decoded inbound event a capability wants surfaced on the SDK. `event` is the EufyMega event
@@ -162,8 +208,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. */
@@ -185,6 +236,15 @@ export interface AvailabilityContext {
      * `undefined` as an empty set — `ctx.paramIds?.has(dp) ?? false`.
      */
     paramIds?: ReadonlySet<number>;
+    /**
+     * Whether the device hangs off a HomeBase (a `parent_sn` other than its own) rather than standing
+     * alone. A DEVICE fact, not a transport one — the same class of routing evidence as {@link hasP2p} —
+     * which is why it sits here rather than on {@link CommandContext}: it is as true of a described
+     * device as of a commanded one. The `rtsp` capability gates on it because a station serves an
+     * attached camera's stream itself and ignores that camera's authentication setting, so the write
+     * cannot do what its name promises there.
+     */
+    homeBaseAttached?: boolean;
 }
 export interface CommandContext extends AvailabilityContext {
     /** Device channel (0 for standalone, `device_channel` on a HomeBase). */
@@ -235,7 +295,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
@@ -243,13 +307,6 @@ export interface CommandContext extends AvailabilityContext {
      * capability uses this to route lock/unlock to P2P vs. reject with a clear MQTT-not-wired error.
      */
     hasP2p?: boolean;
-    /**
-     * Whether the device hangs off a HomeBase (a `parent_sn` other than its own) rather than standing
-     * alone. A DEVICE fact, not a transport one — the same class of routing evidence as {@link hasP2p}.
-     * The `rtsp` capability gates on it because a station serves an attached camera's stream itself and
-     * ignores that camera's authentication setting, so the write cannot do what its name promises there.
-     */
-    homeBaseAttached?: boolean;
     /**
      * Parsed `get_product_data_point` catalog for this device's SKU — present for vacuum/mower devices,
      * absent for all other codecs. Capabilities use it for per-model feature-availability and value-range

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
@@ -370,6 +379,23 @@ export type CarpetStrategy = (typeof CARPET_STRATEGIES)[number];
  */
 export declare const CLEAN_EXTENTS: readonly ["normal", "narrow", "quick"];
 export type CleanExtent = (typeof CLEAN_EXTENTS)[number];
+/**
+ * Build a `CleanParamRequest` (DP 154) stating the three cleaning settings a run uses.
+ *
+ * The message is `{ clean_param: CleanParam }` — field 1 of the request, carrying the same `CleanParam`
+ * this module decodes out of field 1 of the reports it receives, so the shape a write sends is the
+ * shape a read has already been proven against on live hardware.
+ *
+ * All three settings are stated together because one message carries all three: a write naming fewer
+ * would be a `CleanParam` with the rest silent, and what a robot does with a half-stated one is not
+ * something this SDK has observed. `clean_times`(7) is never written — the vendor's own field comment
+ * makes zero mean "not stated", so omitting it leaves the robot's configured pass count alone — and
+ * neither is `fan`(6), which belongs to the suction capability's own data point.
+ *
+ * {@link VACUUM_CLEAN_MEMBERS.setCleanParam} dispatches this.
+ * @internal
+ */
+export declare function encodeCleanParam(cleanType: VacuumCleanType, cleanExtent: CleanExtent, mopLevel: MopLevel): string;
 /**
  * Read one setting out of the CONFIGURED `CleanParam` (DP 154), by its field number.
  *
@@ -1941,6 +1967,88 @@ 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;
+    };
+    /**
+     * State the cleaning settings a run uses — `CleanParamRequest.clean_param` over DP 154.
+     *
+     * The write counterpart of {@link VACUUM_CLEAN_MEMBERS.cleanType},
+     * {@link VACUUM_CLEAN_MEMBERS.cleanExtent} and {@link VACUUM_CLEAN_MEMBERS.mopLevel}: one message
+     * carries all three, so they are set together rather than through three setters that would each send
+     * the same message with the other two silent.
+     *
+     * **The evidence, and its limit.** The frame is field 1 of `CleanParamRequest`, which carries the
+     * very `CleanParam` this module decodes out of field 1 of the reports a live T2351 sends — the
+     * field numbers, the single-field wrappers and the `mop_mode.level` scale are all read off that
+     * capture, and `encodeCleanParam` writes what `decodeCleanParamValue` reads. What is NOT captured is
+     * the write direction itself. It ships as a method rather than an unverified write because the
+     * hazard that rule answers does not arise here: DP 154 is the robot's own settings report, so a frame
+     * it does not accept leaves those three reads unchanged, where a wrong fire-and-forget command would
+     * look exactly like success.
+     *
+     * Suction is not here. It has its own data point and its own capability — a `fan` field exists in
+     * this message and is deliberately not written, for the same reason it is not read.
+     */
+    readonly setCleanParam: {
+        readonly method: (deps: import("./members.js").MemberDeps) => (cleanType: VacuumCleanType, cleanExtent: CleanExtent, mopLevel: MopLevel) => Promise<void>;
+        readonly description: string;
+        readonly available: ((ctx: import("./types.js").CommandContext) => boolean) & ((ctx: import("./types.js").CommandContext) => boolean);
+        readonly answers?: true;
+        readonly args: readonly [{
+            readonly name: "cleanType";
+            readonly kind: "enum";
+            readonly values: readonly ["sweep", "mop", "sweepAndMop", "sweepThenMop"];
+            readonly description: "What the robot does with a surface.";
+        }, {
+            readonly name: "cleanExtent";
+            readonly kind: "enum";
+            readonly values: readonly ["normal", "narrow", "quick"];
+            readonly description: "How far past the mapped edge a job reaches. Wire order, not app order.";
+        }, {
+            readonly name: "mopLevel";
+            readonly kind: "enum";
+            readonly values: readonly ["low", "middle", "high"];
+            readonly description: "How much water the mop lays down. Only meaningful for a clean type that mops.";
+        }];
+    };
+    /**
+     * 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/classify.d.ts

@@ -55,7 +55,9 @@ export declare function codecForType(deviceType: number): Codec | undefined;
  *    EXCEPT `T8520`-prefixed which can be lock variants — still lock.
  *  - `T74xx` → **lock** (SmartSafe 7400-series).
  *  - `T80xx` / `T8001` / `T8002` / `T8010` / `T8030` / `T8023` / `T8025` → **station**
- *    (HomeBase / HomeBase 2 / 3 / Mini), and `T8N00` (NVR) / `T8E00` (PoE NVR) → station.
+ *    (HomeBase / HomeBase 2 / 3 / Mini), `T9000` (the app's own model registry files it as family
+ *    `STATION_9000`, the one station family outside the T8 band), and `T8N00` (NVR) / `T8E00` (PoE
+ *    NVR) → station.
  *  - `T89xx` (entry/motion/water/siren sensors, e.g. T8900/T8910/T8920) → **sensor**.
  *  - `T87xx` keypad (`T8960`) → **keypad**.
  *  - any other `T8…` security T-code → **camera** (the default security family).

package/dist/model/device-family.d.ts

@@ -27,7 +27,8 @@ export declare const WALL_LIGHT_TYPES: ReadonlySet<number>;
  * they own the hub-audio surface (alarm / voice-prompt volume). A deliberate SUBSET of the `station`
  * codec that EXCLUDES the NVRs (S4 Max, PoE NVR): those resolve to `station` for arming/storage but
  * have no speaker, so they must NOT expose the hub-audio controls (they'd fire at nothing). The
- * alarm/prompt wire is verified on HomeBase 3 (HB3); the other hubs share the hub hardware.
+ * alarm/prompt wire is verified on HomeBase 3 (HB3); the other hubs, T9000 (`STATION_9000`) included,
+ * share the hub hardware.
  */
 export declare const HOMEBASE_TYPES: ReadonlySet<number>;
 /** Indoor camera (any indoor variant). */

package/dist/model/device-types.d.ts

@@ -42,6 +42,7 @@ export declare const DeviceType: {
     readonly PROFESSIONAL_247: 24;
     readonly MINIBASE_CHIME: 25;
     readonly CAMERA3_PRO: 26;
+    readonly STATION_9000: 27;
     readonly HOMEBASE_MINI: 28;
     readonly INDOOR_CAMERA: 30;
     readonly INDOOR_PT_CAMERA: 31;

package/dist/model/device.d.ts

@@ -62,6 +62,11 @@ export declare class Device {
      * different wire ids across device families still resolves to one named value.
      */
     private specByParam;
+    /**
+     * Params a resolved capability declares that this device's schema does not carry — withheld by a
+     * member's gate, so not named from the param dictionary either. See {@link Device.applyParams}.
+     */
+    private withheld;
     /** Which param namespace this device's ids live in (clean DPs vs security P2P). */
     private namespace;
     /** The record's `device_name` as stated, before the {@link modelName} fallback is applied. */
@@ -201,6 +206,16 @@ export declare class Device {
      * Apply a raw param map (cloud record or P2P notification). Known params update their named
      * property; unrecognised params are retained as `unknown_<paramType>` so nothing is lost.
      *
+     * Naming precedence: this device's own `PropertySpec` (curated), then the param dictionary for its
+     * namespace, then the `unknown_<paramType>` passthrough. The dictionary def is consulted even where a
+     * spec exists, because `encoding` lives there.
+     *
+     * A param a resolved capability's gate WITHHELD takes the passthrough instead of its dictionary name.
+     * The gate decided the read does not describe this device, the dictionary names it what the member
+     * would have, and republishing it there hands a caller a reading indistinguishable from one the device
+     * really answered. A capability that never resolved withholds nothing: a param arriving before its
+     * capability is still the device's own, and keeps its dictionary name.
+     *
      * @param params param_type → raw value.
      * @param ts observation time (epoch ms); defaults to `Date.now()`.
      * @returns the list of property names whose value changed.

package/dist/model/index.d.ts

@@ -30,3 +30,8 @@ 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, solarbankSceneReadings, 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";
+export { solixProductFamily, isSolixPowerStation, isSolixSolarbank, isSolixSmartMeter, type SolixProductFamily, type SolixFamilyInput, } from "./solix-family.js";
+export { SolixSite, discoverSolixSites, type SolixSiteReader, type SolixSiteOptions } from "./solix-site.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,25 @@
+/**
+ * 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.
+ *
+ * The category name is trimmed here, at ingest — the live catalog returns some names with trailing
+ * whitespace (e.g. `"Plug-in Home Battery "`), and normalising once at the source means every consumer
+ * (a device's `identity().category`, `detectSolixCapabilities`, and any exact-match category test) sees
+ * the clean name, rather than each call site having to remember to trim.
+ */
+export declare function buildModelIndex(categories: SolixProductCategory[]): Map<string, {
+    name: string;
+    category: string;
+}>;