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.

[pako88]

i have the same issue with my x40 after upgrading the firmware (1652) and valetudo (2025.01.0). and for me the wifi connection is lost multiple times a day. i always have to do a soft reset to get it up and working again.

[abueschel]

I already reported the problem to Dennis (via [email protected]) and waiting for a reply. At least to me this looks like this is related to the firmware and not Valetudo, as the previous firmware worked fine with 2025.01.0.

[Hetsh]

Also affected by @abueschel's issue and I might also have the same issue as @pako88.

I started with firmware 1543 on my X40 and uptime in Valetudo was never greater than 24 hours. It seems like my robot rebooted at least once a day, but that had no impact on usability for me. With firmware 1652 the daily reboots still happen, but now they impact usability because I have to reconnect the robot to my wifi every time.

Does somebody know if firmware downgrades are possible?

[Hypfer]

I'm still in the process of investigating this. It seems that there are two distinct failure modes.

Dreame did both change how they handle wifi configuration and the wifi driver in that 1652 x40 firmware.
Problem is that I can't reproduce the issue. Or rather I could, but only one failure mode.

The first one seems to have something to do with some kind of state and hence can be solved by factory-resetting, reinstalling Valetudo and reprovisioning.

The second one seems to be the robot not playing nice with some APs? Not sure. One name that comes up during support of that is Unifi APs but that could be correlation but could also be coincidence.

I'm also watching their support channels and came across this today:
https://www.reddit.com/r/Dreame_Tech/comments/1i944nq/wrong_passwort_cant_connect_my_dreame_x40_ultra/

But then again, no clue of that is just user error or might indicate that there seem to be some new wifi-related issues.

For the time being, personally, I'd try the factory reset approach.
I'm not happy with that because I'd like to know and fix the root cause, but that's where it's at right now.

If you want to help out investigating which state exactly there might be that is causing issues, you can pull a backup of /data before factory resetting, then do that, reinstall valetudo, reprovision, reboot, check if it stays connected and if yes, pull another backup of /data and diff them.
Personally, I'm using git for that by just throwing the whole folder into a new repository but you can use any tool you prefer.

For most comparable results, I'd use the breakout PCB with the OTG jumper connected, plug in a USB drive using that and then copy over the data via the shell on the UART. If you put it back into AP mode to access it via SSH, that might interfere with the stuff we're looking for.

If that doesn't help, downgrading back to FW 1543 also seems to work without breakage.

[Hetsh]

The factory reset worked for me 👍 Unfortunately I didn't back up /data before.