Valetudo

Firmware

Cloud replacement for vacuum robots, enabling local-only operation.

Latest 2026.08.0 · by HypferWebsiteHypfer/Valetudo

Release activity

Release activity — 10 releases across 10 days since Aug 29, 2025. Each cell is one day; darker means more releases that day. Nothing is recorded before Aug 29, 2025. Older weeks are hidden at this screen width.
MayJunJulAug
SundayNo releases on Apr 19, 2026No releases on Apr 26, 2026No releases on May 3, 2026No releases on May 10, 2026No releases on May 17, 2026No releases on May 24, 2026No releases on May 31, 2026No releases on Jun 7, 2026No releases on Jun 14, 2026No releases on Jun 21, 2026No releases on Jun 28, 2026No releases on Jul 5, 2026No releases on Jul 12, 2026No releases on Jul 19, 2026No releases on Jul 26, 2026No releases on Aug 2, 2026
MondayNo releases on Apr 20, 2026No releases on Apr 27, 2026No releases on May 4, 2026No releases on May 11, 2026No releases on May 18, 2026No releases on May 25, 2026No releases on Jun 1, 2026No releases on Jun 8, 2026No releases on Jun 15, 2026No releases on Jun 22, 2026No releases on Jun 29, 2026No releases on Jul 6, 2026No releases on Jul 13, 2026No releases on Jul 20, 2026No releases on Jul 27, 20261 release on Aug 3, 2026
TuesdayNo releases on Apr 21, 2026No releases on Apr 28, 2026No releases on May 5, 2026No releases on May 12, 2026No releases on May 19, 2026No releases on May 26, 2026No releases on Jun 2, 2026No releases on Jun 9, 2026No releases on Jun 16, 2026No releases on Jun 23, 2026No releases on Jun 30, 2026No releases on Jul 7, 2026No releases on Jul 14, 2026No releases on Jul 21, 2026No releases on Jul 28, 2026No releases on Aug 4, 2026
WednesdayNo releases on Apr 22, 2026No releases on Apr 29, 2026No releases on May 6, 2026No releases on May 13, 2026No releases on May 20, 2026No releases on May 27, 2026No releases on Jun 3, 2026No releases on Jun 10, 2026No releases on Jun 17, 2026No releases on Jun 24, 2026No releases on Jul 1, 2026No releases on Jul 8, 2026No releases on Jul 15, 2026No releases on Jul 22, 2026No releases on Jul 29, 2026No releases on Aug 5, 2026
ThursdayNo releases on Apr 23, 2026No releases on Apr 30, 2026No releases on May 7, 2026No releases on May 14, 2026No releases on May 21, 2026No releases on May 28, 2026No releases on Jun 4, 2026No releases on Jun 11, 2026No releases on Jun 18, 2026No releases on Jun 25, 2026No releases on Jul 2, 2026No releases on Jul 9, 2026No releases on Jul 16, 20261 release on Jul 23, 2026No releases on Jul 30, 2026No releases on Aug 6, 2026
FridayNo releases on Apr 24, 2026No releases on May 1, 2026No releases on May 8, 2026No releases on May 15, 20261 release on May 22, 2026No releases on May 29, 2026No releases on Jun 5, 2026No releases on Jun 12, 2026No releases on Jun 19, 2026No releases on Jun 26, 2026No releases on Jul 3, 2026No releases on Jul 10, 2026No releases on Jul 17, 2026No releases on Jul 24, 2026No releases on Jul 31, 2026No releases on Aug 7, 2026
SaturdayNo releases on Apr 25, 2026No releases on May 2, 2026No releases on May 9, 2026No releases on May 16, 2026No releases on May 23, 2026No releases on May 30, 2026No releases on Jun 6, 2026No releases on Jun 13, 2026No releases on Jun 20, 2026No releases on Jun 27, 2026No releases on Jul 4, 2026No releases on Jul 11, 2026No releases on Jul 18, 2026No releases on Jul 25, 2026No releases on Aug 1, 2026

10 releases since Aug 29, 2025

Changelog

2026.08.0

Valetudo 2026.08.0

Added 5
  • Camera streaming support for local-only vacuum robot web interface with safeguards and ethics messaging
  • dustsrc GStreamer source element for video capture from proprietary vendor firmware
  • MPEG1-based video streaming using jsmpeg library for HTTP-only transmission without WebRTC
  • Stylized 90s CRT-themed video renderer using WebGL to display camera feed
  • Dedicated camera page in the web interface with fullscreen support
Changed 2
  • Camera streaming feature is disabled by default and hidden from menus when off to avoid persuasive dark patterns
  • Video streaming uses HTTP instead of WebSockets for better reverse proxy compatibility

Camera Streaming — Yes, really

Valetudo 2026.08.0

I've put an em dash there as a jumpscare. If you didn't notice, I have bad news for you. You might've previously been exposed to AI writing without you even noticing.

(These release notes are quite inline-video-heavy, so for the best experience, I recommend reading them on github.)

Duststreaming
Why (only) now?

So while this always was a technically complex thing, the main blocker has always been an ethics one.

Because the software works and because a good Valetudo user is a self-sufficient invisible one, in my daily grind, I - for the most part - do not get to interact with you cool people. Instead, I get to experience the absolute worst consumer smarthome tech + foss has to offer, which historically made me quite hesitant to implement a technology with as much abuse potential as camera streaming on vacuum robots.

I did however eventually realize that letting this decision be guided by the most terrible of people in a sense means supporting these guys in making the world worse by stripping us of cool stuff. So I sat down and found a solution.

The feature now exists, but it comes with safeguards and a lecture that strips away any sort of plausible deniability for bad behavior. I cannot stop people from being shitty, but I think I’ve managed to ensure they'll at least feel bad about it when they are.

Additionally, I do believe that the messaging in there is genuinely useful and extends beyond just vacuum robots, but you tell me. You can of course also just skip it by typing skip.

Design notes

This whole "designing for better results" doesn't stop there, though.

It extends to the feature being built with non-adoption as the goal. When it is off, you will see no mention of it in the menus other than the toggle to turn it on.

This avoids the classic silicon valley thing of putting something disabled in front of you to make you feel like you're missing out - just so that you're to blame when you eventually do what they've funneled you into doing. With Valetudo, not having the spycam enabled is not just an option but the default people should hopefully gravitate towards.

But, when you decide to enable it, you get cool shit, which we - now that this is all out of the way - will now get into.

History

But first: History.

How do you even build camera streaming for a local-only vacuum robot webinterface on a custom proprietary vendor firmware?

Getting Video

Well, it starts with one thing. I don't know why the allwinner non-mainline kernel kept crashing. It did however matter how hard we tried.

"We" being @Vivia here, who decided to take a break from hacking on gstreamer at work to do some recreational gstreamer hacking vacation instead. The solution is dustsrc, which is a source element that does v4l, but just enough v4l to not scare the kernel.

You can find her talk about it here: https://indico.freedesktop.org/event/11/contributions/516/

As you can see, that was 2025, so a lot of patience with me coming to terms with that ethics dilemma was involved. Thanks, Vivia!

Transmitting Video

So that's how we got frames, but how did we get them into the UI, given that Valetudo is http only, and with that cannot do webRTC. The answer is yet again some FOSS wizardry.

13 years ago, @phoboslab (which you probably know from other cool stuff like the quite okay image format) likely must've noticed that the mpeg1 patents had expired, meaning that one could just use the codec for whatever one likes. The "whatever one likes" then became a canvas/webGL based mpeg1 player in pure JS, which bypasses all of those limitations of "more modern" (and Google W3C-approved) ways of doing Video.

Now, 13 years later, it - in a vibe-mutilated form (sorry) - powers vacuum robot camera livestreaming.

And, since it's just http and no websockets, it should also just work with whatever reverse proxy setup you might be using. Though, I have not actually tested that, so you tell me.

Rendering Video

Because normal video players with their "buffering" loading spinners and HUDs and all are boring, the way video is shown in Valetudo is stylized, imitating a 90s CRT displaying an analog RF Signal.

The way this was implemented was - of course - LLMs, so whether it actually has more soul than a dreadful spinny circle is debatable, but the result nevertheless fills me with joy.

https://github.com/user-attachments/assets/45858dc4-f2e4-4c37-be88-8bbcda54cd2c

As you can see, it clearly intuitively conveys the connection and stream state, without actually telling you the connection and stream state. And it does so while also being fun.

I went for vibes but not necessarily full period correctness or accuracy, so if you're a shader wizard and better nostalgic hacker than me, feel free to open a PR to make it even more 90s CRT. I'm after all just a fake suit pretending to be a hacker by glueing together the stuff of other people into a product.

Cool, how do I use it?

So that's the renderer thingy. But where can you see it?

First of all, on a dedicated camera page. It's boring in the sense that it just shows the camera and you can click on it for fullscreen. You've already seen that one, so it's just shown briefly in the upcoming demo.

https://github.com/user-attachments/assets/99037a58-4249-4dec-8778-2e2c7f9e66e3

The next place is the manual controls view, which with that gains a live feed that shows you - with some lag for extra fun - where you're driving.

That works so well, I can't wait to see what people build/do with it.

https://github.com/user-attachments/assets/e78b6abd-0e54-43ee-8b39-d8224255d08c

Lastly, there's the spectator map, which combines video feed with map feed. On desktop, you get a PiP mode, where you can cycle through PiP window sizes like you'd expect from the usual game minimap UX. On mobile, you get a split view instead.

Valetudo-wise, that I think concludes everything that could sensibly be done with a video feed - with implementations I am very happy with, doing everything I would want them to do as a user.

The bigger picture

Here's the best part though: This could extend beyond Valetudo.

Because this is literally just local http with no cloud dependency, account requirement or app-only limitations, you can build stuff on top of this.

We had a bunch of ideas already while brainstorming.

For example, what about VRchat (VR meaning vacuum robot), where you have a warehouse with robots with bidirectional audio (remember: they have microphones), allowing people to connect and interact with one another through the bot avatars. Think metaverse but without the lizard.

All you need is like a queue proxy server in the cloud + some warehouse with bots. Less than 10k€ total for sure for a somewhat time-limited Art exhibit.

Or what about bot soccer using manual control? Or the vacuum robot racing league?

Or maybe something like botroulette, where you can give a stranger 5 min of time to drive around your home + some contact form afterwards.

Or - like shown earlier to demonstrate manual control - an impromptu rover thingy. Just pair the bot to your phone hotspot, then use the Valetudo UI on your phone to steer the robot somewhere outside without other wifi infrastructure.

There's so much stuff people could do just because this is not chained to a specific vendor-defined experience. Remember when computers were that? General computation devices instead of prebuilt experiences to consume?

Anyway. I would love to see people do cool shit with this. Have fun!

Some additional unordered thoughts

These did not fit into the narrative arc above, so here they are instead.

Mower cameras

I was at the local hardware store the other day and saw these mowers. Can you see why I found them interesting?

Their cameras point down to the ground, which is different from the vacuum robots which point straight forward - and with that see a lot more stuff not meant for their digital eyes.

IR cameras

Duststreamer also runs on the Roborock S8, which has this IR only cam. That was interesting, because it saw nothing (besides its own IR lasers) while indoors with LED lights only.

However, take it outside and it starts seeing things

And, if you take it back inside, all you need is an old incandescent bulb and its waste IR radiation to see:

Robot dashcam

Idk I just found this fun. I hope you'll find it fun too

https://github.com/user-attachments/assets/29619285-e8ef-4f95-93c9-47eeb7f3175e

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
Fixes
  • ui: Harmonize secondary labels 5edb195
  • vendor.dreame: The set of states that can be resumable extends beyond just docked 7a2e09b
  • vendor.dreame: Misc manual control improvements 064cb88
  • vendor.midea: Fix semantic_slam_node crashlooping on J15 Max FW 558 ccda25e
Chores
View originalPermalink
How 2026.08.0 went
2026.07.0

Valetudo 2026.07.0

Added 2
  • Add map annotations feature to mark passable thresholds, curtains, ramps, and other elements the robot needs to be aware of on the map
  • Support segment floor material type carpet with three variants: low-pile, high-pile, and carpet
Changed 3
  • Update Virtual Restrictions UI to use a grouped button layout, reducing from three rows to two
  • Implement map annotations for Dreame robots starting with X/L40 Master/Ultra models, with thresholds available on older Dreames back to L10s Ultra
  • Add Midea implementation for map annotations
Fixed 1
  • Address issue with Dreame bots not remembering segment material settings by fixing another identified culprit

Map annotations, carpeted rooms and updated moderation

Valetudo 2026.07.0

I've been using some downtime to clean up my shelf, which is basically the entirety of this release.

Map Annotations

Map annotations are the generic concept to house any kind of "there is something on the map the robot needs to be aware of, which might not be reliably auto-determined". For example, depending on firmware support, that could be a passable threshold, a curtain, a ramp or similar.

These things existing in the map make the firmware behave differently in some way relating to the location they're at. It might then take a specific path or trust its obstacle avoidance less or really anything like that.

