Why not Valetudo?

After having read through the Why Valetudo? page, you might also be wondering why you might not want to use Valetudo. To answer those questions, here’s a list of a few common reasons in an attempt to reduce the amount of some incredibly exhausting discussions.

Always remember:
The only person forcing you to use Valetudo is yourself. Using Valetudo is your own conscious decision.

If the things listed here are a deal-breaker to you then that’s fine. It’s completely reasonable to have different opinions and thoughts on these things. You just won’t be happy with Valetudo then.

Thank you for not acting entitled.

Valetudo is opinionated software

Opinionated software means that the software has a clear vision on how things should work, what it should do and also what it should not do. Valetudo is a piece of software that you could call opinionated software that is used by the developer himself on a daily basis.

Usually, this is great, as - if you follow the laid out paths - things will just work, because someone else not only ran into the problems associated with those but also already fixed any issues and built strong guide rails that keep you on the path and out of any trouble. It’s smooth sailing. Set-up and forget about it. Nothing can ever majorly go wrong as it’s all already planned-out.

Where this can become something frustrating however is when your vision is misaligned with the vision of the project. You might find yourself angry because you “only want to do that one thing” but it’s super hard and annoying to do so.

Keep in mind that it’s possible that you might just not be the target audience. Even if at first Valetudo sounded cool to you, it may not be a good fit. That’s fine. It doesn’t have to be. Neither do you have to change nor does the project.

Sometimes it’s just not working out. You should see other software.

Valetudo is counterculture

Even though the project exists in the consumer electronics space and is polished as if it was a product, it is very much not that.
Instead, it is highly idealistic, anti-consumerism, anti-hypergrowth and anti just-continuing-what-we-do-now.

Valetudo is not the new hype gadget of the week that you buy for copious amounts of money, play around with for three days and then still feel empty inside, craving for the next fix. It is explicitly anti your tech-influencer parasocial “friends”.

It doesn’t want you to buy more. It wants you to buy less.
To have a positive impact on the world and not just on the bottom line of some commercial entity.
To be content with what you have instead of yearning for more content.
And, most importantly, to have actual human connection.

As mentioned in “Valetudo is opinionated software”, these aspects are baked into its design.
There is no way of using it without being constantly confronted with them.

If you’re not willing to reflect, introspect, grow and most importantly stop, you will not be happy with Valetudo.

Valetudo is not about you

Valetudo is a solution I built to a problem I had that I shared with the world, because I naively assumed that the cost of sharing would be zero.
That was a profound underestimation but now here we are. Can’t stop now as that would be weird.

This means one crucial thing: Valetudo does not exist to solve your problems.
It might solve them, and that’s great if it does, but that’s coincidence, not purpose.

While on the topic of what Valetudo is about, I need to address something.
Something I’ve over the years observed countless times - always leading to entirely unnecessary conflict.

It is people building their identity - or at least large chunks of it - around installing and using Valetudo (or any other FOSS software for that matter). And in principle, I could partially empathize with that and do agree that people can and should feel proud of themselves for taking control of their technology.

That said, the reason I’m mentioning it here is that it’s not always just people feeling proud in a healthy way.
Instead, it sometimes turns pathological: It becomes a make-believe hero story where reality gets twisted to maintain that narrative.

A story where someone isn’t just a user of a piece of software that followed a guide in the docs both written by someone else.
A story where someone becomes a powerful tech wizard who purely on their own freed their robot, took agency and is generally better, smarter and more important than all the others.
And when cognitive dissonance threatens that false story, people attack what they perceive as the source of it - me.

What makes this truly sad is the human suffering behind it.
No one who is doing well in their life clings this desperately to a borrowed identity.

And the tragedy is that it’s unnecessary. Identity isn’t a zero-sum game. You can achieve something and also acknowledge achievements of other people that made your achievement possible. Those other achievements do not take away from your achievement.

I know that it is weird for someone to just write such a text in such a place with such bold claims, but if you run into the same-style conflict for the better part of a decade, you eventually spot patterns. Sadly, this could be a welcoming space for the people affected, but those patterns ruin any possibility for that to happen - and also my day on a weekly basis.

So please just don’t be like that, okay?
Use the software, be proud of yourself - but do so in a healthy fashion

Valetudo replaces the Cloud

Valetudo is a cloud replacement, meaning that it replaces the cloud.
As it stops all connectivity to the vendor cloud, the vendor app will also stop working.

It is not possible to use Valetudo and the vendor app simultaneously.

Reverting to stock is impossible

Rooting and installing Valetudo is a permanent change. There is no way back.

If you’re looking for an experience similar to trying out a Linux Live CD, this is not it.
If you’re unsure whether or not you should install Valetudo, the answer is no, you should not install Valetudo.

Feature-parity is a non-goal

Valetudo is a solution for wanting a vacuum robot that works local only. It is not “$VENDOR but without the cloud”.

Here’s how that works:

✔ “I want to use Valetudo. This robot looks supported so I will use that.”
❌ “I want to use this robot but I don’t like the cloud dependency of it. Guess I’ll use Valetudo.”

This is very important to understand as it means that feature parity with the vendor apps is a non-goal for the project. Instead, feature completeness for the Valetudo project is defined as “it does what it set out to do”, which in this case means “a vacuum robot that works local only”. That can include new and fancy features, yes, but it doesn’t have to do that.

While it’s certainly understandable that one would want all the features of Vendor Model XYZ but without the cloud, this is simply not the right project for that.

"Why is this so important?", you may ask. (Click here for rant)

Good question!

