Valetudo 2025.01.0

[Hypfer]

2025.01.0

New Year, new Robot, MQTT changes and QoL fixes

New Robot

Beside the Dreame X40 and L40, there is also another permutation featuring basically the same hardware:

The Mova P10 Pro Ultra

What it can't do compared to its peers is leave its mops in the dock, however what it can do is cost $600 or less.
You're welcome.

Nightly updater

The nightly update channel now has a version check that actually works.

Previously, it always reported that there is a new version available, leading to some confusion.

MQTT

There are a bunch of MQTT changes and fixes in this release.

Dock Status

For docks that have a status, the dock status is now exposed to MQTT:

This should be helpful for automations.

More optionally exposable capabilities

The following capabilities can now optionally be exposed to MQTT:

• PetObstacleAvoidance
• CarpetModeControl
• CarpetSensorModeControl

again, something helpful for automations.

Fixing an infinite lock

As you know, there is no reboot button in Valetudo and that is for good reason. It should never require one.

Unfortunately, it happened to require one for some people first time setting up their robot.
In those situations, the MQTT client could lock up and never connect until the robot was rebooted.

This was super hard to identify and reproduce, but I think that I finally found the root cause.
Fingers crossed 🤞

Map performance optimizations

The map renderer now simplifies and merges the to-be-rendered paths into one per type before drawing.

While it looks the same as before, it now performs much better when there's a long cleaning task going on.

Changes to the consumables

Consumables are changing a tiny bit with this release, resulting in a breaking change:

sensor is no longer a type but a subType of the newly introduced type cleaning. If you've been relying on that, please update whatever code you use accordingly.

Furthermore, this will also break the Sensor Cleaning entity in Home Assistant.
To fix that, just delete the device in Home Assistant before updating. After the robot reboots, everything should be rediscovered correctly.

This change was necessary due to the new wheel consumable Dreame introduced with newer firmwares.
wheel is now the second subType for consumable type cleaning.

Additionally, it seems that Dreame has removed the mop consumable from some new firmwares.
It hence has been removed from Valetudo as well for the affected robots.

Misc Dreame changes

There are two new Dreame Quirks in 2025.01 if your robot's firmware supports them.

The first being Clean Route:

which does make quite a difference on the "deep" setting:

Also, users of Dreames with an extending side brush will now be able to enable the side brush on carpet:

As said, this will require the latest firmware. Speaking of:

Firmware Updates

Over the last weeks, we were once again busy testing and then updating the Dustbuilder with new firmware versions where available.
Feel free to try them and see if you can spot any improvements.

As the Valetudo updater only updates Valetudo, for instructions on updating the firmware, check out the docs.

In my testing on my X40 master, it was necessary to reconfigure Wi-Fi after the update.
I have not been able to reproduce that since, so no clue if it might affect you as well or if it was only caused by something I fixed when adding support for the new firmwares.

Bonus

In the last release notes, I talked about the vendor apps and how there were some interesting developments.
Since then, there have been some more interesting developments. Just see for yourself:

sqH7fAI.mp4

Imagine being a person that just paid $1500 for a vacuum robot to then discover.. that.

But of course, it should quickly turn out that it's a systemic issue that is not isolated to one vendor:

In a way, this feels vindicating, because it's another great example of why Valetudo exists in the first place.
This style of enshittification simply can't happen to something that is self-contained and operates purely local.

Still, I also feel a deep sadness that Tech and feeling excitement for it has been taken away from me.

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

Breaking Changes

• vendor.dreame: The mop consumable has been removed from X/L40 firmwares and equivalent d7f8e75
• The sensor consumable type is now a subtype of the new type cleaning b798ebb

Features

