Support for the new persistent map format about valetudo HOT 96 CLOSED

Some findings:

The static encryption key (RoCKR0B0@BEIJING) is no longer used.
Instead, a random key is generated for each encrypted file. The key is sourced from /dev/urandom.
Then, this key is itself encrypted using mbedtls_pk_encrypt. The first 512 bytes of the file represent the encrypted key.
The remaining file content past the first 512 bytes is the map encrypted with mbedtls_aes_crypt_ecb and the random key.

That's what I have found so far, but it would be cool if someone else can independently confirm this.

from valetudo.

Maybe the virtual walls are stored the same way as zones are stored.

After spending a ridiculous amount of time reverse engineering the saved map formats, I think I have finally figured it out!!
The no-go zones and virtual wall coordinates are stored in : /mnt/data/rockrobo/PersistData_1.data.

The file first needs to be zlib decompressed, and inside it it contains a block of fixed size where virtual wall coords are stored, and also no-go zones.
The fixed size of these blocks is why the xiaomi app has an upper limit of virtual walls that you can create (50 or so, I think).

I need to spend a bit more time writing some codes to parse these files. This will hopefully allow us (with some effort) to have the virtual walls and no-go zones managed and displayed from within Valetudo!

from valetudo.

@JohnRev thanks for your work. I've added support for patching rrlogd to the imagebuilder script of the dustcloud:

dgiese/dustcloud#162

from valetudo.

nvmap attached in new rr.gz format

navmapfirst.ppm.log.rr.gz

from valetudo.

@JohnRev sudo "you deserve a beer!" it's working!

from valetudo.

@JohnRev somehow my setup was messed up... now it saves the map correctly and it survives reboots. i'll make a diff to see what was screwed up... In between i made a script to have my "own" firmware release - custom apps, scripts, telegram notifications for start-up and status updates (whenever something changes), removed xiaomi stuff and my custom valetudo. This should keep me safe from failures - whenever something goes wrong the vacuum resets itself and i have to start everything from almost scratch.

from valetudo.

@JohnRev my partition was bad. i had to kill almost all services to be able to unmount the partition. i did so and in the end i run fsck. now i have (again) a normal behaviour where maps are stored in between reboots. the patched rrlog + fw 1780 work great.

from valetudo.

Here's a quick and dirty python code to parse PersistData_1.data.
Can anyone who is using virtual walls test it?

import zlib, sys, io
import struct

def read_int(data):
    return struct.unpack('<i', data.read(4))[0]

def read_short(data):
    return struct.unpack('<h', data.read(2))[0]

def convert_coord(coord):
    return 25600 + coord

infile = 'PersistData_1.data'

# Read PersistData starting from 0x17
with open(infile, "rb") as infile:
    infile.seek(0x17, 0)
    data = infile.read()


# decompress the zlib
decompress = zlib.decompress(data)

mapdata = io.BytesIO(decompress)

# Jump to no-go zones block offset
mapdata.seek(0x000318E8)
zonecount = read_int(mapdata)
print("There are %d no-go zones" % zonecount)
zones = []
for i in range(zonecount):
  zones.append([])
  for j in range(8):
    zones[i].append(convert_coord(read_short(mapdata)))

print(zones)

# Jump to virtual walls block offset
mapdata.seek(0x00031C0C)
wallcount = read_int(mapdata)
walls = []
print("There are %d virtual walls" % wallcount)
for i in range(wallcount):
  walls.append([])
  for j in range(4):
    walls[i].append(convert_coord(read_short(mapdata)))
print(walls)

Run this on your PC after copying /mnt/data/rockrobo/PersistData_1.data to the same folder where the python script is saved.

Note: The offsets above should have only been tested on v1780 gen2. Other firmwares may require different offsets.

from valetudo.

tested the py script and it shows me the nogo zones

from valetudo.

I don't see that it patches rrlogd so is the git branch up to date and do you have bspatch installed?

