homebridge-roborock-matter 3.18.0 → 3.19.0

package/CHANGELOG.md

@@ -1,5 +1,41 @@
 # Changelog
 
+## 3.19.0
+
+**The B01 Q10 command dialect has now been run on a Q10, and it works. That measurement is the whole reason this goes to `latest`.**
+
+[@niclasreich](https://github.com/niclasreich) installed `3.19.0-beta.1` on his Q10 S5 (`roborock.vacuum.ss07`) and reported on 27 August 2026 that the robot starts cleaning from both the Homebridge interface and the Home app, and that commands are accepted. Every datapoint code in the dialect was read from python-roborock's docstrings rather than measured here, and the beta shipped saying so; his robot is the first `ss*` device this project has ever had a result from. Commands, return to dock and the state the tile shows while returning all behave as the dialect predicts.
+
+Nothing in the command path changed between the beta and this release. It is the same code with a field result behind it, which is the only thing the beta was waiting for. Details of what the dialect covers are in the `3.19.0-beta.1` notes below.
+
+**A Q10 is no longer polled for status, and no longer reports its own by-design refusal as a failure.** The dedicated B01 status loop asked every Q10 for `get_status` every 25 seconds. The send choke point refused each one correctly — a fire-and-forget dialect cannot answer a read — but a refused request was still a counted one: each refusal incremented the consecutive-failure tally and every tenth logged `B01 status has failed N times in a row` at warn level. On a healthy Q10 that is a warning every four minutes about a robot doing exactly what its protocol says. It was the first thing the beta put in the one field log this project has, and a diagnostic that fires on a working robot is worse than none — it is the same false alarm that made [#14](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/14) take three rounds to diagnose. The loop now skips a Q10 before the request is built and states once, per robot, that the dialect sends no reply, that state comes from home data over HTTPS instead, and where the remaining work is tracked. Asking a question whose refusal is certain before it is asked was never a diagnostic.
+
+A Q7 is unchanged and pinned as such: it is still polled, its answer is still mapped and dispatched, an unrecognised B01 model is still treated as a Q7, and a Q7 that genuinely stops answering still raises the warning. The warning is kept off a robot that cannot answer by design, not removed.
+
+**Known and not fixed by this release: a Q10's tile does not follow the robot into a clean.** State on a Q10 still comes from the home data snapshot, so docked and charging read correctly while a run in progress does not. Reading state from the datapoint updates the robot pushes is the remaining half of [#19](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/19). It is deliberately not in this release: it is the one change that has to touch the incoming MQTT path that Q7 and Q10 share, and bundling it with the promotion of a command path that has exactly one field measurement behind it would risk three working Q7 robots to save a release.
+
+A cloud request that times out without anything having arrived during it now says what its message total actually counts. It used to end with a bare `(8 since startup)`, and that figure is incremented in the MQTT receiver alone — a robot answering on the local socket never touches it, while the 180-second poll chain a reader would compare it against runs over whichever transport is up.
+
+Measured on an S8 Pro Ultra (`roborock.vacuum.a70`) on 27 August 2026: one transient cloud timeout reported `(8 since startup)` after eight and a half hours of polling. Read as a like-for-like ratio that says a link dropping about 95 % of replies; read correctly it says nothing is wrong, because the robot had been answering locally the whole time. The sentence now states that the total covers cloud traffic only and that a low number on a locally-answering robot is normal. A diagnostic that exists to stop wrong conclusions should not hand the reader a ratio that cannot be taken.
+
+## 3.19.0-beta.1
+
+**Beta channel only — `npm install homebridge-roborock-matter@beta`. This does not go to `latest` and no existing installation will pick it up.** It contains the first implementation of the B01 Q10 command dialect, and there is no Q10 robot available to this project to verify it on. Every datapoint code in it is read from python-roborock, where the docstrings mark them verified live against `ss07` hardware, but none of it has been measured here. Shipping that to everyone on `latest` on the strength of someone else's docstrings would be the same mistake [#14](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/14) already cost three rounds of wrong diagnosis.
+
+3.18.0 stopped this plugin sending Q7 frames to a Q10, which the robot discards, and refused instead. That made the plugin honest on a Q10; it did not make one work. This is the command half of [#19](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/19).
+
+A Q10 command is now published in the dialect the robot speaks — a direct write to a numbered datapoint, `{"dps":{"201":1}}`, with no method name, no `msgId` and no datapoint 10000. Start, stop, pause, return to dock, empty the dustbin, room clean, suction level and clean mode are covered.
+
+**The dialect is fire-and-forget, and that shapes the rest of the change.** A Q10 sends no RPC reply at all, so a Q10 request no longer registers a pending request or arms a timeout. Arming one would guarantee expiry on a perfectly healthy link, and reporting that expiry is exactly the false "the Roborock cloud has gone silent" that sent #14's reporter chasing a fault at Roborock. A command resolves when the write leaves the plugin, which means published and not acknowledged; the state Apple Home shows still comes from the optimistic-state machinery, which corrects itself against what the robot reports.
+
+**Reads stay refused on a Q10, and that is the dialect rather than unfinished work.** `get_status`, `get_map_list` and `get_prop` exist to return a value, and a protocol that never answers cannot return one. Serving them would hand the caller something the robot never sent and publish that non-answer to Apple Home as the robot's state. A Q10's status continues to come from home data over HTTPS, a separate transport measured working in #14. Reading state from the datapoint updates the robot pushes is the remaining half of #19.
+
+Two known limitations, stated rather than papered over. Resume restarts a whole-home clean instead of resuming, because the plugin has no distinct resume method to map onto the dialect's dedicated `205`. And `find_me` is refused: upstream has a datapoint number for it but no verified payload, and guessing one on hardware nobody here owns is how #14 happened.
+
+The two clean-type tables are not interchangeable and neither are the two suction scales — Q7 is vacuum=0, vac+mop=1, mop=2 while Q10 is vac+mop=1, vacuum=2, mop=3, and Max+ is 5 on a Q7 and 8 on a Q10. The numbers overlap, so the wrong table does not fail loudly; it mops when it was asked to vacuum. Both directions are pinned by tests.
+
+Q7 is unchanged. Three `sc*` robots run on the maintainer's own bridge, and the regression cover asserts that a Q7 still builds the RPC envelope on datapoint 10000, still arms its timeout, still registers its pending request, and that nothing addressed to a Q10 can ever carry the Q7 form — checked against the whole B01 method surface rather than a list of today's commands, with a guard that fails if that check ever becomes vacuous.
+
 ## 3.18.0
 
 **`B01` is two wire protocols, this plugin only implements one of them, and it has been sending the wrong one to Q10 robots.** This is the root cause behind [#14](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/14), where [@niclasreich](https://github.com/niclasreich)'s Q10 S5 (`roborock.vacuum.ss07`) could not run a single command. The two diagnostic releases before this one, 3.17.7 and 3.17.8, both measured the symptom correctly and both pointed at Roborock's cloud. The cause was here.

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. 1555 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. 1602 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 1555 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 1602 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "homebridge-roborock-matter",
-  "version": "3.18.0",
+  "version": "3.19.0",
   "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/b01Q10Adapter.js

@@ -0,0 +1,226 @@
+// @ts-check
+"use strict";
+
+/**
+ * The B01 Q10 dialect (`roborock.vacuum.ss*`).
+ *
+ * `pv === "B01"` is TWO wire protocols, not one. `b01Q7Adapter` implements the
+ * Q7 dialect (`sc*`), which carries an RPC envelope on datapoint 10000:
+ *
+ *   {"dps":{"10000":{"method":"prop.set","msgId":"…","params":…}}}
+ *
+ * The Q10 dialect writes a numbered datapoint directly, with no method, no
+ * msgId and no datapoint 10000 at all:
+ *
+ *   {"dps":{"201":1}}
+ *
+ * The consequence that matters for this file: **a Q10 command is
+ * fire-and-forget.** The dialect defines no RPC reply, so there is nothing to
+ * correlate a msgId against even when the command works perfectly. Upstream's
+ * own channel says so in its type signature — `send_command(...) -> None`.
+ *
+ * That is why this adapter translates COMMANDS ONLY, and deliberately refuses
+ * to translate reads such as `get_status`, `get_map_list` and `get_prop`. A
+ * read whose value is the answer cannot be served by a dialect that never
+ * answers; translating one would resolve the caller with a fabricated
+ * acknowledgement and then feed that non-answer to `mapStatusToV1`, publishing
+ * nonsense to Apple Home. Status on a Q10 continues to come from home data
+ * over HTTPS, which is a different transport and is measured to work (#14,
+ * 26 Aug 2026). Reading state off the datapoint updates the robot pushes is
+ * the other half of #19 and needs the incoming path, not this file.
+ *
+ * Every code below is read from python-roborock rather than guessed:
+ * `roborock/data/b01_q10/b01_q10_code_mappings.py` for the datapoint numbers
+ * and enums, `roborock/devices/traits/b01/q10/vacuum.py` for the payload of
+ * each command, where the docstrings mark them "Verified live against ss07
+ * hardware". None of it is verified by this project — there is no Q10 here.
+ * See #19.
+ */
+
+const b01Q7Adapter = require("./b01Q7Adapter");
+
+/**
+ * Q10 datapoint codes (`B01_Q10_DP`). Only the ones this file uses are
+ * listed; the upstream enum is far longer.
+ */
+const B01_Q10_DP = {
+  FAULT: 90,
+  COMMON: 101,
+  REQUEST_DPS: 102,
+  STATUS: 121,
+  BATTERY: 122,
+  FAN_LEVEL: 123,
+  CLEAN_MODE: 137,
+  START_CLEAN: 201,
+  START_BACK: 202,
+  START_DOCK_TASK: 203,
+  PAUSE: 204,
+  RESUME: 205,
+  STOP: 206,
+};
+
+/**
+ * `YXDeviceCleanTask` — the task selector carried by dpStartClean (201).
+ * Spot (`PART`, 5) is in the dialect but is not listed here: the plugin never
+ * issues `app_spot`, and a mapping no caller can reach is untested surface.
+ */
+const YX_CLEAN_TASK = {
+  SMART: 1, // whole home
+  ELECTORAL: 2, // segment / room
+};
+
+/**
+ * dpStartBack (202) task codes. 5 = charge, which is what the official app
+ * sends for "return to dock"; 1 washes the mop en route and 4 collects dust
+ * en route, and neither is what a Matter "go home" means.
+ */
+const Q10_BACK_TO_DOCK_CHARGE = 5;
+
+/** dpStartDockTask (203): 2 = collect dust. */
+const Q10_DOCK_TASK_COLLECT_DUST = 2;
+
+/**
+ * Matter clean-type codes -> `YXCleanType`.
+ *
+ * THIS IS NOT THE Q7 TABLE AND MUST NEVER BE SUBSTITUTED FOR IT. Q7 is
+ * vacuum=0, vac+mop=1, mop=2. Q10 is vac_and_mop=1, vacuum=2, mop=3. The
+ * numbers overlap, so a wrong table does not fail loudly — it mops when it was
+ * asked to vacuum.
+ * @type {Record<number, number>}
+ */
+const MATTER_TO_Q10_CLEAN_TYPE = { 0: 2, 1: 3, 2: 1 };
+
+/**
+ * Inverse of the above, for reading a Q10's reported clean type back into
+ * Matter terms.
+ * @type {Record<number, number>}
+ */
+const Q10_CLEAN_TYPE_TO_MATTER = { 1: 2, 2: 0, 3: 1 };
+
+/**
+ * Segment ids out of the several shapes callers use, matching the Q7
+ * adapter's own normalisation so the two families accept the same inputs.
+ * @param {any} params
+ * @returns {number[]}
+ */
+function normalizeSegmentIds(params) {
+  if (Array.isArray(params)) {
+    if (params.length === 1 && params[0] && Array.isArray(params[0].segments)) {
+      return params[0].segments.map(Number);
+    }
+    return params.map(Number).filter((value) => Number.isFinite(value));
+  }
+  if (params && Array.isArray(params.segments)) {
+    return params.segments.map(Number);
+  }
+  return [];
+}
+
+/**
+ * Translate a v1-shaped outgoing command to a Q10 datapoint write.
+ *
+ * Returns `{dp, params}` for a command the dialect can express, or `null` for
+ * anything else — including every read. `null` means the caller must refuse
+ * rather than invent a payload; a guessed datapoint on a robot nobody here
+ * owns is exactly the class of mistake #14 cost three rounds.
+ *
+ * @param {string} method
+ * @param {any} params
+ * @returns {{dp: number, params: any} | null}
+ */
+function translateOutgoing(method, params) {
+  switch (method) {
+    case "app_start":
+      return { dp: B01_Q10_DP.START_CLEAN, params: YX_CLEAN_TASK.SMART };
+    case "app_stop":
+      return { dp: B01_Q10_DP.STOP, params: 0 };
+    case "app_pause":
+      return { dp: B01_Q10_DP.PAUSE, params: 0 };
+    case "app_charge":
+      return { dp: B01_Q10_DP.START_BACK, params: Q10_BACK_TO_DOCK_CHARGE };
+    case "app_start_collect_dust":
+      return {
+        dp: B01_Q10_DP.START_DOCK_TASK,
+        params: Q10_DOCK_TASK_COLLECT_DUST,
+      };
+    case "app_segment_clean":
+    case "app_segment_clean_by_ids": {
+      const roomIds = normalizeSegmentIds(params);
+      if (!roomIds.length) {
+        return null;
+      }
+      return {
+        dp: B01_Q10_DP.START_CLEAN,
+        params: {
+          cmd: YX_CLEAN_TASK.ELECTORAL,
+          // "clean_paramters" mirrors the firmware's own misspelling of
+          // "parameters". Upstream documents that the device accepts that key
+          // and only that key. Do not correct it.
+          clean_paramters: roomIds,
+        },
+      };
+    }
+    case "set_custom_mode": {
+      const v1Code = Array.isArray(params) ? params[0] : params;
+      // One suction table, shared with the Q7 adapter's family switch, rather
+      // than a second copy here that could drift from it.
+      const wind = b01Q7Adapter.v1FanPowerToWind(b01Q7Adapter.B01_FAMILY.Q10)[
+        v1Code
+      ];
+      return wind === undefined
+        ? null
+        : { dp: B01_Q10_DP.FAN_LEVEL, params: wind };
+    }
+    case "set_clean_type": {
+      const matterMode = Array.isArray(params) ? params[0] : params;
+      const q10Mode = MATTER_TO_Q10_CLEAN_TYPE[matterMode];
+      return q10Mode === undefined
+        ? null
+        : { dp: B01_Q10_DP.CLEAN_MODE, params: q10Mode };
+    }
+    default:
+      // Everything else, reads included, is refused by the caller.
+      return null;
+  }
+}
+
+/**
+ * The wire payload body for a datapoint write: `{"dps":{"<dp>": params}}`.
+ *
+ * `params` of `0` is a real value on this dialect — pause, resume and stop all
+ * send it — so only `null`/`undefined` degrade to the empty object, exactly as
+ * upstream's `encode_mqtt_payload` does.
+ *
+ * @param {number} dp
+ * @param {any} params
+ * @returns {Record<string, any>}
+ */
+function buildDps(dp, params) {
+  return {
+    [String(dp)]: params !== undefined && params !== null ? params : {},
+  };
+}
+
+/**
+ * True when the Q10 dialect can express this v1 method at all.
+ * @param {string} method
+ * @param {any} [params]
+ * @returns {boolean}
+ */
+function canSendV1Method(method, params) {
+  try {
+    return Boolean(translateOutgoing(method, params ?? []));
+  } catch {
+    return false;
+  }
+}
+
+module.exports = {
+  B01_Q10_DP,
+  YX_CLEAN_TASK,
+  MATTER_TO_Q10_CLEAN_TYPE,
+  Q10_CLEAN_TYPE_TO_MATTER,
+  translateOutgoing,
+  buildDps,
+  canSendV1Method,
+};

package/roborockLib/lib/b01Q7Adapter.js

@@ -1231,4 +1231,7 @@ module.exports = {
   mapStatusToV1,
   B01_FAMILY,
   b01FamilyForModel,
+  // Exported for b01Q10Adapter, so the Q10 suction table has one home rather
+  // than a second copy that can drift from this one.
+  v1FanPowerToWind,
 };

package/roborockLib/lib/message.js

@@ -47,6 +47,18 @@ class message {
     return this._keys;
   }
 
+  /**
+   * @param {string} duid
+   * @param {number} protocol
+   * @param {any} messageID
+   * @param {string} method
+   * @param {any} params
+   * @param {boolean} [secure]
+   * @param {boolean} [photo]
+   * @param {{b01Q10Dps?: Record<string, any>}} [options] `b01Q10Dps` carries a
+   *   pre-built Q10 datapoint map from the send choke point, which is the only
+   *   place that knows the device family. Absent for every other device.
+   */
   async buildPayload(
     duid,
     protocol,
@@ -54,7 +66,8 @@ class message {
     method,
     params,
     secure = false,
-    photo = false
+    photo = false,
+    options = {}
   ) {
     const timestamp = Math.floor(Date.now() / 1000);
     const endpoint = this.adapter.rr_mqtt_connector.getEndpoint();
@@ -84,7 +97,15 @@ class message {
     }
 
     let payload;
-    if (version == "B01" || version == "\x81S\x19") {
+    if (options && options.b01Q10Dps) {
+      // B01 Q10 (`ss*`) wire format: the datapoint is written directly. No
+      // RPC envelope, no `method`, no `msgId`, no top-level `t`, and no
+      // datapoint 10000 — that datapoint does not exist on this family, which
+      // is why the Q7 form below was discarded by the robot without reply
+      // (#14). The dps map is built in b01Q10Adapter and passed through here
+      // rather than rebuilt, so the family test lives in exactly one place.
+      payload = JSON.stringify({ dps: options.b01Q10Dps });
+    } else if (version == "B01" || version == "\x81S\x19") {
       // Q7/B01 wire format (verified against the python-roborock reference
       // fixtures): a single object on dps 10000 carrying method/msgId/params
       // only. No top-level "t", no numeric "id", no security block; method

package/roborockLib/lib/messageQueueHandler.js

@@ -2,6 +2,7 @@
 "use strict";
 
 const b01Q7Adapter = require("./b01Q7Adapter");
+const b01Q10Adapter = require("./b01Q10Adapter");
 const { describeDevice } = require("./describeDevice");
 
 /**
@@ -120,7 +121,17 @@ function describeCloudSilence(adapter, duid, receiptsAtSend) {
     return ` ${duringRequest} Roborock message(s) reached the plugin from this robot while the request was pending, so the link is delivering; the reply was either never sent or not recognised.`;
   }
 
-  return ` No Roborock message reached the plugin from this robot while the request was pending (${total} since startup).`;
+  // The bare total was uninterpretable, and it misleads in the one direction
+  // that matters. This counter is incremented in the MQTT receiver only, so a
+  // robot that answers on the local socket never touches it — yet the poll
+  // chain a reader would compare it against runs over whichever transport is
+  // up. Measured on Mathias' own S8 Pro Ultra (a70, 27 Aug 2026): one cloud
+  // timeout reported "(8 since startup)" after 8.5 hours in which the 180 s
+  // poll had issued hundreds of requests, all answered locally. Read as a
+  // like-for-like ratio that says a 95 % dead link; read correctly it says
+  // nothing is wrong. Say what the number counts so the comparison is not
+  // available to make.
+  return ` No Roborock message reached the plugin from this robot while the request was pending (${total} cloud message(s) since startup). That total counts cloud traffic only — replies over the local socket are never counted here — so a low number on a robot that usually answers locally is normal and is not evidence the link is failing.`;
 }
 
 /**
@@ -142,7 +153,7 @@ function describeCloudSilence(adapter, duid, receiptsAtSend) {
 
 /**
  * @typedef {Object} MessageBuilder
- * @property {(duid: string, protocol: number, messageID: number, method: string, params: unknown[], secure: boolean, photo: boolean) => Promise<unknown>} buildPayload
+ * @property {(duid: string, protocol: number, messageID: number, method: string, params: unknown[], secure: boolean, photo: boolean, options?: {b01Q10Dps?: Record<string, unknown>}) => Promise<unknown>} buildPayload
  * @property {(duid: string, protocol: number, timestamp: number, payload: unknown) => Promise<Buffer | null | undefined>} buildRoborockMessage
  */
 
@@ -265,8 +276,14 @@ class messageQueueHandler {
       localConnectionState = this.adapter.localConnector.isConnected(duid);
     }
 
-    // B01 (Q7-series) devices are cloud/MQTT-only and speak a different RPC
-    // dialect. Translate the v1-shaped method to the Q7 equivalent here so a
+    // The Q10 datapoint write, when this request is bound for a Q10. Non-null
+    // is what makes the send below fire-and-forget, because that is the only
+    // family whose dialect never replies.
+    /** @type {Record<string, any> | null} */
+    let b01Q10Dps = null;
+
+    // B01 devices are cloud/MQTT-only and speak a different RPC dialect.
+    // Translate the v1-shaped method to the family's equivalent here so a
     // single choke point covers every caller (Matter, polling, UI).
     if (b01Q7Adapter.isB01Protocol(version)) {
       const model = this.adapter?.getProductAttribute?.(duid, "model");
@@ -291,21 +308,43 @@ class messageQueueHandler {
       // That is what #14 spent three rounds on: the timeout diagnostics
       // correctly reported total MQTT silence and thereby sent the reporter
       // after a Roborock-side fault, when the cause was this plugin speaking
-      // the wrong language into a working link. Refusing here says so at the
-      // one place that knows, and keeps the wire clean until #19 implements
-      // the dialect. Methods answered from NEUTRAL_RESPONSES never touch the
-      // wire, so they are left alone — refusing those would regress the
+      // the wrong language into a working link.
+      //
+      // Since 3.19.0 the Q10 dialect is spoken for COMMANDS: the datapoint
+      // write is built here and travels to the encoder in the options bag.
+      // READS stay refused, and that is a property of the dialect rather than
+      // unfinished work — a Q10 sends no RPC reply at all, so a read has
+      // nothing to resolve with. Serving one would hand the caller a value the
+      // robot never sent, and `mapStatusToV1` would publish that non-answer to
+      // Apple Home as the robot's state. A Q10's status comes from home data
+      // over HTTPS instead, a separate transport measured working in #14;
+      // reading it off pushed datapoint updates is the remaining half of #19.
+      //
+      // Methods answered from NEUTRAL_RESPONSES never touch the wire, so they
+      // are left alone either way — refusing those would regress the
       // room-mapping fix from 3.17.3, opened by this same reporter.
       if (family === b01Q7Adapter.B01_FAMILY.Q10 && !neutral) {
-        throw refusal(
-          "b01 q10 dialect unimplemented",
-          `${describeDevice(this.adapter, duid)} speaks the B01 Q10 dialect, which this plugin does not implement yet (see issue #19), so ${method} was not sent. Q10 models (${model || "ss*"}) use direct datapoint writes rather than the Q7 RPC envelope; sending the Q7 form would be discarded by the robot without reply.`
-        );
+        const q10 = b01Q10Adapter.translateOutgoing(method, params);
+
+        if (!q10) {
+          throw refusal(
+            "b01 q10 method unsupported",
+            `${describeDevice(this.adapter, duid)} speaks the B01 Q10 dialect, which has no equivalent for ${method}, so it was not sent. The Q10 dialect (${model || "ss*"}) writes numbered datapoints and sends no reply, so a request that exists to read a value cannot be answered over it; see issue #19.`
+          );
+        }
+
+        b01Q10Dps = b01Q10Adapter.buildDps(q10.dp, q10.params);
       }
 
-      const translated = b01Q7Adapter.translateOutgoing(method, params, family);
+      // A Q10 request is already fully encoded; running it through the Q7
+      // translation as well would overwrite `method` and `params` with the
+      // wrong dialect's names, and `set_custom_mode` would then be refused
+      // outright because the Q10 wind codes are not in the Q7 table.
+      const translated = b01Q10Dps
+        ? null
+        : b01Q7Adapter.translateOutgoing(method, params, family);
 
-      if (!translated) {
+      if (!b01Q10Dps && !translated) {
         if (neutral) {
           this.adapter.log.debug(
             `Method ${method} has no B01/Q7 equivalent for ${duid}; returning a neutral response.`
@@ -322,8 +361,10 @@ class messageQueueHandler {
         throw unsupported;
       }
 
-      method = translated.method;
-      params = /** @type {any} */ (translated.params);
+      if (translated) {
+        method = translated.method;
+        params = /** @type {any} */ (translated.params);
+      }
     }
 
     let useCloudConnection =
@@ -380,7 +421,8 @@ class messageQueueHandler {
       method,
       params,
       secure,
-      photo
+      photo,
+      b01Q10Dps ? { b01Q10Dps } : {}
     );
     const roborockMessage = await this.adapter.message.buildRoborockMessage(
       duid,
@@ -443,6 +485,29 @@ class messageQueueHandler {
               `No local connection to ${describeDevice(this.adapter, duid)}, so the ${method} request was not sent.`
             )
           );
+        } else if (b01Q10Dps) {
+          // THE Q10 DIALECT IS FIRE-AND-FORGET. It defines no RPC reply, so
+          // there is no acknowledgement to wait for and nothing to correlate
+          // against — upstream's own channel returns None. Registering a
+          // pending request here would arm a timeout that is guaranteed to
+          // expire on a perfectly healthy link, and reporting that expiry is
+          // exactly the false "the cloud has gone silent" diagnosis that cost
+          // #14 three rounds.
+          //
+          // Resolving means "the write left this plugin", not "the robot did
+          // it". Nothing downstream may treat it as confirmation: the state
+          // the tile shows still comes from the optimistic-state machinery,
+          // which self-corrects against what the robot actually reports.
+          this.adapter.rr_mqtt_connector.sendMessage(duid, roborockMessage);
+          this.adapter.updateTransportDiagnostics(duid, {
+            lastTransport: "cloud",
+            lastTransportReason: "b01-q10-fire-and-forget",
+            lastCommandMethod: method,
+          });
+          this.adapter.log.debug(
+            `Published B01 Q10 datapoint write for ${duid} with ${payload}. The Q10 dialect is fire-and-forget, so this is a publish confirmation and not a robot acknowledgement; no reply is expected.`
+          );
+          resolve(["ok"]);
         } else {
           // setup Timeout
           const requestTimeout = getRequestTimeout(

package/roborockLib/roborockAPI.js

@@ -4353,7 +4353,56 @@ class Roborock {
     return this._b01StatusState?.get(duid)?.lastV1Status || null;
   }
 
+  /**
+   * Say once per Q10 robot that its status does not come from this loop.
+   *
+   * Once per robot rather than once per poll: at the idle cadence the loop
+   * reaches this 144 times an hour, and a line repeated that often stops
+   * being read. The reader's question is not "was a request skipped" but
+   * "why is my tile not updating and where does its state come from" — so the
+   * notice answers that and points at the issue tracking the remaining half.
+   *
+   * @param {string} duid
+   * @returns {void}
+   */
+  noteB01Q10StatusPollNotAttempted(duid) {
+    if (!this._b01Q10StatusNoticed) {
+      this._b01Q10StatusNoticed = new Set();
+    }
+    if (this._b01Q10StatusNoticed.has(duid)) {
+      return;
+    }
+    this._b01Q10StatusNoticed.add(duid);
+    this.log.info(
+      `${this.describeDevice(duid)} speaks the B01 Q10 dialect, which sends no reply to a status read, so the dedicated B01 status loop does not poll it. Its state comes from the home data snapshot over HTTPS instead. This is a property of the dialect and not a fault; reading state from the datapoint updates the robot pushes is tracked in issue #19.`
+    );
+  }
+
   async refreshB01Status(duid, options = {}) {
+    // A Q10 (`ss*`) IS NOT POLLED AT ALL, and that gate belongs here rather
+    // than at the send choke point. The choke point already refuses
+    // `get_status` for a Q10 by name — correctly, since a fire-and-forget
+    // dialect cannot answer a read — but a request refused is still a request
+    // counted: the catch below incremented `consecutiveFailures` on every one
+    // and warned "B01 status has failed N times in a row" every tenth. At the
+    // 25-second idle cadence that is a warning every four minutes about a
+    // robot that is working exactly as designed, which is the same false alarm
+    // #14 spent three rounds chasing. Asking a question whose refusal is
+    // certain before it is asked is not a diagnostic.
+    //
+    // Returning null is what the throttle below already returns, so every
+    // caller handles it; no state entry is allocated either, and
+    // `getLastKnownLiveStatus` answers null for a Q10 as it does for a classic
+    // robot — "nothing known", never a value.
+    if (
+      b01Q7Adapter.b01FamilyForModel(
+        this.getProductAttribute(duid, "model")
+      ) === b01Q7Adapter.B01_FAMILY.Q10
+    ) {
+      this.noteB01Q10StatusPollNotAttempted(duid);
+      return null;
+    }
+
     // Q7/B01 status snapshot via prop.get, mapped to v1-shaped fields and
     // dispatched on the existing live-message path so the Matter accessory
     // updates exactly like it does for classic robots.