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

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

@@ -481,7 +481,7 @@ export declare function buildActions(caps: readonly Capability[], deps: MemberDe
  * @internal
  */
 export declare function describeCapabilities(bound: Partial<DeviceActionMap>, ctx?: AvailabilityContext): CapabilityDescriptor[];
-export type { CommandContext, CapabilityActions, CapabilityStateReader, CapabilityModule, DetectionSpec, CapabilityFrame, CapabilityEvent, InboundSignal, EventMapping, ProductLine, ActionArgSpec, DecodedState, } from "./types.js";
+export type { CommandContext, CapabilityActions, CapabilityStateReader, CapabilityModule, DetectionSpec, CapabilityFrame, CapabilityEvent, InboundSignal, EventClaim, EventMapping, ProductLine, ActionArgSpec, DecodedState, } from "./types.js";
 /**
  * The value-kind vocabulary a read is annotated with, re-exported from the barrel that publishes the
  * read itself, so the union a member's `kind` is drawn from is reachable from the same import.

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

@@ -136,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
@@ -197,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). */
@@ -259,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

@@ -379,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.
  *
@@ -1963,6 +1980,48 @@ export declare const VACUUM_CLEAN_MEMBERS: {
     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).
      *

package/dist/transport/mqtt/index.d.ts

@@ -5,3 +5,4 @@ export * from "./broker-discovery.js";
 export * from "./biz-stream.js";
 export { SolixMqtt } from "./solix-mqtt.js";
 export type { SolixMqttOptions, SolixMqttDevice, SolixReading, SolixParamFrame, SolixChannel } from "./solix-mqtt.js";
+export { SOLIX_MODBUS_EMS_MODES } from "./solix-mqtt.js";

package/dist/transport/mqtt/solix-mqtt.d.ts

@@ -46,10 +46,20 @@ export interface SolixParamFrame {
  *   slots read 0 on a single-CT install.
  *
  * The frame carries sixteen float slots (`0xa8`..`0xb7`). The four that name no field — `0xb2`, `0xb5`,
- * `0xb6`, `0xb7` — stay raw `channel_<hex tag>` (see {@link solixReadings}). `0xb2` in particular is NOT
- * a current total: under a 1.371 A line current it reads 0.009, three orders of magnitude off. Both
- * `0xb2` and `0xb7` read zero at idle and non-zero under load, so they carry *something* load-related;
- * what, is not established.
+ * `0xb6`, `0xb7` — stay raw `channel_<hex tag>` (see {@link solixReadings}). Both `0xb2` and `0xb7` read
+ * zero at idle and non-zero under load, so they carry *something* load-related; what, is not established.
+ * `0xb2` is dimensionally consistent with **power factor** and rules **reactive power** out: on the same
+ * frame the line reads ~240 V at 1.371 A (apparent power S = V·I ≈ 328 VA), so a reactive-power slot would
+ * read in the hundreds of VAR, not `0xb2`'s 0.009 — whereas a power factor P/S is a sub-unity ratio of the
+ * right magnitude (~0.008). It is left raw regardless, since a single frame doesn't pin it. `0xb7` (~0.1
+ * under load) has no such magnitude tell and stays fully open.
+ *
+ * Each name is annotated with the equivalent register from Anker's OWN vendor integration for the
+ * newer Modbus-TCP meter generation (Smart Meter Gen 2), which independently corroborates the meaning
+ * of each tag: our `meterPowerL1` is their `primary_phase_1_active_power`, and so on. Same physical
+ * quantities, different hardware/transport (their meter reports two CT channels — `primary` and
+ * `secondary` — and also exposes `reactive_power`, `power_factor` and per-phase energy, none of which
+ * this single-channel ff09 frame carries).
  *
  * This table is **meter-family-specific**: the same tag carries a different quantity on another Solix
  * device (a Solarbank's `0xac` reads a power value, not a voltage), so {@link solixReadings} applies
@@ -92,6 +102,13 @@ export declare const SOLIX_SOLARBANK_PRODUCT_PREFIX = "AE10";
  * (a uint8) and temperature from the `0xa4` BMS status blob. The 4 PV-string channels (`0xc6`–`0xc9`),
  * the AC currents (`0xb2`/`0xb3`) and export energy (`0xb4`) are not yet confirmed, so they stay raw
  * `channel_<hex>` until a capture pins them.
+ *
+ * Names are annotated with the equivalent register from Anker's OWN vendor integration for the newer
+ * Modbus-TCP Solarbank generation (which includes a "Solarbank 4 E5000 Pro" config — the same product as
+ * `AE103`, a newer hardware rev), cross-checking each meaning. Their integration splits our signed
+ * `batteryPower` into `battery_charging_power` / `battery_discharging_power` off one register, and exposes
+ * a single `pv_power` total rather than our four per-string channels; `socketPower` (the on-board AC
+ * outlet) has no register there. Same quantities, different transport.
  */
 export declare const SOLIX_SOLARBANK_FIELD_NAMES: Readonly<Record<number, string>>;
 /**
@@ -103,6 +120,28 @@ export declare const SOLIX_SOLARBANK_FIELD_NAMES: Readonly<Record<number, string
  * stays raw `state_<hex>` until confirmed the same way.
  */
 export declare const SOLIX_STATE_FIELD_NAMES: Readonly<Record<number, string>>;
+/**
+ * The Solarbank EMS `operating_mode` enumeration from Anker's OWN vendor integration for the newer
+ * **Modbus-TCP** hardware rev (Solarbank 4 E5000 Pro, register `operating_mode` gated by the `0x8006`
+ * capability mask). Value → English label:
+ * - `0` selfConsumption — "Self-Consumption Mode"
+ * - `1` timeOfUse — "Time Of Use Mode"
+ * - `3` thirdPartyControl — "Third-Party Controlled"
+ * - `4` custom — "Custom Mode"
+ * - `5` socketOverlay — "Socket Overlay Mode"
+ * - `6` smart — "Smart Mode"
+ * - `7` dynamicTariff — "Dynamic Tariff Mode"
+ *
+ * Value `2` is unassigned there — seven modes across `{0,1,3,4,5,6,7}`, not eight.
+ *
+ * NOT a decoder for this SDK's ff09 `mode` (`state_info` tag `0xa9`): that OLDER cloud/MQTT `AE103`
+ * numbering is DIFFERENT on every value — `1`=custom, `2`=self-consumption, `4`=rapid charge, `7`=smart,
+ * `8`=dynamic tariff (recorded on the `0xa9` field above, correlated against the app). Labelling an ff09
+ * `mode` value with this Modbus map would be confidently wrong. It is exported as the vendor's own
+ * reference enumeration and the thing an AE103 `0xa9` correlation capture would be checked against —
+ * fold the two only if such a capture proves the numbers match.
+ */
+export declare const SOLIX_MODBUS_EMS_MODES: Readonly<Record<number, string>>;
 /**
  * Decode a `state_info` ff09 frame to named + raw settings values. Skips the header tags (`< 0xa5`:
  * request marker, serial, timestamps). Each settings tag is emitted under `state_<hex>` (a plain number

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mega-yfue/eufy-sdk",
-  "version": "0.2.0-beta.21",
+  "version": "0.2.0-beta.23",
   "description": "One typed TypeScript client for the Anker eufy v6 cloud — capability-driven devices, realtime events over P2P/MQTT/push, and live media",
   "license": "Apache-2.0",
   "author": "mega-yfue",