Dreame Vacuum v2.0 is out
After a long time in beta, Dreame Vacuum v2.0 is finally released as a stable version. It comes with the Dreame Vacuum Card built in, the Lovelace card that replaces the official app.
The documentation is completely new, so please check it first if you have any questions:
Wow, after update it no longer works with existing vacuum card, and dreame vacuum card is asking money.
Your website says it will send arbitrary code to be executed at my home assistant from your server. No thank you.
This was definitely not intentional. If the existing card is not working, it is likely a regression bug that will be fixed. Please create an issue on GitHub with the details, and I will look into it.
Regarding the integration asking for money: the integration itself is completely free. Absolutely nothing that was already working has been disabled, made unusable, or put behind a paywall. I simply introduced a new, completely optional dashboard card that is paid. You do not have to use it. I have explicitly stated this on the documentation page. In fact, in this latest release, I have even added new features to the free core integration, such as backend translations.
To show my continued support for free alternatives, other existing custom cards now have their own dedicated setup pages in the docs. For example: Lovelace Xiaomi Vacuum Map Card | Dreame Vacuum
Maintaining a project of this scale takes a massive amount of my personal time. Introducing an optional paid card is a necessary step to ensure I can sustain and support this integration for years to come. Ultimately, food is not free, and I need to find a way to make the time I invest sustainable. But I want to be very clear: everything that was free before is still completely free, and no support has been cut from those free features.
Lastly, regarding the “arbitrary code” mentioned on the website: that code is strictly the paid card itself and the licensing mechanism designed to protect my work. All payments are processed by Polar.sh, a highly reputable and strict Merchant of Record. Operating through them means my real identity, tax, and legal details are fully verified. If I were to distribute anything malicious, you would easily have direct legal recourse against me. In reality, if I did anything illegal, Polar would immediately shut down my account and take severe legal action against me long before that. This is a legitimate project, and I have zero intention of risking it.
Open source is not meant to be paid(I mean, if the card is good, I would donate, but not a mandatory fee!)…
If you agree, vote below:
There is a fundamental misconception here. According to the Free Software Foundation and OSI, the “free” in open source refers to liberty, not price (“free speech, not free beer”). Open source principles explicitly allow charging for software or separate add-ons.
The core integration remains 100% free and open-source. The dashboard card is an entirely separate, optional UI.
Regarding the poll option about making “at least part of it free”: I can’t predict the future, so maybe eventually. But right now, my first priority is ensuring that the massive amount of time and effort I’ve invested into building this project is actually compensated.
As for “if the card is good, I would donate”: You don’t have to pay blindly to find out if it’s good. I have prepared a comprehensive documentation where you can see every single feature in action before spending anything: https://dvc.tasshack.com
If you actually take a look at it, you’ll see that this isn’t just a simple dashboard card. It is a complete user interface that practically replaces the official robot vacuum app. It includes advanced map editing, viewing obstacle photos, and full access to every single robot setting directly from Home Assistant. It features a custom map renderer built from scratch, ensuring it runs incredibly fast, in high resolution, and is fully touch-optimized for mobile.
It is leaps and bounds beyond the basic, bare-bones custom cards you might be used to installing for free.
I couldn’t really gauge the card’s features from the video. It would be great to have a trial period or a chance to actually play around with the card itself. $30 is a steep price just to try it out…
If the detailed documentation and the video aren’t enough to gauge the features, there isn’t much else I can do to demonstrate it beforehand. However, if you do decide to purchase it and are genuinely unsatisfied with its performance, you can always open a dispute with the payment provider. If you present a valid, legal reason, you will be refunded. That is already your legal right as a consumer.
As a reminder, this project is fundamentally a backend integration. It has no obligation to provide a custom dashboard UI, and for the past 4 years, it hasn’t. You can simply continue using the free integration exactly as you always have, as if this new paid card doesn’t exist. No one is forcing anyone to buy anything.
Regarding a trial period: it sounds like a good idea in theory, but there is a major technical catch you are missing. To enforce a trial period, I would need to implement a mechanism that actively disables the code once the trial expires. That means the card would need to constantly send requests back to an external server and the payment processor to verify your trial status.
Also I’d like to point out that the new card itself is not actually open source. It carries a license header saying it’s under a proprietary license. That is to say, while the integration itself is MIT licensed, the new custom card is very much not.
The related code (frontend.py in python) is trivially obfuscated, and an AI coding agent can pick it apart trivially. -please don’t obfuscate python code running in HA, I don’t like the idea of obfuscated 3rd party python code being loaded into HA-
And I stopped bothering to poke at the obfuscated JS code after I encountered that header.
I will be switching my own installation over to a copy with all these obfuscated bloat stripped out.
P.S. I hope you don’t seriously expect the obfuscation to hold up too long nowadays. I would say that given some time an AI agent can probably deobfuscate the entire thing and pick it apart throughly. And I’m not talking about the super expensive “frontier AI”, I’m talking about the cheaper open models too.
You are absolutely correct: the new card is not open source. It is under a proprietary license because it is a paid product, and I need to protect the massive amount of time and effort I’ve invested into it.
Furthermore, from a licensing perspective, there is absolutely no conflict here. The core backend integration uses the MIT license, which is a highly permissive license. It explicitly allows combining, interacting with, or serving proprietary and commercial components. There is absolutely no rule stating that an MIT-licensed backend cannot serve a proprietary frontend payload.
The obfuscation in the code is simply an anti-cracking measure to prevent license cloning, as the card is licensed per device. Ironically, as you pointed out yourself, an AI agent can trivially pick it apart. If it’s really that easy for you to see exactly what the code is doing, then you already know there is nothing malicious going on. Complaining about “not liking obfuscated code running in HA” while simultaneously admitting you can easily see what it does is a bit contradictory.
Regarding stripping out the “bloat”: go right ahead. I actually designed the integration specifically so that the Dreame Vacuum Card module is entirely decoupled. You can literally just delete frontend.py and remove two lines from __init__.py, and the rest of the open-source integration will continue to run perfectly without it.
I structured the architecture this way precisely because I anticipated some users might want to easily remove it.
If you want to take it a step further, you are more than welcome to fork the project and maintain your own version completely stripped of the frontend components.
On the contrary, it’s not really contradictory, I just don’t like the idea of it. And picking it apart with an AI agent has a cost in the end after all. (Plus I didn’t really pick apart that blob of frontend JS code because of the token cost.)
Also, that per-device licensing is presumably why you added integrity checks for the integration itself. Which means modifying the open source part of the integration will likely void the license checks or something. 
I prefer not to discuss the exact details of how the integrity and licensing mechanisms work publicly. Disclosing those details serves no purpose other than potentially undermining the effort designed to protect my work.
However, without getting too technical, I can assure you that modifying the open-source part of the code does not permanently disable the card or void your license.
If you make modifications to the code, you are always welcome to open a Pull Request. If your changes are merged into the official release, the card will naturally continue to work without any issues.
Even if your PR isn’t accepted, or if you just want to run your own custom and modified version of the integration locally, I can still ensure the paid card remains fully functional on your specific setup. You aren’t locked out of modifying the open-source backend. All it takes is just communicating with me.
I’m also someone who isn’t going to use the paid card (both because I don’t pay for any of my SmartHome software, but also because I don’t want any of the features it offers) but I really appreciate the way you structured it to make those parts easy to remove. I know a lot of people are going to have knee-jerk reactions to it, but this worked fine for me!
It is completely natural that you don’t need this card. With Home Assistant’s native clean_area service and daily automations, you don’t even need a visual map to clean specific rooms. To be honest, I rarely use the UI myself. However, this card was built specifically as a premium option for a niche of users who want a highly interactive, hands-on UI to completely replace the official app.
I really wish I hadn’t forgotten to add this to the documentation from the beginning. I will definitely add a “How to strip the paid frontend” section to the docs soon. I honestly just didn’t think of it at the time, but making it a part of the official documentation makes perfect sense for users who specifically want to completely remove the obfuscated paid components from their installation.
The card is maybe actually good, and I might consider buying it if it supports other vacuums that Dreame (I have the Tapo RV30 Max).
So, is the RV30 Max supported?
I noticed your fork. While I mentioned that you were free to strip out the frontend components, I see that you instead went out of your way to deobfuscate the code and post it publicly in cleartext.
You have already looked at the code. You know exactly what it does, and you know there is absolutely nothing malicious hiding in it. So why insist on making it public?
If you try to break a lock, you just force me to install a bigger, more complex lock next time. That means I will be forced to waste my time adding heavier obfuscation, and you will waste your time trying to reverse it again. It’s a completely pointless cycle that just wastes both of our time and effort.
Publishing that code publicly doesn’t provide any real value to anyone. If someone else is genuinely curious about what is inside, they can easily deobfuscate it themselves just like you did. There is no need for you to host it publicly for them.
I know that this specific part of the code falls under the MIT license and you are legally allowed to do this. However, while I understand you might be annoyed that the custom card is a paid feature, there is absolutely no need to actively try to damage my work just because you disagree with it. Please act in good faith and either remove the cleartext code or at least make your repository private.
Arguing for validity of DRM and digital locks with a community dedicated to freeing their devices from the chokehold of proprietary software is a weird idea.
Maybe the optics of this wouldn’t be so bad if you just released it as a separate package. Sadly, you decided to violate community trust by smuggling an obfuscated, DRM-laden piece of software through the HACS FOSS upgrade channel onto machines of people who previously used your integration SPECIFICALLY to avoid this kind of evil proprietary software practices.
You mention “community trust,” but frankly, we are completely even on that front. The community lost my trust about a year ago. The constant “take everything, give nothing back” entitlement almost made me pull the plug and delete the repository entirely. Instead of trashing years of work, I pivoted to a revenue model. My relationship shifted from community/supporter to business/customer. If you feel a loss of trust, that is fine, because I do not trust the community either.
Calling it “smuggling” DRM is a ridiculous exaggeration. Smuggling implies sneaking in malware or stealing data behind people’s backs. This is my repository and my codebase. I published a transparent, public update to my own project. I have the absolute right to put whatever I want into my own code. If you are so strictly against proprietary code, the solution is simple: just click uninstall.
Happy to pay to continue to support this project. Thanks for your work @tasshack
Guys, i have an X50 , how do you guys start the vacuum like in cleangenius or custom mode? how do your scripts look like?
Do you play with these services like examples below, cleangenius => deep or off
- action: select.select_option
target:
entity_id: select.x50_master_cleangenius
data:
option: "deep_cleaning"
- action: select.select_option
target:
entity_id: select.x50_master_cleaning_route
data:
option: "intensive"
- service: select.select_option
metadata: {}
data:
option: "{{ option }}"
target:
entity_id: select.x50_master_cleaning_mode
=> mopping / sweeping / … ?
interested how you guys do this…