Error 500 when using map function while charging

[ovaltineo]

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).

[Crazyachmed]

Works fine for me on 3514. I had this issue only before I let the robot run for the first time.

[ovaltineo]

It definitely has a map of the house - I can see the map in the Xiaomi app and FloleVac app. It was giving the error 500 when I tried it while charging. I tried now while it is doing a zoned cleaning and it worked.

[ovaltineo]

Sure it enough, it returns error 500 when it went back to dock to charge. Is this a known bug?

[Crazyachmed]

Now that you are saying it, it displays an old map as soon as it hits the dock

Maybe related to issue #23 ?

[metronidazole]

I received this error the first time (gen 1 build 3254) I set up the device (no previous maps). Haven't had the issue since, including while charging.

[Mdleal]

I am seeing the issue with a Gen 2 running v11_001633.

@metronidazole What firmware are you running?

[mrwsl]

@Mdleal same here: Rockrobo S50 with 1633 firmware.

[moskovskiy82]

Same with me 1780

[JohnRev]

I have the same issue with 1644 and above. The issue does not occur on 1518.

I have noticed that in the newer firmwares, the map file in /mnt/data/rockrobo/rrlog/ gets renamed from navmap344327.ppm.0000.gz to navmap344327.ppm.0000.rr.gz when the vacuum is charging, and so the regex on https://github.com/Hypfer/Valetudo/blob/2b38868bf5df113e6fe66788502c9822ef68b71c/webserver/WebServer.js#L925 and https://github.com/Hypfer/Valetudo/blob/2b38868bf5df113e6fe66788502c9822ef68b71c/webserver/WebServer.js#L928 will fail.

I tried modifying the regex to something like: /^navmap([0-9]+)\.ppm\.([0-9]{4})(\.rr)?\.gz$. With this updated line, the navmap file is correctly identified and located, but the decryption fails. I am not sure how those .rr.gz files are encrypted.

[Hypfer]

Firmware 1518 is the last firmware that uses the old map format IIRC. It could be possible that the .rr.gz navmap is in a completely different format which is not (yet) supported.

A sample .rr.gz Mapfile should be interesting. If you're comfortable with sharing your map please attach it to #44

[JohnRev]

I have already downgraded back to 1518. When I get some time, I will try to upgrade again and post the .rr.gz mapfile

[leonardpitzu]

i'm on 1633 - what do you need, the nvmap archive (which i attached to #44) or something more?

[Hypfer]

Looks like they indeed changed the encryption key. I have no idea how the previous one was found so unless someone finds out more I can't do much about it.

[leonardpitzu]

Can we downgrade? I think it’s the best option now.

[leonardpitzu]

There must be an app which does the encryption - we can debug it and find the key which is probably hard coded.

[mrwsl]

@JohnRev Do you have some hints on how to downgrade? Just do the same steps with older firmware?

[JohnRev]

@herrwusel : I downgraded by flashing 1518 using flasher.py and the instructions here https://github.com/dgiese/dustcloud/wiki/VacuumRobots-manual-update-root-Howto

@leonardpitzu, @Hypfer : Another idea. How about we just use the latest map from robot.db with an extractor similar to https://github.com/dgiese/dustcloud/blob/master/devices/xiaomi.vacuum.gen1/mapextractor/extractor.py . This will only be needed when charging, since live maps were working fine on the newer versions, if I recall correctly.

[Crazyachmed]

This will only be needed when charging, since live maps were working fine on the newer versions, if I recall correctly.

Somewhat. The live map is currently mirrored (the saved map is not), at least in my case, and also the live map looses path data after some time, so it looks like the robot started somewhere mid cleaning.

[mrwsl]

With newer firmware I had the issue that the rooms were stacking over each other. I put the vacuum into a new room and it kept showing the map from the room before as well. Have to test it with 1518 though.

[leonardpitzu]

i downgraded myself this morning. i will try to get a look into how this thing in built but my free time is mostly during flights so my progress will be...

[leonardpitzu]

after downgrading all seems to work. i can see the map after the vacuum does it's round. if i reboot the vacuum though i get the error500 message that "Error: No usable map data found". anything i should know or do it is this just the way things work until a new sweep is node and the live map is reconstructed?

[JohnRev]

There seems to be some issue with how the subfolders under /mnt/data/rockrobo/rrlog/ are scanned in FIND_LATEST_MAP_IN_ARCHIVE. If there is a new folder with no usable map in it, Valetudo throws a 500 error.

To reproduce, go to /mnt/data/rockrobo/rrlog/, do an ls and see the name of the newest folder. Let's assume it's 000105.[redacted]. Create an empty directory with a larger number mkdir 000106.[redcated]. Valetudo throws error 500.

The expected behavior is that Valetudo should ignore the empty folder since there was no usable map in there.

[cryptomilk]

@JohnRev I've just build the latest valentuo with your fix but I'm still getting the Error 500 (running Gen2 v001780). I guess I will install strace to see what is going on, I think valetudo has no debug logging right?

[cryptomilk]

I see that it walks all /mnt/data/rockrobo/rrlog/000* directories and lists there contents, but it doesn't find what it is looking for and returns: Error: No usable map data found

[cryptomilk]

I've changed the regex to also include rr files, but the map function still doesn't work, however I can open the file if I download it and open it here.

[cryptomilk]