This feature took me quite a while, not because the code would've been complicated, but because the concept should be easily adaptable to the future. At least as adaptable as something can reasonably be while trying to predict the future.

I again had fun designing some more custom icons, but I can't tell you more about that, because that happened 6-8 months ago and my memory of it is by now a bit fuzzy.

In said predicted future, there might be more map annotations. Though, as always and consequently, I will refrain from just mirroring the vendor app verbatim.

For example, Dreame has "non-passable thresholds" which, to my understanding, logically achieve the exact same as virtual walls. I can see why for UX they have them as a counterpart that exists in the same view, but also, for UX reasons, it's kinda dumb to have two different things that do exactly the same. .. or I am just missing something, but I did at least ask the support and they didn't know either.

What do we have?

For now, on Dreame, starting with the X/L40 Master/Ultra, we have thresholds, curtains and ramps. On older Dreames going back to the L10s Ultra, we only have thresholds.

Unfortunately, I have none of those things at home, so I cannot personally test those things much. I've already asked users to test the nightly build and heard back good results for thresholds and curtains, but ramps are still a big mystery.

So please, let me know if those ramps (and the other annotations) work for you.

What they should do is:

  1. For thresholds, the robot should be able to better climb them through being aware that they exist and driving accordingly
  2. For curtains, the robot should be able to clean below them through ignoring the "THERE IS A SOLID WALL" info it receives from its Lidar
  3. For ramps, the robot should take the designated path to reach an otherwise inaccessible area

https://github.com/user-attachments/assets/162c5323-2de5-43d4-acb6-d286f980b177

I also have the Midea implementation here, however, that has not seen any testing so far, so for this release, it's only Dreame. Also, no ramps there.

One thing I am not quite happy with yet are the visuals in the map. Especially the colors, but honestly everything. So if you have thoughts/ideas there, please let me know!

The only thing that will for sure stay is the wavieness of the curtain. A lot of tuning went into that.

Virtual Restrictions UI Cleanup

Since I had to implement this grouped button for the Map Annotations anyway, I've also updated the Virtual Restrictions UI to use it:

Much better. Still two rows, but not three.

Segment Floor Material Type Carpet

Staring at firmwares, I've noticed that Dreame has, for probably a few fw versions, supported setting the floor material of a segment to carpet. The existence of fully carpeted rooms has finally been acknowledged by big tile.

So now you can do that (if supported by your robot).

There are up to three types of carpet floor material. low-pile, high-pile and just carpet. I think the visualization turned out quite well.

Additionally, I've once again looked into why Dreame bots seem to not want to remember the segment material. I found another possible culprit, and, in my testing, it didn't happen anymore, however, you tell me.

Fingers crossed (again)

New Dreame Firmwares

As announced in dust_announce, new firmwares for the Dreame X/L40 Ultra/Master + the MOVA P10 Pro Ultra have been added to the dustbuilder. They come with an update to the obstacle avoidance model as well as probably logic changes.

What else is going on?

As with the last release, most of the meat is within this section.

Rooting all the things

Starting off with something non-Valetudo, I got a rootshell on my 2018 Bosch EBike's Nyon display:

This now exposes an API with data that should've been there in the stock firmware

So that's kinda cool and completely not ready to be shipped.

Now that I'm there, it's not all that difficult to pull off, but the way up to there took a while.

Anyway, I'm not exactly sure where to go with this. Lots of questions still to be asked and answered. But be advised: It's possible.

GLM-5.2 has been super useful there. Cool model. Can't wait to someday run this class of LLM at home on my own hardware.

Valetudo Moderation

The Telegram moderation bot Easterwave received some love now that Telegram allows for sending ephemeral messages that are only visible to a specific user. This way, the bot can now provide feedback to a user, which is the first component of a feedback loop.

Additionally, I've added some further regex patterns, which should reduce the amount of people I need to manually ban.

Combined, this might make people hate me less, because suddenly they have some feedback + it was a machine that did it. But also, and more importantly, less interrupts for me through stuff that is incorrect (rel: XKCD 386) and with that more unfragmented focus time.

On solving social problems with technical solutions

This is actually a fascinating topic, because common wisdom would tell you that you cannot solve a social problem with a technical solution. And that is true, but, interestingly, consumerist entitlement is so devoid of humanity and so formulaic and script-based that it actually starts being trivial to be countered with mere regexes.

This makes a lot of sense, because corporate processes are standardized to conserve energy and be optimized. So, consequently, the bypasses to them would also be standardized to conserve energy and be optimized. And, consequently to that, the bypass blocker can equally be standardized (and written as a simple regular expression) to conserve energy and be optimized.

For example, let us consider this regex: /is there (?:a |any |some )?(?:particular )?reason/i

It is beautiful, because, within the context of FOSS like this, it basically exclusively triggers on bad faith. That arrangement of words is inherently unnatural, stilted and inauthentic, because it is an engineered wrapper to bypass corporate HR firewalls.

The actual message there is "I don't like this." or "I want something." or "I believe it should be different", but those real statements would be shunned when said like that. So instead, it gets wrapped into this "curious inquiry" standard issue wrapper.

"Dear sir, I was just wondering why you did this." [...] "I am outraged that you would act with this kind of hostility to a mere question"

You get the idea. Something something sea lion.

The purpose of the wrapper is to make any action other than compliance be an illegal move. And, if you as a FOSS maintainer (or really person in general) play by those rules, you either become a martyr or persona non grata.

If you take a peek at the code, you will find a bunch more of them. You might find that interesting. You might also occasionally find yourself using the same scripts. I do, at least. It is - after all - an environmental poison.

Which is also why some of those regexes will fire even though people aren't being actively malicious. We've just all absorbed the inherent maliciousness of our environment and, unfortunately, sometimes reproduce it without noticing.

Another good reason for having a bot deal with it instead of another human.

Positive outlook

To wrap this side-track up and go from discussing dont's to proposing do's, let's look at how to not trigger that mentioned example regex.

At its core, good faith communication would not try to hide the true motive but run with it. For example, a phrasing like the following would work better:

"I expected the thing to work like this, but instead it works like that. Now I'm wondering why that is"

As you can see, it succeeds through putting all the cards on the table right away, instead of trying to hold some back for later leverage. It approaches the other party with respect and at eye level, telling them exactly where one is coming from, what drives them, and what their true goals are.

This of course requires the goals to not be ones that would be shunned by society if put plainly, but that is the whole idea behind this exercise.

Anyway, for some reason, I regularly forget that I can just use software to solve issues I have, just to then rediscover that possibility and be full of joy. Not sure why. A very weird loop.

But also an important reminder that the game of social interactions is rigged against my people and playing by the rules will just get you into a bad place. Hence, you need to hack it, automate it and conserve energy for the things that matter.

I am curious what the future will bring there. Imagine your rooted cyberpunk implant running a bullshit filter in real time. Possibilities are endless and just limited by the fact that there are no such implants and this is all a pipe dream.

But one can dream. How would we even solve latency?

Some cool use of LLMs

I have learned through extensive exhaustion that my ramblings aren't always easy to decode for people. With the advent of LLMs though, I have found a great solution to that. I can use them as some kind of translator-ish machine. A translator that sometimes doesn't work at all - certainly not on autopilot - and if it does, it's still a lossy translation.

I have so far rather successfully used this tooling in a feedback loop to extract what makes its communication work and improve my own mental model, and, eventually, reduce my token spending. But, there is still some way to go, so, for your convenience, if that "the game" thing was a bit too obscure, Gemini did (I think) a good enough job at decoding my ramblings:

At its core, "The Game" is an unwritten, continuous negotiation over who has to spend cognitive and emotional energy. If we look at human social interaction as a distributed system, The Game is the protocol normal society uses to resolve conflicts, establish hierarchy, and allocate resources (the resource being attention and effort).

You all know this (possibly subconsciously), but not all of us are equally well equipped at birth to actually run this in hardware at scale. This is.. not ideal, because it presents this arbitrage opportunity, where great amounts of value can be extracted at a bargain through various known patterns such as exhaustion attacks, traps or just general force.

Anyway, cool prosthetics. The bot, but also LLMs. Don't let your pride (or "beauty standards") stop you from using one yourself if you should require one. And don't just sign up to a (metaphorical) subscription for it, please.

One more thing

That management book I found in a public bookshelf while on vacation told me that you should end with "one more thing" because Steve Jobs did it. So.. one more thing:

Expect new robots in the hopefully near-ish future. We've been finishing up most of that, but there are currently some infrastructure topics blocking the finalization.

We're now looking at 8GB eMMCs, which doesn't exactly bode well for the current dustbuilder deployment, given that everything is much larger. So yeah, this dumb shit is what slows you down. As always.

The usual

If you want to see Valetudo on more robots and/or like this release, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • vendor.dreame: MapAnnotationsCapability 58446b8
  • ui: MapAnnotationsCapability 49bee99
  • core: MapAnnotationsCapability f1db08b
  • ui: Reduce virtual restriction edit map button count using a unified add button 80a3c25
  • vendor.dreame: Segment material type carpet a975c3a
  • vendor.dreame: Map two more error codes 6889856
  • core: Segment material type carpet cdd6710
  • vendor.dreame: Add fan speed turbo quirk b4e3326
  • vendor.midea: Various no-up handlers for stuff in J15Max FW 558 72226e9
Fixes
  • vendor.dreame: Pass the mapId when saving segment material to maybe fix reverting material settings e18dfcd
  • ui: Some client_structure cleanups 345dab4
  • vendor.dreame: Fix Deep carpet cleaning quirk gracefully handling the firmware saying no 371812c
  • End logWriteStream instead of closing it df740d9
Chores
  • release: 2026.07.0 bffad62
  • vendor.viomi: Clean up unnecessary optional chaining db19ec1
  • Minor cleanup fc9df01
  • Some cleanup f14b4c0
  • test: Switch to native nodejs test runner 10866d0
View originalPermalink
How 2026.07.0 went
2026.05.0

Valetudo 2026.05.0

Added 4
  • Expose Dock Components (Freshwater, Wastewater, Dustbin, Detergent) to Home Assistant via MQTT
  • Support room cleaning via MQTT starting with Home Assistant 2026.5.2
  • Add WASD keyboard controls to Manual Control UI
  • Add ability to select between Joystick, D-Pad, or Keyboard Controls in Manual Control UI
Changed 2
  • Update documentation framework from Jekyll to eleventy with improved styling and visual identity
  • Valetudo can now replace itself with a cloned process instead of performing full system reboot during updates
Fixed 1
  • Valetudo no longer kills itself when reaching 1/3 of system memory by instead replacing itself with a cloned process

Some stuff you may find useful, lots of prose

Valetudo 2026.05.0

The last release notes opened with

A surprising amount of relevant things has happened since the last release.

Unsurprisingly, for Valetudo features, that momentum was not kept up. But still, a lot of things happened. A lot of stuff always happens.

MQTT / Interfacing with Home Assistant

The meat of this release is in here.

Dock Components

As promised in the last release notes, Dock Components (Freshwater, Wastewater, Dustbin, Detergent) are now exposed to Home Assistant via MQTT (depending on your model of robot and Firmware of course).

This should make for some neat new automations.

Room Cleaning

Lately, the vacuum entity in Home Assistant gained the ability to start a cleanup on a selection of HA Areas. Starting with HA 2026.5.2, thanks to @jbouwh, this can now be done via MQTT.

And, starting with this Valetudo release, thanks to @jhbruhn, it can be done with Valetudo.

I have slightly mixed feelings about this. I can see myself personally using this and it is objectively useful, but it also pushes Valetudo further down the stack and more into invisibility. That might possibly have negative long-term impacts, however, with my cries of "I exist" being as loud as they are, this might already be compensated for.

Manual Control UI/UX Improvements

Why did I not add WASD controls sooner? It's the obvious thing to do, so why didn't I?

It's fun!

Also, as you can see, you can now just select if you want a Joystick, the D-Pad or Keyboard Controls.

I remember someone asking for this at one point, because iirc their partner liked the D-Pad better or something like that? There you go.

Eternal life

One day, I woke up and thought

Hey, doesn't fork() + exec() mean that the process clones itself and then swaps out its internals with something else? Can you do that on yourself?

Answer being

Yes, that's execve()

Follow-up question being

Can I just patch my nodejs runtime to expose that to Valetudo?

Answer being

Someone beat me to it.

https://nodejs.org/docs/latest/api/process.html#processexecvefile-args-env NodeJS can do it since v22.15.0. Valetudo (at the time of writing) uses v22.18.0

So, if Valetudo senses that its time has come, it can now write down its last thoughts, then replace itself with a clone and just continue as if nothing ever happened. I take great joy out of building mini sci-fi horror stories.

But why?

There are currently two use-cases for this:

Updater

First one is the updater not doing a full system reboot. That's very nice, but might possibly expose some yet unseen side-effects.

We shall see. It could easily be deactivated and rebooting was fine, but this is quicker, less disruptive, and also fun and cool.

Failsafe

Second one being Valetudo no longer killing itself if it ever reaches 1/3 of system memory.

