hypfer / valetudo Goto Github PK

Hi!

First of all: Thanks for providing such a good tool for the Xiaomi vacuum. I like it very much!

One thing I noticed after playing with Valetudo for a few days: The coordinate system seems to be kind of unreliable.
Standing in front of the charging station (looking at it), I had a reproducible movements with -x towards me and +y to my left.
After setting up my zones accordingly (did it in the config.json directly), I had to reboot my vacuum to see them and the coordinate system is completely different, an no matter how many reboots and whatelse, I can't get it back the way it was. Now it is +x towards me, and -y to my left (so rotated by 180°, if I'm not mistaken). I did not move the charging station in the whole process.

Additionally, neither orientation fits the description under "Zoned Cleanup" with x for left and right. ;)

Please let know if I can help in any way to solve this.

Btw., I think it would be most intuitive to place the coordinate system on the charging station and then standing on it (of course only virtually). I would then place the x-axis with increasing numbers to the right and the y-axis orthogonally to the wall.

Best regards,
Fo

I would love to see a notification if the currently used firmware is out-of-date. This way I only need the Mi app to update the firmware (as I assume this might be difficult to achieve using Valetudo?).

Hi,
is there any possibility to call a zone cleaning via http request / api?

Kay

I'm not sure if anyone has done this before (maybe I didn't look hard enough) but it was pretty easy to store and restore the current map on a rooted Xiaomi robot. To store, I just copied /mnt/data/rockrobo/* (excluding directories) to a backup folder. To restore, I copied from the backup folder to /mnt/data/rockrobo, then I kill 'player' process which gets restarted by the watchdog within a minute. Voila, the robot now starts using the restored map.

I think these two functions can easily be incorporated in Valetudo. It certainly saves me from re-mapping the house whenever the robot decides to forget the map. My zoned cleanup coordinates are always spot on because of this.

Sometimes it happens that not the whole map is generated, but only a part of it.

I have attached a video to it.
https://youtu.be/yGNcIR5bgXI

The problem occurs not only in Homeassistant (set up as a camera), but also when I access the maps directly via URL. After a few refreshes only half of the image comes up every now and then.

Is there a place that documents which API's are available and how to use them? I see a lot of people using http requests for various API's and I don't see how they know how to use them. Are we just supposed to look at webserver.js?

Unfortunately, these things are more of a hobby for me and so I don't know enough to understand the coding in webserver file to figure out the API's

Apart from "Quiet", "Balanced", "Turbo" and "MAX" there is a "Mop" Cleanup mode.
/api/current_status shows "fan_power":105 in this mode.

Could you please add this option (Mop) to the "Select fan speed" list?

Thanks!!

please add

-> makes it look good on the iphone x (otherwise the bottom bar is covered by the ios control bar)

Add support for enabling or disabling Carpet mode.

Not sure if I'm doing something wrong but I have this issue.

Steps to recreate:

1. add the X1, Y1, X2, Y2 coordinates to a new zone and call it "Hallway"
2. add the X3, Y3, X4, Y4 coordinates to another zone and choose "add area to existing zone" and select "Hallway"
3. Select the Hallway as a zone to start cleaning

Result:
The MiHome app shows a rectangle to indicate that only X1, Y1, X2, Y2 coordinates are being cleaned.

Expected Result
The MiHome app shows a 2 rectangles to show that X1, Y1, X2, Y2 and X3, Y3, X4, Y4 coordinates are being cleaned.

P.S. Also as a feature request it would be able to inspect the the X, Y values being used for each zone.

I am creating this issue as a follow-up for #44.
In #44, we discovered that the "new map format" after firmware 1780 on gen2 is still the same ppm file, but just encrypted differently.
For valetudo to keep working correctly, we need to patch rrlogd as in #44 (comment) or using @cryptomilk's firmwarebuilder additions dgiese/dustcloud#162.

For this issue, I'd like to specifically focus on the no-go zones and the virtual walls.
I have already posted an explanation about where and how these are stored (see: #44 (comment) and #44 (comment)).

I have pushed a demo on how to display these no-go zones and virtual walls in Valetudo (in the new /zone map url).
A few issues:

• The map drawing logic is confusing me. Someone with better knowledge could probably get this done faster than me
• The virtuual zones are centered at (25600, 25600), and not (25500, 25500) as it is often common in map parsing scripts. Is this going to be a problem?

My changes can be found here; https://github.com/JohnRev/Valetudo/tree/PersistData . For now, this will only display the stored no-go zones and walls on the map. We can not manage them from Valetudo just yet, and I am not sure if I will have enough time to implement this myself.

Precondition:
The v2 robot is in the dock

Problem description:
If I start manual control, the button stop manual control becomes active only for a split second, then the start manual control button becomes active again.

The robot says "using remote controls" followed by "finished using remote controls" right afterwards.

If I repeat this process a few times at some point the robot starts the fans and does not "finish using remote controls" immediately, such that manual control is possible.

Expected behavior:
Keep manual controls running after starting them until "stop manual control" is clicked

Hi

This project is awesome !
I did not tried yet, since I have a gen 1 robot.
As I can read, it is only for Gen 2 robots ? Which limitations are leading to this ?
Can I help porting to gen 1 ?

Hi together,

after installing and preparing the robot (1780, Gen2, valetudo0.0.9) 4 days ago actually everything went nice. Maps are persistent and miio is working moderatly, means, it's reporting a lack of communication to the dummycloud from time to time, however after 5 sek. the system is responsible via valetudo again.

My problem is, that every morning the robot isnt reachable anymore. I have to set back it to 192.168.8.1 and redefine SSID/PW in valetudo again.

Does anyone had similar experiences? What can I do?

Greetings
Christian

Super obvious and I'm sure its on everyone's wishlist but hadn't seen it documented yet.

It would be great to mirror some of the functionality of the official app and allow the user to both pinpoint areas for GoTo and click+drag to create zones. 👍
I have had a look at the front-end JS and the data returned from the API and can see it's not the easiest, but hopefully is possible!

Somehow the build process broke for no apparent reason.

Downgrading to pkg 4.3.3 "solves" this.

[email protected]
Error! TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
at assertPath (path.js:39:11)
at Object.join (path.js:1157:7)
at getPath (/home/hypfer/Valetudo/node_modules/dir-glob/index.js:6:41)
at globs.concat.map.x (/home/hypfer/Valetudo/node_modules/dir-glob/index.js:47:59)
at Array.map ()
at module.exports.sync (/home/hypfer/Valetudo/node_modules/dir-glob/index.js:47:33)
at globDirs (/home/hypfer/Valetudo/node_modules/globby/index.js:58:9)
at getPattern (/home/hypfer/Valetudo/node_modules/globby/index.js:61:64)
at globTasks.reduce (/home/hypfer/Valetudo/node_modules/globby/index.js:107:19)
at Array.reduce ()

It would be useful to check the firmware version in the Settings, as is possible in the Xiaomi app.

Hello,

first of all great Project :)!!!!

I have a weird Problem.
I open the WebGui and it shows up correctly. But than a few seconds later, randomly it starts loading and loading and cant get informations from the Vaccum. (Loading state...) for maybe 5 Minutes and than its okay again and than 5 Minutes later it starts againg loading and loading.

Can someone help me, fix this issue.
I have a rooted firmware (rooted with Dustcloud)
FW Version: 3.3.9
FW Build: 001518

How did i install Valetudo: i copied the latest final Binary 0.0.7 with the valetudo.conf.
If you need more Informations, tell me :)

Kind regards,

BLAUSICHT

Not sure how feasible this is, but it would make it much easier to set up zones if we were able to see where the vacuum currently is in the vacuum coordinates format 😄Then we could use manual control to drive it to corners of rooms etc.

Thanks flole for reporting

Hi!

In addition to the firmware version shown in the settings I would also suggest to show the (currently running) valetudo version as well. I know that I should be able to remember which version I have, but just to be safe. ;)

This would enable users to include map rendering into their home automation system.
For example Home Assistant with a custom lovelace card

The roborock firmware uses its own timezone configuration: even if you configured the timezone of the ubuntu system correctly and date shows the right time the firmware still uses its own tz.
The timers of the roborock (stored in /mnt/data/rockrobo/apptimer.cfg) that are also set by valetudo's timer configuration dialog abide this tz and will happily wake you in the middle of the night (been there, done that).

To fix this you have to set two files in /mnt/data/rockrobo correctly.
For example, to set the timezone to Europe/Vienna you can execute this via ssh:

echo 'Europe/Vienna' > /mnt/data/rockrobo/timezone
ln -sf /usr/share/zoneinfo/Europe/Vienna /mnt/data/rockrobo/localtime

Alternatively, mirobo does also the correct thing (although wasting a few bytes):
mirobo --ip ... --token ... timezone Europe/Vienna

It would be very nice to be able to do that within valetudo or at least display the timezone information on the timer page ;)

Hi, the roborock is driving back home, when using the new "roborock/zone" url. I'm trying to find out all coordinates and cleaning some rooms for this, so the map is completely recognized.
But as soon, as the robot has finished cleaning a zone it goes back to the charger.

This isn't interruptible, even if I select a second zone or a new "goto" location.
Using a gen 2 with 1518 firmware.

Valetudo worked properly on older firmware but now returns error 500 when using map function on Gen 1 firmware v11_003514 (downloaded via FloleVac app).

• Add the possibility to configure a mqtt server
• Provide the current status via mqtt
• Enable commands via mqtt
• Provide the latest map via mqtt

Hi,

Any plans for translation support ?
Even if the app is simple enough, for my mother that doesn't speak a word of anything-but-french, it's not usable ;)
I'm willing to help if needed ;)

I added the following cron expression (0 0 10 ? * MON,THU *) and expected my robot to start cleaning this morning but nothing happened. I'm using image v11_001518 and Valetudo 0.0.9.

Is this working for someone?

Bin time is recorded by the robot in seconds.
File is /mnt/data/RoboController.cfg, value is bin_in_time:

RoboController : { runtime : { bin_in_time = 265; time_slept = 0; sound_volume = 70; clean_id = 45; carpet_mode_enabled = 1; carpet_mode_curr_integral = 450; carpet_mode_curr_highwater = 500; carpet_mode_curr_lowwater = 400; carpet_mode_stall_time = 10; fan_power = 60; temp_fan_power = -1; }; };

While this doesn't let us react to removing the bin or see whether it's in, Valetudo can display the cleaning time since last bin removal.

Keeping and displaying an additional timestamp every time this value jumps to 0 or decreases would also be great.

Is anyone else's map flipped, making it difficult to interpret? If I manually flip it (over either axis - vertical preferred though) it looks fine.

I noticed #46 mentioned the issue but I don't see a resolution to this issue there

Found this in the log. No idea when this happened or why; and everything's fine again but maybe it should be handled more directly than just passing the exception up the stack if it can actually happen (I certainly did not do anything too unusual... just some wlan configuration, system updates via apt-get etc. - nothing directly related to valetudo (apart from interacting with its website)).

Webserver running on port 80
fs.js:145
	throw err;
	^

Error: ENOENT: no such file or directory, open '/dev/shm/navmapfirst.ppm'
	at Object.fs.openSync (fs.js:579:3)
	at Object.fs.openSync (pkg/prelude/bootstrap.js:483:32)
	at Object.fs.readFileSync (fs.js:485:33)
	at Object.fs.readFileSync (pkg/prelude/bootstrap.js:679:36)
	at /snapshot/Valetudo/webserver/WebServer.js:808:58
	at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:442:3)

dgiese/dustcloud@5e89f5d

The way the map tab is implemented seems to require quite some browser resources. I have not tested in detail but the desktop versions of Firefox and Chromium alike get noticeably slaggier when the map is opened. GPU memory in chromium's process memory peaks at about 300MB. The resident size of the respective Firefox tab up to about 2GB(!).
I detest web development, javascript and ruby so I'am a bit out my depth here but I guess things would improve if the canvas (or its contents) are not recreated on every update(?) and left to the GC to clean up but either simply updated or manually destructed.

This happens because maps are sorted by filename.
They should however be sorted by their creation time.

Thanks to Stephan Eisvogel for pointing that out

Hi, I'm currently looking into some enhancements for the map drawing (I'm having issues like flipped maps, and am looking for a way to fix these).

I noticed that right now, there are essentially two places with code for drawing the map: server-side (e.g. /api/remote/map?returnImage=true) and client-side in client.html. From my understanding, that's mostly for historical reasons because the client-side code was there first.

Anyway, I think it would make sense to remove the client-side logic entirely, replacing it with a call to fetch the image from the device. This would make the code easier to maintain. Plus, the volume of data transferred for the map should drastically decrease as well -- that can be an issue if, like me, you're exposing the robot over the internet using a reverse proxy.

Are there any objections to this? If not, then I'd work on this and would probably provide a PR within the next few weeks.

PS: What is the "new persistent map format" you're mentioning in #44 ? Just curious, if it's something easy I might look into that too (no promises though).

Readme says this tool is supposed to be hosted on a vacuum itself. And also that Valetudo only guaranteed to run properly with certain rooted firmware versions.

The question is: How hard will it be to make it run on a standalone server, not a vacuum?

Should I start developing my own Web interface to control it? Or there is a chance this already developed and maintenaned tool can be patched to be used with stock device? Is Valetudo tied with some functionality that only can be reached locally on vacuum?

I totally understand the concerns that led to developing a tool which doesn't need cloud. But rooting device and downgrading firmware to support Valetudo is not what I want.

Hey,

i found a bug that referrers to line 421 in WebServer.js:
if(/^([0-9]{6})\.([0-9]{17})_R([0-9]{4})S([0-9]{8})_([0-9]{10})REL$/.test(filename)) { ..
The folder structure on my Vacuum Cleaner V1 with latest firmware looks like:
000068.20180730053838787_1387101066286_2018062200REL

In my case i changed that line to
if(/^([0-9]{6})\.([0-9]{17})_([0-9]{13})_([0-9]{10})REL$/.test(filename)) { ...

This works for me, but that is not a generic solution... Please have a look on it. Thank you

Hi,

could you please provide a zip or tarball for releases which contain the binary + the deployment directory. Like in the soruce directory when you compile it:

+ valetudo
+ deployment
 \ - Readme.md
   - valetudo.conf

This way I could add a --valetudo-path to the imagebulider.sh of dustcloud and directly add it when building the firmware.

Thanks.

In Xiaomi App the current zones of zoned clean ist shown. In Valetudo not.
It would be very nice the see the current zone in Valetudo.

The Zone is visible during zoned clean until next clean.

btw, great work!

I discovered a small issue when using Home-Assistant to Poll the Map too often (every 10 seconds to get a sort of Live map). The /tmp directory filled and the vacuum locked up. A re-boot fixes the issue obviously.

I had done other things on the vacuum in the past so I might have had less space available than normal.

A quick work-around was to throw this into cron
*/1 * * * * cd /tmp/maps && ls -t /tmp/maps | tail -n +2 | xargs rm --