from valetudo.

Did you start a new cleanup? Since you were running an unpatched rrlogd it might be that the data it's trying to display is still encrypted.

The removed encryption only applies to new cleanups.

from valetudo.

The patched rrlogd is working. I've just tried a cleaning session and could retrieve the map after the finished session.
Thank you very much, JohnRev!

from valetudo.

Can we please not use this issue or any issue at all for basic tech support.

This is not a forum but rather a place to gather information and use said information to implement the feature mentioned in the title.

from valetudo.

Oh ffs.

from valetudo.

@Hypfer: This thread should probably be closed. As you pointed out, the conversation has gotten out of hand.
The new map format parsing is now well understood. The rrlogd patches (in gen1 or gen2) have already been documented. No changes are required in Valetudo itself. Maybe just update the README.md ?

There is another issue created for the newer features that come with the persistent maps #72

from valetudo.

Here's another update.

The encrypted rr.gz files go through this process:

1. A random key is obtained by reading /dev/urandom/
2. The key is encrypted with an RSA public key, using mbedtls_pk_encrypt
3. The encrypted key is stored in the file header (first 512 bytes)
4. The gzip-ed file is encrypted using AES ECB mbedtls_aes_crypt_ecb and appended to the .rr.gz file

This is presumably so that Xiaomi can later decrypt the key using their RSA private key, which will then enable them to decrypt the gzip archive.

Some possible workarounds:

1. Intercept the calls to /dev/urandom and redirect to a custom file. This way, we will always know what the "random" key is.
2. Replace the public key with one which we know the private key for
3. Disable encryption all together.

Options 2, and 3 would break the compatibility with the Xiaomi cloud servers, and so they are best used with dummycloud enabled. Option 1 could theoretically still work, but can be easily detected by Xiaomi.

I tried experimenting with Option 1 for a bit, but was unsuccessful. So I decided to just disable encryption, since I do not care about the Xiaomi cloud because my vacuum is not allowed to connect to the internet anyway. Turns out this is the simplest option.

I updated my gen2 vacuum to 001780 and patched rrlogd. The patched file is attached here.
Then, I updated the regex that I pointed out in an earlier comment: #40 (comment)
Valetudo now correctly shows the maps on v001780 when the vacuum is docked.

The patched rrlogd for v001780 is attached here. It should be copied to the vacuum and moved to /opt/rockrobo/rrlog/. Don't forget to give it execution permission, chmod +x /opt/rockrobo/rrlog/rrlogd
Note: it is probably wise to keep a copy of the original rrlogd file first: mv /opt/rockrobo/rrlog/rrlogd /opt/rockrobo/rrlog/rrlogd_.
Also note: that I did not test this on any other version, and it will probably not work and require different patch offsets.
Final note: You will need to either reboot your vacuum, or kill the running rrlogd process first so that the robot will re-spawn a process with the patched rrlogd.

Here are the hex patches used:

0001051C: 4B 47
00010746: FF E3
00010747: F7 20

rrlogd_patched_001780_gen2.zip

from valetudo.

@JohnRev can you patch a rrlog (of course i will privide it) for gen2? i would try this and see how the new persistant pams work out...by the way - what's the setting needed to enable the map storage feature?

from valetudo.

This is gen2. I should have clarified.
Not sure about the map storage. I was mainly focused on finding means for decrypting the rr.gz file :)

from valetudo.

gr8. i'll download 1780 and get myself to work. i guess we should e carefull and stop the automatic update mechanism - xiaomi will most probably close some doors and we might remain stuck with some default stuff...

from valetudo.

My vacuum has never connected to the internet, so I'm not too worried about the automatic updates.
If you do use the patched rrlogd file, it would probably be wise to use dummycloud too as I'm pretty sure the patched rrlogd breaks compatibility with the xiaomi cloud services.

from valetudo.