This hasn't happened since probably at least 5-6 years, however, with the Midea bots no longer rebooting nightly, after a Month of uptime, someone found no Valetudo on their bot.

Ideally, you would fix this at the root, but the root - at least as far as I can tell - is not to be found in my JS code, but might instead be in the runtime itself.

Replacing yourself with an identical clone with a memory implant is thus the next best thing to a solution to issues such as memory fragmentation or tiny leaks.

Docs

The docs have been redone framework-wise. Content stayed the same, but tech and design changed massively.

Gone is the old, outdated and stale Jekyll version. In is eleventy (a JS-based generator).

Additionally, styling was greatly improved and now embodies the somewhat distinct visual identity Valetudo eventually grew.

This broke a few permalinks, so if you're coming from a third-party guide, [clarkson laughing at you meme].

What else is going on?

Welcome to the more blog than usual section of the release notes.

Marstek Venus A

I bought a battery storage system for my solar setup. It comes with very attractive pricing (170-220€/kWh), is modular, expandable and has an ethernet interface.

It is also majorly broken and not for the faint of heart.

This thing is pain. Everything about it is pain. They've moved from single units to a modular architecture, but the firmware doesn't really support it.

Meaning that if you add a new battery module later, the system just breaks until you pray to the support, which is ignoring your tickets. So you instead contact the leaked email address of some random parent company employee and beg that they push an update via the cloud. And then it still doesn't work.

The ethernet port was a great upgrade up until the point it stopped negotiating at fast ethernet speeds and just dropping offline. Now, with the port in the switch forced to 10Mbit half-duplex, it works. Question is for how long.

But, I am now immersed deeply enough into its inner workings to not throw it into the trash. Thanks sunk cost.

First thing I started with was getting rid of the App. This sorta worked and produced Venuscontrol, which is a WebBluetooth reimplementation of said app.

It however doesn't do OTA Updates, and, as said above, you kinda need those if you want to do.. anything really.

If you're looking for something to hack, please, build a non-insane custom firmware for this thing. From my understanding, those aren't signed, so you can just flash something else if you want. But maybe double-check that.

If you do just want a thing that works without the cloud.. uh. well. I suppose you could buy just the Master with 0 Expansions. That should probably work and is attractively priced.

But I dunno.

BambiHeavy

After upgrading my living room from "Ikea galore" to "damn, you're 30 now. It is mid-century time.", it was time for a new TV. This was a great opportunity to again learn why local businesses are dying and how doing anything else than buying online is a bad idea.

But anyway, before the return odyssey, this gave me 18h with a Philips-branded OLED TV. The brand however no longer belongs to the dutch conglomerate but some Chinese corp called TPV Technology. Same goes for "Philips Hue" which is also not Philips but Signify (7.54% annual dividend yield, btw. Fairly consistently.)

This split appears to have eventually led to a fallout between those two new corps, ending with Philips Hue lights and Philips TVs no longer playing nice with each other.

Recently, possibly in an effort to improve margins, Philips TVs moved from Android TV to TitanOS, which is some.. startup? I dunno. It's some Linux thing, which is just customizing the SOC vendor SDK. Basically it's a Vacuum Robot with a screen.

Firmware updates were signed but not encrypted, so it was an interesting dive into the thing.