1st: great project. thanks for sharing!

I Installed latest beta-release v0.0.3 from the release-section (pre-built) on my Gen2 and followed the instructions from deployment/Readme.md
The server starts and I can access it via web-browser, but I cannot use any of the functions on the home-screen. Everything is greyed out. The map and also the settings-screen are working. I assume there is something wrong with the local miio-interconnect between rockrobo <-> valetedo on the vac. I get plenty of error-messages in /mnt/data/rockrobo/rrlog/miio.log

0x21 0x31 0x00 0x60 0x00 0x00 0x00 0x00 0x04 0x70 0xd2 0x17 0x00 0x00 0x02 0x7a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
[20180727 16:55:49] [INFO] OT protocol diagrams come...
[20180727 16:55:49] [WARNING] OT MD5 not match.


0x21 0x31 0x00 0x60 0x00 0x00 0x00 0x00 0x04 0x70 0xd2 0x17 0x00 0x00 0x02 0x7a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
[20180727 16:55:49] [INFO] OT protocol diagrams come...
[20180727 16:55:49] [WARNING] OT MD5 not match.


0x21 0x31 0x00 0x60 0x00 0x00 0x00 0x00 0x04 0x70 0xd2 0x17 0x00 0x00 0x02 0x7a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
[20180727 16:55:49] [INFO] OT protocol diagrams come...
[20180727 16:55:49] [WARNING] OT MD5 not match.