i was connected to the internet (i got the gadget exactly when it came on the market). now i am on dummycloud and ccrypt is removed (just an empty file). my firewall is also plugging all holes so i should be safe. have you tried to enable the map storage feature? and if yes how did you do it?

from valetudo.

No, sorry, I haven't looked into the map storage feature. Tho if you do figure out how to enable it, let me know!

from valetudo.

@JohnRev i updated the beast and used your patched rrlogd but i keep getting error 500 from the webserver...

from valetudo.

@leonardpitzu, you will have to compile Valetudo with the updated regex from #40 (comment)

from valetudo.

@JohnRev Already done that - I get the correct path to the files and I am trying correctly to open them. That’s where I got with the debugging. I user the rrlogd you provided. Added some more logging to figure out what’s wrong...

from valetudo.

Interesting. It works fine for me. How does your /mnt/data/rockrobo/rrlog/ folder look like?
If there are a bunch of subfolders there, i suggest you delete them and try again with a fresh sweep of the vacuum.
Then, after the vacuum is docked, there should be a new subfolder containing a bunch of .gz file. Can you confirm they are unencrypted gzip files?

from valetudo.

Oh, and did you reboot your vacuum to make sure it uses the patched rrlogd?
If you dont want to reboot, try killing the running rrlogd process (find process id with ps aux | grep rrlogd then kill -9 [pid]). The vacuum will respawn one with the patched rrlogd (assuming it is placed in the right path)

from valetudo.

@JohnRev How did you go about patching rrlogd?

from valetudo.

@JohnRev i've done some more debugging (i know linux quite well but i'm 250km away from the vacuum so debugging is a bit more tricky :) ). anyway here's what i found (again, using fw 1780 on gen 2, your patched rrlogd and a patched/modified version of valetudo):

