fang of vacuula: taking a Neato vacuum back from the cloud

The vendor shut down its servers, so the robot needs a new owner

fang of vacuula, formerly Brainslug, exists to repair a Neato robot vacuum so that it can be controlled locally after the shutdown of the Neato servers. The project's stated scope is to give your robot at least the same functionality as when you bought it, with the honest qualification that the project is in a development state.

That framing is the whole reason to read the project. A vacuum cleaner that needs a cloud service is a device with a shutdown date, and this is the community response to that date for one particular family of hardware.

The mechanics are unusual and are the interesting part. The robot's serial command interface is the one thing every Neato has, including the models that never had WiFi at all, and the project uses it. The network side of the conversation is moved onto a separate ESP32 device, which becomes the thing that talks to your WiFi, and the robot itself is driven over its serial port. The README states the consequence: since it is no longer the robot that connects to the WiFi, but the ESP device, the limitations the robot's own WiFi had are removed, and robots that originally had no wireless support still work.

So the cloud is not replaced by another cloud, it is replaced by a microcontroller you solder to a serial port. That is a very different kind of repair, and it is why the project ships soldering-level instructions per generation.

The licence is MIT, the primary language is TypeScript, the default branch is main, and the last push was on 2026-05-22. The releases are V1.1.1 in December 2025, v1.2 in March 2026 and V1.2.1 at the end of March 2026.

Four generations, and the hardware decides everything

Neato robots are grouped by generation, and the grouping exists because the firmware versions differ, so each generation needs its own configuration.

The gen1 group is the original XV line: XV11, XV12, XV14, XV21, XV RS/HP, XV signature and XV signature pro. The gen2 group is the Botvac line: D70, D75, D80 and D85, plus the Botvac Connected non-DX models 905-0249 and 905-0317. The gen3 group is the Connected Botvacs, D3 with 905-0321, 905-0437 and 905-0327, D4 with 905-0499 and 905-0514, D5 with 905-0358, 905-0357 and 905-0402, D6 with 905-0496 and 905-0517, and D7 with 905-0415 and 905-0537.

And then there is gen4, which is marked sadly not yet supported. The D800, and the D8, D9 and D10 Intelligent models with their part numbers. The reason given is that these robots use a completely different board, chip and firmware, and cannot be interfaced with directly. The workaround the project proposes is to wire an ESP32 to the button itself, and it asks for help on Discord or in the discussions.

The gen1 group is in a different position again. The README says the team is still working out the best way to connect those robots, and invites people to join the Discord where that experimentation is happening, which is a candid admission that the oldest hardware is the hard case.

So the practical triage for anyone with a robot on the shelf is straightforward: check the model number against the three lists, and if it is a D8, D9 or D10 Intelligent, this project cannot help you yet.

The feature matrix, with the gaps marked by the release that will fill them

The README carries a per-generation feature table, and the footnotes under it are the most useful part, because they say when the missing features are coming.

Start and stop works on all three generations, and so does checking errors. Status is marked as limited functionality for gen1 and gen2 and fully supported for gen3, and editing settings is not supported at all on gen1. Scheduling on the robot through its own screen works on gen1 and gen2 but not on gen3, while scheduling via ESPHome and scheduling via a Home Assistant automation work everywhere, the latter two with the footnote that Home Assistant is required. Notifications also work on all three, again with the Home Assistant footnote.

The three features that are missing in some generations carry numbered footnotes that name a release. Return to start is unavailable on gen1 and gen3, and return to dock is unavailable on gen1 and gen2, both marked with footnote 3, which says support can be added by version 2. Manual driving is unavailable on gen1 and gen2, marked with footnote 2, which says support can be added by version 1.

That is a rare and good thing to see in a hobby project: the gaps are not hand-waved, they are numbered and scheduled, and the table tells you which robot you need to buy for a given feature. If you want a vacuum you can drive manually, the table says gen3 and only gen3, which is a much more useful answer than a general statement that some features are missing.

The status of the project itself is kept in a separate status.md file, which the README points to for project status, roadmap and the meaning of the version numbers.

The ESP32 in the middle, and the firmware version you have to match

You need an ESP device, and the README is specific about which ones, because a bad choice costs an evening.

The ESPs recommended by ESPHome will all work and have prebuilt files for easy installation: the ESP32, the ESP32S3 and the ESP32C3. The warning that follows is that some ESP devices that are very cheap and small should be avoided, since they have some defects and need to use a lower power output on the WiFi signal. The supported-esp32.md file has the detail, and it is the file to read before buying anything.

There is also a firmware constraint, and it is not negotiable. The project parses the data from the serial interface, so the robot's firmware has to be on a version that has been confirmed working. For gen2 that is 2.2.0 or 2.2.1, and for gen3 it is 4.5.3 or 4.6.0, with a note that many 4.X.X versions will work. If your robot is on another version, the README asks you to get in touch rather than guessing.