0x21 0x31 0x00 0x60 0x00 0x00 0x00 0x00 0x04 0x70 0xd2 0x17 0x00 0x00 0x02 0x7a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
[20180727 16:55:49] [INFO] OT protocol diagrams come...
[20180727 16:55:49] [WARNING] OT MD5 not match.

Hi,
I followed the instructions to install the valetudo binary and conf file. But I get a "start: Job failed to start" error when I try to start the service. Does it not work with the latest Gen 1 firmware 3.3.9_003357?
I've tested with Beta 0.0.5 and Beta 0.0.4 and got the same error.

root@rockrobo:~# ls -l /usr/bin/valetudo
-rwxr-xr-x 1 root root 45562700 Sep 13 07:59 /usr/bin/valetudo
root@rockrobo:~# cat /etc/init/valetudo.conf
#!upstart
description "Valetudo"

start on filesystem
stop on runlevel [06]

oom score 1000
exec /usr/local/bin/valetudo
respawn
respawn limit 10 90

root@rockrobo:~# service valetudo start
start: Job failed to start
root@rockrobo:~# uname -a
Linux rockrobo 3.4.39 #1 SMP PREEMPT Tue Aug 21 10:06:40 CST 2018 armv7l armv7l armv7l GNU/Linux
root@rockrobo:~#

