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

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

@@ -2,11 +2,15 @@ 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 — the four whose write is confirmed against a real station. Three are
+ * byte-exact captures and `custom1` is a live confirmation; `ARMING_MODE_WIRE` carries the per-value
+ * evidence. `ArmingMode` is both the const value-object (`ArmingMode.home`) and the union type of its
  * 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
+ * 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}.
+ *
+ * Deliberately NARROWER than the set a device may report. The remaining five modes are ones the app itself
  * defines and the `mode` read still names them, but no capture shows one being SENT — and
  * on a fire-and-forget wire a wrong one looks exactly like success. Leaving them out of this union is the
  * compile-time half of the refusal; `mode`'s published argument and the generated rejection are the
@@ -17,10 +21,31 @@ export declare const ArmingMode: {
     readonly away: "away";
     /** Armed for occupancy — reduced/perimeter protection while home (wire value 1). */
     readonly home: "home";
+    /** Custom 1 — a user-defined posture configured in the app (wire value 3). */
+    readonly custom1: "custom1";
     /** 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 +59,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. `custom1` 3 joined {@link ArmingMode} on a live confirmation rather than a
+     * capture, making four settable in total. The remaining five are named by the app but never observed
+     * leaving it, so this capability reads them and refuses to send them. See `ARMING_MODE_WIRE` for the
+     * per-value breakdown.
      */
     readonly SET_ARMING: 1224;
     /**
@@ -139,9 +165,9 @@ 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
+     * station can report, and the argument's `values` publishes only the four whose write is confirmed. That
+     * argument IS the domain the derived setter enforces and the refusal names, so an unconfirmed mode is
+     * refused by naming the four that work — nine labels for the read and four for the write, off one
      * declaration.
      *
      * `armingCommand` may also throw synchronously (missing account identity) and `bindMembers` turns that
@@ -187,15 +213,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.
+ * read/write MECHANISM, but only 4 of the 9 modes it reports (away/home/custom1/disarmed, the
+ * {@link ArmingMode} union) are confirmed as writes — see `ARMING_MODE_WIRE` for which 5 are still
+ * unverified third-party integers, and which of the 4 is live-confirmed rather than byte-captured.
  */
 export declare const ARMING: CapabilityModule;

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

@@ -385,7 +385,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;
@@ -555,7 +555,7 @@ export type { VacuumActivity, VacuumCleanType, CarpetStrategy, CleanExtent } fro
 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/transport/http/mega-client.d.ts

@@ -186,8 +186,16 @@ export declare class MegaHttpClient {
      *  restored-session short-circuit must NOT treat it as a usable session. Cleared on Ok/reset. */
     private pending2fa;
     private tokenExpiresAt;
-    /** Stable per-install device id — the auth token is bound to it. */
-    private openudid;
+    /**
+     * Stable per-install device id: `openudid` as configured, as restored from the session store, or as
+     * derived from the ACCOUNT when neither supplied one — two clients that configure none therefore
+     * share it, and are one install as far as everything keyed on this is concerned.
+     *
+     * Two things are keyed on it, and both fail the same way when it is shared: the auth token is bound
+     * to it, so each login displaces the other's session, and the secure-MQTT client id is built from it,
+     * so each connection evicts the other's channel.
+     */
+    readonly openudid: string;
     /** The device model reported to the cloud (explicit `phoneModel`, else a stable random one). */
     private readonly phoneModel;
     /** The `user-agent` for the media-download path (explicit `mediaUserAgent`, else derived from the model). */

package/dist/transport/mqtt/app-client-id.d.ts

@@ -11,6 +11,12 @@ export interface AppClientIdInput {
 }
 /** Build a client_id shaped like `android-{appName}-{uid}-{mqttUuid}-{timestamp}`. */
 export declare function buildAppShapedClientId(input: AppClientIdInput): string;
-/** A fresh stable-looking install UUID (16 hex chars) — generate ONCE per identity and persist it
- * (a new random value on every connect defeats the point of "stable"). */
-export declare function generateMqttUuid(): string;
+/**
+ * The `mqttUuid` segment for a client bound to `installId`, hashed to the 16-hex shape
+ * {@link buildAppShapedClientId} expects. Deterministic, so a client keeps its id across restarts and
+ * takes its own stale session over rather than doubling up beside it; one-way, so the id it is derived
+ * from is not recoverable from a client_id that travels the wire in clear.
+ *
+ * Two clients are distinguished exactly as far as their `installId` is: equal ids in, equal ids out.
+ */
+export declare function mqttUuidFrom(installId: string): string;

package/dist/transport/mqtt/command-router.d.ts

@@ -87,9 +87,6 @@ export interface MqttRouterDeps {
 export declare class MqttCommandRouter {
     private readonly deps;
     private readonly logger;
-    /** Stable per-process install id for the app-shaped MQTT client_id (see {@link buildAppShapedClientId}) —
-     * generated once, reused for every security-MQTT connect this router makes. */
-    private mqttUuid?;
     constructor(deps: MqttRouterDeps);
     /**
      * Whether this transport stack drives `dev`'s `ff09-*` commands — a **eufy-cloud device**

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

@@ -14,6 +14,16 @@
 import { EventEmitter } from "node:events";
 import type { EufyDevice, RealtimeTransport } from "../../core/types.js";
 import { type Logger } from "../../core/logger.js";
+/**
+ * Whether a connect failed because the broker REFUSED the client — a CONNACK return code the client
+ * cannot retry its way out of, as `mqtt.js` words it (`Connection refused: not authorized`). A socket
+ * that dies without an answer is not this: it is the same request, unanswered, and retrying it is the
+ * only way to learn which of the two happened.
+ *
+ * A refusal that arrives as a dropped connection instead of a CONNACK reads here as the transport
+ * failure it is indistinguishable from.
+ */
+export declare function isNotAuthorized(err: unknown): boolean;
 /**
  * Per-user mTLS credentials as returned by get_user_mqtt_info.
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mega-yfue/eufy-sdk",
-  "version": "0.2.0-beta.0",
+  "version": "0.2.0-beta.2",
   "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",