homebridge-roborock-matter 3.17.0 → 3.17.2

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 3.17.2
+
+**The Qrevo CurvX's dock can now offer the Empty Bin switch.** Reported with a diagnostics export, and then settled by hand, by [@jcoz00](https://github.com/jcoz00) in [#6](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/6). His a185 reports `dock_type: 20`, and the dock table this plugin inherited stops at 9 — so the CurvX fell through to "unknown dock" and was treated as having no auto-empty capability, which kept the optional Empty Bin switch added in 3.17.0 from ever being offered for it. Dock type 20 is now a named, recognised auto-empty dock.
+
+The switch is still opt-in and still off by default, so nothing changes for anyone who has not asked for it.
+
+**Only the auto-empty is granted, and only because its owner confirmed it.** Upstream also names a dozen dock codes above 9 that this project has had no report for, and none of those was added — a capability granted on a table alone is what cost a Q Revo S owner a suction level its robot does not have in [#10](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/10). Wash and dry are unconfirmed on this dock and stay unclaimed. A test now pins both halves: dock type 20 is in the set because an owner said so, and the codes nobody has reported stay out until one does.
+
+## 3.17.1
+
+**Closing the plugin's settings page could print a Node crash dump into your Homebridge log.** Reported with the log to prove it by [@jcoz00](https://github.com/jcoz00) in [#6](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/6). The Homebridge UI runs the settings-page server as a child process and closes its IPC channel the moment the page goes away; every reply that server sends is a `process.send()`, including the `ready()` handshake it fires before serving a single request. A send that loses the race against that close is reported asynchronously as an unhandled `'error'` event, which is fatal — so a closed settings page ended in `Error: write EPIPE`, a stack trace and a `Node.js v24.19.0` banner in the log. Nothing was broken and nothing in the log said so. A dead channel now ends that child process quietly; every other error stays exactly as loud as it was.
+
+**A robot's dock capability is announced when it changes, instead of on every poll.** `dock_type` rides along in nearly every `get_status`, and 3.17.0 told the platform about it each time, re-running the HomeKit action-switch sync roughly once a minute per robot. At default settings that sync returns immediately, but anyone who had switched the Empty Bin action on for a robot whose dock cannot auto-empty collected a `Not publishing the Empty Bin switch…` debug line every minute per robot — enough to shorten the useful reach of the debug log. Detection itself still runs on every poll; only the announcement is gated, and a dock type that genuinely changes is still announced.
+
 ## 3.17.0
 
 **Compatible auto-empty docks can now expose an optional Empty Bin action switch in Apple Home.** Contributed by [@jbyhb](https://github.com/jbyhb) in [#13](https://github.com/mathiashornbek/homebridge-roborock-matter/pull/13). It uses the same opt-in HomeKit action-switch bridge as Start, Dock, Pause and Find, appears only when the robot reports dust-collection support, and sends the dock's native `app_start_collect_dust` command through the normal confirmed command path. A cached status that does not show the robot docked is advisory rather than a hard gate: the robot is the authoritative judge and its refusal follows the existing command-error path.

package/README.md

@@ -37,7 +37,7 @@ This is the most feature-packed, most thoroughly engineered Roborock plugin for
 - 📍 **See where it's cleaning — live.** Apple Home shows _"Cleaning — Kitchen"_ with the room the robot is actually inside, updating as it moves from room to room. Works even for cleans started from the robot's button or the Roborock app. No other Homebridge plugin does this.
 - 🧭 **One robot, one tile — and as many robots as you own.** Sign in once and your whole fleet comes along: every vacuum on your account appears as its own clean, native accessory in Apple Home. No clutter of fake fans and helper switches, and rooms appear with the names you gave them in the Roborock app.
 - ⚡ **Fast and reliable.** Commands go directly to the robot over your own network whenever possible, with the Roborock cloud as automatic backup — and built-in diagnostics in the settings if you ever want to look under the hood.
-- 🛡️ **Verified by Homebridge.** Reviewed and endorsed by the Homebridge team. 1393 automated tests, zero known vulnerabilities, no analytics, and a startup designed to never crash your Homebridge — even when your Wi-Fi or the Roborock cloud has a bad day.
+- 🛡️ **Verified by Homebridge.** Reviewed and endorsed by the Homebridge team. 1438 automated tests, zero known vulnerabilities, no analytics, and a startup designed to never crash your Homebridge — even when your Wi-Fi or the Roborock cloud has a bad day.
 
 ## Features
 
@@ -252,7 +252,7 @@ The complete path — robot → plugin → Homebridge → matter.js store — wa
 
 ## Contributing
 
-Model reports, diagnostics exports, and pull requests are very welcome. The codebase ships with 1393 tests (protocol fixtures verified against the [python-roborock](https://github.com/Python-roborock/python-roborock) reference), strict TypeScript checking, and CI across Node 22/24 × Homebridge 1.11/2.x — `npm test` before you push and you're set.
+Model reports, diagnostics exports, and pull requests are very welcome. The codebase ships with 1438 tests (protocol fixtures verified against the [python-roborock](https://github.com/Python-roborock/python-roborock) reference), strict TypeScript checking, and CI across Node 22/24 × Homebridge 1.11/2.x — `npm test` before you push and you're set.
 
 ## Support the project
 

package/homebridge-ui/server.js

@@ -7,6 +7,13 @@ import { createRequire } from "node:module";
 import { HomebridgePluginUiServer } from "@homebridge/plugin-ui-utils";
 
 const require = createRequire(import.meta.url);
+const {
+  installChannelGoneGuard,
+} = require("../roborockLib/lib/uiServerLifecycle.js");
 const { RoborockUiServer } = require("../dist/ui/index.js");
 
+// Before the server is built, not after: its constructor calls ready(), and
+// that send is the one that crashed for a user who closed the settings page.
+installChannelGoneGuard(process);
+
 new RoborockUiServer(HomebridgePluginUiServer);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "homebridge-roborock-matter",
-  "version": "3.17.0",
+  "version": "3.17.2",
   "description": "The most complete Roborock plugin for Apple Home. Supports the entire Roborock lineup — from the classic S-series to the new 2025 Q7 series that no other plugin can control. Sign in with your Roborock account and get native start/stop, room cleaning, suction levels, battery, and live 'cleaning in the kitchen' room tracking. Verified by Homebridge.",
   "license": "MIT",
   "author": {

package/roborockLib/lib/deviceFeatures.js

@@ -68,6 +68,12 @@ const dockTypes = {
   7: "Empty Wash Fill Dry Dock (S8 Pro Ultra)",
   8: "Empty Wash Fill Dry Dock (Q Revo)",
   9: "Empty Wash Fill Dry Dock (Q Revo Pro)",
+  // Upstream python-roborock calls 20 `k1s_dock`. It reached this project as a
+  // diagnostics export from an a185 (Qrevo CurvX) owner in issue #6 — the
+  // first dock code ever seen here above 9 — and he confirmed the auto-empty
+  // by hand. Named for the capability he reported, not for the ones upstream's
+  // codename might imply: nobody has confirmed wash or dry on this dock.
+  20: "Auto-Empty Dock (K1S — Qrevo CurvX)",
 };
 
 const firmwareFeatures = {
@@ -1393,6 +1399,15 @@ class deviceFeatures {
         this.isWashThenChargeCmdSupported();
         this.isSupportedDrying();
         break;
+      // K1S: a185 Qrevo CurvX. Auto-empty only, and deliberately so — its
+      // owner confirmed the dock empties the robot's bin (issue #6, 23 Aug
+      // 2026), which is the whole of what was asked and the whole of what is
+      // granted. Wash and dry are unconfirmed on this dock, and the a104
+      // suction level in issue #10 is what a capability granted on a table
+      // alone costs. Add them here on an owner's word, not on a codename's.
+      case 20:
+        this.isDustCollectionSettingSupported();
+        break;
       default:
         break;
     }

package/roborockLib/lib/uiServerLifecycle.js

@@ -0,0 +1,95 @@
+"use strict";
+
+// The Homebridge UI runs this plugin's settings-page server as a child
+// process and closes the IPC channel the moment the page goes away. Every
+// answer that server gives is a `process.send()` — including the one-shot
+// `ready()` handshake its constructor fires before it has served a single
+// request — and a send that loses the race against that close does not throw.
+// Node reports it asynchronously as an `'error'` event on `process`, and an
+// `'error'` event with no listener is fatal.
+//
+// Measured in the wild on an a185 (issue #6, 23 August 2026): closing the
+// settings page printed a full Node crash dump into the user's Homebridge log
+// — `Error: write EPIPE` inside `HomebridgePluginUiServer.ready`, "Unhandled
+// 'error' event", a stack trace and a `Node.js v24.19.0` banner — for a page
+// they had already closed and a process that had nothing left to do. Nothing
+// was broken. Nothing in the log said so.
+//
+// Checking `process.connected` before sending does not fix this: the channel
+// can close between the check and the write. The listener does, so the child
+// gets exactly one, installed before the server is constructed. A dead
+// channel is a normal end of life and exits quietly; anything else is a real
+// fault and stays exactly as loud as it was before this file existed.
+
+/**
+ * The error codes Node uses when the other end of the IPC channel is already
+ * gone. `EPIPE` is the write losing the race, the `ERR_IPC_*` pair is the
+ * same condition caught before the write is attempted, and `ECONNRESET` is
+ * the parent tearing the socket down mid-write.
+ *
+ * @type {readonly string[]}
+ */
+const CHANNEL_GONE_CODES = Object.freeze([
+  "EPIPE",
+  "ERR_IPC_CHANNEL_CLOSED",
+  "ERR_IPC_DISCONNECTED",
+  "ECONNRESET",
+]);
+
+/**
+ * Is this the parent having gone away, rather than a fault worth reporting?
+ *
+ * @param {unknown} error
+ * @returns {boolean}
+ */
+function isChannelGoneError(error) {
+  if (!error || typeof error !== "object") {
+    return false;
+  }
+
+  const code = /** @type {{ code?: unknown }} */ (error).code;
+
+  return typeof code === "string" && CHANNEL_GONE_CODES.includes(code);
+}
+
+/**
+ * Install the one listener that keeps a closed settings page from looking
+ * like a plugin crash.
+ *
+ * @param {NodeJS.EventEmitter & { exit?: (code?: number) => void }} proc
+ *   The process to guard. Injected rather than closed over so the rule can be
+ *   exercised without ending the test runner.
+ * @param {(error: unknown) => void} [onChannelGone]
+ *   What to do once the channel is confirmed gone. Defaults to exiting
+ *   cleanly: the parent that asked for this server no longer exists, so
+ *   lingering would leak a child process per opened settings page.
+ * @returns {NodeJS.EventEmitter} the same process, for chaining.
+ */
+function installChannelGoneGuard(proc, onChannelGone) {
+  const handleChannelGone =
+    onChannelGone ||
+    ((/** @type {unknown} */ _error) => {
+      if (typeof proc.exit === "function") {
+        proc.exit(0);
+      }
+    });
+
+  proc.on("error", (error) => {
+    if (isChannelGoneError(error)) {
+      handleChannelGone(error);
+      return;
+    }
+
+    // Not our case. Re-throwing from the listener turns this back into the
+    // uncaught exception it would have been, stack intact.
+    throw error;
+  });
+
+  return proc;
+}
+
+module.exports = {
+  CHANNEL_GONE_CODES,
+  isChannelGoneError,
+  installChannelGoneGuard,
+};

package/roborockLib/lib/vacuum.js

@@ -137,6 +137,41 @@ class vacuum {
      * @type {Map<string, Set<string>>}
      */
     this.reportedUnmappedStatusAttributes = new Map();
+
+    /**
+     * The dock type last seen from a robot's live `get_status`, per duid.
+     *
+     * `processDockType()` is idempotent and cheap, so it keeps running on
+     * every poll. Telling the platform about it does not: the notification
+     * re-runs the HomeKit action-switch sync behind it. A robot that reports
+     * `dock_type` in every `get_status` — which is most of them — therefore
+     * re-announced unchanged capabilities roughly once a minute per robot,
+     * and a user who had opted the Empty Bin switch on for a robot without an
+     * auto-empty dock collected the "Not publishing the Empty Bin switch"
+     * debug line at that same rate. A dock type is worth announcing when it
+     * is new or has actually changed; a repeat of the same value cannot tell
+     * the platform anything it did not already act on.
+     *
+     * @type {Map<string, unknown>}
+     */
+    this.lastSeenDockType = new Map();
+  }
+
+  /**
+   * Record the dock type a robot just reported, and say whether it is news.
+   *
+   * @param {string} duid
+   * @param {unknown} dockType
+   * @returns {boolean} true on the first sighting, and on every real change
+   */
+  rememberDockType(duid, dockType) {
+    const isNews =
+      !this.lastSeenDockType.has(duid) ||
+      this.lastSeenDockType.get(duid) !== dockType;
+
+    this.lastSeenDockType.set(duid, dockType);
+
+    return isNews;
   }
 
   /**
@@ -574,7 +609,10 @@ class vacuum {
               this.adapter.vacuums[duid].features.processDockType(
                 deviceStatus[0][attribute]
               );
-              dockCapabilityUpdated = true;
+              dockCapabilityUpdated = this.rememberDockType(
+                duid,
+                deviceStatus[0][attribute]
+              );
             }
 
             if (

package/roborockLib/roborockAPI.js

@@ -2456,7 +2456,13 @@ class Roborock {
 
   supportsDustCollection(duid) {
     const dockType = Number(this.getVacuumDeviceStatus(duid, "dock_type"));
-    const autoEmptyDockTypes = new Set([1, 3, 5, 6, 7, 8, 9]);
+    // 20 (upstream `k1s_dock`, the a185 Qrevo CurvX) is here because its owner
+    // confirmed the auto-empty in issue #6, not because upstream names the
+    // code. Upstream also names 10, 11, 13-19, 21-24 and 26; none of those has
+    // an owner report, so none of them is here. Keep this set and
+    // `processDockType()` in step — a code in one but not the other is a dock
+    // that either offers a switch it cannot drive or hides one it can.
+    const autoEmptyDockTypes = new Set([1, 3, 5, 6, 7, 8, 9, 20]);
 
     return (
       autoEmptyDockTypes.has(dockType) ||