Recovery after a service ends
Neato after the cloud shutdown: what can you recover?
Manual cleaning, a conditional exchange and community bridges offer different outcomes. Your model matters—and a planned server is a separate proposition.
Start with the model, then the feature
A robot starting a cleaning run is not the same as recovering schedules, maps or no-go areas. The options below have different prerequisites. We checked vendor and project documents, then reconstructed seven D7 accounts: five community recovery attempts, one exchange complaint and one separate non-bridge comparison. These selected accounts do not establish how often recovery succeeds.
Physical-button cleaning
The vendor says a physical-button full-house cleaning run remains available after cloud withdrawal. This is a limited fallback, not restoration of app features.
Warranty commitments
The announcement says manufacturer warranty commitments remain intact; it does not establish eligibility for an individual owner.
European exchange: eligibility first
The published European exchange covers purchases since May 2023 with active cloud-feature use, offering a current Kobold VR7 in exchange. Support must check eligibility; fulfillment and Swedish availability have not been independently verified.
OpenNeato: D3–D7 bridge
OpenNeato documents D3–D7 support and explicitly excludes D8, D9 and D10. It requires an ESP32 bridge connected to the debug port.
OpenNeato: implemented versus planned
The project labels itself early beta. Its documentation lists local scheduling but describes zone cleaning and no-go lines as work in development. Do not present those planned features as restored.
Fang: hardware generations differ
Fang distinguishes hardware generations and marks D8–D10 unsupported. Its generation-specific feature table is narrower than the ambition to recover original functionality.
Fang: schedules are not maps
Fang documents scheduling through ESPHome and Home Assistant paths, with separate firmware compatibility requirements. Floor-map editing, no-go lines and zones are described as under development.
Separate proposed server
A separate Vacuula server proposal claims hardware-free recovery including newer models. This check did not establish a released server or successful newer-model restoration. The existing Fang bridge compatibility table does not prove the proposed server compatibility.
What happened in the selected D7 accounts?
Issue threads contain multiple people. A closed issue does not mean every reporter recovered. Each entry below follows one account; model and version details are included only where established.
Start commands failed; final outcome unknown
D7 initially reported House/Spot commands failing with error 234; command testing followed. Issue closure is not an owner-confirmed durable recovery. No verified final owner update; maintainer later said original reporter stopped responding.
Reported recovery, uncertain cause
D7 owner reported scheduled cleaning failure, then apparent disappearance after sensor cleaning, log clearing and prolonged battery disconnection. Multiple simultaneous actions; duration after recovery unknown. A planned firmware update is not confirmed installed.
Two weeks with a custom workaround
D7 owner reported recurrent error despite clearing errors and prolonged battery disconnection; a custom external scheduler checking error state and restarting commands reportedly ran without incident for two weeks. Self-report; extra Linux automation; not proof of stock scheduler reliability or long-term resolution.
Hardware modification did not remove the error
D7 owner tested a voltage-regulation modification with ESP32-C3; the later update still reported the no-motion error. No final recovery reported in this issue; electrical modification not tested or recommended by publication.
Reported exchange refusal based on purchase date
Owner reports purchase in November 2018, application on 7 July 2026 and refusal citing purchase before May 2023. The complaint is dated 12 August 2026. Public first-person allegation; correspondence not independently examined. Legal accusations not adopted. No later completed exchange established.
Power loss after bridge installation and removal
Reported browser control after D7 bridge installation, removed bridge because cables prevented closing the robot, then no LEDs or apparent power-up; battery disconnection reportedly did not restore it; later chose a replacement robot. Firmware, bridge version, electrical diagnosis and causal mechanism unknown. No verified repair or proof that software/bridge caused damage.
Separate comparison: power loss without a bridge
Separate D7 account reported briefly lighting then going dark after opening and reassembly, without service-port or ESP32 work. Suspected an accidental electrical short, without confirming diagnosis. Not a bridge recovery attempt; context comparator only. Speculated cause unverified; no repair or follow-up duration established.
Choose the route you can actually use
- If basic cleaning is enough, the documented physical-button fallback avoids a community installation. It does not restore the app.
- For the exchange, purchase date and prior cloud use are explicit conditions. Swedish fulfillment remains unverified here; ask the official support channel to check your case before assuming a replacement.
- For a D3–D7 bridge, check the exact firmware and needed features. Scheduling and map restrictions are separate capabilities. The selected owner evidence here covers only D7.
- For D8–D10, the two inspected bridge projects exclude these models. A separate server proposal is not proof of released support or a reason to buy unsupported hardware.
What changed in version 2?
13 October 2026: added the power-loss account and a separate non-bridge comparison. A reported sequence does not establish an electrical cause. These entries broaden the selected outcomes without supporting a failure rate.
Sources and limits
Documents checked 13 October 2026. Owner accounts are self-reports, not inspected robots. Two problem-selected issue threads yielded four model-specific recovery attempts and two additional accounts whose models were not established; the latter are excluded from the D7 entries. A third problem-selected thread added one D7 bridge attempt ending in reported power loss and one separate D7 account with power loss after opening without a bridge. The latter is a context comparison, not a bridge attempt. One separate exchange complaint was added. No failure or success rate can be calculated. Attachments and correspondence were not independently examined. We have no verified completed exchange, no D3–D6 outcome sample and no long-term comparison of bridge reliability. Proposed server availability remains unverified.