• ui: Simplify and merge paths to improve performance ac5e096
• vendor.dreame: Introduce Side Brush on Carpet quirk f795e2e
• vendor.dreame: Wheel consumable monitoring 1eda6ef
• core: Introduce wheel consumable subtype 6161901
• updater: Add unnecessary NullUpdateProvider for good measure 1b9dc20
• updater: Introduce a working version comparison to the nightly update channel 2cb8efc
• ui: Shuffle the MQTT settings around a96ab06
• mqtt: Remove obsolete addICBINVMapProperty setting 6dec70f
• vendor.dreame: MOVA P10 Pro Ultra df0609e
• vendor.dreame: Introduce clean route quirk 7b3dfb0
• vendor.roborock: Add error mapping for error codes 27 35 9d3df05
• ui: Trim host field inputs a07503b
• mqtt: Optionally expose PetObstacleAvoidance, CarpetModeControl and CarpetSensorModeControl capabilities 2cc0ab5
• mqtt: Publish Dock Status to MQTT ee76222

Fixes

• vendor.dreame: Newer dreames may store obstacle images elsewhere b8477fb
• mqtt: Attempt to fix the reconfigure mutex never being left 1af75e0
• docs: Wording fd89128
• ui: Add missing word in welcomeDialog c78e8c2
• vendor.dreame: Hide obstacles of type 200 88c0af5
• mqtt: Fix Home Assistant object_id generation d77480c

Refactoring

• mqtt: Minor cleanup 8f22341

[Freekers]

Thanks again for your hard work. No issues here after the update so far <3

[abueschel]

@Hypfer Happy new year and thanks a lot for this release! I ran into the mentioned issue having to reconfigure Wi-Fi after the firmware update (1652) on my X40. I can indeed reproduce it reliably, as I have to do it after every reboot of the robot now. I am unsure if this issue should be reported with DustBuilder or here.

[Hypfer]

Okay, people, this is not how it works.

If you want me to care about your problem, you need to start caring about it too.
I've already kicked one person for half-assing it and this now would mark the second one.

As I said there are two distinct failure modes of which one seems to be related to the state on disk, while the other seems to relate to the WiFi APs in use. UniFi specifically.

If you're suffering from failure mode 2, obviously a possible solution found for failure mode 1 won't solve your problem.

If you don't know what a "failure mode" is, fine. Just ask. It might be a phrase unknown to people. I can see that.
But don't do something random and useless that clutters, confuses and does not help anyone.

Remember that I don't experience the issues you experience so it's all irrelevant to me personally.
I do care of course, but if you half-ass things, that care dies quickly.

I can understand that you as a user don't want to really deal with things and instead want them to just work, but I want to deal with them even less because it's not my problem and I'm not being paid to care. Hence, you will have to overcome that "not wanting to deal with things" or else things will move nowhere

[Hypfer]

As for what to do about failure mode 2

As I said, I do care so I've been thinking what to do and one thing to try is to just use the older WiFi driver.
For this, I've added a third experimental option to https://builder.dontvacuum.me/_dreame_r2416.html

Right now it is just fw 1652 but with the 8189fs.ko (wifi driver) from fw 1543.
They are distinguishable during runtime by looking at /sys/module/8189fs/srcversion

the one from 1543 reports B1D52C676BA822FF274BD9E
whereas the one from 1652 reports DDF88B407AA87408564AF4C

I have no clue if that will make a difference, but having stared at the diff of those two firmwares for a while, it seemed like a reasonable thing to try.

[abueschel]

I have installed the eperimental r2416 firmware, confirmed /sys/module/8189fs/srcversion reports B1D52C676BA822FF274BD9E. Unfortunatley after reboots, WiFi is still not reconnecting.

What I've noticed (maybe unrelated)

In /var/run/wpa_supplicant.conf my PSK is correctly written in plain text, and my SSID is either erroneously replaced by a random amount of numerals or encoded in some form as a number. I did some research on wpa_supplicant.conf and found no reference to the latter being a thing. Maybe someone with working WiFi can cross-check this?

In /data/config/miio/wifi.conf everything is as one would expect, with the correct SSID and the PSK encrypted by wpa_passphrase.

Anyway, thanks for caring @Hypfer and I apoligize for any annoyance my posts may have caused.

[gf-a]

The SSID random numerals in wpa_supplicant.conf is just Hex, you can decode it with Hex to Text decoder.
I have The same problem with WiFi keeps disconnecting.