Looking at strace I see that it reads both files the log and the map. The unzipped filesize is also correct.So it looks like the data is correctly delivered to the browser, but the browser is not able to display it for some reason ..

[JohnRev]

@cryptomilk: If you can open the file, then the rrlogd patch is working. Maybe the issue is what I have already fixed in this pull request: https://github.com/Hypfer/Valetudo/pull/59 ? Did you try with this change? Otherwise, check what is the response of http://[vacuum_ip]/api/map/latest

[cryptomilk]

@JohnRev I already have that fix and also applied the regex fix you posted earlier. As I said, the files are correctly read, but then the webbrowser runs havoc that firefox wants to stop the script. Acorrding to strace the file are correctly read and parsed and delivered to the browser.

[JohnRev]

It would be interesting to debug, and possibly open a separate issue for this bug. Do you mind sharing your map and log files so we can try to replicate?

[cryptomilk]

@JohnRev Contact me via mail and I can send you the files.

[Fietspomp86]

Isn't this issue already solved from the other issue? #44 With the patched rrlogd for me it's working when charging (Gen1, 3514 firmware)

[SoulSlayerPT]

Could not make the rrlogd patch to work with 1632 and 1702. Can someone provide me a link to 1780 firmware? Cannot find it anywhere..

[cryptomilk]

./imagebuilder.sh --rrlogd-patcher=/path/to/patcher.py

HOWTO: https://hackmd.io/s/HkwF33oWE

[SoulSlayerPT]

Can you provide a link to the firmware files? 1780 or 1792? because the link in the instructions doesn't work.

[SoulSlayerPT]

Tried with your link and firmware 1702. It doesn't work.. Still error 500 while charging.

sudo ../dustcloud/devices/xiaomi.vacuum/firmwarebuilder/imagebuilder.sh \

--firmware=../firmware/v11_001702.pkg \ --soundfile=../firmware/english.pkg \ --public-key=$HOME/.ssh/id_ed25519.pub \ --valetudo-path=../valetudo \ --disable-firmware-updates \ --patch-rrlogd \ --replace-adbd /home/pedro/rockrobo/image/imagebuilder.sh Compatible readlink found! Script path: ../dustcloud/devices/xiaomi.vacuum/firmwarebuilder Generate SSH Host Keys if necessary Decrypt soundfile .. Unpack soundfile .. ~/rockrobo/image/fw.jgVkds/sounds ~/rockrobo/image ~/rockrobo/image Decrypt firmware Unpack firmware ~/rockrobo/image/fw.jgVkds/fw ~/rockrobo/image ~/rockrobo/image Replace ssh host keys Disable SSH firewall rule Add SSH authorized_keys reconfiguring network traffic to xiaomi replacing adbd Creating backup of rrlogd Trying to patch rrlogd Successfully patched rrlogd Installing valetudo Pack new firmware ~/rockrobo/image/fw.jgVkds/fw ~/rockrobo/image Encrypt firmware ~/rockrobo/image Copy firmware to output/v11_001702.pkg and creating checksums Cleaning up FINISHED

[hagenuck1]

I just upgraded to 1702 using imagebuilder, too. But for me Valetudo & dummycloud wasn't included. Did this work for you? Maybe there is an issue with the imagebuilder currently?

Having error 500 when the roborock is charging, too.

[Fietspomp86]

Maybe you need to let the robot do a first run before trying to see if it works when charging? Just updated my Gen1 using the link from cryptomilk. Used firmware 3514 and included Valetudo and Dummycloud. Working just fine for me, no more error 500 when charging.

[SoulSlayerPT]

I did the run and i still have the error. That is why i would like to have a 1780 firmware pkg to download. to try with it and if doens't work copy the file manually.

[Mdleal]

I am having the same issue with 1780 as well. Is there a way to verify rrlogd is patched?

[cryptomilk]

Run valetudo manually. I should then log errors on the console.

[Mdleal]

I copied the patched rrlog file from this issue and it's working now.

[SoulSlayerPT]

Can someone upload to wetransfer or some other website the 1780 pkg so i can test also? Thanks

[cryptomilk]

@Mdleal could you try if rrlogd works if you patch it using: https://github.com/JohnRev/rrlogd-patcher

[SoulSlayerPT]

@cryptomilk With your last link it is working now! I patched the rrlogd and it is now working with 1702

[cryptomilk]

I will change the imagebuilder script to use the rrlogd-patcher.

[Maja61]

I test the patcher with an rockrobo.vacuum.v1 v3.3.9_003452, but it doesn´t help. I have still error 500 during charging.

[cryptomilk]

@Maja61 Yes, as the README.md states clearly: Gen1 Firmwares >= 3514

[ideasman69]

i followed this guide to the letter using v3514 on a gen1 and still get error 500 when charging. No errors from firmwarebuilder and patching of rrlog says it was successful.

edit: i had a copy of an unpatched v3514 rrlogd file which matched the "successfully patched" version generated by firmwarebuilder. So I've patched it manually, put it back on and restarted. Will see if it makes any difference.

[cryptomilk]

Fixes: https://github.com/dgiese/dustcloud/pull/181

[Maja61]

@Maja61 Yes, as the README.md states clearly: Gen1 Firmwares >= 3514

Update the Robo to 3600 and again follow the guide of the patcher, but again still error 500.

EDIT: seems to be a problem with chrome, with Firefox no error 500 and map still available during charging.