Dear all,

I'm not sure if this is the right place for such a discussion, so please excuse me if I'm wrong here.
Unfortunately I'm very bad at programming, so I integrated Valetudo into my homebridge (Homekit) environment in a very bad manner. (but it works ;-)
I use the homebridge-plugin cmdAccessory to fire curl-commands with the API-calls for Valetudo. in my homebridge-config this looks similar to this:

 {
"name": "RockroboDock",
"on_cmd": "curl 'http://<rockrobo-ip>/api/drive_home' -XPUT -H 'Origin: http://<rockrobo-ip>' -H 'Host: <rockrobo-ip>' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Content-Length: 0' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: de-de' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15' -H 'Accept: */*' -H 'Referer: http://<rockrobo-ip>/'",
"off_cmd": "curl 'http://<rockrobo-ip>/api/pause_cleaning' -XPUT -H 'Origin: http://<rockrobo-ip>' -H 'Host: <rockrobo-ip>' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Content-Length: 0' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: de-de' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15' -H 'Accept: */*' -H 'Referer: <rockrobo-ip>/'",
"polling": true,
"interval": "10",
"state_cmd": "/bin/false",
"manufacturer": "aebgit",
"type": "Switch"
},

I wonder if somebody more skilled than me, can use this as inspiration for a homebridge-module that uses the Valetudo web-api. In my eyes this would be a great benefit to the homebridge- and rockrobo-community, because the current solutions (like homebridge-xiaomi-mi-robot-vacuum) that make use of the xiaomi-token are very unreliable.

Bet regards
Andreas

references:
https://github.com/Hypfer/Valetudo
https://github.com/nfarina/homebridge
https://www.npmjs.com/package/homebridge-xiaomi-mi-robot-vacuum
https://github.com/YinHangCode/homebridge-mi-robot_vacuum

First of all, thanks for working on this. From all the possible ways to access the map your approach seems to be the nicest one!

It would be nice to have an ability to request the generated image data directly without fetching the mapsrc-contained URL. A new parameter return_image=true could be added to return the PNG data (and proper HTTP content-type) as a response, which would allow direct integration to, e.g., homeassistant via https://www.home-assistant.io/components/camera.generic/