Learnings
  1. The OSD is just some HTML pages.
  2. The rest of the Firmware is just duct tape.
  3. The ambilight demos (I forgot to take pictures :( ) are just WebGL demos from random places on the web (including codepen).
  4. There was a 20€ Invoice PDF in that firmware, documenting the purchase of some background music to be used in said demos.

OLED, at least in that implementation, is bad tech. It can be super bright, but only if just a small object on screen is. If the whole screen has to display something bright, it auto-brightness-limits itself to "broken CCFL in a Thinkpad T60 waiting to be replaced".

There is an OSD option to disable that, but then it just switches to that low brightness at all time. Utterly useless.

Add to that that OLED can get sunburn (yes, really!) - meaning that you should not put it up in a room with windows - and you find yourself mentally cursing at the world, the shop, the salespeople and yourself for not just buying it online.

Of course, being the lokale Einzelhandel, you cannot just return the thing and get your money back. Instead, you have to buy something more expensive from the store.

So now I have some slightly used Sony Bravia 5, which was the only non-shit non-OLED TV they had in stock. It's alright I guess. Would've just been cheaper when bought online.

What to do about it

But anyway, the cool thing about the Philips-branded one was that Ambilight. Even having it for just 18h was enough to make me miss it. So I've pondered what to do.

Could do Hue entertainment, but that needs the proprietary Hue Bridge + the Hue Sync box between TV and content source. Could do Hyperion, but that needs you to usually have very little expectations when it comes to aesthetics. Could maybe.. solve it in software?

One cool thing that has happened is that someone reverse engineered the proprietary "Hue Entertainment" extension to the Zigbee protocol. That's their secret sauce that enables a light update rate up to 25 updates per second.

This also was implemented in Zigbee2Mqtt, meaning that if you have Hue lights that support Hue Entertainment, the only missing piece is transforming screen content into light commands. Thus, I figured that that might be a great test for Qwen3.6-27b and its abilities.

Now, there is BambiHeavy which does just that:

https://github.com/user-attachments/assets/a1db0c37-d7fc-4809-9c25-7f9363880586

It's alright. I'm mostly happy with it; apart from some minor tweaks to be done. All in all, Project Hail Mary looked great with it.

It is still vibecoded jank, but you may find that useful regardless. You may also find knowing that Z2M can do Hue entertainment useful, because Ambilight is just one use-case for that.

Someone please build a cool music visualizer. Maybe hook up squeezelite to it?

Hotline Valetudo

In my continuing efforts of pivoting from "building software" to "making performance art that somehow also does real useful things", I've felt like leaning in some more on the corporate satire.

Therefore, the Valetudo Premium Support System VPSS is now available via +495021 / 9039940. For privacy reasons, caller ID suppression via prefixing with #31# is advised, but you do you.

You can also run it locally if you do not want to pay for calls to germany. It's exactly the thing committed to GitHub.

Hopefully you will have fun.

Also, equally hopefully, some entitled idiot will gloss over all communication in the docs, skip right to the premium support hotline, and end up in a hell of his own making. Please hold the line.

Meta

Qwen3.6-27b has been pretty much essential in all of these fun little hacking side-things. It effectively substitutes the raw energy, free time and "this is all new and interesting"-boost I had ca 10 years ago (and now don't) with GPU compute.

I think with these open weights models, vibecoding is here and here to stay.

I suppose one will just have to make peace with that, the same way one will have to make peace with suddenly needing glasses, hearing aids, or really any kind of augmentation to compensate for biological reality being inadequate. Which, I suppose, is fine, if there is no rent-seeking cloud landlord middleman.

Custom firmware hearing aids when?

Actually, I have no idea how good or bad that specific market is. I'm just pulling this example out of thin air without having any knowledge about it. Please correct me in the comments.

Either way, I guess the aforementioned LLM assistance could actually have a positive impact in the development of such tech that people truly own themselves. If we use these tools correctly that is. And if we don't shut off our brain entirely.

It would also be nice if the entry fee wasn't multiple thousand euros of hardware, but that's going to change with time (I hope).

The slightly less usual

Speaking of entry fee to AI, I've been hitting the VRAM limits of my 24GB RTX 4090 pretty hard and pretty consistently.

So if you have something with more of that (and equal or greater compute) lying around (e.g. decommissioned server or whatever), my NAS would be happy to receive an upgrade.

Beside that, as usual:

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • mqtt: Room cleaning for HA 2026.5 and up 6bdef9f
  • ui: WASD manual control 80cf405
  • updater: Allow force updating to the same version for dev testing purposes 38b943a
  • Biblically accurate exception handling b786064
  • mqtt: Publish Dock Component Status to MQTT 5d905ec
Fixes
  • vendor.dreame: Obstacle naming 149a205
  • vendor.dreame: Add additional model IDs 6c51d72
  • vendor.dreame: Disable postWriteDelay for manual control commands 8a93d60
  • ui: Some map touch handling cleanup e9998d2
  • webserver: Remove obsolete express-list-endpoints 00c61e3
Refactoring
  • docs: Migrate to eleventy + redesign 0cf7d72
  • vendor.dreame: Send all communication through the miot helper 6fc711d
  • vendor.dreame: Central miot helper a9a5ab3
Chores
View originalPermalink
How 2026.05.0 went
2026.02.0

Valetudo 2026.02.0

Added 6
  • Dock component status view showing individual component status for supported robots
  • Robot options grouped with sub-headers to improve UX on robots with large option lists
  • MopDockMopDryingTimeControlCapability to control mop drying time in the mop dock
  • AutoEmptyDockAutoEmptyDurationControlCapability to control auto empty duration of the auto empty dock
  • CleanRouteControlCapability with context metadata properties to handle varying vendor implementations
  • Support for Dreame L20 (MR813) robot

Features, Robots, Maintenance and everything in-between

Valetudo 2026.02.0

A surprising amount of relevant things has happened since the last release. I'm not sure how, given the comparatively short time frame. But it did, so here's me talking about it.

Features

As said, a ton of stuff happened, but first, let's focus on what you as a user will see.

Dock Components

On robots that support it, the controls for the Dock have been updated with a status view for all the individual components:

This starts off collapsed and only renders expanded if there is something going on.

The icons are custom and were made in-house by our janitor that likes to go on long philosophical tangents.

In the next release, I'd like to expose these to MQTT for even better automations.

Robot Options

On the most recent supported robots, the list of options has grown to a size that was becoming actively harmful to the UX. Having dabbled in the vendor apps and done some market research however, it was clear that hiding everything in submenus would be worse, as those suffer from bad organic discoverability.

Thus, it's now both.

By grouping and introducing these sub-headers, the wall of text has been broken up into something a lot more mentally digestible.

New capabilities

Now that we have all this new free conceptual space + the idea of "discoverability" fresh in my mind, I've turned to the quirks and found some worthy of hoisting up into their own capability.

MopDockMopDryingTimeControlCapability

This one controls the mop drying time of the mop in the mop dock.

AutoEmptyDockAutoEmptyDurationControlCapability

This one controls the auto empty duration of the auto empty dock.

CleanRouteControlCapability

This one... was surprisingly hard, because of vendor behavior varying a lot more than you'd want it to for a unified capability. What might apply to "just mopping" on one vendor might be for all cleanup tasks on the other. Also, some options might be one-time toggles.

Fortunately though, the very extensible concept of capabilities having properties that are context metadata did provide the solution here.

New Bots

In the 2025.08 release notes, I wrote

Extrapolating from the current state, it is unlikely that we will see many more new Dreames being supported by Valetudo.

So what is this then? Well... did you spot the two modifiers in there? "many more" and "new".

While I am an ideological hardliner on principles, I'm not one on purity for the sake of purity. I do not need to shoot myself into the foot to "make a point" (usually unsuccessfully).

Truth be told, the method is the same for these bots. The research does carry over. These are just low-hanging fruit we shall pick, because why wouldn't you.

Dreame L20 (MR813)

I do not like this robot. It offends me.

This definitely is in part due to residual anger and memories of people pestering me, telling me how great it is and how it is of utmost importance to be supported. But it also is due to the robot itself.

"Sports Utility Vacuum" is the term @aep coined for it, and it fits perfectly. While it can do regular vacuum robot things, just like an SUV, it does so worse than a normal one.

Here's my list of gripes:

  1. The dock is positively ginormous for no benefit + at least my unit regularly struggles to dock properly.
  2. The robot itself is higher than it needs to be due to the mics in the tower bumper for the useless voice assistant feature (I think this bot started that?), meaning that it fits under less furniture
  3. The design was an overly complicated dead end due to various reasons beyond the choice of a different SoC

and 4. Due to that failed overengineered design + what I assume are contractual obligations, there are now two completely different bots both named L20, with only the second more-like-the-rest-of-the-lineup one being the one that is rootable.

The L20 Ultra is a monument to bad business decisions. I don't know which exactly and neither do I have solid proof, but the stench is hard to oversniff.

But anyway, the "L20" with extra quotes (the MR813 one) now is also supported by Valetudo.

If you buy the right one (and be very careful that you do based on its SN), it will work like the other bots. The win here is not this robot but an improved ability to source a supported robot.

Also it does run the same SW so on that side it's not all that different. Interestingly though, they've stripped miio from that firmware, but that was easy to fix through frankensteining something.

Why from that older bot only and not from e.g. the X40 is beyond me though.

Bonus (and also segue):

In some regions (not mine tho), there is also an L30, which is the L20 but with a water heater in the dock. Apparently, a knee-jerk reaction to Ecovacs releasing that feature first; taking away the crown of features from Dreame.

Same bot with minimal changes to its dock. New SKU. Purely reactive.

Dreame X30

I said segue. Why did I say segue

The Dreame X30 is a bot that did not really happen.

It was announced by Dreame, just so that they could then announce the X40 before the X30 was even available for purchase yet. This again was a knee-jerk reaction to Roborock releasing a new Flagship with an extending side brush; taking away the crown of features from Dreame.

So no one really bought this thing, because it was obsolete before it even launched.

Being close to an X40 (minus some suction, extending side brush, newer SW and a different front camera/LED assembly design), it is a good bot. You can still get it new for decent-ish prices.

Valetudo Home Assistant custom_component

A while back, I've announced that there were Valetudo Icons for Home Assistant. The solution there wasn't great and didn't fully work.

The only way to get it working properly is to have a full custom_component, which eventually was created. That thing sat dormant for a while but now comes with a feature a lot of you have been waiting for:

Once configured, it will enrich all discovered Valetudo Robots with an "Estimated Segment" sensor.

This is experimental, but I've heard from people that they're happy with it, so I suppose it works mostly reliably.

You can get it here: https://github.com/Hypfer/hass-valetudo

Goodbye Create React App

Valetudo's frontend used CRA, which was unmaintained since ~2022 and sunset in early 2025. While it has served Valetudo well, it was also responsible for a ton of completely unused dependencies + npm audit constantly complaining about many vulnerabilities (none of them actually affecting Valetudo).

Getting rid of it was long overdue, but, the sheer amount of understanding of the tooling required to do so kept me from doing it. .. but then I remembered that LLMs are a thing now. They're like.. exactly the right tool for this job. They're boilerplate comprehension machines.

So with that tool assistance, I got to work and cleaned up the massive wall of incomprehensible gibberish post-eject down to a much more comprehensible 300 line webpack config that does only what Valetudo needs.

While I am fairly confident, it would not surprise me if this broke something more subtle, so if you spot something, please let me know.

Maintenance

Speaking of changes that might break things, with CRA gone, dependencies were bumped. React is now v19 and ExpressJS is v5.

React just worked, but ExpressJS caused some breakage that should be fixed now.

Same applies here. If you spot something, please let me know.

Misc
  1. Segment Names are now rendered larger than in the last release. Thx for the feedback on that
  2. After having an epiphany, I found a way of implementing Segment renaming on Midea, so that's available now
  3. Dreame bots that support it now have access to the "Carpets First" quirk, which will make them clean carpets first
  4. New firmware updates for Dreame X/L40 Master/Ultra + Mova P10 Pro Ultra are now available on the dustbuilder
  5. The UI was polished some more, with the Valetudo colors now being used everywhere
Docs

There's even more. No matter if you're a newcomer or a recurring user, both of these things will affect you.

We (this time not the royal but the me, Dennis et al.) have managed to get rid of the clunky and proprietary LiveSuit for rooting Dreames. The docs have been updated with the new instructions utilizing the FOSS sunxi-tools. A lot less headache will now hopefully be had.

Additionally, I have updated the buying supported robots docs page with actual guidance again. The LLM told me that it reads the vibe as "you've met an engineer at a bar and he rambles on about robots", which is what I was going for.

What else is going on?

With the Valetudog going superfast in the 2025.11.0 release notes, Valetudo itself is now going the speed limit:

@NKnusperer, the absolute madman, took his passion for Valetudo to the streets. Did you know that there is an aftermarket for custom in-door light projectors? Did you know that these services accept arbitrary images?

There was no other way this discovery could've went. 60€ well spent.

I also really like how it might as well pass as some kind of new EV startup, and with that a prototype car or whatever. Which, fair, is easy, given that Valetudo is tech and EV startups are tech, but it's still cool!

If you also have a cool and non-commercial idea, art assets can be found here: https://github.com/Hypfer/Valetudo/tree/master/assets

I, too, have been creative with Valetudo lately. I hope that you will like it.

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • vendor.dreame: Carpet First quirk 4589bbc
  • vendor.dreame: Map additional error codes 158c678
  • ui: Add support for xm files 8363770
  • vendor.midea: Dustbag dock component 8e020ef
  • vendor.dreame: Add missing metadata 8c2fefe
  • vendor.midea: DockComponentStateAttribute 8d483b7
  • vendor.dreame: DockComponentStateAttribute d771b4c
  • ui: DockComponentStateAttribute cc3c6a2
  • core: DockComponentStateAttribute eaaa1bd
  • ui: Peent 4798616
  • vendor.midea: MapSegmentRenameCapability e2045ba
  • vendor.dreame: L20 Ultra (MR813) 12abbd3
  • vendor.midea: AutoEmptyDockAutoEmptyDurationControlCapability bc2445d
  • vendor.roborock: AutoEmptyDockAutoEmptyDurationControlCapability 4da60ae
  • ui: AutoEmptyDockAutoEmptyDurationControlCapability 597bf57
  • core: AutoEmptyDockAutoEmptyDurationControlCapability 448e3ad
  • vendor.midea: MopDockMopDryingTimeControlCapability 1366c97
  • vendor.roborock: MopDockMopDryingTimeControlCapability 0344ba4
  • vendor.dreame: MopDockMopDryingTimeControlCapability b3e1527
  • ui: MopDockMopDryingTimeControlCapability e550f9e
  • core: MopDockMopDryingTimeControlCapability fe4e164
  • Replace IntensiveMoppingPathControlCapability with more generic CleanRouteControlCapability b08a3d2
  • ui: Increase segment label name font size eb3bde0
  • vendor.viomi: IntensiveMoppingPathControlCapability 6a8c5ef
  • vendor.dreame: IntensiveMoppingPathControlCapability 63a761e
  • vendor.roborock: IntensiveMoppingPathControlCapability f2568bf
  • vendor.midea: IntensiveMoppingPathControlCapability 9e75fd4
  • ui: IntensiveMoppingPathControlCapability 5b08538
  • core: IntensiveMoppingPathControlCapability 3849905
  • ui: Valetudo Genuine Advantage™ cac7960
  • ui: Group robot options into categories with subheaders 2b03afc
  • vendor.dreame: X30 support 8928887
  • vendor.dreame: L10 Ultra also supports material 99a91f6
Fixes
  • ui: UX cleanup of sidebar nav 0c82159
  • vendor.roborock: Fix initialization of supportedAttachments after refactor 92dd06d
  • ui: Prod build 414d959
  • webserver: Use correct new expressjs 5 syntax for optional path parameters 5ec1f5a
  • ui: Don't break the layout 76650d9
  • vendor.dreame: L10spuh FW 1633 does not have a mop consumable anymore 4280e9a
  • vendor.viomi: Wait even longer for the firmware to think fd9ec50
  • ui: Fix goto marker scaling and draw order 2a1fb8e
Refactoring
  • ui: Inline useless env.js file 9c0d22a
  • ui: Eject from now-dead CRA 4713182
  • ui: Get rid of heavy libs that were basically unused 4558f04
  • Pull initialization of supportedAttachments into ValetudoRobot base class 3a8cb21
  • ui: Pull valetudo colors to a central location 2035cbd
Chores
View originalPermalink
How 2026.02.0 went
2026.01.0

Valetudo 2026.01.0

Starting fresh into the next demi-decade

Valetudo 2026.01.0

Kicking off 2026, Valetudo now comes with improved visuals. Don't worry, it's not YouTube. You can stop screaming. The soul is still here. I'm just iterating.

A new font

Most central to this is the new choice of font. Replacing the default material Roboto, Valetudo now uses IBM Plex Sans.

I really like that font. It is mostly Helvetica but IBM and with some twists and interesting visual features. Compared to Roboto, which is engineered to be in the background, IBM Plex Sans tells you that it exists and has something to show to you.

Beside the merits of the font itself, I think out of all corps, IBM is probably the most aligned with what Valetudo is. When I think IBM, I think massive Mainframes, sturdy Thinkpads and lasting substance. Serious business that didn't bother with petty nonsense like rebranding or new logos since the early 70s.

They are a corp and have skeletons in their basement for sure, but for the most part, they just do their thing, building their International Business Machines and keeping the world running. A refreshing contrast to the rest of big tech, currently at the forefront of dismantling democracy, turning everything into dysfunctional gambling, just being evil and generally setting things on fire.

Of course, I'm also writing this to invoke Cunningham's law and get someone to tell me about all the evil stuff IBM does, so that I can return to my cynical baseline.

Anyway. I think this gives Valetudo a more distinct visual identity, which fits the maturity and spirit of the project.

Improved icons

Being stuck sick at home and not attending 39C3, I still wanted to do something that isn't hacking vacuum robots for a change. Fortunately, I have this whole project that comes with many different hats I can wear, so I've decided to wear the design hat and take a vacation from Valetudo by working on Valetudo.

The map view always felt a bit like it was built by an engineer; possibly because it was built by an engineer. Therefore, I stared at it for a while and pondered why that is. 🔮

After investigating at what the vendors do and what makes their visual language tick, I noticed that my icons were just.. bland and flat. A unicolor gray circle on a gray background.

So the first thing I changed was to add more visual detail. Three circles are more interesting than one circle. Additionally, I've noticed that the vendors use slight gradients to give the icons presence in the space instead of appearing like someone layered cardboard cutouts on top of something. So I did that too, and indeed it suddenly starts feeling much better.

Just by looking at the comparisons, I could not tell you that there is a gradient now. It just feels.. better. So that is neat. As it should turn out however, Firefox got very unhappy rendering all those gradient-filled SVGs at 60fps.

I suppose that makes sense. Filling a simple shape with a single color is much less computationally expensive than calculating the color to fill with for each single pixel. It also doesn't help that the map renderer architecture is not at all following best practices on how to build performant 2d graphics.

So that came with a technical detour, adding automatic mipmap generation and letting the renderer use raster graphics instead, while still keeping the visual clarity of the SVGs.

While I was at it, I've also cleaned up some other performance issues. For example, also caused by the architecture, using shadows and blur on the canvas completely tanks performance due to.. idk I didn't care enough at this time. Something something very large things to draw.

Lastly, I've made the red and purple of virtual restrictions a bit less pure red and purple, as those didn't really fit the rest of the map.

Improved visuals

Beside icons, other visuals were also improved.

For example, text on the map now comes in these pills:

This greatly elevates the look from "meme-font Impact with black and white stroke" to "how all the other vendor apps are looking", which isn't always a correct goal, but this time it sure is.

Additionally, handling of zoomlevels was improved. The text now scales more sensibly and so do the icons. For some reason, past-me thought that icons must never get smaller than x pixels, leading to this abomination:

Now, new year new me 💅 is doing the sensible thing:

Don't ask me why it took me so long to realize that the previous thing was nonsense.

Floor Materials

Not all is just visual in this update, though this also comes with new visuals. After just going through backlogs of messages and generally looking around and assessing the situation, I've noticed that @xuefer apparently managed to draw floor materials in what I assume must be a private fork of Valetudo. (Which is great! Everyone should do it like that. It is FOSS precisely so that this can happen. People solving their own problems.)

This intrigued me, because I just never had an idea how to implement that. Seeing it being possible though made things finally click. Once that mental block is gone, it is actually surprisingly simple. All you need to do is render some pixels in a different color and then you get texture. So thank you @xuefer, for being a model citizen!

From a technical standpoint, this works by checking the coordinates of a pixel drawn, determining if according to the texture it should be accented, and if so, draw with an accented color. Simple stuff and super easy to extend with more textures.

So now, if your robot's firmware supports it, you can configure the floor material of a segment.

What is this good for, you wonder? That's where the next item comes in

FloorMaterialDirectionAwareNavigationControlCapability

That's a mouthful. If your firmware supports it, you can now tell the robot "these are wood planks and you will hurt them and possibly you if you don't clean them in paths aligned with them".

I don't have such flooring, nor would I want to have it the same way I do not need non-dishwasher-safe things in my life. But if you do, this will likely improve your experience.

What else is going on?

If you're reading this, you probably have a 3d printer, or are at the very least aware of their existence. What you may not know however is that we by now have similar machines for similar prices for embroidery.

@jhbruhn recently got one, but was unhappy that it required an account and the vendor app to use. So of course he did what we all should do when facing such tech: He liberated it through making it interoperable.

Using https://github.com/jhbruhn/respira you can now use the Brother PP-1 SKiTCH embroidery machine completely without the cloud.

If you or someone in your household might be interested in these crafts, now is the time to look into that.

I am unfortunately not a very artsy person, so I cannot really paint vivid pictures for you regarding what could all be done with that thing. I am great at being cynical though!

So one thing you could do is create counterfeits of work clothes, which may or may not allow someone with criminal energy to enter places they should not be in. Getting busted for being a darknet embroidery vendor will also most certainly get you onto some podcasts. Of course, please don't actually do that. Just because you don't see them behind your screen, doesn't mean that cybercrime would have no victims.

Putting that aside, I do think that there is real potential for ethical red-teaming here. You could easily manufacture the right clothing on-site in the trunk of your car. That also makes for a good story and gets you onto podcasts, but it does so by improving the world instead of harming it.

Maybe we as the hacker bubble could push for a bit more ethics and not reward criminals as much as we tend to sometimes do. Just some food for thought.

I will leave you with this perfectly cut clip from 39C3 I found on the internet (needs sound):

https://github.com/user-attachments/assets/f783baea-c897-426f-9ccb-e5a673a0bd10

Happy new year!

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • ui: Update capability icons with new monochrome robot icon design 5004619
  • ui: Improve some wording d6cb9c3
  • webserver: Lawful compliance 6638b23
  • ui: Update robot icons to look less like a pokeball 386dbd8
  • ui: Switch font to IBM Plex Sans d0fa5a2
  • ui: Improve label rendering for map structures 8fd17be
  • ui: General map polish including improvements to performance + UX + looks 6d54afa
  • ui: Improve map icons 05450c4
  • vendor.midea: More quirks 8dfb08c
  • vendor.dreame: FloorMaterialDirectionAwareNavigationControlCapability 2c4717f
  • vendor.roborock: FloorMaterialDirectionAwareNavigationControlCapability + MapSegmentMaterialControlCapability 5c257a5
  • ui: FloorMaterialDirectionAwareNavigationControlCapability 4005e0e
  • core: FloorMaterialDirectionAwareNavigationControlCapability 7db5b75
  • webserver: Add another 404 page 3456363
  • vendor.dreame: MapSegmentMaterialControlCapability 5273df1
  • vendor.midea: MapSegmentMaterialControlCapability 93132c6
  • ui: MapSegmentMaterialControlCapability b13d796
  • core: MapSegmentMaterialControlCapability 6a8dd6f
Fixes
  • ui: Minor visual cleanup 4cbc004
  • vendor.dreame: The latest L10spuh firmware uses the newer-style mop extension controls 04bac60
Refactoring
  • vendor.roborock: Wording 714af6c
  • ui: Clean up mapLayer color handling 2146713
Chores
View originalPermalink
How 2026.01.0 went
2025.12.0

Valetudo 2025.12.0

Midea root goes public, more Robots, Carpets

Valetudo 2025.12.0

It appears that time has advanced. Not sure when that happened. Once you're done reading these release notes, consider shutting off your device and spending the end of the year with people that matter to you.

Merry Christmas, and, of course, a Happy New Year

Midea Public Root

After more than 6 months of work, my Christmas present to you is the public release of the root for Midea robots. 🎁 And, of course, full support for them in Valetudo.

Over this timespan, I've bought basically all the models they have, took them apart, reverse-engineered them, tested them, and implemented the support in Valetudo for them. And of course, all the supporting stuff like writing an installer, documenting the procedure, actually testing the procedure, etc.

I will have to warn you though: I have stared at this for so long that Betriebsblindheit will most certainly have set in, meaning that it is possible and likely that I've missed something that will be ironed out in future updates. Also, while I have all of those robots, I have just one of each, so there's only so much I can cover with my testing.

But, with that, Valetudo now has a new Vendor with an easy root not requiring some self-soldered PCB; Featuring models that are cheap, models that can climb higher thresholds, and models that have a bagless auto-empty dock.

It was a lot of fun, but as with every big project, the final stretch was getting quite tedious, so I'm very much looking forward to some kind of vacation. I crave some free time not spent hacking or thinking about hacking robots.

=> Valetudo on Midea Telegram Group

New Robots

Since I wanted this root to be as complete as it could be, I have spent a lot of money.

I also had to send back two WHD robots that arrived broken, which got Amazon to flag my otherwise mostly unused account for returning defective goods. No shit, Amazon. Of course I'm returning a broken item as broken when it is broken. Of course, that item will arrive broken.

Anyway, if that ever happens to you, welcome to a circle of hell where there are just machines telling you that you did something wrong but not what exactly, when or how. A place where the only maybe-humans that exist talk to you in predefined text blocks that do not at all have anything to do with what you're saying.

FWIW, this Kafkaesque nightmare might be a great opportunity for European e-commerce, so thanks Jeff.

Eureka J15 Max Ultra

This one is the best Midea currently has to offer. In CN, it is sold as the V16, which I think is a better name than trying to cram it into a "J15" Series, even though it is quite different hardware.

This one is what the V15 (J15 Pro Ultra and Ultra) should've been from the beginning. With eMMC instead of NAND and with a firmware that actually tells you which rooms are part of the current cleaning task.

As with all of their bots, it is not competitively priced (yet?) but, well.

The somewhat better threshold climbing ability is a neat addition to the Valetudo lineup, though I kinda expected a bit more. As a benchmark you should be able to simulate at home, it did successfully manage to climb over two Ikea IVAR shelves, but only when they're offset by quite a bit:

https://github.com/user-attachments/assets/5afb4b17-ddcc-4b23-a0a3-54fe8f1509b2

I did see some influencer ads claiming that it can handle floor-standing mirrors gracefully, though I did not verify that myself just yet. If true, that could be neat as well.

Midea E20 Plus

I bought this one (or rather its almost-identical brother, but we'll get to that shortly) because I was thinking "Ah, well, easy win. Why not". That could not have been further from the truth.

In reality, this turned out to be a comparatively ancient design Midea is still milking, meaning that I had to reverse-engineer and reimplement most of the communication again. It did help that I already knew how their newer protocol works, because I could fall back on similarities.

So I did move quite a few steps closer to the M7, which was the first Midea bot I ever bought but then left as-is, due to bad HW specs.

When it works, it works okay, I guess? It's just.. unsophisticated.

For example, the way the cliff sensors are tied into the firmware is anything but graceful. The rest of the logic does not seem to be fully aware of them, meaning that it tends to drive at full speed to the edge of the stairs, just to then violently stop. It will then continue doing that for multiple minutes straight.

They also didn't bother with adding some diode or whatever, meaning that when turned off and you shove it around, the wheels spinning will make its LEDs light up through backfeeding.

The bagless dock looks cool and seems to work? I have no complaints there. I do not think that it makes much sense to buy a worse robot just to not buy 20€ in one lifetime of dustbags, but if that's your thing, you now have options.

Because of its transparency though, you will always be looking at dirt and debris, which to me feels detrimental to the living space. It is however fun watching the dirt spin around during the auto-empty cycle. There are pros and cons.

Midea E20 Evo Plus

Speaking of options, here's the same robot again. The same robot again? The same robot again!

But no! They've removed the second side-brush motor, added some cheap plastic plug in its place and now use the new side-brush design of the V16. So.. it's less hardware for the same price.

I dunno man. Why would you do that.

The answer might be that this one runs a slightly newer firmware, though no idea what the difference might be. As it is literally the same robot, I just took that firmware and used it for the E20 Plus dustbuilder, closing the gap between the two I guess.

My specific unit is actually interesting though, as I had managed to kill it by accidentally flashing the J12 firmware onto it. It did not like that, but recovering made it even worse.

Eventually, however, I remembered that some guy on Kleinanzeigen scammed me when buying the Obode A8+, which is basically the same design again. That thing, however, was mostly toast:

https://github.com/user-attachments/assets/f8baa764-2efb-43fa-acd2-27208176dc60

(Needs Sound. Feel free to remix that beat)

But, through the power of Kontakt 60 and a free Ikea anti-child-crush furniture-wall-mount-kit washer, I was able to recover its compute module and, with some magic, reflash it to the E20 Evo Plus firmware.

I would not recommend this. I bet it's half-broken now and will never talk to the cloud again, but that was kinda the point anyway, so.. FWIW, it was a great learning opportunity.

The lessons learned there were that a) Kleinanzeigen is full of scammers and b) an installer with sanity checks is not optional. Not even for the people building the installer.

Carpets

Besides implementing existing functionality for new robots, Valetudo also gained a new feature: Carpet Rendering.

Valetudo will now show the carpets as detected by the firmware, provided the firmware actually reports them. As this is a mostly carpet-free household, I almost forgot about this change, but YMMV and you might find this very useful.

R2338H Kerfuffle

Dreame did a thing and silently released a new variant of the L10s Pro Ultra Heat that, for the user, is almost indistinguishable from the older version. That distinction, however, becomes painfully evident once the user tries to root it, only to be faced with a robot that doesn't charge anymore.

That was a frustrating thing, but eventually I figured it out and added further validation to the Dustbuilder. It is now super janky, featuring a second dustbuilder page for the same robot, just with a single character difference in the SN. But what can you do.

The silver lining is that a new firmware version for the "regular" ones came out of it too, so if you're using the L10s Pro Ultra Heat, feel free to head to the dustbuilder for an update.

If you're one of the unfortunate people that have been hit by this but aren't recovered just yet, please ping me on Telegram.

What else is going on?

I was sent a video of Valetudo being controlled using a VR headset:

https://github.com/user-attachments/assets/73305ba4-9ba2-4fb9-a9cb-3ee0b01761a4

What I really like about it is that it just works and decently at that. I had never planned for VR Valetudo, nor did I have to. It is just a webpage in a browser. Peak interoperability.

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • ui: Also show carpets in edit map view 0d3ee08
  • vendor.midea: E20 Plus 51d8531
  • Display detected carpets 133f843
  • vendor.midea: Add quirks for various mop-related controls 10c692a
  • vendor.midea: J15 Max Ultra 2771580
  • vendor.midea: Various cleanups 6a4a6ca
  • vendor.midea: E20 Evo Plus cde0bc8
Fixes
  • vendor.dreame: Detect R2338H 197f866
  • ui: Slightly improve visibility of carpets 689b48f
  • vendor.midea: Misc fixes a9b3621
  • vendor.midea: Misc b31dc84
  • vendor.roborock: The S4 does not support carpet mode aaa1415
  • mqtt: Use new default_entity_id instead of deprecated object_id in autodiscovery 4ba6c43
Refactoring
Chores
View originalPermalink
How 2025.12.0 went
2025.11.0

Valetudo 2025.11.0

Refactoring, bugfixes, new Robots

Valetudo 2025.11.0

Holistic is the word I'd pick to describe all the different things that I did as part of this release.

Midea

Midea is still moving along. I am buying new robots, taking them apart, try to root them and through that, improve the rooting process. This was already successful. We now have a much more user-friendly way of rooting.

This is why you wait with the release of a root, even when you already feel somewhat confident in it. It is not the first time and will not be the last time that we found something even better through looking at it longer.

Eureka J12 Ultra

j12u

I now own this robot. It runs Valetudo. The RK3308 SoC is not the quickest and thus Valetudo needs a minute after boot to fully start up, but once it is started up it just works. Valetudo as we know it.

Being older than the J15, I could see some of the evolution their software went through. This led to me gaining a better understanding of what were previously rather confusing details, duplications and not-quite-clear aspects of the software, data formats and interfaces.

This was the one mentioned in the last release notes with the whole WHD weirdness. Something interesting about it was just how good Gemini was at geoguessing the prior shipping label's location based on a StreetView screenshot. On top, I learned that northern france looks quite similar to the UK in some ways.

Eureka J15 Ultra

j15u

I now also own this robot. It runs Valetudo. This one runs the same firmware as the J15 Pro Ultra, however, it is not exactly the same robot. There are some minor differences. The fan motor is a bit weaker, it has no internal water tank, it can't lift the main brush (rather unnecessary tbh), the mop wash board in the dock is different and stuff like that. Otherwise, it is exactly the same.

This one was sold to me as completely defective. It had no issues whatsoever other than coming with old dust and hair from the previous (again french) owners. I am starting to see a trend here.

Eureka J20 - no Valetudo support :(

I have also looked at the J20, excited about the possibility of a Valetudo-supported robot with this new rolling mop technology.

Unfortunately, this turned out as a waste of time and money, as it is just branded "Eureka" but actually made by a different ODM (LD-Robot?). This means that the software is entirely different and a dead-end without updates. On top, it came with a laughably small 128MB flash chip, which is not enough to sustain Valetudo.

The search continues...

Eureka E6 Plus - no Valetudo support either :(

This one cost me ~100€ as a "badly worn" Amazon WHD, so I tried for fun. What showed up instead was a factory-sealed box with a completely new robot. Eureka definitely seems to have bribed fortuna for me (or they have a lot of robots that won't sell?)

Unfortunately, this too was made by another ODM. Not sure who or what hardware is inside, but I didn't bother with it. It felt cheap and not worth the trouble while also offering no benefits or USPs.

It was cute and small though. I would still like to one day find a supportable robot that is cute and small. There is the Xiaomi Ultra Slim, but it never made its way to the west beyond some random resellers on Aliexpress, unfortunately.

More and slightly polished achievements

Total statistics achievements have received some love with this release. There are now more of them that will hopefully bring you some joy. It at least did bring me joy to add them.

Furthermore, in the achievement list, you can now see at which point it was achieved. This should eliminate some confusion.

No screenshot here, as that would spoil the fun.

Updater reliability improvements

Somewhere in the middle of building the Updater, my mind apparently kinda stumbled over itself. It was prepared so that the update process would never let go of a file handle, but it never actually did that. This, in rare cases, led to situations where the newly downloaded Valetudo binary for some reason had vanished, but the updater still continued to delete the existing one.

Not sure what made the downloaded binaries vanish. Probably some "storage cleanup" cronjob or similar, but it also doesn't matter. By fixing the code and keeping the file handle, we do not have to care.

This should thus fix a rare breakage you likely haven't experienced yet (I hope).

Mop Cleaning fix for the Dreame W10 (Pro)

Valetudo was sending the wrong payload for the DreameMopDockCleanManualTriggerCapability on the W10 and W10 Pro, leading to the robot not doing anything. This should now work as expected.

Docs refactoring

In the August release, I've talked about how looking again at the architecture of the code brought some inconsistencies and bugs to light that I swiftly fixed. In this release cycle, the same thing happened to the docs.

Bugs have been fixed, unhandled exceptions have received a graceful handler, interfaces have been cleaned, implicit assumptions have been made explicit, separation of concerns was achieved, context was provided and overall, the whole thing was again looked at from a distance and in detail.

Thus, while the groundwork was there all along, they should now be a much more polished and comprehensive experience without sudden and grave potholes.

I have also added a "developer commentary" spoiler to the Code of Conduct. Now that it had been a few months, I had the time to collect some thoughts about it and that is where you can find those.

My general goal was to make Valetudo more approachable/relatable/human and less intimidating/defensive/hostile, while still keeping the filtering aspects as-is. Feel free to have a look at these changes and let me know what you think.

Home Assistant deprecated the object_id

As part of the normal refactoring process, Home Assistant has deprecated the object_id for Home Assistant Core 2026.4. You might have seen a warning about that in your Home Assistant instance.

This is an easy fix in Valetudo - in fact, the commit is already on a branch - but it won't be merged just yet, as that would break Valetudo for HA versions older than 2025.10. For now, you can rest easy, knowing that I am aware of this and just click on "Ignore".

What else is going on?
The Valetudog went 270 mph

This is the Valetudog:

The Valetudog is Valetudo's official mascot; born from an interesting looking corner drawn on a map of my second-ever Roborock S5. Through the power of paying 22€, I've stealthily inserted an obscure Valetudo reference into the content of a creator I really like.

And with that, it now was part of a new land speed record. I do not think that he knows what the Valetudog or Valetudo is, but that also isn't necessary, nor would changing that be my goal.

Instead, continuing with the parasocial admiration, if you like Valetudo, chances are quite high that you might like Superfast Matt's content, so I highly recommend checking it out. If cars are not your thing, you might still enjoy the video where he drives his RV off a cliff or the one where he builds an autonomous zen garden from a cheap 3d printer.

DEF CON 33 happened

I've been watching through the DEF CON 33 talk VODs. Here are some you might find interesting:

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Features
  • vendor.midea: J15 Ultra 84c8697
  • vendor.midea: J12 Ultra 8fc5a0a
  • webserver: Add another 404 page 64b0ee0
  • ui: More and better Achievements c3609fc
  • mqtt: HA autodiscovery manufacturer should be Valetudo 78ee0f5
  • vendor.dreame: Add some more obstacle IDs aa8c98e
  • ui: Enhance AI safety guardrails 4b45af6
Fixes
  • vendor.midea: Fix J12 ota update check failing 6c94eda
  • vendor.dreame: Remove legacy payload for manual mop clean trigger that worked for 0 remaining robots 94ae396
  • ui: Fix statistics label d1dd007
  • updater: Pass around a file descriptor to/and make things safer ff7e462
Refactoring
  • vendor.midea: Misc cleanup 1de0ca3
Chores
View originalPermalink
How 2025.11.0 went
2025.10.1

Valetudo 2025.10.1

Iterating on and due to the new vendor

Valetudo 2025.10.1

After the last release notes, which have been more of a devlog/manifesto, this one returns to a slightly more technical focus.

That said, things aren't over or resolved, so if you haven't read the 2025.08.0 release notes yet, I highly recommend you do: Valetudo 2025.08.0

So many new capabilities

As I wrote in the last release notes, with there now being two vendor implementations doing the same thing, a lot of quirks graduated and became capabilities. I am very glad for that, given that on recent supported Dreame robots, the quirks section contained more options than the regular robot settings, which was anything but good design.

Starting off with the first two, I'd like to again thank everyone who took part in the public brainstorming session for the icons. Even after seeing them for a while now, I still think that they've turned out great, and, as suggested, they indeed look merch-able. Though.. very obscure merch (which is usually the best kind of merch).

MopExtensionControlCapability

This one actually doesn't belong here, as it was introduced in the last release. It however does now have this new and improved custom icon, hence, here it is again.

MopTwistControlCapability

If your robot can't extend its mop to reach closer to the walls, it might be able to twist to achieve the same. Or, if it can extend it, it might still be able to twist to reach below some furniture overhangs.

The icon and description will reflect which of the two it is.

MopExtensionFurnitureLegHandlingControlCapability

Being named to prove just how enterprise-y Valetudo has become, this one allows you to enable logic in the firmware that extends the mop to clean closer to legs of tables and chairs.

MopDockMopWashTemperatureControlCapability

Pretty self-explanatory. The available options are somewhat arbitrarily named, however so are the labels within the vendor apps, as even though they say e.g., 100°C, they do not actually reach 100°C.

/u/Maximus-CZ This happens when the cost of lying is lower than potential profit

MopDockMopAutoDryingControlCapability

Also self-explanatory, with the icon TBD and currently being just a placeholder. If you have ideas how that could look like, please let me know!

Also, I was thinking of having a MopDockMopCleaningFrequencyControlCapability, MopDockMopCleaningIntensityControlCapability and MopDockMopDryingControlCapability in the future. It might make sense for those icons to become a whole consistent set.

I do have fun actually building them though, so unless you're like an actual professional graphics artist able to mimic the existing style, rough ideas would be best.

One capability less

Revisiting the existing capabilities, I noticed that with the introduction of the AutoEmptyDockAutoEmptyIntervalControlCapability the AutoEmptyDockAutoEmptyControlCapability became redundant, as "Off" is also an interval. A very long one.

Thus, these two have been merged, which is a breaking change. I don't think that it will break anything for anyone, but spacebar heating is a thing after all.

Device and state classes for Home Assistant via MQTT

Someone asked why they couldn't change the precision of various Valetudo-provided Entities in Home Assistant (e.g., area in m² instead of cm²). A few hours later, I asked myself why I hadn't done that a long time ago. Oh well.

Anyway, Entities for e.g., Area or Time provided by Valetudo now have the correct device_class and state_class set, meaning that Home Assistant now has the metadata to provide proper enriched handling. They also now use the correct units as per the HA data model. No clue how I missed that up until now.

This is so much better.

Note: HA will likely tell you that some units changed due to this change. You can safely select "Update without converting".

Midea

The implementation for Midea is moving along. Beside controls, Valetudo now even shows obstacle images on Midea! (Not all of them might be real)

There are still a bunch of things to do, but once that is done, I'd like to revisit rooting and hopefully come up with some nice guide as usual. I've also bought another robot. Let's see how that will work out.

FWIW, it was cheap being an Amazon WHD. And also weird, because the original recipient clearly was not a real person + the address being not a real house + the thing being completely unused. ... not sure what was going on there, but cheap robot with Amazon invoice. I won't complain.

What else is going on?

You might have heard that Google is further closing down the formerly open platform known as Android. If you haven't heard, well now you do. Here's F-Droid's statement for your convenience: https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html

This is.. not ideal.. for many reasons. It wouldn't make sense to go into all of them within this context, however, Cory Doctorow's prophecy of the (now no longer just coming) War on general computation is something to mention here.

Unfortunately, studies show that opposing authoritarian governments may have adverse effects on shareholder value, meaning that relying on big tech to not be evil might not be a winning strategy. Thus, motivated by the distressed croaks of my almost boiling amphibious self, I started asking around what options we have.

Beside blissful ignorance and moving into a shed in the woods, those seem to be:

  • Android, but with a good vendor (e.g. Fairphone)
  • somewhat Android, but also different (e.g. GrapheneOS)
  • something else, but with an Android compatibility layer for transitioning (e.g. SailfishOS by Jolla)

Apparently, there are actually Valetudo users daily-driving SailfishOS phones. Also, apparently, Jolla exists, is European, and has been actually shipping Linux phones for many years now.

Building on some of their tech (thanks, FOSS), there is also Debian-based smartphone Linux distribution Droidian, or, the "let's turn Droidian from a hack for existing products into an actual product on its own" FuriLabs FLX1s. FuriLabs in this case is a startup founded by one of the maintainers of the aforementioned Droidian.

They are pretty new, small and appear to be neat, hence the mention here, as what I find interesting and neat, you might also find interesting and neat. Also, something something rooting for the underdog, though, keep in mind that I have not ever actually seen their product. This is a pointer; not a recommendation.

It points here 👉 furilabs.com


To end on a high note, if you've been watching the Dreame subreddit, you might've seen something peculiar recently. Some users reported that the app started showing them these new and exciting ads (click to enlarge):

Yes, those really are smut dark romance stories, so that.. idk.. you can "practice self-care and mindfulness" while the robot does its cleaning.

Unfortunately, Valetudo users missed out on that enriching and context-aware experience. Sorry.

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Breaking Changes
  • Merge AutoEmptyDockAutoEmptyControlCapability into AutoEmptyDockAutoEmptyIntervalControlCapability 7d1aea3
Features
  • vendor.dreame: MopDockMopAutoDryingControlCapability 6fcfc6a
  • vendor.roborock: MopDockMopAutoDryingControlCapability 847093a
  • vendor.midea: MopDockMopAutoDryingControlCapability ed78538
  • core: MopDockMopAutoDryingControlCapability f150a89
  • mqtt: Add missing deviceClass + stateClass attributes, update enums and fix units for HA 921dd13
  • vendor.midea: Improve state reporting 0afc47e
  • vendor.midea: MopExtensionFurnitureLegHandlingControlCapability 7c0fc3a
  • vendor.dreame: MopExtensionFurnitureLegHandlingControlCapability 92cd7f6
  • core: MopExtensionFurnitureLegHandlingControlCapability e6615d2
  • ui: Improved MopExtension and MopTwist icons fd83cd3
  • webserver: You know the rules and so do I 0dcca1d
  • vendor.midea: MopTwistControlCapability 72444e6
  • vendor.dreame: MopTwistControlCapability ea236ab
  • core: MopTwistControlCapability 92ee9a5
  • vendor.midea: Pet obstacle avoidance and stain cleaning 0ea2a50
  • vendor.midea: Everything carpet f94f3c1
  • vendor.midea: MopDockMopWashTemperatureControlCapability 52c8c4b
  • vendor.dreame: MopDockMopWashTemperatureControlCapability 53ff4fa
  • core: MopDockMopWashTemperatureControlCapability de62cbf
  • vendor.midea: Auto empty controls ae01b69
  • vendor.midea: Obstacles galore 17ebfae
  • ui: Improve MopExtensionControl Icon 757e682
Fixes
  • vendor.dreame: Fix DreameAutoEmptyDockAutoEmptyIntervalControlCapabilityV1 c0136de
  • vendor.dreame: Give the firmware some time to think ec61206
  • vendor.midea: Do not fail fast 5715fb0
  • ui: MopDockMopWashTemperatureControl should be a dockListItems 493c570
  • vendor.midea: Add missing return statement 52b4625
  • vendor.dreame: Fix connection timeout on startup on very recent firmwares 15c1f80
  • miio: Fix super rare bug crashing the process 0c6272f
  • vendor.midea: Fail any requests instantly on initial startup a963fa1
  • vendor.dreame: Add another new modelId df46e2e
  • vendor.dreame: Add missing model ID 87d0760
  • vendor.roborock: No-Op handle two more events 0261f57
  • vendor.dreame: Track emptying state of auto empty dock 6f0fc2a
Refactoring
  • vendor.dreame: Group all the ephemeral state into an object 2fdef9f
  • vendor.midea: Move specific capabilities into actual implementation class c0d1640
  • MockRobot: Smurf for consistency 5d40584
  • vendor.midea: Rename implementation class for J15PU 785e6b8
Chores
View originalPermalink
How 2025.10.1 went
2025.10.0Pre-release

Valetudo 2025.10.0

Iterating on and due to the new vendor

Valetudo 2025.10.0

After the last release notes, which have been more of a devlog/manifesto, this one returns to a slightly more technical focus.

That said, things aren't over or resolved, so if you haven't read the 2025.08.0 release notes yet, I highly recommend you do: Valetudo 2025.08.0

So many new capabilities

As I wrote in the last release notes, with there now being two vendor implementations doing the same thing, a lot of quirks graduated and became capabilities. I am very glad for that, given that on recent supported Dreame robots, the quirks section contained more options than the regular robot settings, which was anything but good design.

Starting off with the first two, I'd like to again thank everyone who took part in the public brainstorming session for the icons. Even after seeing them for a while now, I still think that they've turned out great, and, as suggested, they indeed look merch-able. Though.. very obscure merch (which is usually the best kind of merch).

MopExtensionControlCapability

This one actually doesn't belong here, as it was introduced in the last release. It however does now have this new and improved custom icon, hence, here it is again.

MopTwistControlCapability

If your robot can't extend its mop to reach closer to the walls, it might be able to twist to achieve the same. Or, if it can extend it, it might still be able to twist to reach below some furniture overhangs.

The icon and description will reflect which of the two it is.

MopExtensionFurnitureLegHandlingControlCapability

Being named to prove just how enterprise-y Valetudo has become, this one allows you to enable logic in the firmware that extends the mop to clean closer to legs of tables and chairs.

MopDockMopWashTemperatureControlCapability

Pretty self-explanatory. The available options are somewhat arbitrarily named, however so are the labels within the vendor apps, as even though they say e.g., 100°C, they do not actually reach 100°C.

/u/Maximus-CZ This happens when the cost of lying is lower than potential profit

MopDockMopAutoDryingControlCapability

Also self-explanatory, with the icon TBD and currently being just a placeholder. If you have ideas how that could look like, please let me know!

Also, I was thinking of having a MopDockMopCleaningFrequencyControlCapability, MopDockMopCleaningIntensityControlCapability and MopDockMopDryingControlCapability in the future. It might make sense for those icons to become a whole consistent set.

I do have fun actually building them though, so unless you're like an actual professional graphics artist able to mimic the existing style, rough ideas would be best.

One capability less

Revisiting the existing capabilities, I noticed that with the introduction of the AutoEmptyDockAutoEmptyIntervalControlCapability the AutoEmptyDockAutoEmptyControlCapability became redundant, as "Off" is also an interval. A very long one.

Thus, these two have been merged, which is a breaking change. I don't think that it will break anything for anyone, but spacebar heating is a thing after all.

Device and state classes for Home Assistant via MQTT

Someone asked why they couldn't change the precision of various Valetudo-provided Entities in Home Assistant (e.g., area in m² instead of cm²). A few hours later, I asked myself why I hadn't done that a long time ago. Oh well.

Anyway, Entities for e.g., Area or Time provided by Valetudo now have the correct device_class and state_class set, meaning that Home Assistant now has the metadata to provide proper enriched handling. They also now use the correct units as per the HA data model. No clue how I missed that up until now.

This is so much better.

Note: HA will likely tell you that some units changed due to this change. You can safely select "Update without converting".

Midea

The implementation for Midea is moving along. Beside controls, Valetudo now even shows obstacle images on Midea! (Not all of them might be real)

There are still a bunch of things to do, but once that is done, I'd like to revisit rooting and hopefully come up with some nice guide as usual. I've also bought another robot. Let's see how that will work out.

FWIW, it was cheap being an Amazon WHD. And also weird, because the original recipient clearly was not a real person + the address being not a real house + the thing being completely unused. ... not sure what was going on there, but cheap robot with Amazon invoice. I won't complain.

What else is going on?

You might have heard that Google is further closing down the formerly open platform known as Android. If you haven't heard, well now you do. Here's F-Droid's statement for your convenience: https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html

This is.. not ideal.. for many reasons. It wouldn't make sense to go into all of them within this context, however, Cory Doctorow's prophecy of the (now no longer just coming) War on general computation is something to mention here.

Unfortunately, studies show that opposing authoritarian governments may have adverse effects on shareholder value, meaning that relying on big tech to not be evil might not be a winning strategy. Thus, motivated by the distressed croaks of my almost boiling amphibious self, I started asking around what options we have.

Beside blissful ignorance and moving into a shed in the woods, those seem to be:

  • Android, but with a good vendor (e.g. Fairphone)
  • somewhat Android, but also different (e.g. GrapheneOS)
  • something else, but with an Android compatibility layer for transitioning (e.g. SailfishOS by Jolla)

Apparently, there are actually Valetudo users daily-driving SailfishOS phones. Also, apparently, Jolla exists, is European, and has been actually shipping Linux phones for many years now.

Building on some of their tech (thanks, FOSS), there is also Debian-based smartphone Linux distribution Droidian, or, the "let's turn Droidian from a hack for existing products into an actual product on its own" FuriLabs FLX1s. FuriLabs in this case is a startup founded by one of the maintainers of the aforementioned Droidian.

They are pretty new, small and appear to be neat, hence the mention here, as what I find interesting and neat, you might also find interesting and neat. Also, something something rooting for the underdog, though, keep in mind that I have not ever actually seen their product. This is a pointer; not a recommendation.

It points here 👉 furilabs.com


To end on a high note, if you've been watching the Dreame subreddit, you might've seen something peculiar recently. Some users reported that the app started showing them these new and exciting ads (click to enlarge):

Yes, those really are smut dark romance stories, so that.. idk.. you can "practice self-care and mindfulness" while the robot does its cleaning.

Unfortunately, Valetudo users missed out on that enriching and context-aware experience. Sorry.

The usual

If you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Autogenerated changelog
Breaking Changes
  • Merge AutoEmptyDockAutoEmptyControlCapability into AutoEmptyDockAutoEmptyIntervalControlCapability 7d1aea3
Features
  • vendor.dreame: MopDockMopAutoDryingControlCapability 6fcfc6a
  • vendor.roborock: MopDockMopAutoDryingControlCapability 847093a
  • vendor.midea: MopDockMopAutoDryingControlCapability ed78538
  • core: MopDockMopAutoDryingControlCapability f150a89
  • mqtt: Add missing deviceClass + stateClass attributes, update enums and fix units for HA 921dd13
  • vendor.midea: Improve state reporting 0afc47e
  • vendor.midea: MopExtensionFurnitureLegHandlingControlCapability 7c0fc3a
  • vendor.dreame: MopExtensionFurnitureLegHandlingControlCapability 92cd7f6
  • core: MopExtensionFurnitureLegHandlingControlCapability e6615d2
  • ui: Improved MopExtension and MopTwist icons fd83cd3
  • webserver: You know the rules and so do I 0dcca1d
  • vendor.midea: MopTwistControlCapability 72444e6
  • vendor.dreame: MopTwistControlCapability ea236ab
  • core: MopTwistControlCapability 92ee9a5
  • vendor.midea: Pet obstacle avoidance and stain cleaning 0ea2a50
  • vendor.midea: Everything carpet f94f3c1
  • vendor.midea: MopDockMopWashTemperatureControlCapability 52c8c4b
  • vendor.dreame: MopDockMopWashTemperatureControlCapability 53ff4fa
  • core: MopDockMopWashTemperatureControlCapability de62cbf
  • vendor.midea: Auto empty controls ae01b69
  • vendor.midea: Obstacles galore 17ebfae
  • ui: Improve MopExtensionControl Icon 757e682
Fixes
  • vendor.dreame: Give the firmware some time to think ec61206
  • vendor.midea: Do not fail fast 5715fb0
  • ui: MopDockMopWashTemperatureControl should be a dockListItems 493c570
  • vendor.midea: Add missing return statement 52b4625
  • vendor.dreame: Fix connection timeout on startup on very recent firmwares 15c1f80
  • miio: Fix super rare bug crashing the process 0c6272f
  • vendor.midea: Fail any requests instantly on initial startup a963fa1
  • vendor.dreame: Add another new modelId df46e2e
  • vendor.dreame: Add missing model ID 87d0760
  • vendor.roborock: No-Op handle two more events 0261f57
  • vendor.dreame: Track emptying state of auto empty dock 6f0fc2a
Refactoring
  • vendor.dreame: Group all the ephemeral state into an object 2fdef9f
  • vendor.midea: Move specific capabilities into actual implementation class c0d1640
  • MockRobot: Smurf for consistency 5d40584
  • vendor.midea: Rename implementation class for J15PU 785e6b8
Chores
View originalPermalink
How 2025.10.0 went
2025.08.0

Valetudo 2025.08.0

3000 words of meta and 1 new vendor

Valetudo 2025.8.0

Welcome back to another issue of my personal blog the Valetudo release notes. This one is particularly chunky.

Defending Valetudo

Kicking things off with something meta, over two months ago, I found myself struggling very hard to continue building Valetudo due to a handful of people trying their very best to get me to struggle to continue building Valetudo.

To counteract that, quite desperately, I've decided to shine a light on it and let people know that that was happening. You can find that post here: https://t.me/dust_announce/76

The TL;DR of the whole thing is that rejection hurts and personal growth might hurt too, so instead, some people choose to hurt others. As a visceral mental model, think of the following:

Girl rejects Boy, then Boy first apologizes, sees that he doesn't get anywhere with that and thus proceeds to call her a slut, tries to turn the whole school against her, or, in extreme cases, do even worse things.

Whatever else comes to mind when you read this, e.g. weird lovebombing-style grandiose statements of affiliation and all, or finding others that got rejected to forge alliances, yes, that. Yes, all of that.

The overall response to that post fortunately was overwhelmingly positive. As said in the group, that did help me greatly, so thank you all again for caring.

That said, one event of emotional support only gets you so far and given the nature of the project and my outspoken disdain for dysfunction, such attacks will be a constant threat. Thus, as said in the post, you as a user can help the project greatly by speaking up if you see someone on the internet talking shit about it and/or me personally.

.. Unless that shit is warranted of course, in which case you should still speak up, but against me. Though, please make sure that you have an actual factual reasonable point before you decide to do that.

Anyway, another thing that came from that was people asking me "When was the last time that you had fun with the project?". So what I did was block the attackers, handed the defending over to the userbase (thank you, again) and then pondered where to go now.

The rest of the release notes are a result of that.

Valetudo Code of Conduct

Valetudo has a Code of Conduct now.

Honestly, I didn't think that I'd ever do this, because back when the topic of CoCs was new, I mostly just felt alienated by all of it. We suddenly got these weirdly corporate and highly specific documents that no one actually read but everyone signed off, because HR (formerly known as Twitter) wanted so.

Most of the time, it didn't feel enforceable, and when I observed someone trying to invoke it, that usually was just bad faith retaliation for negative emotions. I was sometimes sceptical that the communicated goals were also the intended goals and, most importantly, that the means used to achieve those goals were actually suited to do so.

Granted, it is possible and likely that I am just privileged enough that I did not for the most part see all the negatives, CoCs possibly successfully removed. However, I did see the abuse of it, since at one point there even was a retaliatory PR to Valetudo, adding a CoC in response to being banned on the support channel for asking about unsupported robots.

But, as it should turn out, CoC as a concept does not necessarily mean the Contributor Covenant. That is just one idea of how a CoC could look like. One that is IMO not only primarily optimized for large, bureaucratic projects, but also IMO not sufficiently hardened against real-world attack scenarios.

It is possible to take the idea of a CoC and just make it your own. Use what you feel is good about it and come up with your own thing. After all, that's what got us all the FOSS. People thinking "I'd like to build software this way" and then proceeding to just doing that. Why should project governance be any different?

I did just that and you can now read it here and (continue to) act accordingly: The Valetudo Code of Conduct

I am genuinely proud of that document. I believe it does fully encompass what I want Valetudo to be and that with only such few words. It also still very prominently carries the ethical messages of other CoCs; just more conceptually high-level and less "list of things you're not allowed to do".

With it now existing for over two months, it does to me appear like it was the right choice. People start significantly fewer (successful) fights when you point to a rule compared to stating ad-hoc what went wrong. ... even though you're the one who wrote those rules.

I suppose it helps establish that something isn't personal/emotional and made up on the spot? Maybe it better fits their mental model of the world? Thus requiring less energy put into comprehension?

Still, weird. But what can you do. Guess that's just a limitation of the systems we live in (or happen to be).

So.. just hack them I guess.

The future of Dreame and Valetudo

I do not like Dreame much anymore. This happened gradually and mostly unnoticed, however with the period of reflection now, it has become quite apparent.

Don't get me wrong. Their products are still objectively good. Maybe even the best right now. But they've very much stopped respecting their customers.

  • I don't like their new brand image.
  • I don't like their new target audience.
  • I don't like their new pricing.
  • I don't like how far up market they've moved.
  • I don't like their hundreds of confusingly named permutations of robots that are all almost the same but also not.
  • I don't like their bait-and-switch practices with cheaper-to-build worse robots sharing almost the same name with a critically acclaimed robot.
  • I don't like how they let older models die without software updates even though the hardware is the same and could easily receive all those new features.
  • I don't like how little replacement parts are available.
  • I don't like their physical store in LA akin to an Apple Store.
  • I don't like how their official subreddit mod is using bad LLMs to confuse and coax gullible people with pure automated nonsense.

Dreame, according to Dreame, had 44% of Vacuum Robot sales in Germany in April 2025. What am I even doing here?

Extrapolating from the current state, it is unlikely that we will see many more new Dreames being supported by Valetudo. They are simply not fun anymore.

That said, of course, what is supported will stay supported, as supported means that I actually own the robot and thus I have an interest in keeping it working.

So where do we go from here? We hack things.

A new Vendor

Here at Valetudo, we root (for) the underdogs. And one such unterhund is Midea. Yes. The company that primarily builds air conditioners.

Midea has actually been at it for years now and they actually build their own stuff from the ground up instead of buying some ODM thing.

I've been looking at earlier models by them previously - also thanks again Marco Reps + Friend for letting me have a look at the S8+ -, however, the hardware of those earlier models was rather meh, so nothing came out of it. That, however, changed, and so did the brand they sell their robots under.

They're now sold as "Eureka"-brand robots and I got myself a J15 Pro Ultra. I also annoyed Dennis quite a lot to also get a J15 Pro Ultra so that we could get to work.

And we did get to work.

It was great. It was fun. It was like returning to earlier times.

eureka_j15pu

Some historical context

As you may or may not know, Valetudo always has been miio only. Anything supported by Valetudo was speaking miio. Miio in this context meaning the "old" transport protocol of the Xiaomi MiHome ecosystem

It was however always clear that this was going to change at some point. Case in point, literally years ago, Xiaomi switched to a new transport protocol named miot. That could've already been the end of Valetudo (or at least required RE work that was beyond my capabilities at that point).

But instead, as what is frankly just a hackish workaround, since then, we have just been downgrading and patching the communication layer of the vendor firmwares. This way, Valetudo could just keep on working, talking the old miio to the old miio_client interface. Frankly, it is surprising and a testament to their architecture that this still works today.

It is however not just Xiaomi who moved on from early beginnings. The Vendors themselves have long left the multi-vendor MiHome app and moved new robots to their own apps. The reasons for that being unknown and subject to speculation only, with possible answers ranging from "features" to "control".

Fortunately for us, Dreame - even in their newest Dreamehome-exclusive robots - left all the MiHome handling logic in their firmwares, even though, there is no way to actually use them with the Xiaomi Cloud. So this way, the mentioned life support hack for Valetudo could be extended even longer by adding even more hack. Thanks, Dreame!

Having seen the future, in hindsight, even with the MiHome cloud being a cloud, we did not know how good we had it. Anything in there was somewhat "compatible" with each other - no matter the vendor. And, most importantly, there were local interfaces.

While you still had to provision a device by binding it to your cloud account, once on your network, you could send it commands locally. This was meh-ish for robot vacuums, since you did not get a map, but it was there. You could do that. Once it was on your network, it could keep working (if only in a degraded state).

Nowadays, robots only allow you to provision them via a local interface with everything else going through the cloud, not only affecting latency and reasonability, but also hard tethering the device to said cloud even more than in earlier days.

Moving beyond miio

Midea, even though sharing a two-letter prefix, is not miio. It is not adjacent to miio either. Midea is something completely new.

Similar to how the other vendors are now doing it, the Midea cloud uses the standard technologies https and mqtts as transports. While they are standard, they were something completely new for Valetudo.

Fortunately, them being standard and Valetudo being written in JS, all the parts to get things done were already available on npm. You just needed to add glue:

First there is Aedes. Aedes is a pure-js implementation of an mqtt broker, sharing libs with the mqtt client library already used. I cannot overstate just how much easier the existence of Aedes made implementing that interface. Just imagine what would have to be done if it didn't exist. You'd have to compile and vendor mosquitto, orchestrate and manage that process, deal with indirection through code you do not really control and all that.

Thank you, Aedes maintainers, for making my life so much easier! (And also thank you, nodejs maintainers (among lots of others), for enabling the Aedes maintainers to do so.)

Even more interesting than that but on a similar note is node-forge, which enabled the s in mqtts and https. node-forge is a pure-js implementation of everything TLS. This, as with Aedes, frees you from the need to compile and vendor OpenSSL, manage that process, run shell commands, etc., too making my life so much easier.

Furthermore, its origin story is insane and worth a read, implementing TLS in JS, bypassing the whole browser through utilization of Adobe Flash to gain access to raw sockets. Take a look at it here: A JavaScript Implementation of TLS (Part 1/2)

And now, 15 years later, it unclouds vacuum robots - a use-case the author(s) probably could not ever have imagined. This is a prime example for why you should just do weird shit. Don't listen to people telling you that you should just use the browser's TLS. Reimplement it in JS. Have fun! (Maybe not use it in production in most-if-not-all use-cases)

The best part about this is that this was groundwork. It did not just enable Valetudo to talk with Midea, but it has given it the infrastructure to grow beyond the limits of the space it basically fully exhausted.

There is a new world beyond miio waiting to be explored.

Hacking the Tedium

On the topic of exploring said worlds, another interesting detail about this journey is that LLMs not only supercharged it, but also probably enabled it.

As you may or may not be aware, I am at heart lazy and sometimes somewhat more of a suit than a dev. I like putting in 1x and getting out 10x in return. I dislike the tedious chopping away at something, doing the same mundane thing for long periods of time with little visible progress.

There is so much more I could do with my limited time than just staring at Ghidra, pondering for weeks. Not that I'd actually be using the time that way, but hypothetically I could.

LLMs are (please excuse the language) an absolute gamechanger here, as they are incredibly amazing at reducing the tedium by multiple orders of magnitude. Instead of staring at decompiled c++ gibberish for hours on end, sometimes having to even look at the asm to make sense of things, just copy-paste the whole thing into an LLM and ask it what is going on.

The LLM will get things wrong and will hallucinate, however, so will you (probably).

If you keep that in mind while using them and double-check its assumptions and claims through referencing the actual code, what took months becomes days. What was a large block with you having no idea how to slice it becomes digestible chunks. And even if the content of one such logical chunk will be wrong, the actual chunking boundaries can be right and then you just have to figure out that one clearly defined problem.

So for me personally, if used this way, it's a great technology. I can only encourage you to try it yourself with the one reverse engineering project you wanted to do but never got yourself to actually pick up. Chances are it will be just what you need to overcome inertia.

But, also, don't ever hand over the steering wheel. .. And keep the shotgun loaded. The space around AI is still crawling with grifters, parasites, lunatics and people high on hype.

Where are we now?

So now, Valetudo has very experimental support for the Eureka J15 Pro Ultra. While not fully done yet and not having seen the polish other implementations had, it is "good enough" to be released - experimentally.

As always, there is a new docs entry for it, containing everything you would want to know right now: Midea J15 Pro Ultra

And it's the same Valetudo that you and I are used to. I love it.

To toot my own horn a bit, I was pleasantly surprised just how well Valetudo handled a Robot with 0 capabilities. I was also unpleasantly surprised to see some old design decisions that did not make all that much sense. So I also had the opportunity for some cleanups.

Reflecting on this process and comparing it with the early steps of Valetudo on the Roborock S5, it is quite the contrast. Back then, there was just an ext4 rootfs Ubuntu 14.04 you could ssh into and throw a binary on it, which then parsed some debug map ppm image files in a ramdisk. Now, before you even have the chance to think about how to even send commands at all, you first need to stare at Ghidra for hours, figure out how to build and install read-only squashfs firmware packages, patch multiple core binaries and jump through a plethora of other hoops.

If IoT had been how it is now, Valetudo would not have happened. Fortunately, it did, and through it, I was given this opportunity to develop the necessary skills.

Not just reverse engineering, but also people management, expectation management, personal growth and many many more things. All that I would never have accomplished if I hadn't been interacting with so many different concepts, people, ideas and things through Valetudo.

So at this point I'd like to say: Thank you, dear reader, for providing the context to create the space that enables me to connect with the world, to ponder and to grow 🪴

Returning to Midea: Given that it is an entirely different firmware by an entirely different vendor, things will of course behave slightly differently. Given that Midea is also very much trying to catch up with the big players, software quality is sometimes.. questionable and some jank does exist.

But, overall, it is mostly abstracted away. You install Valetudo. You get a robot like you'd expect it to be. No surprises, just Valetudo.

As a bonus, the completely different map logic also leads to completely new map art:

What else is new?
On Home Assistant Deprecations

With this release, Valetudo's MQTT interface has been updated to advertise itself on MQTT in the slightly changed ways HA 2026.2 will make mandatory. Since Valetudo provides a standalone battery level entity since 2023, no breakage happened or is going to happen from this, as long as your version of Home Assistant isn't absurdly outdated.

So now for some rant on the same asymmetry and invisibility as always:

Please keep in mind that I myself, as the real person I am, use both Valetudo and Home Assistant daily. I am seeing these messages probably even before you do. I am reading most of the beta release notes of HA.

It makes no sense to create an issue or message me about this. Time-wise it's far away and there is no reason to believe that I would not be aware of it.

The most charitable interpretation of what transpires regardless is that people - busy with their own lives - apply defaults from other projects operating under different models, leading to a misguided "attempt at helping" with little thought put into if it actually could help.

The less charitable interpretation would be "I see yellow box. I push elsewhere so that it stops being my problem."

However, whatever in that spectrum it might be, it doesn't matter much, as the end result of that sucks regardless. And, even in the best case interpretation, it is still immensely taxing to handle the mental load of other people.

Writing this down in this context, rewording it many times to convey the message while taking out one's own emotions is immensely taxing.

It sucks. If you can, please consider making it suck less. I'd be very glad. It's 30 seconds for you or 30 seconds times 10,000 users for me.

Side-note: This explicitly does not mean scaling up the capacity to handle people not caring through processes or manpower. Managing dysfunction at scale is still managing dysfunction instead of resolving it.

New Capabilities

With there being a new implementation in Valetudo, there were also new overlaps of functionality. Instead of implementing a quirk for the same thing available on multiple vendors, some of these quirks now graduated and became full capabilities:

As you can see, I've created a custom icon for the Mop Extension. I'm not yet 100% sure if it will stay that way, given that the actual information part (the mop sticking out) is quite small, but I also don't have any other ideas. Especially since there will be similar icons based on the same base shapes for other mop-related capabilities.

As Midea isn't done yet, I expect there to be more such cases in the near future.

Refactoring of the ConsumableStateAttribute

As said, working on a completely new robot implementation also gave me the chance to revisit some earlier design decisions, the ConsumableStateAttribute being one of them. Why was it even part of the state instead of being fully encapsulated in the ConsumableMonitoringCapability?

The answer is that it was like that in the vendor implementation and I just copied it without questioning enough. Now, with that vendor implementation outside my context window, this decision had to stand on its own - which it did not. Hence, cleanup.

For users of Home Assistant, you will notice nothing. If however you're running a different home automation system or consume the REST API in other ways, this might be breaking for your setup.

Upgrade to Node V22

Having been using Node v20.10 since 2023-12, it was about time for an update. For a moment, it almost looked like that would not be happening, as the built v22-based binary turned out larger than the 40 MB that the updater expects as the maximum size for Valetudo.

However, after staring at the nodejs git repo for a while, I found some options, tweaks and things I could do to trim down some of the size, meaning that for now at least, no changes to the updater are necessary.

This release also enables pointer compression for the aarch64 build, leading to a bit less RAM usage. Not that that would matter much, given that all supported 64-bit robots have 1GB RAM (or more).

It might happen that, especially on the lowmem armv7 build, the heap size will need tweaking due to the update. I haven't seen any issues in my testing, but please let me know if you see something abnormal like Valetudo crashing, as it should very much not be doing that.

Valetudo AI

Following industry trends, Valetudo now has an AI assistant feature that may or may not be helpful depending on how you look at it. There is no escape. It will be in your sidebar.

Closing thoughts

Someone on 4chan claimed that "the Valetudo dev is a schizo and his software is a backdoor". To help that guy win his internet argument, with this release, I've obliged and added one. Please let me know when you find it :)

The usual

There are a few new robots I'd like to look at, so if you like this release or Valetudo in general, you might want to consider donating:

https://github.com/sponsors/Hypfer

https://builder.dontvacuum.me/donations.txt

Appendix

Motivated by something you can discover in this very update, I found myself reading a book by Joseph Weizenbaum - self-declared heretic of technology - written in 1984. It is called "Kurs auf den Eisberg - Die Verantwortung des Einzelnen und die Diktatur der Technik" and unfortunately seems to only be available in German. Fortunately, it is quite short and actually just an interview written down, meaning that it is accessible to simpletons like me who just learned how to read.

Anyway, there were many, many moments in there, where I questioned the print date of the thing. Did we ever leave the 80s?

Recommended read. ISBN: 9783492105415

Autogenerated changelog
Breaking Changes
  • Drop ConsumableStateAttribute in favor of ValetudoConsumable entity ddc9918
Features
  • vendor.midea: Midea ae1ac47
  • ui: Further improve UX of AI Assistant d575e2f
  • ui: Introduce Valetudo AI Assistant da4c8c4
  • vendor.dreame: CameraLightControlCapability cefa92b
  • core: CameraLightControlCapability 994c3f9
  • vendor.dreame: MopExtensionControlCapability 1189bd9
  • core: MopExtensionControlCapability ccc3073
Fixes
  • vendor.dreame: Minor change for newer firmwares eb21332
  • ui: Fix ValetudoSplash showing scrollbars with some specific browser window dimensions 47e129c
  • ui: Actually reading docs helps build better software 6bec34d
  • ui: Improve mobile UX of AI Assistant f6b08e6
  • ui: Only show AppBar Subheaders when there are items for it 453ac70
  • core: Remove ip from default config 3746d26
  • vendor.viomi: Remove redundant second emitMapUpdated on map reset f29592f
  • webserver: Fetching the map should not poll the state 81801d6
  • ui: Add feedback when saving virtual restrictions 69e47ab
Refactoring
  • mqtt: Simplify segment ID validation 649eb4e
  • core: Use native crypto.randomUUID where possible b456a2b
  • core: Move map polling orchestration logic into ValetudoRobot base class b12fb03
Chores
View originalPermalink
How 2025.08.0 went
View all

Discussion