In commercial products, there are forces at play that constantly push towards adding more and more features. It doesn't matter if they bring something valuable to the table or even make sense at all. What matters is that the number of features of product A is higher than the number of features of product B, as customers use that number to make their buying decisions.

The issue with that however is that that's simply not a useful metric to judge the value of a product. In fact, a lot of products will eventually reach a point, where every additional feature makes them worse due to complexity of use, instability, severe security vulnerabilities and other undesirable stuff that I'm sure you've already seen and felt many times. Usually, soon after, the product collapses under its own weight and something new comes along, repeating the same cycle again.

However, as Valetudo is not a commercial product it doesn't have to follow the same playbook. Again, it could do that, yes, but that would be bad because that cycle is quite frankly just utterly insane.

Only supported robots are supported

While this may sound incredibly dumb, it unfortunately needs saying nonetheless.

Only supported robots are supported. Unsupported robots are not supported.

If you have an unsupported robot, it is not supported. There is no support for it because it is not supported.

While there might be code in Valetudo that enables operation of a specific robot, it doesn’t mean that it is also supported. Support can only be provided for supported robots.

To receive support, you will need a supported robot. It is impossible to support an unsupported robot as - due to it being not supported - there simply is no knowledge available that could be utilized to provide support.

It is possible to use Valetudo on unsupported robots or in unsupported ways. Just note that there will be no support for these unsupported scenarios.

Valetudo is only available in english

Valetudo does not feature any localization. Let me explain the reasoning behind this with a few examples.

First, consider this car radio in a car made for the german market:

In fact, the radio is engineered by Bosch in Hildesheim. Still, the button isn’t labeled Karte.

Now, let’s take a look at the Valetudo UI (Version 0.6.1):

Regarding overall complexity, it’s comparable to the buttons on the radio. It’s even easier to understand, because there are a lot more icons.
Considering that people do in fact manage to use their car radios even if their english skills may be lacking, I’d say that accessibility isn’t a problem here.

As a matter of fact, Internationalization isn’t free. It always introduces more work, more complexity etc.
Of course accessibility is often worth the effort, however since we’ve already established that this factor isn’t relevant here, we can take a look at a non-exhaustive list of downsides of i18n:

• Getting support is harder when screenshots/error messages are in a language that isn’t english, because supporters may not speak it
• Development of new features, refactoring etc. is always blocked by having to translate everything new to all languages
• Increased codebase complexity
  • Harder to read
  • Harder to work with
• Lots of initial work to translate everything
  • Time/effort that could be spent better elsewhere

Now, let us look at another real-world example of i18n.

This is a screenshot of Apple Shortcuts running on an iPhone set to the German locale. It is just a basic HTTP PUT with a JSON payload. For some reason however, “Header” as in “HTTP Header” was translated to “Überschrift” which means “Headline”. Even worse, “Request body” became “Haupttext anfordern” which translated back to english means “(to) request the main text”???

This is another example. Here we have the Integrated Development Environment Visual Studio 2017 made by Microsoft attempting to open a project file that was created in an older version of Visual Studio.

Instead of asking us if we want to change the target SDK of the project file - which is called solution in Visual Studio - it is showing us a dialog titled “Lösungsaktionen prüfen” which translates back to “check actions to solve something”. Then there’s a sub-header labelled “Projekte neu ausrichten” which translates to “realign projects” (plural).

The only way I was able to decipher what that dialog even means was by opening the same project on a different system with the locale being set to en-US.

In both examples, the actual meaning got lost in translation, which is a common issue. Even with German being a common language and understanding of the HTTP protocol being fairly common as well.

Preventing this is hard, because you will need someone who understands the project from a technical standpoint as well as speaks the language it should be translated to. This is also required even if the translation is done by someone else, because you still have to validate what they did.

As even huge corporations known for being user-friendly and also paired with insane budgets fail to do this all the time, I don’t think that it is actually a feasible task.

No multi-floor/multi-map support

2024 Update

At this point, the whole topic is honestly just legacy content.
I’m getting the feeling that most of the time it is being brought up, it is being brought up not because people actually were looking for information on it, but instead because they read about it on this page.

TL;DR:

1. There are strong technical reasons against it.
2. There are strong logical reasons against it.
3. Most importantly: There are also strong opinions against it.

Multi-floor to me always seemed like a feature cooked up by product management in an effort to have another feature for sales purposes, without getting too costly on the hardware and development side. It always broke the core idea of having an autonomous cleaning thing you don’t have to care about, because it can’t be autonomous if you have to put it somewhere. Some people used it regardless. Some due to real budget concerns; others due to fictional ones.

But that all was back when robots just came with a simple small and light-weight charging station. Nowadays, the docks are huge. They auto-empty. They house clean and dirty water. They can even be permanently hooked up to the water supply. And the robots also need them. They can’t mop without the dock, because they regularly clean the mops during cleanup.

There is just no way that a reasonable person will use a current- or even last-gen robot on multiple floors. Some will try, yes, but only to eventually discover that it makes no sense to move the giant heavy dock from floor to floor every single time.

Regardless, this actually doesn’t have to be a “does it make sense? Does it not make sense?” discussion. Not only because we’d never see the end of it, as in the end it’s just opinions, but because it never was a discussion.

Instead, it always was:
“I’m not going to do it and here’s some insight into why that is.”

Not because I’d be obligated to explain myself, but because I’d like to give others the opportunity to understand the viewpoint. I’m not expecting people to agree with it; just to respect my boundaries and for that I’m doing all I can by being transparent in my thoughts about this.