• the webserver searches for the long folder names stored in /mnt/data/rockrobo/rrlog
• the webserver makes a list of folders and searches for maps (this time using the new regex from #40)
• if a folder and a mapfile and a logfile are found within the folder the map is being "reconstructed", that is the log is being decrypted.

and here it stops with the error:

digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

Previousely the log was being encrypted with the standard symmetric key which we all know. So the webserver was decryptiong it using the key, unpacking it and do the rest of it's thing.
From your description i figured you disabled the encryption all together so the webserver now failes to decrypt the data. Even more, when i download the encrypted logs locally and try to unpack them it fails - probably the magic number is wrong.

from valetudo.

@leonardpitzu :Just to confirm, did you make sure the running rrlogd process is the patched one? Simply replacing the file won't do it.
It sounds to me the gz files are still being generated by the unpatched rrlogd

from valetudo.

@JohnRev copied the patched rrlogd and rebooted the thing... i'm doing some more testing to see what's going on...

from valetudo.

Oh! I think I attached the wrong rrlogd. In the one you're using right now, the first 512 bytes are the encrypted key and the rest of the file is the (unencrypted) gzip. So if you do something like dd if="navmap702931.ppm.0001.rr.gz" of="navmap-unencrypted.gz" bs=1 skip=512 you should get the clean unencrypted gz.
I have updated my initial comment. If you don't mind, please use this rrlogd. It is the same one as I have on my vacuum right now.
md5sum is 93e8df884b4c6162ffa2a11161f47429
Send it to the vacuum, kill the running rrlogd process (or reboot), and try again.
rrlogd_patched_001780_gen2.zip

from valetudo.

@dugite-code: I disassembled rrlogd, looked for the function call that appends the encrypted key to the header, and disabled (NOP) that call. Then I looked for the call that stores the encrypted gz bytes to the file, and made them store the unencrypted buffer instead. The hex patches posted in my first comment do just that, and you can apply them to your unpatched rrlogd (of version 1780) to get the same patched rrlogd that I posted here.

from valetudo.

@JohnRev i looked at the attached rrlogd and it's not the patched one. I patched it and am testing it now. will report back

from valetudo.

Thanks! I am waiting. Sorry for attaching the wrong rrlogd initially ... I got my files mixed up 😄

from valetudo.

Awesome!! And thanks for being willing to testing it 😄

I discovered there's some 500 errors still showing up after some time, but these are strictly related to the code logic of how the /mnt/data/rockrobo/rrlog is scanned in FIND_LATEST_MAP_IN_ARCHIVE function. I will write about them in #40 .

Glad it's working, and hope this helps others too!

from valetudo.

@leonardpitzu, I have a question for you.
After rebooting the vacuum, does the robot forget the last map when performing a new sweep and generates a new one? Or does it trace correctly over the previously generated map?

from valetudo.

@JohnRev mine also has Alzheimer and generates a new map. This is a "feature" i would guess unless we figure out what the "save map" button actually does. If we can set the same flag, by hand, we can keep the map between reboots. I read somewhere that the setting is some new file in /mnt/data/rockrobo. The file has to contain the value 1 in order to enable the map storage feature. Yet i can't seem to find that post nowhere so i am stuck right now...

from valetudo.

I think I was able to get the saved map functionality to work. Would you be willing to test it?

1. Do a full sweep to generate the map to be saved
2. Install python-miio pip install python-miio, then execute the following (replacing with the correct variables, obviously).
3. Execute:

export MIROBO_IP=vacuum_ip
export MIROBO_TOKEN=vacuum_token_key

mirobo raw-command set_lab_status 1
mirobo raw-command save_map

4. Reboot the vacuum
5. Do a new sweep

from valetudo.

Indeed, the above commands seem to produce a file /mnt/data/rockrobo/lab.cfg with content 1.
Not sure if just creating that file (echo 1 > /mnt/data/rockrobo/lab.cfg) would suffice, but the above commands worked well for me, as far as I can tell.

from valetudo.

@JohnRev that was the config file + flag. I am not sure though how this should work... Between reboots the maps is lost but i still get to see the track/path of the vacuum (well, at least the last part of it as it's split as o lately on more pieces). I have a persistent gridmap in /dev/shm (around 1MB) but even witht the "preferGridMap":true i only get to see the path...

from valetudo.

Note sure I understand. Do you mean in Valetudo you see the path but without a map?

from valetudo.

yes

from valetudo.

Now that is something I haven't seen yet. It would be interesting to see which path file is being parsed by Valetudo.
Using which method did you enable the persist flag? Manually in lab.cfg, or with the mirobo set_lab_status and save_map commands?

from valetudo.

i used lab.cfg manual edit. valetudo is selecting the latest folder and searching for navmap and slam.

from valetudo.

Perhaps the mirobo raw-command save_map command was needed?
I just tried a reboot and my old map was still there, with the last path drawn.
I did a new sweep, and the robot "remembered" the last map and just started tracing over it

from valetudo.

Nice setup!

So now we have a way to use Valetudo on gen2 v001780 (with patched rrlogd) and a way to keep maps after reboot (with lab.cfg)!!

from valetudo.

So they are still using ppm maps?

How are virtual walls stored?

from valetudo.

Yes, ppm is still used.

I haven't been able to figure out where virtual walls are stored (yet), and I don't have the mi app to test it either (my vacuum isn't connected to the internet).

It would be helpful if someone who does use the mi app can provide some insight

from valetudo.

from valetudo.

Posted it there marcelrv/XiaomiRobotVacuumProtocol#15 (comment) with some additional info

from valetudo.

How are virtual walls stored?

@Hypfer : These are possibly stored in /mnt/data/rockrobo/user_map0 and/or /mnt/data/rockrobo/PersistData*.data.
Other interesting files: /dev/shm/PersistInfo , /dev/shm/SharedMapInfo

from valetudo.

@JohnRev after the scheduled reboot (every day my vacuum reboots on its own at 3:30am) the maps were not visible any more in valetudo - again only the last part of the track was visible. i removed dummycloud and checked with the official app - the map is saved correctly and all settings are as well correct. I made a full factory reset of the device and made a sweep. Maps were saved (persistent files were generated). After a reboot, boom, maps were gone again in valetudo. I am out of ideas...

from valetudo.

Hmm... I haven't faced this issue yet, and I have been rebooting my vacuum daily.
Are you getting error 500 in Valetudo? Maybe the issue is from what I described here: #40 (comment) ?

Also, would you be willing to try all the steps, including the mirobo commands, from my earlier comment (#44 (comment))? I think this was the only difference between what you have done and what I have.

from valetudo.

@leonardpitzu & @JohnRev Why do you reboot your device daily if I may ask?

from valetudo.

For some reason that I haven't been able to figure out yet, my vacuum loses connection to my wifi overnight (but otherwise remains functional), and so I must reboot it to get it connected to my router again

from valetudo.

@JohnRev done that. No change at all. What those commands do is identical to what the original app does. I've done the same settings with both and still the same behaviour. I also encounter #40 but i overcome it by removing the new folder. Still, the map is not visible from the "old" folder - only the track (see attached screenshots - one is valetudo, the other is the original app. both screencaps are after a manual reboot [sudo shutdown -r now]).
@herrwusel i'm not rebooting it - it does so on its own at 3:30 every morning. It's some sort of scheduled tasks. I would assume all vacuums do so but you don't see it because either you're not monitoring the network or you don't have startup/shutdown/reboot notifications as i do.

from valetudo.

@leonardpitzu Would you be willing to sharing the latest .rr.gz navmaps from the newest folder?

from valetudo.

@JohnRev here you go (there are also some new generated folder so you can have an idea what happens @reboot).
Archive.zip

from valetudo.

# gzip -d /000548.20181215162410931_R0018S81502125_2018101702REL/navmapfirst.ppm.log.rr.gz
gzip: navmapfirst.ppm.log.rr.gz: decompression OK, trailing garbage ignored

After reboot, your navmapfirst.ppm is empty (or corrupt?), and that is why the map is blank and Valetudo can't display it.
The official app probably pulls the map from the Mi cloud, and that's why it's displayed (just a guess)

I don't know why your navmapfirst.ppm.log.rr.gz is like that ... My guess is the "saved" persistent map is incorrect, or incomplete somehow? Maybe re-save a new one with the mi app?
Btw, is there a file /mnt/data/rockrobo/user_map0 on your vacuum? What's it size?

from valetudo.

@JohnRev user_map0 is 198k. i'll try a fsck... the map is resaved. i made a new one this morning, rebooted and valetudo is what you see it above...

from valetudo.

@JohnRev another idea - if i delete all folders would it bring something? what else do i need to refresh to make everything "like new"? factory reset brings nothing - i've done it and everything is still there.
Edit: watchdog log - pSharedRegionCreate,85: Failed to create shared memory region '/PersistInfo'

from valetudo.

I have once deleted all the folders inside the rrlog folder to refresh things after a factory reset. You could try that, but I'm not sure it's related.

from valetudo.

@JohnRev at what level have you set the logging? Is upload still enabled? are the other scripts still running or do you have them exit as soon as they are called?
i made a full recovery - press power+plug+wifi reset. i just want to have "the same" setup as you do so we can exclude errors

from valetudo.

I don't recall messing with the logging levels and the scripts (they don't exit). I do have tje xiaomi servers in the hosts file and the iptables rules in rc.local (from dummycloud setup). Upload is enabled, but the vacuum can't connect to the internet to do the upload.

from valetudo.

@JohnRev a full wipe and many hours later i got the damn thing to have consistent logs - the rr.gz are extractable and have no errors. still they are empty and the map is as well empty - i only see the path of the vacuum as in the screenshot above. again i am out of ideas...

from valetudo.

I think that there might be no "new map format" 🤔
Maybe the virtual walls are stored the same way as zones are stored.

from valetudo.

Any idea how zones are stored?

from valetudo.

marcelrv/XiaomiRobotVacuumProtocol#15 (comment)

I guess you can fetch them with a miio command? Or is that write only?

from valetudo.

FYI: The latest 0.9 valetudo release works with v001780 and a patched rrlogd quite fine.

I wonder how the persistent map feature really works. Normally I guess you want to store a complete map of your rooms as persistent and be able to load it. The robot might do a run and might not able to enter a room because the door is closed, however you still want a map with all rooms mapped so you can send the robot for a zoned clean up.

You can activate the persistent map feature doing the following:

echo -n 1 > /mnt/data/rockrobo/lab.cfg

Time for more investigation.

from valetudo.

I've patched v001792.

radiff2 rrlogd.v001792 rrlogd.v001792.patched 
0x000105a8 4b => 47 0x000105a8
0x000107d2 fff7 => e320 0x000107d2

radiff2 -a arm -D rrlogd.v001792 rrlogd.v001792.patched 
(locked: no new keys can be created (anal.split))
--- 0x000105a8  4b
- add r0, sp, 0x12c
- movs r2, 0x10
+++ 0x000105a8  47
+ add r0, sp, 0x11c
+ movs r2, 0x10

--- 0x000107d2  fff7
- bl 4294966930
+++ 0x000107d2  e320
+ movs r0, 0xe3
+ invalid

Here is support for patching rrlogd directly when building the image (uses bsdiff/bspatch)

https://github.com/cryptomilk/dustcloud/tree/master-imgbuild-rrlogd

from valetudo.

Do you know what else is stored in this file?

from valetudo.

There's at least 1 more thing stored in there, but I am not sure what it is

from valetudo.

Timers maybe?

from valetudo.

@JohnRev did you look into libNavDriver.so for that?

from valetudo.

I just updated to 1780 and still get 500 errors with valetudo 0.9. Is it just me?

from valetudo.

Did you patch rrlogd?

from valetudo.

I did when building the firmware but will try again today. Maybe I did something wrong there.

from valetudo.

./imagebuilder.sh --patch-rrlogd then check the log that it has been patched. My latest changes to the image builder script allow to already add valetudo to the flashable firmware image.

from valetudo.

Here is what I did:

sudo ./dustcloud/devices/xiaomi.vacuum/firmwarebuilder/imagebuilder.sh -k id_ed25519.pub -f v11_001780.pkg --disable-xiaomi --patch-rrlogd
Scriptpath: ./dustcloud/devices/xiaomi.vacuum/firmwarebuilder
.../dc/imagebuilder.sh
compatible readlink found!
Generate SSH Host Keys if necessary
decrypt soundfile
ccrypt: .../dc/english.pkg: Kennwort passt nicht -- unverändert
unpack soundfile
decrypt firmware
ccrypt: .../dc/v11_001780.pkg: Kennwort passt nicht -- unverändert
unpack firmware
patch ssh host keys
disable SSH firewall rule
integrate SSH authorized_keys
reconfiguring network traffic to xiaomi
pack new firmware
encrypt firmware
2ef9c67f1a7d9b6a9ea292837e4bbf2a  output/v11_001780.pkg

I don't read anything from the rrlogd patch.

from valetudo.

I was missing the bsdiff package. I got this now:

./dustcloud/devices/xiaomi.vacuum/firmwarebuilder/imagebuilder.sh -k id_ed25519.pub -f v11_001780.pkg --disable-xiaomi --patch-rrlogd
Scriptpath: ./dustcloud/devices/xiaomi.vacuum/firmwarebuilder
.../dc/imagebuilder.sh
compatible readlink found!
Generate SSH Host Keys if necessary
decrypt soundfile
ccrypt: .../dc/english.pkg: Kennwort passt nicht -- unverändert
unpack soundfile
decrypt firmware
ccrypt: .../dc/v11_001780.pkg: Kennwort passt nicht -- unverändert
unpack firmware
patch ssh host keys
disable SSH firewall rule
integrate SSH authorized_keys
reconfiguring network traffic to xiaomi
checking if we can patch rrlogd
pack new firmware
encrypt firmware
bce3c1cdf5fdd16f14b0209636a8538e  output/v11_001780.pkg

After pushing the firmware to to vacuum I still get the error 500. How do you add valetudo while building?

from valetudo.

In addition to what @Hypfer pointed out, it seems that your rrlogd patch didn't work?
In the log you pasted, I can only see checking if we can patch rrlogd, but no follow-up .. it should be followed by creating backup of rrlogd and patching rrlogd.
On your vacuum, can you do md5sum /opt/rockrobo/rrlog/rrlogd, if it is not 93e8df884b4c6162ffa2a11161f47429, then it is not the patched rrlogd for gen2 v1780.
You can replace it manually with this one https://github.com/Hypfer/Valetudo/files/2670885/rrlogd_patched_001780_gen2.zip and kill the running rrlogd process (or reboot the vacuum).
See earlier posts for more details.

from valetudo.

Pushing the patched rrlogd manually did the trick - thanks @JohnRev and @Hypfer. Still dont know why the image wasnt build correctly.

from valetudo.

Other things stored in PersistData_1.data include: "Goto Routing", "Clean Routing" ( paths/routes?), "Dock position", "Robot position". Haven't had time to update my code for parsing them ... might do that if I get some free time :)

from valetudo.

I don't know if this belongs here, but I also get a 500 error when charging. When roborock (gen1, version 3514 rooted) is running, map is generated just fine.
When charging the roborock/api/map/latest shows: Error: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

So does mine also need a patched rrlogd?

from valetudo.

I'm having the same problem as Fietspomp86, during cleaning the generated map can be viewed without any difficulties, as soon as the robo has finished cleaning, the map vanishes and the above html error 500 or with "../latest" error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt) is displayed.

from valetudo.

It is possible that on the gen1 firmware version, rrlogd has a new encryption method. However someone needs to reverse engineer it to see what actually is going on.

from valetudo.

@Fietspomp86 rrlogd for gen1 will need to be patched too, but none have been published yet. @ralf-ms are you also using gen1 with 3514 firmware?

from valetudo.

yes, correct: gen1 / 3514

from valetudo.

Ok allright, what do I need to do then? I'm fairly ok with linux so I can try to patch it with some instructions.

from valetudo.

Try the attached rrlogd, if you want. I haven't tested it myself as I don't have a gen1 vacuum.

gen1_v11_003514_rrlogd_patch.zip

from valetudo.

Ok, I've copied the rrlogd and rebooted. Apparently that removed Valetudo which is strange. Installed Valetudo again and started vacuum to test. Now it's turning off and on every 10 seconds.
And right now it's speaking Chinese to me.... So for me it's not working yet....

EDIT: Strange enough it has resetted itself to old firmware I guess, speaking Chinese and disconnected from WiFi.

from valetudo.

I am guessing the "patched" rrlogd failed and ended up crashing the robot, which then went into recovery mode... maybe?
Sorry about that. As I said, I don't have the gen1 to test, and I just tried applying the same patches that I made for gen2 onto the gen1 rrlogd (while adjusting the offsets accordingly).
I may look at this more if I get some time

from valetudo.

After transfering the rrlogd to the robot, did you make sure you gave it execution permissions?
chmod +x /opt/rockrobo/rrlog/rrlogd

from valetudo.

No problem!
I will try to post an "auto patcher" script that would patch rrlogd on any firmware/generation.

from valetudo.

After transfering the rrlogd to the robot, did you make sure you gave it execution permissions?
chmod +x /opt/rockrobo/rrlog/rrlogd

Quite possible I forgot that.... I'll retry it when it's back online.

from valetudo.