check if the config.json is really reset - I don’t think so since you still get MQTT messages and connect to the server
Fun fact however: roborock restarts every day at around 3:30 to 4am and if it encounters errors on boot, a counter is being increased - if the counter is high enough, it resets its firmware
When I go to the robot IP the map works very fine. I see everything, I can draw zones and move to commands. Everything works.
This is what boot.log on my robot shows:
* Starting Mount filesystems on boote[74G[ OK ]
* Starting Signal sysvinit that the rootfs is mountede[74G[ OK ]
* Starting Populate /dev filesysteme[74G[ OK ]
* Stopping Populate /dev filesysteme[74G[ OK ]
* Starting Clean /tmp directorye[74G[ OK ]
* Stopping Clean /tmp directorye[74G[ OK ]
* Starting Populate and link to /run filesysteme[74G[ OK ]
* Stopping Populate and link to /run filesysteme[74G[ OK ]
* Stopping Track if upstart is running in a containere[74G[ OK ]
* Starting Initialize or finalize resolvconfe[74G[ OK ]
* Starting set console keymape[74G[ OK ]
* Starting Signal sysvinit that virtual filesystems are mountede[74G[ OK ]
* Starting Signal sysvinit that virtual filesystems are mountede[74G[ OK ]
* Stopping set console keymape[74G[ OK ]
* Starting Bridge udev events into upstarte[74G[ OK ]
* Starting Signal sysvinit that remote filesystems are mountede[74G[ OK ]
* Starting device node and kernel event managere[74G[ OK ]
* Starting load modules from /etc/modulese[74G[ OK ]
* Starting cold plug devicese[74G[ OK ]
* Starting rockrobo play bootring servicee[74G[ OK ]
* Starting log initial device creatione[74G[ OK ]
* Stopping rockrobo play bootring servicee[74G[ OK ]
* Starting configure network device securitye[74G[ OK ]
* Stopping load modules from /etc/modulese[74G[ OK ]
* Starting Mount network filesystemse[74G[ OK ]
* Stopping cold plug devicese[74G[ OK ]
* Starting set console fonte[74G[ OK ]
* Stopping log initial device creatione[74G[ OK ]
* Stopping set console fonte[74G[ OK ]
* Starting userspace bootsplashe[74G[ OK ]
* Stopping userspace bootsplashe[74G[ OK ]
* Starting Send an event to indicate plymouth is upe[74G[ OK ]
* Stopping Read required files in advance (for other mountpoints)e[74G[ OK ]
* Stopping Send an event to indicate plymouth is upe[74G[ OK ]
* Starting configure network devicee[74G[ OK ]
* Stopping Mount network filesystemse[74G[ OK ]
* Starting Signal sysvinit that local filesystems are mountede[74G[ OK ]
* Starting configure network device securitye[74G[ OK ]
* Starting flush early job output to logse[74G[ OK ]
* Starting adb daemone[74G[ OK ]
* Stopping Failsafe Boot Delaye[74G[ OK ]
* Starting System V initialisation compatibilitye[74G[ OK ]
* Stopping flush early job output to logse[74G[ OK ]
* Starting configure virtual network devicese[74G[ OK ]
* Stopping System V initialisation compatibilitye[74G[ OK ]
* Starting system logging daemone[74G[ OK ]
* Starting System V runlevel compatibilitye[74G[ OK ]
* Starting logrotate 5s check daemone[74G[ OK ]
* Starting save kernel messagese[74G[ OK ]
* Starting OpenSSH servere[74G[ OK ]
dnsmasq: unknown interface wlan0
* Starting regular background program processing daemone[74G[ OK ]
* Stopping save kernel messagese[74G[ OK ]
* Starting DNS forwarder and DHCP server dnsmasq e[80G
e[74G[e[31mfaile[39;49m]
* Starting rrwatchdoge daemone[74G[ OK ]
* Starting Bridge file events into upstarte[74G[ OK ]
* Stopping System V runlevel compatibilitye[74G[ OK ]
As you suggest, the config.json is not reset. I just checked, my zones and all mqtt settings are perfectly in place.
Funfact: is this a valetudo or a xiaomi setting? Actually I don’t think it has a booting problem. I can reboot the robot via ssh without any problems anytime. Comes right back up after a minute or so.
EDIT:
you said to put into configuration.yaml the following:
state_topic: "valetudo/roborock/map_data"
but the official guide says
state_topic: "valetudo/rockrobo/state"
Is this important?
this used to give me troubles before, but is unrelated to the issue at hand, you can fix it by changing the line in /etc/dnsmasq.conf from bind-interfaces to bind-dynamic
The fun fact is a xiaomi thing, nothing valetudo can do about it
I am still wondering if you have valetudo RE installed and it just does not show you in the version that it is RE?
reading up on this, it seems this was a firmware reset which got you back to valetudo, so you should be fine
Here is another topic on github that had the same issue as you - you might try RRCC from the previous post and install valetudo from there (save the config.json first)
no, this was a copy paste error on my side
OK new evening new try.
what you said earlier, that you think there is still valetudo RE installed but the interface just showed me a different version induced me to reinstall valetudo again.
I copied the .deb file from here to my vacuum using filezilla, logged into the robot via ssh and installed it with dpkg -i filename.deb. Now the IP of my vacuum shows the following software information:
this used to give me troubles before, but is unrelated to the issue at hand, you can fix it by changing the line in /etc/dnsmasq.conf from
bind-interfacestobind-dynamic
I fixed this, just to be sure. Thanks for the hint.
Now, robot is running fine, my config.json on my valetudo re enabled robot looks like this:
"mqtt": {
"enabled": true,
"identifier": "tachikoma",
"topicPrefix": "valetudo",
"autoconfPrefix": "homeassistant",
"broker_url": "mqtt://192.168.188.45",
"provideMapData": true,
"mapSettings": {
"drawPath": true,
"drawCharger": true,
"drawRobot": true,
"border": 2,
"scale": 4
},
"caPath": ""
},
"dummycloud": {
"spoofedIP": "203.0.113.1",
"bindIP": "127.0.0.1"
},
"webInterface": {
"localization": "en",
"hideMapReload": true,
"style": ""
},
"httpAuth": {
"enabled": false,
"username": "valetudo",
"password": "valetudo"
},
"telegramBot": {
"enabled": false,
"token": "",
"password": "",
"host": "",
"proxy": "",
"clients": [],
"sendConsumables": true,
"sendConsumablesEvery": false
},
"allowSSHKeyUpload": true,
"map_upload_host": "http://127.0.0.1"
}
If I listen to mqtt topic valetudo/# in home assistant I can see:
Message 8 received on valetudo/tachikoma/attributes at 8:21 PM:
{
"cleanTime": "169.5",
"cleanArea": "8805.5",
"cleanCount": 501,
"last_run_stats": {
"startTime": 1582372097000,
"endTime": 1582373128000,
"duration": 968,
"area": "15.0",
"errorCode": 0,
"errorDescription": "No error",
"finishedFlag": true
},
"currentCleanTime": "16.1",
"currentCleanArea": "15.0",
"mainBrush": "130.5",
"sideBrush": "30.5",
"filter": "144.2",
"sensor": "27.7",
"state": "docked",
"valetudo_state": {
"id": 8,
"name": "Charging"
}
}
No map data shows up. Don’t know where to go from here?
The link you provided suggest I should reinstall valetudo again from scratch right? Don’t know if I am in for that honestly…
Since you are now on valetudo RE, the best choice is now to go for valetudo-mapper 
I have never tried it, but from my understanding:
If you are running home assistant (formerly known hassio), there should be an add-on
If you are running home assistant core (formerly known home assistant) in a docker then use the dockerfile and map the config
Or simply just run it with npm start as described
My only guess at this point is (and it is really just a guess), that you had a firmware reset from valetudo RE to valetudo 0.4.0 but some files from RE were still there.
That’s why I love RRCC, once it is rooted and you have your ssh pair, you can connect to it with a nice gui and 1 click install valetudo. Saved me a ton of work when the robot had its firmware reset before.
But then again, I have never tried valetudo RE and do not know if you can simply override it. I’d give the mapper a try first, does not seem too difficult
You are absolutely right. I used RRCC after I retrieved the token to install valetudo in the first place. It was almost plug’n’play, very nice.
I just managed to get valetudo-mapper running on my laptop but this was more of a test. Where did you find this add-on for HA? Searched everywhere did not find it. And when I just want to create it as a docker container I cant seem to figure out how to bind mount /data/config.json as mentioned in the instructions. Because this is a file it always tells me config.json is a directory…
I don’t use home assistant (formerly hassio), so I am not sure how addons are integrated, I kinda just know they are there and when doing some research I found repositories like:
this one or this one
Are you using docker-compose or docker? Can you share your commands?
You might have used a trailing “/”
I just tried it myself, the log looks fine for me
commandline:
Creating valetudo-mapper-master_mapper ... done
Attaching to valetudo-mapper-master_mapper
mapper |
mapper | > [email protected] start /app
mapper | > node app.js
mapper |
mapper | Loading configuration file: /app/config.json
mapper | Connecting to MQTT Broker
container log (from portainer):
[email protected] start /app
node app.js
Loading configuration file: /app/config.json
Connecting to MQTT Broker
This is the docker-compose I was using:
version: '3'
services:
mapper:
build: .
ports:
- "3000:3000"
volumes:
- $dockerdir/valetudo-mapper-master/config.json:/app/config.json
I got it up and running, but since I do not have valetudo RE i could not test it working
Again, many thanks for your reply.
I got it working!!! 
A little sum up for everyone who has similar difficulties getting a live map into HA:
dpkg -i filename.deb. Other installation methods can be found here but again, I guess this is the easiest one.mqtt:
broker: IP_of_machine_mosquitto_is_running_on
to your config.yaml. For me this was the very same my whole Home Assistant is running on.
"mqtt": {
"enabled": true,
"identifier": "tachikoma",
"topicPrefix": "valetudo",
"autoconfPrefix": "homeassistant",
"broker_url": "mqtt://HA-username:password@MosquittobrookerIPAdress",
"provideMapData": true,
"mapSettings": {
"drawPath": true,
"drawCharger": true,
"drawRobot": true,
"border": 2,
"scale": 4
},
"caPath": ""
},
"dummycloud": {
"spoofedIP": "203.0.113.1",
"bindIP": "127.0.0.1"
},
"webInterface": {
"localization": "en",
"hideMapReload": true,
"style": ""
},
"httpAuth": {
"enabled": false,
"username": "valetudo",
"password": "valetudo"
},
"telegramBot": {
"enabled": false,
"token": "",
"password": "",
"host": "",
"proxy": "",
"clients": [],
"sendConsumables": true,
"sendConsumablesEvery": false
},
"allowSSHKeyUpload": true,
"map_upload_host": "http://127.0.0.1"
}
docker run -d -v /path/to/your/config.json:/app/config.json roflcoopter/valetudo-mapper
This is my config.json:
{
"mqtt" : {
"identifier": "tachikoma",
"topicPrefix": "valetudo",
"autoconfPrefix": "homeassistant",
"broker_url": "mqtt://HA-username:password@MosquittobrookerIPAdress:1884",
"caPath": "",
"mapSettings": {
"drawPath": true,
"drawCharger": true,
"drawRobot": true,
"drawForbiddenZones": true,
"drawVirtualWalls": true,
"border": 2,
"scale": 4,
"gradientBackground": true,
"crop_x1": 30,
"crop_y1": 70,
"crop_x2": 440,
"crop_y2": 440
},
"mapDataTopic": "valetudo/tachikoma/map_data",
"minMillisecondsBetweenMapUpdates": 10000,
"publishMapImage": true,
"publishMapData": true
},
"webserver": {
"enabled": true,
"port": 3000
}
}
Note that you should use the same identifier, “Tachikoma” or the name of your vacuum so that valetudo-mapper knows where to catch the data from. The broker url should be your mosquitto service in home assistant as the mapper will send the created image to this destination.
Edit: Running a docker container separately from HA proved to be unstable for me. It crashed several times. So I followed @komadori1 's advice and added this repository and installed valetudo-mapper as add-on in home assistant. Now everything runs smooth as butter 
sensor:
- platform: mqtt
state_topic: "valetudo/tachikoma/state"
json_attributes_topic: "valetudo/tachikoma/map_data_parsed"
name: tachikoma_map
value_template: 'OK'
scan_interval: 5
recorder:
exclude:
entities:
- sensor.tachikoma_map
Restart home assistant and add the valetudo-map-card for lovelace from HACS to any home screen with this code
type: 'custom:valetudo-map-card'
entity: sensor.tachikoma_map
crop:
bottom: 0
left: 0
right: 0
top: 0
icon_scale: 1
map_scale: 1
min_height: 0
rotate: 0
show_dock: true
show_path: true
show_vacuum: true
Hopefully you see the same result as me:
the problem is solved
Glad this all worked out in the end now
Maybe you could change the title to focus on valetudo RE and mapper and mark the summary of yours as a solution for others to find it more easily
I will do that. I will add my configuration for zoned cleanup and notifications later on. Maybe someone can use that. Googleing around I found many different configuations, some are heavily outdated and I had to use some trial and error to get that working.
I have a second vacuum, its the Xiaomi vacuum 1s, do you know how to get live map from there? From my research I found neither dustcloud nor valetudo is available for this device.
Thank you so much, I have been using the hassio supervisor for a long time with this, but I recently started to migrate everything to docker on Unraid and this one I couldn’t figure out. Your tutorial on this made it work for me again! Thank you so much!
@EdwardEnglish your post above got this working for me beautifully. THANK YOU!
Now I want to have a 2nd vac and map… Not sure yet if that will require a 2nd container running a second instance of valetudo-mapper.
@jimz011 Did you ever figure out getting this container to work in unRaid?
Glad this could help.
I have a second vacuum but it’s an s1 and valetudo does not support it.
Maybe you should ask the guys from valetudo-mapper how it would work with two devices or find something to start the mapper again.
If you don’t come up with anything I did manage to run valetudo-mapper in plain docker apart from Home Assistant. Your second valetudo-map-card would then interpret that external data. Could be one solution.
Im using custom:vacuum-card with valetudo RE. All working fine except for zone cleaning script. I was able to get coordinates from Valetudo RE custom zones I made, but when I call app_zoned_clean it goes to another place…
How are you using zone cleaning from HA?
Just made it
clean_all:
alias: Vacuum Home
sequence:
- service: vacuum.send_command
data:
entity_id: vacuum.rockrobo
command: 'zoned_cleanup'
params:
'zone_ids':
- home
Did this fix it? I have the same issue and have not been using it in zoned mode for a while now.
Zoned cleaning from valetudo web interface works but using the same coordinates in home assistant does not. It goes somewhere else or can’t reach the zone at all