homebridge-roborock-matter 3.4.7 → 3.4.8

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 3.4.8
+
+**Selecting "Vacuum" and getting a vacuum-and-mop was not a display bug — one timed-out command cancelled the one that mattered.** skmzwanke reported in [#8](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/8) that he selected Vacuum for a single room and the robot mopped it anyway, and his 3.4.5 log names the cause outright.
+
+On a v1 robot the difference between "Vacuum" and "Vacuum and mop" **is** the water-box mode: choosing Vacuum sends water-box OFF. Fan power only picks a suction level within the chosen mode. The prep sequence sent fan power first and, if that command timed out, returned — so the water command was never sent at all. In his log, `set_custom_mode` timed out after two seconds, `set_water_box_custom_mode` never appeared, and the robot kept the mopping setting it already had from the Roborock app. A cosmetic command that did not answer in time cancelled the one carrying the user's actual choice.
+
+- **The water command now goes out first, and no command in the sequence is cancelled by another's failure.** Dropping the early return cannot delay the start: the caller already races the whole prep against its own timeout, so the early return was buying latency protection that was paid for one level up.
+- **A partial apply is now announced at warn level**, naming the robot and what was not confirmed. It was a debug line before, which meant that on a default log level the robot simply did the wrong job in silence while the Matter tile reported the mode that had been selected. That mismatch took two rounds of #8 to pin down.
+- **The rule is enumerated over the sequence, not over the two commands in it today:** no clean-mode prep command may return out of the middle of the sequence. A third setting added later is covered by construction.
+
 ## 3.4.7
 
 **The diagnostic report told Q7 owners their robot had tried to reach the LAN and failed. It never tried.** Following [#7](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/7), jawnlydon unpaired his robot from Apple Home, uninstalled the plugin, reinstalled it and paired fresh — and his report still read `markedRemote: true`, `remoteReason: marked-remote-after-connect-failure`, `connectionStatus: Cloud fallback`, "usually because LAN TCP was not connected at that moment". His `roborock.vacuum.sc05` speaks the B01 protocol, which has no LAN request surface at all: the plugin marks these robots cloud-only at startup precisely so it never opens a local socket to them. Every line above described a network fault that could not occur, and he spent an evening chasing it.

package/package.json

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

@@ -2355,6 +2355,49 @@ class Roborock {
       return;
     }
 
+    // The water command goes first, and no failure below cancels a later
+    // command.
+    //
+    // On a v1 robot the difference between "Vacuum" and "Vacuum and mop" IS
+    // the water-box mode: selecting Vacuum sends water-box OFF. Fan power is a
+    // suction level *within* the chosen mode. The fan command used to run
+    // first and, on timeout, return — skipping the water command entirely. So
+    // skmzwanke selected Vacuum in Apple Home, the fan command timed out after
+    // two seconds, the water command was never sent, and his Saros 10 ran a
+    // vacuum-and-mop over the room he had asked to be vacuumed (#8). A
+    // cosmetic command that did not answer in time cancelled the one that
+    // carried the user's actual choice.
+    //
+    // Dropping the early return cannot run the start command late: the caller
+    // races this whole sequence against its own prep timeout, which is what
+    // bounds the delay. The early return was buying latency protection that
+    // was already paid for one level up.
+    const failedCommands = [];
+
+    if (Number.isInteger(settings?.waterBoxMode)) {
+      const waterCommands = this.getMatterWaterModeCommandCandidates(duid);
+
+      if (waterCommands.length === 0) {
+        this.log.debug(
+          `Matter clean mode requested water mode ${settings.waterBoxMode} for ${duid}, but no supported Roborock water command was detected.`
+        );
+      } else {
+        try {
+          await this.runFirstMatterSettingCommand(
+            duid,
+            waterCommands,
+            settings.waterBoxMode,
+            commandOptions
+          );
+        } catch (error) {
+          failedCommands.push("water mode");
+          this.log.debug(
+            `Matter clean mode water commands failed for ${duid}; continuing with start command. ${error.message || error}`
+          );
+        }
+      }
+    }
+
     if (
       Number.isInteger(settings?.fanPower) &&
       this.getMatterCleanModeCapabilities(duid).canControlFanPower
@@ -2372,40 +2415,21 @@ class Roborock {
           "set_custom_mode",
           error
         );
-        if (this.isMatterSettingTimeoutError(error)) {
-          this.log.debug(
-            `Matter clean mode fan command timed out for ${duid}; skipping remaining clean-mode prep and continuing with start command. ${error.message || error}`
-          );
-          return;
-        }
+        failedCommands.push("suction level");
         this.log.debug(
           `Matter clean mode fan command failed for ${duid}; continuing with start command. ${error.message || error}`
         );
       }
     }
 
-    if (!Number.isInteger(settings?.waterBoxMode)) {
-      return;
-    }
-
-    const waterCommands = this.getMatterWaterModeCommandCandidates(duid);
-    if (waterCommands.length === 0) {
-      this.log.debug(
-        `Matter clean mode requested water mode ${settings.waterBoxMode} for ${duid}, but no supported Roborock water command was detected.`
-      );
-      return;
-    }
-
-    try {
-      await this.runFirstMatterSettingCommand(
-        duid,
-        waterCommands,
-        settings.waterBoxMode,
-        commandOptions
-      );
-    } catch (error) {
-      this.log.debug(
-        `Matter clean mode water commands failed for ${duid}; continuing with start command. ${error.message || error}`
+    // At warn level on purpose. The clean is about to start and the Matter
+    // tile will report the mode the user selected, so a silent partial apply
+    // leaves the tile stating something the robot is not doing. That mismatch
+    // is exactly what took two rounds of #8 to pin down, and the log is where
+    // the next person will look.
+    if (failedCommands.length > 0) {
+      this.log.warn(
+        `Roborock did not confirm the ${failedCommands.join(" and ")} for ${this.describeDevice(duid)} before starting; the robot may keep its previous settings for this run, so the clean may not match the mode selected in your controller.`
       );
     }
   }
@@ -2521,11 +2545,6 @@ class Roborock {
     ].some((pattern) => message.includes(pattern));
   }
 
-  isMatterSettingTimeoutError(error) {
-    const message = `${error?.message || error || ""}`.toLowerCase();
-    return message.includes("request") && message.includes("timed out after");
-  }
-
   /**
    * Self-healing capability detection for periodic poll commands: once a
    * robot definitively answers a request with an "unsupported"-class error,