Buying Guides
Valetudo Supported Robot Vacuums List (2026)
Valetudo supported robots in 2026: buyer matrix by ARM binary tier, secure boot notes, root toolchain (UART/USB/laptop), and privacy-focused LAN segmentation.
Quick answer: Which robot vacuums are supported for Valetudo in 2026?
Only models listed on the official Supported Robots page—currently spanning Xiaomi, Dreame, MOVA, Roborock, Viomi, Eureka, Cecotec, Proscenic, Commodore, and IKOHS rebrands—each with a documented root path. Use the ARM binary tier (armv7 vs aarch64) plus secure-boot notes to pick the right firmware bundle, then isolate the vacuum on an IoT VLAN with MQTT to Home Assistant.
Source: Valetudo
Executive summary
If you are optimizing for data ownership, Valetudo is one of the few credible ways to keep LiDAR maps, schedules, and telemetry off a vendor cloud while retaining a modern robot vacuum feature set1. The blocker for most privacy-focused shoppers is not enthusiasm—it is SKU archaeology: vendors recycle names, silently swap PCBs, and patch root chains after disclosures2.
Bottom line: treat Valetudo compatibility like a hardware compatibility list, not a marketing checkbox. Buy only after reconciling retail naming with the exhaustive upstream roster, then plan rooting tools (UART adapter, breakout PCB, or laptop-only workflows) the same way you would plan a router flash3.
This guide compresses that roster into a buyer matrix: ARM artifact tier (armv7, armv7-lowmem, aarch64), secure boot flags where documented, typical root interfaces, and privacy-oriented deployment notes that tie into our broader local-first smart home editorial baseline (MQTT broker choices, IoT VLAN pattern, WAN blocking discipline).
Live upstream list versus this matrix
The phrase “live-updated” in SEO copy often implies a continuously synced database. In this repository we publish periodically refreshed editorial snapshots with citations to upstream sources. Device support reality changes when vendors ship silent revisions or when maintainers add or retire models2.
Before you spend money, open the canonical Supported Robots page on valetudo.cloud and verify:
- The exact marketing cluster you are considering appears verbatim (not “close enough”).
- The install doc for your vendor still lists the same prerequisites (UART PCB, disassembly depth, laptop-only paths).
- Any bold warnings about duplicate product names (common with Dreame/MOVA/Xiaomi lines) still match the unit you can physically inspect.
If your candidate fails any step, assume unsupported until proven otherwise—privacy gains evaporate the moment you are forced back to a cloud app.
How to read the deployment columns
“Valetudo binary” (CPU tier)
Upstream labels builds as armv7, armv7-lowmem, or aarch64. Think of this as the instruction set architecture bucket for the official binary you will deploy—not a cute nickname for vacuum polish. It matters for RAM assumptions, performance headroom, and whether some auxiliary tooling behaves subtly differently on 32-bit userspace.
Secure boot
Where present, secure boot indicates additional bootloader constraints that interact with how rooted firmware is applied and updated2. When upstream marks “yes (since FW …)”, interpret that as your shopping homework: firmware level and manufacturing era matter as much as box art.
Typical root interface (summary band)
This column compresses multi-page procedures into routing guidance. It is not a substitute for the official install guide—use it to decide whether you are willing to own UART work, full disassembly, or mostly USB-and-laptop workflows before you buy4.
Vendor ecosystem overview
The vacuum industry rarely exposes clean SoC branding in retail listings. Instead, upstream docs cluster robots by vendor firmware/cloud emulation stacks that Valetudo replaces2. The table below maps those stacks to tooling flavors you should budget for.
| Vendor cluster | What Valetudo is emulating/replacing | Typical physical tooling | Privacy-relevant notes |
|---|---|---|---|
| Dreame + Xiaomi(Dreame OEM) + MOVA | Dreame-class Linux firmware + miio-era conventions | 3.3 V USB UART + Dreame breakout PCB; minimal disassembly on many models | Strong feature sets; watch duplicate model names and secure-boot milestones tied to firmware builds2. |
| Roborock + Xiaomi V1 (Roborock) | Roborock-era chains | Laptop-first routes on older manufacturing bands; full disassembly on many newer roots | Excellent historical platform; manufacturing dates and NAND vendor changes decide feasibility (ex.: Q7 Max notes)2. |
| Viomi + Xiaomi Vacuum-Mop P + CRL-200S rebrands | Viomi / 3irobotix-style stacks | Linux laptop + micro USB; sometimes reflash to Viomi V6 firmware for parity | Multiple retail skins hide identical CRL-200S hardware—good for spare parts, tedious for naming confusion2. |
| Eureka (Midea) | Eureka-specific maintained roots | Linux laptop + USB cable on documented models | Attractive when you want USB-centric workflows versus UART-first Dreame habits2. |
Model matrix: Xiaomi, Dreame, and MOVA
The rows below mirror the Supported Robots inventory as of this article’s publish date2. Copy/paste candidate SKUs into upstream pages before purchasing—especially for imports where retailer titles truncate sub-versions.
| Model | Valetudo binary | Secure boot (per upstream) | Typical root interface band |
|---|---|---|---|
| Xiaomi V1 | armv7 | — | Laptop-first before 2020-03 manufacturing; disassembly path later2. |
| Xiaomi 1C | armv7 | no | UART + breakout PCB; only dreame.vacuum.mc1808 revision is supported2. |
| Xiaomi 1T | aarch64 | no | UART + breakout PCB2. |
| Xiaomi P2148 | aarch64 | no | UART + breakout PCB2. |
| Xiaomi Vacuum-Mop P | armv7 | — | Linux laptop + USB; avoid viomi.vacuum.v8 bricking trap2. |
| Xiaomi Vacuum-Mop 2 Ultra | aarch64 | yes (since FW 1167) | UART + breakout PCB2. |
| Xiaomi X10 Plus | aarch64 | yes | UART + breakout PCB2. |
| Dreame D9 | armv7-lowmem | no | UART + breakout PCB; not D9 Max2. |
| Dreame D9 Pro | armv7-lowmem | no | UART + breakout PCB (ported D9 firmware storyline)2. |
| Dreame F9 | armv7 | no | UART + breakout PCB2. |
| Dreame L10 Pro | aarch64 | yes (since FW 1138) | UART + breakout PCB2. |
| Dreame Z10 Pro | aarch64 | yes (since FW 1156) | UART + breakout PCB2. |
| Dreame W10 | armv7-lowmem | no | UART + breakout PCB; docking ergonomics complicate UART timing2. |
| Dreame W10 Pro | aarch64 | yes | UART + breakout PCB; secure-storage cloudKey quirks documented upstream2. |
| Dreame L10s Ultra | aarch64 | yes | UART + breakout PCB; distinguish from unsupported L10s Ultra Gen2 naming collision2. |
| Dreame D10s Pro | aarch64 | yes | UART + breakout PCB; not non-Pro D10s2. |
| Dreame D10s Plus | aarch64 | yes | UART + breakout PCB; not D10 Plus without “s”2. |
| Dreame L10s Pro Ultra Heat | aarch64 | yes | UART + breakout PCB; upstream documents MCU/Linux mismatch remediation via SSH OTA-style fixes2. |
| Dreame L20 Ultra | aarch64 | yes | UART + breakout PCB; serial R2394 vs R2253 rootability split for visually identical units2. |
| Dreame X30 Ultra | aarch64 | yes | UART + breakout PCB2. |
| Dreame L40 Ultra | aarch64 | yes | UART + breakout PCB; watch fake “L40” rebadges upstream warns about2. |
| Dreame X40 Ultra | aarch64 | yes | UART + breakout PCB; negative deviceId miio edge case documented for recent manufacturing2. |
| Dreame X40 Master | aarch64 | yes | UART + breakout PCB; same miio deviceId caveat cluster as other late-2025 Dreame notes2. |
| MOVA Z500 | armv7 | no | UART + breakout PCB2. |
| MOVA S20 Ultra | aarch64 | yes | UART + breakout PCB2. |
| MOVA P10 Pro Ultra | aarch64 | yes | UART + breakout PCB; not P10 Ultra2. |
UART ergonomics are “privacy relevant” in the practical sense: jobs that never get finished usually revert to cloud apps—exactly the telemetry path you are trying to starve.
Model matrix: Roborock and Viomi
Roborock entries skew toward time-consuming physical access compared with many Dreame UART workflows2. Budget trays, lighting, and patience—not just software hygiene—before committing.
| Model | Valetudo binary | Secure boot (per upstream) | Typical root interface band |
|---|---|---|---|
| Roborock S5 | armv7 | — | Laptop-centric paths; keep firmware ≥ 2008 for segment features2. |
| Roborock S6 | armv7 | — | Full disassembly; maintainer warns experience may be subpar versus personally owned units2. |
| Roborock S6 Pure | armv7-lowmem | — | Full disassembly; same subpar caveat2. |
| Roborock S4 | armv7 | — | Full disassembly2. |
| Roborock S4 Max | armv7-lowmem | — | Full disassembly2. |
| Roborock S5 Max | armv7-lowmem | — | Full disassembly2. |
| Roborock S7 / S7+ | armv7-lowmem | — | Full disassembly; mop module increases mechanical risk2. |
| Roborock S7 Pro Ultra | armv7-lowmem | — | Full disassembly2. |
| Roborock Q7 Max / Q7 Max+ | armv7-lowmem | — | Full disassembly; SkyHigh NAND manufacturing split may block rooting even though procedure is safe2. |
| Viomi V6 | armv7 | — | Linux laptop + USB2. |
| Viomi SE | armv7 | — | Linux laptop + USB2. |
If you already standardize on segmented LAN policy, pair this hardware decision with our walkthrough for blocking stranded IoT WAN leaks—DNS overrides alone rarely tame aggressive gadgets (guide).
Model matrix: Eureka, CRL-200S rebrands, and specialty listings
These rows capture Midea Eureka SKUs plus CRL-200S derivatives sold under budget regional brands2. They are frequently overlooked in English-language threads despite being fully documented upstream.
| Model | Valetudo binary | Secure boot (per upstream) | Typical root interface band |
|---|---|---|---|
| Eureka J15 Max Ultra | aarch64 | — | Linux laptop + USB cable2. |
| Eureka J15 Pro Ultra | aarch64 | — | Linux laptop + USB cable2. |
| Eureka J15 Ultra | aarch64 | — | Linux laptop + USB cable2. |
| Eureka J12 Ultra | aarch64 | — | Linux laptop + USB cable2. |
| Eureka E20 Evo Plus | aarch64 | — | Linux laptop + USB cable2. |
| Eureka E20 Plus | aarch64 | — | Linux laptop + USB cable2. |
| Cecotec Conga 3290 | armv7 | — | CRL-200S hardware; reflash to Viomi V6 stack per upstream2. |
| Cecotec Conga 3790 | armv7 | — | CRL-200S hardware; reflash to Viomi V6 stack per upstream2. |
| Proscenic M6 Pro | armv7 | — | CRL-200S hardware; reflash to Viomi V6 stack per upstream2. |
| Commodore CVR 200 | armv7 | — | CRL-200S hardware; reflash to Viomi V6 stack per upstream2. |
| IKOHS Netbot LS22 | armv7 | — | CRL-200S hardware; reflash to Viomi V6 stack per upstream2. |
CRL-200S clones illustrate why privacy shopping must be SKU literal. The exterior plastics mean nothing; only the documented hardware lineage earns VLAN trust.
Verification traps worth a highlighted row
Some cautions deserve explicit repetition because they destroy value faster than a mis-tuned MQTT broker:
| Trap | Why shoppers collide with it | Risk posture |
|---|---|---|
| Dreame / Xiaomi naming collisions | Vendors ship incompatible robots under visually similar names (Gen2, non-Pro, regional bundles)2. | Buying unsupported hardware despite “looking identical.” |
| Roborock Q7 Max NAND rotation | Manufacturing switched NAND vendors; rooting procedure may fail benignly after irreversible disassembly2. | Financial + time sink; privacy plan stalls mid-project. |
| Xiaomi 1C revision drift | Only dreame.vacuum.mc1808 qualifies; SSID fingerprints matter2. | Permanent mismatch with install docs. |
| Dreame L20 Ultra twins | Serial prefix R2394 vs R2253 separates rootable from not2. | Highest severity “wrong twin” scenario in recent flagship tiers. |
| Negative miio device IDs (late 2025 Dreame manufacturing) | Documented remediation touches factory identifiers—do not improvise if you dislike unbricking afternoons2. | Automation flake / integration confusion post-root. |
When any trap triggers, your fallback is almost always vendor cloud registration—the telemetry outcome this whole architecture seeks to avoid.
Privacy-first LAN posture after root succeeds
Valetudo gives you local HTTP + MQTT control planes, which pairs cleanly with Home Assistant—but local control is not automatic defense-in-depth3.
Practical segmentation checklist:
- Dedicated IoT VLAN + ACLs denying unsolicited WAN egress (allow explicit updates only when you intend them—similar discipline as cameras)(WAN blocking, VLAN primer).
- MQTT broker authentication, preferably TLS on your LAN if threat models include compromised Wi-Fi guests (broker comparison).
- No cloud account dependency for daily driving—keep vendor apps air-gapped or uninstall once MQTT parity is verified (install playbook).
Threat modeling reminder: you traded vendor dashboards for your own maintenance. That is usually the right trade for privacy advocates—as long as you patch brokers and watch anomalous LAN scans with the same rigor you apply to NVR VLANs.
Operational cadence: firmware hygiene without telemetry churn
Valetudo releases evolve capabilities and housekeeping behaviors5. Pair upstream release notes with:
- Home Assistant backup cadence before vacuum-breaking upgrades (identical discipline as Zigbee/Matter hubs).
- Offline artifact caching: download firmware bundles over a management workstation, not blindly from the vacuum WAN path you nominally distrust.
- Documented rollback: keep serial consoles wired before experimental flashes—recovery tooling is part of privacy resilience too.
If this operational overhead surprises you, revisit our conceptual primer on what cloud removal buys—and costs (firmware privacy angle, cloud-free vacuum roundup).
Checklist
- Verify the SKU appears verbatim on the official Supported Robots list before paying.
- Match Valetudo binary tier (armv7 vs aarch64) to the release artifact you will flash.
- Read secure-boot and firmware-threshold notes for your exact model cluster.
- Budget UART tools or disassembly depth honestly—unfinished roots revert to clouds.
- Plan MQTT auth + VLAN segmentation before trusting the vacuum near HA credentials.
- Archive upstream install screenshots/checksums locally before offline maintenance windows.
Primary sources table
| ID | Title / role | URL |
|---|---|---|
| 1 | Supported Robots (canonical inventory + per-model notes) | valetudo.cloud/pages/general/supported-robots/ |
| 2 | Buying guidance & flagship trajectory commentary | valetudo.cloud/pages/general/buying-supported-robots/ |
| 3 | Hypfer/Valetudo source & releases | github.com/Hypfer/Valetudo |
| 4 | Dreame UART breakout hardware helper | github.com/Hypfer/valetudo-dreameadapter |
| 5 | Dennis Giese hardware teardown corpus | robotinfo.dev |
| 6 | Feature request / unsupported-model intake form | requests.valetudo.cloud |
Conclusion
Supported robots for Valetudo in 2026 remain a moving-but-knowable set: upstream publishes an explicit allow-list, and privacy-conscious shoppers win when they treat that list like a PCI-style compatibility matrix rather than marketing prose2.
If you want procedural depth next, continue with the installation + MQTT + Home Assistant guide, then lock the vacuum behind the same IoT segmentation standards you use for cameras and voice assistants (WAN egress blocking, broker hardening).
Frequently Asked Questions
Where is the authoritative list of Valetudo supported robots?
The exhaustive, maintained inventory is on valetudo.cloud under Supported Robots. If a model is absent there, it is not supported—regardless of forum anecdotes.
Does “Valetudo binary” tell me the exact SoC in my vacuum?
Not directly. It names the CPU architecture tier (armv7, armv7-lowmem, aarch64) used by the official Valetudo build you install. For chip-level specifics use teardown references linked from upstream docs.
Which supported robots avoid UART soldering-style rooting?
Several legacy Roborock paths are laptop-first (with manufacturing-date caveats). Most modern Dreame-class robots expect UART access via a breakout PCB. Eureka models commonly use USB-from-a-laptop workflows. Always read the section for your exact model on the official install pages.
Why should I still VLAN-block my vacuum after installing Valetudo?
Local control removes mandatory cloud dependency for everyday cleaning, but the device remains a Linux appliance on your LAN. Segmentation limits blast radius if credentials leak or a future bug opens unexpected services—standard IoT hardening still applies.
What is the biggest “wrong SKU” trap in 2026 shopping?
Confusing near-identical marketing names across Dreame, Xiaomi, MOVA, and Roborock lines—supported status is per hardware identity, not retail wording. Examples include Dreame “Gen2” rebrands, Roborock Q7 Max NAND changes, and Dreame L20 Ultra serial-prefix splits called out upstream.
How often should I revisit compatibility when buying used?
Before every purchase. Vendors patch exploit chains; NAND or PCB revisions rotate silently within the same product name. Confirm against the live supported list and model-specific warnings dated after your manufacturing batch when possible.
Footnotes
-
https://valetudo.cloud/pages/general/supported-robots/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37 ↩38 ↩39 ↩40 ↩41 ↩42 ↩43 ↩44 ↩45 ↩46 ↩47 ↩48 ↩49 ↩50 ↩51 ↩52 ↩53 ↩54 ↩55 ↩56 ↩57 ↩58 ↩59 ↩60 ↩61 ↩62 ↩63 ↩64 ↩65
-
https://valetudo.cloud/pages/installation/dreame/#uart-shell ↩