Premise: The author uses the article to describe their experience "reclaiming" their robot vacuum from the cloud, using the open source project Valetudo.
Premise: The author uses the article to describe their experience "reclaiming" their robot vacuum from the cloud, using the open source project Valetudo.
Valetudo is a firmware replacement for your robot. It integrates with a vacuum’s existing software and acts like a cloud replacement that allows you to control your robot vacuum locally. Instead of having to use a proprietary app on your phone, which connects to a distant server, which then connects back to your robot, you can simply control it directly with either an Android app or a simple web interface. (An iOS app is currently not available.) It also works with MQTT, and it can be controlled via the open-source home automation solution Home Assistant once properly configured.
I find it interesting that the author plainly defines Valetudo as a custom firmware replacement, whereas the project’s github page very clearly states it is not a custom firmware. The project acts...
I find it interesting that the author plainly defines Valetudo as a custom firmware replacement, whereas the project’s github page very clearly states it is not a custom firmware.
The project acts as a replacement cloud, which seems far less intrusive (or risky) to me than flashing custom firmware onto the vacuum. Just surprised the author missed that relatively important piece of information.
While I agree that this would generally sound like the "safer" approach, I'd wonder (before having read the article, I will do so later) how the replacement cloud as a "target" is achieved without...
I find it interesting that the author plainly defines Valetudo as a custom firmware replacement, whereas the project’s github page very clearly states it is not a custom firmware.
The project acts as a replacement cloud, which seems far less intrusive (or risky) to me than flashing custom firmware onto the vacuum.
While I agree that this would generally sound like the "safer" approach, I'd wonder (before having read the article, I will do so later) how the replacement cloud as a "target" is achieved without some form of soft- or firmware substitution?
I read in as far as the I could, and it does look like they require you to do what they call "rooting" of the device. Which is, essentially, installing a custom firmware on the robot. it...
I read in as far as the I could, and it does look like they require you to do what they call "rooting" of the device. Which is, essentially, installing a custom firmware on the robot. it definitely seems to be a hacked firmware situation.
I was going to guess they used something like DNS redirection or simple port redirection to intercept calls to the server and replace them with their own, but it seems much more invasive than that.
The days when you could just mess with DNS are largely over thanks to TLS and certificates. Even in the notoriously lazy and security free embedded space it is now the default because you'd have...
The days when you could just mess with DNS are largely over thanks to TLS and certificates. Even in the notoriously lazy and security free embedded space it is now the default because you'd have to do a tiny amount of extra work to use plain http.
I'd still say that there's a large gap between a) patching the vendors firmware and rooting a device and flashing something completely custom, and b) what exactly firmware means - is it just the on device software but largely a standard Linux userland or is it a large blob of assembler and device specific code that runs without a proper os and pokes into hardware registers?
I will be trying this out in the near future. I have a 2-year-old Roborock S7 -- unfortunately, one of the trickier ones to hack, but I'm up for the challenge. The robot worked great for a year,...
I will be trying this out in the near future. I have a 2-year-old Roborock S7 -- unfortunately, one of the trickier ones to hack, but I'm up for the challenge.
The robot worked great for a year, but then after we moved to a new flat, it simply never connected to the new network here, no matter how many times, how many tricks I tried. For the past year, it has continued to work great physically, but with extremely limited set-up/customization options, as the app is now useless.
I'm moving again in a few weeks, so it is entirely possible that the robot will start working again once I have Internet set up at the new place, but even so, I prefer the "not-phoning-home" option. It will be a month or so before I can dive into this project, but I will definitely try it, and if I remember, I will report back here on the outcome.
I've always wanted a Roomba that curses explicatives when it runs into something. Could get some A-list Hollywood celeb voice packages, like the old days of Garmin.
I've always wanted a Roomba that curses explicatives when it runs into something. Could get some A-list Hollywood celeb voice packages, like the old days of Garmin.
Premise: The author uses the article to describe their experience "reclaiming" their robot vacuum from the cloud, using the open source project Valetudo.
I find it interesting that the author plainly defines Valetudo as a custom firmware replacement, whereas the project’s github page very clearly states it is not a custom firmware.
The project acts as a replacement cloud, which seems far less intrusive (or risky) to me than flashing custom firmware onto the vacuum. Just surprised the author missed that relatively important piece of information.
While I agree that this would generally sound like the "safer" approach, I'd wonder (before having read the article, I will do so later) how the replacement cloud as a "target" is achieved without some form of soft- or firmware substitution?
I read in as far as the I could, and it does look like they require you to do what they call "rooting" of the device. Which is, essentially, installing a custom firmware on the robot. it definitely seems to be a hacked firmware situation.
I was going to guess they used something like DNS redirection or simple port redirection to intercept calls to the server and replace them with their own, but it seems much more invasive than that.
The days when you could just mess with DNS are largely over thanks to TLS and certificates. Even in the notoriously lazy and security free embedded space it is now the default because you'd have to do a tiny amount of extra work to use plain http.
I'd still say that there's a large gap between a) patching the vendors firmware and rooting a device and flashing something completely custom, and b) what exactly firmware means - is it just the on device software but largely a standard Linux userland or is it a large blob of assembler and device specific code that runs without a proper os and pokes into hardware registers?
I will be trying this out in the near future. I have a 2-year-old Roborock S7 -- unfortunately, one of the trickier ones to hack, but I'm up for the challenge.
The robot worked great for a year, but then after we moved to a new flat, it simply never connected to the new network here, no matter how many times, how many tricks I tried. For the past year, it has continued to work great physically, but with extremely limited set-up/customization options, as the app is now useless.
I'm moving again in a few weeks, so it is entirely possible that the robot will start working again once I have Internet set up at the new place, but even so, I prefer the "not-phoning-home" option. It will be a month or so before I can dive into this project, but I will definitely try it, and if I remember, I will report back here on the outcome.
We did this. Thankfully my husband likes to tinker with tech issues. I don't like appliances phoning home to any remote headquarters.
I've always wanted a Roomba that curses explicatives when it runs into something. Could get some A-list Hollywood celeb voice packages, like the old days of Garmin.