To find out which robot you have and what it is running, the project points at the Vacuula Tools web app, with a link to a page that identifies the robot. That tool is the first step of the install, and it is the same application that is linked from the header as the project's site.

The ESP32 then takes over the network side. It connects to your WiFi, and the robot no longer has to.

Why this works on robots that never had WiFi

The README explains the reasoning in a paragraph, and it is the argument that makes the whole project sound.

The reason it works on all Neato robots is that they all have the command interface, even the robots that originally don't have any WiFi will still work, since it is no longer the WiFi robot that is connecting to the WiFi, it is the ESP device. This also removes any limitations the robot's own WiFi may have had.

Read that as an engineering decomposition. The robot's serial interface is the stable contract, and it is the only part of the system the vendor's shutdown could not take away. Everything above it, the radio, the protocol, the cloud account, the app, is the part that was proprietary and got switched off. The project replaces the whole upper half with a microcontroller you can program, and keeps the lower half, which is the part that actually knows how to drive the brushes, the dock and the bumper.

There is a second-order effect worth noting. Because the ESP32 is a general-purpose board, the robot can be driven by whatever the ESP32 can talk to, which is how the project reaches Home Assistant, ESPHome and a Home Assistant automation for scheduling, and why the feature matrix marks those entries as requiring Home Assistant. The robot is no longer a device with an app, it is a device with a serial port and an ESP32 next to it, and everything else is a client.

That also explains the shape of the project. The repository is mostly documentation and firmware images, not an application, because the application is the ecosystem around the ESP32.

Two install routes, and the project recommends Home Assistant

There are two documented ways to use the repair, and they are separate documents in the repository root: install-no-ha.md for running without Home Assistant, and install-ha.md for running with it.

The author's recommendation is explicit, and it comes with a reason rather than a preference. If you don't mind to tinker a little, they recommend the Home Assistant route, described as an open source home automation tool that puts local control and privacy first, with links to its website, a live demo, its installation guides and its help forum, and pointers to the YouTube guides and forums for it.

The Home Assistant route therefore gets scheduling, notifications and the automation features in the feature matrix, and it is the route the footnotes point at.

One requirement changes with version 2. From version 2 of the project, when ROS is used for getting a floormap, you will need a separate computer running ROS, and the easiest and prioritised way to set that up will be via Home Assistant. The floormap itself is described as being in the making, with the ability to create, view and edit floormaps so the robot can have the same functionality with no-go lines and zones.

Support is offered in three places, and the README names them: the discussions section of the repository, the project's Discord, and the Home Assistant help forum.

A repository that is mostly documentation, and a beta branch scheme

The top-level listing explains the project form. There is the README, and then a set of documents that are the actual product: faq.md, manual.md, status.md, supported-esp32.md, ha-images.md, install-ha.md, install-no-ha.md, and a separate install guide per ESP generation in install-esp-device-gen2.md and install-esp-device-gen3.md.

Alongside them are the parts of a working system: a build/ directory, a config/ directory, a webserver/ directory, a brainslug-tools/ directory which is the browser tool used to identify a robot, an assets/ directory, a pics/ directory, and a research/ directory.

The beta scheme is spelled out, and it is worth knowing before you clone. The main branch has the code and the guide for the latest release, and the next branch carries the latest beta. Where a feature is on its way into a beta but is not in one yet, it lives on a branch named next/<feature name>. The config files for the betas live in the config folder instead of the releases tab, and the links in the different guides point there. So a guide is not a single stable artefact, it is a pointer that changes shape depending on which branch the configuration comes from.

Two small things in the listing are worth a mention. The project was renamed, from Brainslug to fang of vacuula, and the discussions link in the README still points at the older repository name, Philip2809/neato-connected, so the history is still visible from the links. And the beta and release processes are documented in files that sit next to the install guides rather than in a wiki, which is the right place for something a contributor needs to follow.

Editorial conclusion

Adopt fang of vacuula if you own a Neato or Botvac that no longer talks to the vendor's servers and you are prepared to open it up and wire in an ESP32, because the serial command interface is the only route left and this project has already done the work for three generations of robot. Do not adopt it if your robot is a D8, D9 or D10 Intelligent, because the README says those use a different board, chip and firmware that cannot be interfaced with directly, and do not expect the Home Assistant route to be plug and play, since the base robot has to be flashed first. Before you start, check the firmware version of your robot against the table of confirmed versions, because the data is parsed from the serial interface and a mismatch will not work, and read status.md, which is where the project keeps its roadmap and the meaning of its version numbers.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vacuula/fang on GitHub