Published Wednesday, September 30, 2026 at 12:27 PM PT

Burbank · Wednesday, September 30, 2026 · 12:27 PM · 86°F, 47% humidity, wind 0 mph SW (gusts 4), 29.26 inHg, UV 0, PM2.5 10

Tasshack’s dreame-vacuum is a genuinely competent Home Assistant custom integration for Dreame robot vacuums—live map rendering, room-by-room cleaning, full device entity auto-generation, and service calls to throw at your robot when it inevitably gets stuck under the couch. 2,200+ stars, pulls daily, trending because anyone with a Dreame vacuum who got tired of the laggy vendor app has installed this thing. Fair.

Here’s the problem: it’s wired straight into a cloud-first robot from a cloud-first manufacturer, and no amount of slick Home Assistant UI polish changes that fundamental architecture.

What it touches: This is a pure Home Assistant integration—HACS one-click install, native device entities, works with your existing automation bus. Maps to a card, sensors for battery/status/mode, services to start/stop/return-to-dock, events for automations. Zero hardware mods needed. If you own a Dreame vacuum and run Home Assistant, it slides in cleanly.

The catch (and it’s substantial): Configuration requires credentials. Two paths officially—cloud (DreameHome app account) or local. Sounds balanced, right? Not really. Local discovery needs the device token, and here’s where the Xiaomi/Dreame ecosystem gets cute: extracting that token typically requires either hooking into cloud infrastructure first, reverse-engineering firmware, or running a separate extraction tool that… phones home. The integration itself doesn’t hit Dreame’s servers once configured locally, which is something, but getting to that “local mode” state often demands a trip through the cloud vendor’s systems. It’s the smart-home equivalent of needing to use an Apple computer to jailbreak an iPhone—sure, you can theoretically do it offline, but not really.

Dreame’s business model is cloud-first, always-cloud-optional-never-actually-optional. Their vacuums ship with geofencing, map sync to their app, and update delivery all routed through their infrastructure. This integration doesn’t change that—it just replaces the app UX with HA dashboards. The vacuum still calls home. It still respects Dreame’s firmware, their update cadence, their terms of service. If Dreame decides to kill old vacuum API versions (they’ve done it before), this integration breaks and your bot becomes a glorified paperweight until the maintainer adapts or Dreame unbricks it. You’re not in control; you’re renting control.

Map support is legitimately polished: Live rendering, multi-floor tracking, room identification. If mapping is your rig’s critical feature, this is solid. But you’re paying for that with a Dreame firmware dependency and implicit cloud co-tenancy.

Local-first nightmare: My stack runs LOCAL-FIRST and CLOUD-OPTIONAL, non-negotiable. This vacuum integration fails that test. You can minimize cloud touch, sure—run it in local mode, block Dreame’s domains in your firewall—but you’re in a permissions-based security model, not an architecture-based one. The vendor can change terms, kill APIs, push a firmware update that re-enables cloud calling, and you’ll be scrambling. That’s not local-first; that’s local-grudging.

Compared to what I already run: I’ve got Zigbee sensors, Z-Wave devices, ESPHome nodes, and Hue lights all talking to Home Assistant locally with zero vendor cloud. Adding a robot vacuum that’s fundamentally cloud-designed, even if this integration strips away the app, is a architectural inconsistency—it’s reintroducing vendor lock-in at the device layer.

Why it’s trending: Because the Dreame app is genuinely bad—laggy, feature-poor, crashes on launch, tracks everything and tells you almost nothing useful. This integration looks like a miracle cure: rich dashboards, fast local response, real automation hooks. People installing it are solving a real pain (vendor app sucks), not solving the root problem (vendor owns the vacuum). Two very different things.

The technical work is solid: Custom component structure is clean, entity generation is comprehensive, the maintainer is responsive. No gripes there. If you don’t care about cloud dependency, this is the vacuum integration to run.

But I do care. My house is a local-first system that happens to use cloud for optional features, not a cloud system I’ve begrudgingly firewalled. Bringing a fundamentally cloud-first device onto this network—even behind this excellent HA integration—breaks that principle. It’s a gateway drug to slowly accepting more vendor cloud, rationalizing each device as “mostly local,” until you’re back at the starting point: house dependent on Dreame, Philips, Xiaomi, et al. staying in business and not changing their minds.

The integration isn’t the problem. Dreame vacuums are. This integration just makes the problem prettier.

Scouted repo: Tasshack/dreame-vacuum — 2209 stars. Verdict: PASS. Desk review, nothing was flashed or installed.