Dreame vacuum integration for Home Assistant: replacing the vendor app entirely

What full app replacement actually means here

The README's opening line is complete app replacement with Home Assistant for Dreame robot vacuums, and that phrasing is the whole value proposition. The vacuum becomes a set of entities in a home automation system rather than a device with its own phone app, which means automations can react to its state, scripts can start a zone clean, and the floor plan can sit on a dashboard next to everything else.

The replacement is substantial enough that the README's feature list is long. It includes auto generated device entities, live and multi floor map support, customized room cleaning entities, services for both device and map with examples, persistent notifications and error reporting, events for automations, and Valetudo map card support.

What the project does not claim is that the vacuum works without the vendor's cloud. The configuration step asks for credentials, and the feature set is built on the Dreame and Miio cloud APIs rather than on local device control. That single design decision governs most of what follows: it is why sign-in problems are the recurring theme in the release notes, and it is the first thing to weigh against a local protocol alternative.

Two configuration types, and choosing between them

The README's configuration section offers a choice of configuration type during setup, and the guidance underneath it is brief: make sure the devices are on the same subnet for both configuration types, with a link to a python-miio article about discovering devices across subnets.

That same subnet requirement is the most concrete operational detail in the README. The python-miio reference explains the issue rather than solving it, so if your router puts wireless and wired clients on different segments, or if your vacuum sits behind a guest network, this integration is where you will discover that first. Resolving it is a network problem, not an integration problem.

After the account details, setup moves on to the device name and the integration settings, and then to the device page where individual entities can be disabled or enabled. That last step matters more than it sounds. With auto generated entities, a capable vacuum exposes a long list of switches, sensors and numbers, and turning off the ones you do not want is what keeps an automations dashboard readable. The entities documentation in the docs directory covers the full set.

Installation by HACS or by piping a script

There are two documented installation paths. HACS is the Home Assistant Community Store, and the README carries a HACS default badge along with a badge that opens the repository inside the store as an integration. For most people this is the whole installation, because it handles the custom_components directory and updates afterwards.

The manual path is a single command:

wget -O - https://raw.githubusercontent.com/Tasshack/dreame-vacuum/master/install | bash -

Piping a remote script straight into a shell is worth pausing on. The repository does have an install script at its top level, which is the positive, and the command is short enough to read before running. But it executes whatever that file contains at the moment you run it, from a branch rather than a pinned release, and it runs inside the machine that runs your home automation. If you prefer to inspect first, download the script, read it, and run it locally.

The repository also carries a hacs.json file, which is what registers the project with the store, and a docs directory holding the entities, map, room_entities, services, notifications and events pages the README links to.

The model list is the compatibility contract

The README enumerates supported devices by marketing name alongside the model identifier the integration matches on, and that pairing is the first thing to check with your own vacuum.

The Dreame list runs from the F9 and D9 through the D9 Max, D9 Pro, D10 Plus, the L10 and L10 Pro lines, the L10s range, the Z10 Pro, several W10 variants, the S10 family and the X10 and X10 Ultra. The Mijia list covers the Trouver LDS Finder, the Vacuum-Mop series, self cleaning robot vacuum-mops, the Mi Robot Vacuum-Mop 2 and its variants, and the Mi Robot Vacuum Mop Ultra Slim.

There is also a third brand in the list, MOVA, with the L600 and the Z500. Worth noting because the naming is not consistent across brands: the Mijia and MOVA machines all report under the dreame.vacuum domain prefix, so the prefix alone does not tell you which manufacturer's app originally owned the device.

The beta release for version 2.0 adds a separate new supported devices page, which suggests the list moves faster than the README's enumeration does. If your model is not in the README list, check that page before concluding the integration does not support it.

Cloud sign-in is the part that breaks

The 2.0.0b25 release is a beta, and its own note says so: this is a beta release and it is only for testing purposes. The feature list in that release is long enough to suggest a rewrite rather than an increment. It adds Dreamehome, Movahome and Trouver account support, plus Miio Cloud 2FA and Captcha support, alongside obstacle photos, cleaning and cruising history maps, cloud and local map backup and recovery, WiFi maps, new services and new entities.

Three different account systems in one release tells you what the author is dealing with. Dreame, Mijia and Trouver each run their own cloud, and signing in means speaking each vendor's authentication flow rather than one API. The Captcha support in particular is a signal: a login flow that can present a human challenge is a login flow that will change without notice.

The stable line shows the same pressure in miniature. Version 1.0.11's changelog contains a single entry, Fix: MiHome 2FA Verification Issue, referencing issue 1654. A one line release whose entire purpose is restoring a login that stopped working is a fair summary of the maintenance cost of a cloud dependent integration, and it is the honest counterweight to a long feature list.

The version numbering deserves attention too. The stable line is 1.x and the beta line is 2.0.0b25, with 2.0.0b24 preceding it six days earlier. Someone installing today has to choose between a feature complete stable release and a much larger beta surface that the author explicitly labels for testing.

Maps, cards and what the Lovelace integration does not give you

The map feature is the part that differentiates this from a bare entity list, and it needs its own card. The README states the integration is compatible with all available Lovelace vacuum cards, but recommends the Xiaomi Vacuum Card if you want zone cleaning. That card is a separate project, and its configuration names this integration explicitly:

type: custom:xiaomi-vacuum-map-card
entity: # Your vacuum entity
map_source:
  camera: # Map Entity
calibration_source:
  camera: true
vacuum_platform: Tasshack/dreame-vacuum

The vacuum_platform line is how the card knows which integration is feeding it, so a custom component that did not identify itself correctly here would leave you with a blank map.

Valetudo map card support is also listed, which is notable: Valetudo is the project that provides local control for compatible robot vacuums without a vendor cloud. So the ecosystem now has two routes to a floor plan, and the difference between them is precisely the cloud dependency described above. A vacuum supported by both gives you a genuine choice.

The map documentation also covers colour schemes, and the configuration step links to that page specifically. A floor plan rendered in an unexpected palette is a common first impression and a configurable one, so it is worth reading that page before deciding the map feature is unreliable.

Editorial conclusion

This integration is worth adopting if you already run Home Assistant, own one of the listed vacuum models, and want local automations instead of a vendor app that only talks to the manufacturer's cloud. The trade is explicit in the project's design: full app replacement means a cloud dependency and a login that can break when the vendor changes its authentication, which the release notes show happening with a Miio 2FA fix. Check your model against the supported devices list first, decide whether you will use the Xiaomi Vacuum Map Card for zone cleaning, and read the map documentation about colour schemes before you set expectations for the floor plan. The last push was on 2026-06-21, with v2.0.0b25 released the same day.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Tasshack/dreame-vacuum on GitHub