Cloud replacement for vacuum robots enabling local-only operation
Map data format changes, quality of life improvements and bugfixes.
As expected, something would go wrong with the map data format change. This is a bugfix release, so 98% of the previous changelog still apply.
In 2021.12.0, if you have rooms that aren't rectangular, it might happen that the triangle to select it vanishes, leading to you being unable to trigger a segment cleanup using the UI. This happened because in those cases, the UI calculates the median pixel coordinates to properly place the triangle. This value isn't calculated by the backend, because it is an expensive operation, and we're both RAM and CPU-limited there.
To calculate the median, the UI needs the decompressed pixel coordinate format. This works exactly once during the initial render, because of the MapLayerRenderer doing the pixel decompression on the map passed by reference to it.
As soon as the WebWorker is available however, this doesn't happen anymore, as the worker only receives a copy of the data.
This means that there are now 0 pixels as far as the SegmentLabel is concerned, leading it to be placed at coordinates [NaN,NaN]
.
Since testing is done locally without constant map updates, everything seemed fine during development.
Another thing discovered due to this bug was that the GithubValetudoUpdateProvider did not filter out pre-releases or drafts. Not a big issue though as it just requires you to update twice in a row.
Anyways, on with the 2021.12.0 changelog:
This release features the first version increment of the ValetudoMap data format.
Initially, in version 1, pixel data such as walls or floor were stored as a huge array of coordinate pairs:
[x0, y0, x1, y1, ...]
. This was not a very efficient way of storing that data as most of it is redundant.
This resulted in map files that were over 1 MiB in size being pushed to your browser every 3 seconds.
To combat this, some thought was put into how the data is stored. If you have a row of pixels, all of them will have the same y-coordinate, meaning that you only have to store that once. People already figured that out in the 60s.
With Map V2, pixels are stored as [xStart0, y0, count0, xStart1, y1, count1, ...]
where [xStart, y]
is the starting point and count
represents additional pixels with the same y-coordinate to the right.
This resulted in V2 map files using between 5% and 15% of the size of the equivalent V1 map. The huge testfile map for example was compressed from 847 kB to 75 kB.
While this is a breaking change, the breakage actually isn't that big of a change as V2 can easily be converted back to V1.
In fact, running JSON.parse()
on a V2 map and then converting it to a V1 one in memory is more than twice as fast as running JSON.parse()
on a V1 map.
Since this change drastically reduces the traffic caused by live maps, I expect to see general usability and reliability improvements in situations where the Wi-Fi reception isn't that great.
The LogViewer has been greatly improved and now features a structured and color-coded view of your log.
You can use the text filter at the top to either filter for the loglevel or the message contents. Just start typing.
Both consumables and timers now feature a help button, which shall explain how to use these features.
Map data format changes, quality of life improvements and bugfixes.
This release features the first version increment of the ValetudoMap data format.
Initially, in version 1, pixel data such as walls or floor were stored as a huge array of coordinate pairs:
[x0, y0, x1, y1, ...]
. This was not a very efficient way of storing that data as most of it is redundant.
This resulted in map files that were over 1 MiB in size being pushed to your browser every 3 seconds.
To combat this, some thought was put into how the data is stored. If you have a row of pixels, all of them will have the same y-coordinate, meaning that you only have to store that once. People already figured that out in the 60s.
With Map V2, pixels are stored as [xStart0, y0, count0, xStart1, y1, count1, ...]
where [xStart, y]
is the starting point and count
represents additional pixels with the same y-coordinate to the right.
This resulted in V2 map files using between 5% and 15% of the size of the equivalent V1 map. The huge testfile map for example was compressed from 847 kB to 75 kB.
While this is a breaking change, the breakage actually isn't that big of a change as V2 can easily be converted back to V1.
In fact, running JSON.parse()
on a V2 map and then converting it to a V1 one in memory is more than twice as fast as running JSON.parse()
on a V1 map.
Since this change drastically reduces the traffic caused by live maps, I expect to see general usability and reliability improvements in situations where the Wi-Fi reception isn't that great.
The LogViewer has been greatly improved and now features a structured and color-coded view of your log.
You can use the text filter at the top to either filter for the loglevel or the message contents. Just start typing.
Both consumables and timers now feature a help button, which shall explain how to use these features.
Bugfixes, polishing, two minor breaking changes and new features. Don't forget: If you're running Valetudo 2021.11.0, you can now use the integrated updater :)
The UI now checks if the robot is connected to a Wi-Fi network and if not opens a special provisioning page. It's pretty neat and also fixes the issue of Dreames not being provisionable with the new UI.
Statistics related to the current (or most recent) operation of the robot are now back. Yes, they are also being published to MQTT. Stop asking.
Data is published to MQTT as machine-readable (seconds for runtime, cm² for the area) as it is meant to build automations with it. Using cm² instead of m² saves us from having to deal with floats.
More importantly, you can now get total statistics from your robot.
Depending on your model those can be
This isn't available via the UI yet as it is yet TBD how to do that. Maybe have like badges, achievements or a rank system? Maybe have random trivia related to the numbers? (e.g. having cleaned 0.0001% of the Saarland)
Feel free to leave your input in the comments. Like, subscribe and click the bell icon
If you're good with graphics design, something like e.g. a Corporal IV vacuum robot badge would be a great contribution.
By actually reading the relevant RFCs, we've discovered that valetudo_something.local
is not a valid bonjour hostname as the _
is illegal.
While it does seem to work in most setups, it might cause problems in some, which is why starting with this release, Valetudo will use an RFC-compliant hostname: valetudo-something.local
.
Please update your bookmarks if you were using any.
Valetudo 2021.11.1 makes use of new features introduced in Home Assistant 2021.11 (namely configuration_url
and entity_category
).
This means that Home Assistant >= 2021.11 is now required if you want to use it with Valetudo.
You might also have to delete your Valetudo device in HA and let it get rediscovered so that the changes are applied properly.
It now looks like this:
We have received unconfirmed, unsubstantiated and possibly falsified reports of Valetudo going OOM related to Wi-Fi connectivity issues and the MQTT interface.
To combat this, Valetudo now drops any outgoing MQTT message if there are more than 1 MiB of outgoing messages buffered. This may or may not ever happen. If you see a warning in your log related to this, please report back. I have not been able to reproduce this.
Home consumable durations are now reported as an int. This should fix issues with OpenHab.
Dreame paths now parse to multiple path map entities instead of a single one, which fixes the visual with lines going straight across the map connecting the previous path to the next one. Consumers of the Valetudo map data might have to be updated to properly display multiple path entities.
I've bought a Dreame 1C to do some QA, which led to a few fixes. I'm now quite happy with the current state of its implementation in Valetudo.
Likely the most important release of the year.
Apparently, Valetudo 0.6.1 was released only a bit more than a year ago, but tbh it feels like an eternity. So much has changed since then. The iteration speed of the project has been insane in the last months. As we've now finished most if not all of the huge tasks, I expect things to slow down a little.
Here's a quick recap of what happened since 0.6.1:
Starting with this release, the new react-based UI introduced by @jomik with large contributions by @ccoors is now the default.
The existing map renderer was ported to react with a few quality of life improvements:
Speaking of navigating back: Given that the new UI is based on a frontend framework including proper routing, we now have a working back button. Amazing!
The only thing not yet available in the new UI is management of Zone and GoTo presets. This will be added later. For now, please navigate to the old UI via the menu and use that.
Starting with this release, Valetudo will be capable of updating itself with the press of a button.
This has been a long-requested feature and considering how mature this whole project has become, I decided that it was finally time to actually implement that. As it is implemented now, it uses the GitHub API by default, meaning that I am not able to track you.
There's also no automatic update check, because periodical pings to some cloud service are obviously problematic.
You will decide when to press the "Check for Updates" button and also when to update.
I've decided to get a few more stickers printed because merch
I'm currently looking for a job that isn't a corporate hellhole with nice people doing interesting stuff. If you're a likeminded hacker looking for a new colleague or know someone who does feel free to ping me
Thanks :)
Another release with a lot of UI changes by @ccoors. Also, there's an Android companion App now.
Thanks to the help of @TheLastProject who had built the first prototype in less than 18h after initially mentioning the idea on the telegram group, there's now an Android Companion App for Valetudo.
Don't worry, it is completely optional. All it does and aims to do is to find Valetudo instances on your network via Bonjour and help you with the provisioning (configuring Wi-Fi) process of new robots with Valetudo installed. This can be helpful for example if you were to give your non-linux-skilled parents a rooted robot for Christmas or whatever.
It's available on F-Droid and Google Play and of course open source.
For more information, please check out the docs.
@ccoors provided very nice previews displaying their changes in each PR, which is why I will just copy-paste them here for your convenience. Also, I'm lazy
As you might've noticed, the logo slightly changed. This avoids the bug in some people, which made them read it as aletudo when looking at it.
The thing from the telegram group finally got a name: Valetudog It's now some kind of mascot I guess.
I also bought a lot of stickers of it
Unfortunately, I have no idea what to do with them. They did turn out quite nice though.
Starting with this release, it's no longer possible to clean multiple zone presets at once via MQTT. That should've never been possible in the first place since it's conceptually wrong as you can only call a single preset at a time. Sorry about that.
Note that this is a breaking change and will require updating of e.g. your Home Assistant automations. Instead of an array, you now have to send just the preset ID as a string.
This release is packed with UI improvements thanks to @ccoors
The new UI now subscribes to the ValetudoEvents endpoint and allows for interaction with them.
This is helpful as they might contain errors that you've missed. Also, your robot might require confirmation from you to store a new map so make sure to keep an eye on that.
You can now use the new UI to set up ValetudoTimers.
Note that timers are always stored and evaluated as UTC. The local time display is simply a convenience feature.
MQTT configuration can now also be done via the new UI.
It features a nice topic preview to make it easier for newcomers to interact with Valetudo via MQTT.
Also, the API will no longer return any MQTT credentials but instead replace them with <redacted>
for security reasons.
A basic log viewer has been added to the new UI. While still WIP, it already allows for live updates as well as filtering, which is a neat improvement.
If you own a Dreame Z10, you're now able to enable/disable the automatic dust collection via the Swagger UI. Furthermore, you can also trigger it manually via either the UI, the REST API or MQTT, meaning that you can now fully customize the collection interval by using e.g. Home Assistant automations.
You can now disable the Obstacle Avoidance Feature of your Dreame L10/Z10 via the Swagger UI if you experience issues such as the robot refusing to drive onto a carpet.
The new UI now also features a consumables section with a neat hover feature hopefully helping newcomers better understand the consumables.
The new UI about section has been extended to display data returned by the runtime information endpoint.
This release features some more bugfixes and some breaking config changes
If you haven't seen it already, check out the previous release notes.
This release features a much cleaner mqtt configuration schema. Now, one can actually understand what the options are for.
Since this a breaking change, Valetudo will likely reject your old config file and create a new one. Don't worry though. The old one is backed up meaning that you can simply copy-paste your timers, presets etc. Just check the Log for more information.
Valetudo will now use the autogenerated machine identifier as the mqtt identifier and friendly name. If you've been using the defaults until now, you'll either want to manually configure the identifier or update your scripts, delete your Vacuum Device in Home Assistant etc.
The autogenerated unique machine identifier can be found in the Log.
It will sorta look like this: ModestFewChinchilla
The Map data camera image has been replaced with a nicer looking one that will also hopefully lead to less confusion for newcomers. It looks like this:
The out of memory issues causing Valetudo to shut down have been fixed again even though that they were already fixed.
For some reason, npm started installing the old and unpatched dependency. Probably some weirdness regarding the package-lock.json
or something like that.
This has been solved by reimplementing what the dependency did in Valetudo itself. Fortunately, this allowed us to add logging to that.
If you're seeing something like [WARN] Stale SSE connection to the Map SSE Hub detected. Terminating.
in your log, the mitigation is working.
I've added some notes for each implementation to the Supported Robots Page to make it easier for people to choose a robot to buy.
This release features the new React-based UI by @Jomik as well as some MQTT config changes
The new UI has been merged and is now available as a usable preview. There's still a lot to do, however that should be much easier now that it is merged.
Until everything has been ported over, the old UI will still be the default.
You can open the new one via the menu, which now also houses a shortcut to the Swagger UI as well:
There's a drop-down where you can select a zone preset to clean in the new UI.
Futhermore, there's also a button, which lets you set the iteration count for segment cleanups.
This marks a huge step forward for the project, which has been due since years. Thanks again to @Jomik ❤
This release removes all mqtt settings where I couldn't find a reasonable explanation for why they exist. If you're missing something, please let me know in the comments and include an explanation why it was needed.
If you're looking for a Valetudo-supported and affordable Vacuum Robot featuring an Auto-Empty Dock, you can now buy the Dreame Z10 Pro. I didn't know that I needed an auto-empty dock before I got one, but I definitely needed one.
Do note that it's supported on the feature level of the L10 Pro, meaning that you can't control the Dock yet. That shouldn't matter though as it is on by default and doesn't strictly require any interactions.
This release contains mostly bugfixes and code cleanup. Also, ordered cleanup and iterations for MQTT segment cleaning.
Rooting Dreame robots has been made publicly available with Dennis' DEF CON 29 Talk Robots with lasers and cameras but no security Liberating your vacuum.
For more information, consider joining the Dreame Robot Vacuum Telegram Usergroup.
This release allows you to specify an iteration count when calling Segment Cleanups via MQTT. Furthermore, you can also request it to respect the order you've provided. e.g. Kitchen then Living Room then Bathroom.
This requires firmware support and is also a breaking change. You'll have to update your MQTT scripts/automations/whatever.
The docs contain an example payload.
If you have children, cats or drunk roommates who like to mess with your robot vacuum, you can now lock the buttons via Valetudo. This of course needs firmware support. Something that seems to be available on most Dreame-made robots.
Please note that there's no UI toggle for it yet, meaning that you'll have to use the Swagger UI (http://ROBOT_IP/swagger/) to enable it.
Valetudo 2021.08.0 and up will publish a bonjour service, which should make it easy to auto-discover a Valetudo instance. This will likely be useful in the future.
This release includes, SSDP and Zeroconf advertisement, an Event/Notification feature some bugfixes and lowmem optimizations. Furthermore, 2021.07.1 fixes a race condition which was present in 2021.07.0 causing crashes on reboot.
To make using Valetudo a bit easier and more straight-forward, advertisement of the Service via both SSDP/UPnP as well as Zeroconf was added.
If you're on Windows, opening "Network" in the File Explorer should look similar to this:
If you're on a Mac, I'm sure that there's also something.
Furthermore, Valetudo will log the .local
domain it's using, which might be useful in some setups.
Starting with this release, we now have something that will deal with everything that would've been a push notification when using the regular app. Utilizing this, the "Bin Full" notification on roborock vacuum robots may finally happen.
There's no UI for it just yet, however it will be implemented eventually.
As storage space can be quite limited on these devices, it is now possible to use the NodeJS runtime bundled with Valetudo for other things as well.
This can be helpful if one would e.g. want to implement a Microservice, which also runs on the Robot, talks to Valetudo and provides Telegram connectivity.
Just add the --ignore-payload
flag plus another JS file:
./valetudo --ignore-payload repl.js
The baked-in v8 options will still apply when reusing the runtime. That however shouldn't be an issue for most use-cases.
Apparently, the Map Reset on the S5 Max never worked. That might explain some issues users of this Robot were seeing. It should be fixed now.
During the development of 2021.07.0, a lot of time was spent optimizing Valetudo for use in lowmem environments such as the Roborock S5 Max or Dreame D9.
It was discovered that there were issues with the SSE Map update feature, which lead to Valetudo being killed by the Kernel OOM killer. This was the cause of the confusing "Hey my Valetudo is just.. gone" reports.
While this was fixed by introducing limits there, Valetudo was also extended to watch its own Memory usage and shut down if it exceeds 1/3 of system memory. This should provide an additional failsafe.
Furthermore, Valetudo will also set its OOM score to a rather high value by itself, so that the Kernel OOM killer will always kill Valetudo and nothing else.
Still, if you can, please buy a 512mb or more RAM robot.