Verification Request: homebridge-dyson-vis-nav

Plugin Name

homebridge-dyson-vis-nav

Link To GitHub Repo

https://github.com/rummeyer/homebridge-dyson-vis-nav

Plugin Icon (Optional)

No response

The plugin does not offer the same nor less functionality than that of any existing verified plugin.

🟢 Yes

The plugin successfully installs and does not start unless it is configured.

🟢 Yes

The plugin does not require the user to run Homebridge in a TTY or with non-standard startup parameters, even for initial configuration.

🟢 Yes

The plugin does not contain any analytics or calls that enable you to track the user.

🟢 Yes

If the plugin needs to write files to disk (cache, keys, etc.), it stores them inside the Homebridge storage directory.

🟢 Yes

The plugin does not throw unhandled exceptions, the plugin must catch and log its own errors.

🟢 Yes

More Information

What it does

Exposes the Dyson 360 Vis Nav robot vacuum to Apple Home as a native Matter
robot vacuum cleaner, using the Matter support added in Homebridge 2.0. It
connects through Dyson's AWS IoT MQTT gateway, which is the only way to reach
this model — unlike the older 360 Eye and 360 Heurist, the Vis Nav does not
accept local connections.

How it differs from existing verified plugins

The two verified Dyson plugins, homebridge-dyson-pure-cool and
homebridge-dyson-bp01, cover air treatment devices. No verified plugin covers
a Dyson robot vacuum, which is a different device class, a different protocol
and a different Matter device type.

The approach itself is not novel here — homebridge-roborock-matter,
homebridge-xiaomi-roborock-matter and homebridge-aeg-robot-matter are
already verified and present their robots the same way. This does for Dyson what
those do for their manufacturers.

The reason it has to be done this way is that HAP has no robot vacuum service at
all. Apple added robot vacuums to the Home app through Matter rather than to
HomeKit, so plugins predating Homebridge 2.0 could only present a vacuum as a
fan or a set of switches. This plugin publishes the RoboticVacuumCleaner device type with the
rvcRunMode, rvcCleanMode, rvcOperationalState, serviceArea and
powerSource clusters, so the robot appears as what it is: start, pause,
resume, return to dock, cleaning modes, battery and charging state, per-room
cleaning, and faults reported in the Home app's own vocabulary rather than as a
generic error.

Two things a reviewer should know up front

Matter must be enabled on whichever bridge the plugin runs on. Because there
is no HAP equivalent, the plugin cannot expose anything without it: it logs a
clear error saying so and does nothing further, rather than registering a
misleading accessory. The README recommends giving the plugin its own child
bridge and enabling Matter there, which leaves the user's main bridge untouched.

The robot pairs separately. Apple Home does not accept bridged robot
vacuums, so Homebridge publishes it as a standalone Matter node with its own
pairing code. This is Homebridge's own handling of external accessories, not
something the plugin arranges, but it does mean the robot is not added along
with the Homebridge bridge. The README covers this as its own numbered step.

Testing

CI builds, lints and runs the checks on Node 22, 24 and 26
Three checks beyond the compiler cover what a Homebridge plugin needs but no
compiler can see: the settings-UI flags and file layout, the configuration the
custom UI hands to the Dyson client, and that the custom UI's server process
starts and signals ready
A recorded MQTT session from a physical Vis Nav is replayed in CI through the
device layer, checking it reaches every state it is known to reach — cleaning,
mapping, docking, charging, faults — with nothing logged as a warning or error
Verified end to end against a physical Dyson 360 Vis Nav paired with the Apple
Home app
On maturity, so it is not something you have to discover: the plugin was
published recently and has been exercised against one physical robot. The Dyson
protocol layer is not new code — see below — but the Matter layer is.

Credit

The Dyson cloud API and MQTT protocol handling is carried over from
matterbridge-dyson-robot
by Alexander Thoukydides, under its ISC licence, with the import paths rewritten
and the scope narrowed to this one model. The repository keeps a tool and a
documented procedure for adopting upstream fixes, so the two do not drift.
Attribution is in the licence, the README and every ported file.

Start with the linked plugin repository and review its README, Matter setup, custom UI checks, configuration handoff, and device-layer MQTT replay. Run the CI checks described in the request across the supported Node versions, then verify the recorded device states and the stated Homebridge verification requirements. Done means the evidence supports verification without unresolved errors or missing criteria.