homebridge-roborock-matter 3.4.17 → 3.4.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -0
- package/README.md +22 -14
- package/package.json +1 -1
- package/roborockLib/roborockAPI.js +21 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,23 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 3.4.19
|
|
4
|
+
|
|
5
|
+
**Two things the README told users were not what had been measured.** No behaviour changes in this release; both are wording, and wording is what people choose a plugin on.
|
|
6
|
+
|
|
7
|
+
The feature table promised control "from the Home app, Siri, or automations". Nobody had ever checked the last word, and a user has now measured it: Apple Home does **not** offer sending a Matter vacuum to its dock as an automation action, which is why he had to move that part of his setup to a HAP-based plugin. The table no longer claims it, and a new [Automations in Apple Home](README.md#automations-in-apple-home) section says exactly what is known — the commands all work from the tile and from Siri, one automation action has been measured absent, and the rest is unverified rather than promised.
|
|
8
|
+
|
|
9
|
+
The fault-reporting section also blamed the "Report faults in Apple Home" setting for a tile that got stuck on "Updating…". A controlled test on the same robot, with fault reporting and dock-fault escalation both switched on and a genuinely empty clean-water tank, has now shown the tile staying in Ready throughout: the wedge was a stale pairing from an earlier install, which the Troubleshooting section already explained. The correction is written into the section rather than quietly deleted, because someone may have left the feature off on the strength of it. The same test also confirms the main finding more strongly than before — the fault was published beside a full Matter **Error** state this time, not just beside Charging, and Apple Home still drew nothing.
|
|
10
|
+
|
|
11
|
+
## 3.4.18
|
|
12
|
+
|
|
13
|
+
**A robot that drops off the Roborock cloud filled the log with stack traces about the plugin correctly deciding not to send.** When the transport a request would need is not there — the robot is marked offline, MQTT is down, or the local socket is not connected — the request queue declines to put it on the wire. That is a deliberate, calm decision, and it writes its own debug line where it happens. But the rejection then arrived at the error handler unclassified, so it was logged as a plugin error, with a full stack trace, once per poll, for as long as the condition lasted.
|
|
14
|
+
|
|
15
|
+
The shape it takes in a real log: a robot goes offline at 3:28 AM, and a single poll cycle produces six stack-traced errors in the same second, followed by one a minute after that. Nothing is wrong with the plugin in any of them.
|
|
16
|
+
|
|
17
|
+
These three refusals now go through the same throttle the request timeouts have always used: one warning, then a suppressed-count summary when the window reopens. Each reason keeps its own bucket, so a robot being offline does not silence the reporting of a separate MQTT outage. Errors that are genuinely the plugin's fault — including its failure to build a request at all — are untouched and still log with their stack.
|
|
18
|
+
|
|
19
|
+
`__tests__/refused-sends-are-not-plugin-errors.test.js` enumerates the rule over the source rather than over the three messages that were reported: every message the request queue can reject with must be one the classifier recognises, so a refusal path added later fails the test until it is classified. Verified red against 3.4.17: 10 of 15 failed.
|
|
20
|
+
|
|
3
21
|
## 3.4.17
|
|
4
22
|
|
|
5
23
|
**Installing this package asked npm to build it, and that build could only ever fail or warn.** `dist/` is in the published tarball and `main` points into it, so nothing a user installs needs compiling — but package.json still carried `"prepare": "npm run build"`, a hook npm runs at install time. The two things it could do to a user, both measured:
|
package/README.md
CHANGED
|
@@ -37,21 +37,21 @@ This is the most feature-packed, most thoroughly engineered Roborock plugin for
|
|
|
37
37
|
- 📍 **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.
|
|
38
38
|
- 🧭 **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.
|
|
39
39
|
- ⚡ **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.
|
|
40
|
-
- 🛡️ **Verified by Homebridge.** Reviewed and endorsed by the Homebridge team.
|
|
40
|
+
- 🛡️ **Verified by Homebridge.** Reviewed and endorsed by the Homebridge team. 571 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.
|
|
41
41
|
|
|
42
42
|
## Features
|
|
43
43
|
|
|
44
|
-
| |
|
|
45
|
-
| ----------------------------------- |
|
|
46
|
-
| 🤖 **Full control from Apple Home** | Start, stop, pause and send the robot home to its dock — from the Home app
|
|
47
|
-
| 🚪 **Clean specific rooms** | Pick rooms right in Apple Home, with the names you gave them in the Roborock app — multi-floor homes included
|
|
48
|
-
| 📍 **Live room tracking** | See which room the robot is cleaning right now, updated as it moves ([details](#live-room-tracking))
|
|
49
|
-
| 📊 **Honest cleaning progress** | Each room goes pending → cleaning → done — and a room only counts as done when the robot was actually there
|
|
50
|
-
| 🌀 **Cleaning & suction modes** | Vacuum / Mop / Vacuum + Mop on models that support it — plus optional Quiet / Balanced / Turbo / Max suction levels (Max+ on Q7)
|
|
51
|
-
| 🔋 **Battery & charging** | Battery level and charging state on the accessory ([one Apple-side caveat](#battery-percentage-in-apple-home))
|
|
52
|
-
| 🧠 **New models just work** | Brand-new Roborock models get sensible defaults automatically, and the plugin adapts to what each robot actually supports
|
|
53
|
-
| 🩺 **Built-in diagnostics** | Connection status, a one-click connection test, and a ready-to-share report if you ever need help
|
|
54
|
-
| 🔐 **Easy, safe login** | Sign in with your Roborock account right in the settings — two-factor supported, session stored encrypted
|
|
44
|
+
| | |
|
|
45
|
+
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
46
|
+
| 🤖 **Full control from Apple Home** | Start, stop, pause and send the robot home to its dock — from the Home app or Siri ([automations: one Apple-side limit](#automations-in-apple-home)) |
|
|
47
|
+
| 🚪 **Clean specific rooms** | Pick rooms right in Apple Home, with the names you gave them in the Roborock app — multi-floor homes included |
|
|
48
|
+
| 📍 **Live room tracking** | See which room the robot is cleaning right now, updated as it moves ([details](#live-room-tracking)) |
|
|
49
|
+
| 📊 **Honest cleaning progress** | Each room goes pending → cleaning → done — and a room only counts as done when the robot was actually there |
|
|
50
|
+
| 🌀 **Cleaning & suction modes** | Vacuum / Mop / Vacuum + Mop on models that support it — plus optional Quiet / Balanced / Turbo / Max suction levels (Max+ on Q7) |
|
|
51
|
+
| 🔋 **Battery & charging** | Battery level and charging state on the accessory ([one Apple-side caveat](#battery-percentage-in-apple-home)) |
|
|
52
|
+
| 🧠 **New models just work** | Brand-new Roborock models get sensible defaults automatically, and the plugin adapts to what each robot actually supports |
|
|
53
|
+
| 🩺 **Built-in diagnostics** | Connection status, a one-click connection test, and a ready-to-share report if you ever need help |
|
|
54
|
+
| 🔐 **Easy, safe login** | Sign in with your Roborock account right in the settings — two-factor supported, session stored encrypted |
|
|
55
55
|
|
|
56
56
|
## Quick start
|
|
57
57
|
|
|
@@ -119,10 +119,18 @@ Everything is configurable from the Homebridge UI. The essentials:
|
|
|
119
119
|
|
|
120
120
|
By default a robot that has stopped for any reason shows as **Ready** in Apple Home — whether it finished the job or is wedged under the sofa. Turning on **Report faults in Apple Home** changes that: a robot that is stuck, has a blocked brush or wheel, a missing dust bin, a flat battery or a dock it cannot reach reports the Matter **Error** state instead of Ready. It is off by default because a robot in Error may be refused a Start command by Apple Home.
|
|
121
121
|
|
|
122
|
-
**Dock and tank conditions are deliberately not reported, and this is worth explaining.** The plugin can read them all accurately — empty clean-water tank, full waste-water tank, missing dust bag, blocked air duct — and two releases tried to surface them through Matter's fault attribute (`OperationalError`).
|
|
122
|
+
**Dock and tank conditions are deliberately not reported, and this is worth explaining.** The plugin can read them all accurately — empty clean-water tank, full waste-water tank, missing dust bag, blocked air duct — and two releases tried to surface them through Matter's fault attribute (`OperationalError`). Four controlled tests on an S8 Pro Ultra with a genuinely empty clean-water tank showed it does not work: Apple Home drew no warning when the fault was published beside a Charging state, and drew no warning in the final test either, where the robot was raised all the way to the Matter **Error** state carrying "Clean water tank empty" — the tile simply kept reading Ready. **Apple Home does not appear to render Matter vacuum faults from a bridged accessory at all** — which is also why an earlier version removed the same write back in 1.4.61. Reporting them was therefore pure cost, and the attribute is no longer published in any configuration.
|
|
123
|
+
|
|
124
|
+
This section also used to blame the setting for a tile stuck on "Updating…", which was not caused by it: in the final test the same robot, with both switches on, stayed in Ready throughout. That wedge came from a stale pairing left behind by an earlier install — see [Troubleshooting](#troubleshooting). The correction is stated here rather than quietly deleted, because someone may have left the feature switched off on the strength of it.
|
|
123
125
|
|
|
124
126
|
A detached water tank or mop pad is never treated as a fault either: that is the normal, correct configuration for a vacuum-only run.
|
|
125
127
|
|
|
128
|
+
## Automations in Apple Home
|
|
129
|
+
|
|
130
|
+
Every command lives on the tile: start, stop, pause and send-to-dock all work from the Home app and from Siri, because the plugin implements Matter's own `RvcOperationalState` commands — including **GoHome**, which is exactly what the dock button sends.
|
|
131
|
+
|
|
132
|
+
What Apple offers _inside_ Home automations is a separate question, and it is Apple's to answer, not the plugin's. It has now been measured once, by a user in [#3](https://github.com/mathiashornbek/homebridge-roborock-matter/issues/3): Apple Home does **not** offer sending the vacuum to its dock as an automation **action** for a Matter vacuum. Whether it offers the other commands as actions, or a vacuum as an automation _trigger_, has not been verified here — so this README no longer claims automation support in either direction. If you want a schedule today, the honest answer is that it has to come from the Roborock app's own schedules, or from helper switches in a HAP-based plugin; this plugin is Matter-only by design and does not publish any.
|
|
133
|
+
|
|
126
134
|
## Battery percentage in Apple Home
|
|
127
135
|
|
|
128
136
|
Apple Home renders the battery percentage from pairing time and refreshes it only on a fresh read (commissioning, hub restart) — while charging state on the very same cluster updates live. This is not a plugin bug, and the root cause is now **confirmed in the source of matter.js** (the Matter stack Homebridge uses): the percentage attribute carries the spec's "changes omitted" quality, and matter.js currently never emits subscription reports for such attributes — while Apple Home never re-reads them on its own. The fix is tracked upstream in [matter-js/matter.js#4163](https://github.com/matter-js/matter.js/issues/4163) (an opt-in to report them anyway, which the spec permits); once it lands, Homebridge can enable it for bridged accessories and every plugin gets working battery percentages at once. Full investigation: [homebridge#3958](https://github.com/homebridge/homebridge/issues/3958).
|
|
@@ -143,7 +151,7 @@ The complete path — robot → plugin → Homebridge → matter.js store — wa
|
|
|
143
151
|
|
|
144
152
|
## Contributing
|
|
145
153
|
|
|
146
|
-
Model reports, diagnostics exports, and pull requests are very welcome. The codebase ships with
|
|
154
|
+
Model reports, diagnostics exports, and pull requests are very welcome. The codebase ships with 571 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.
|
|
147
155
|
|
|
148
156
|
## Support the project
|
|
149
157
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "homebridge-roborock-matter",
|
|
3
|
-
"version": "3.4.
|
|
3
|
+
"version": "3.4.19",
|
|
4
4
|
"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.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": {
|
|
@@ -3827,6 +3827,27 @@ class Roborock {
|
|
|
3827
3827
|
return "timeout";
|
|
3828
3828
|
}
|
|
3829
3829
|
|
|
3830
|
+
// `messageQueueHandler.sendRequest` declines to put a request on the wire
|
|
3831
|
+
// when the transport it would need is not there. It writes its own calm
|
|
3832
|
+
// debug line at the refusal site, so the rejection describes a transport
|
|
3833
|
+
// condition, not a plugin failure — logging it as an error with a stack
|
|
3834
|
+
// trace once per poll buried real problems whenever a robot dropped off
|
|
3835
|
+
// the Roborock cloud. Each reason keeps its own kind so that one outage
|
|
3836
|
+
// does not silence the reporting of another.
|
|
3837
|
+
if (/Not sending method .+ request\./.test(text)) {
|
|
3838
|
+
if (text.includes("is offline")) {
|
|
3839
|
+
return "device offline";
|
|
3840
|
+
}
|
|
3841
|
+
if (text.includes("Cloud connection not available")) {
|
|
3842
|
+
return "cloud unavailable";
|
|
3843
|
+
}
|
|
3844
|
+
if (text.includes("Local connection not available")) {
|
|
3845
|
+
return "local connection unavailable";
|
|
3846
|
+
}
|
|
3847
|
+
|
|
3848
|
+
return "transport unavailable";
|
|
3849
|
+
}
|
|
3850
|
+
|
|
3830
3851
|
if (text.includes("retry")) {
|
|
3831
3852
|
return "retry";
|
|
3832
3853
|
}
|