Open neurological opened 3 years ago
same bug existed on other build version, same fix should work as well?
It definitely isn't same since you have an error code -10000 and there it was -10005.
Also the code for set_lab_status
here currently is almost identical to what was used as a fix there.
Please see whether the logs (Settings -> Info) have some more information on what that error code could mean, though I'm pretty sure that "invalid type" is all the firmware decided to tell us unfortunately.
Here's the full log pasted after a reboot and trying to re enable lab mode again
2021-02-23T18:31:27.462Z tgBot polling: Error: ESOCKETTIMEDOUT
2021-02-23T18:31:26.609Z Timesync packet received
2021-02-23T18:31:07.653Z Timesync packet received
2021-02-23T18:31:07.310Z tgBot polling: Error: getaddrinfo EAI_AGAIN api.telegram.org
2021-02-23T18:31:02.239Z tgBot polling: Error: ESOCKETTIMEDOUT
2021-02-23T18:30:49.490Z Timesync packet received
2021-02-23T18:30:36.116Z tgBot: probeV6 finished with: v4
2021-02-23T18:30:32.311Z Timesync packet received
2021-02-23T18:30:32.306Z Robot connected
2021-02-23T18:30:26.751Z Probed last id = 1001 using get_status (3 retries)
2021-02-23T18:30:25.730Z Webserver is running on port 80 (http)
2021-02-23T18:30:25.726Z Dummycloud is spoofing 203.0.113.1:8053 on 127.0.0.1:8053
2021-02-23T18:30:25.656Z No ssl key found. Expected path: /mnt/data/valetudo/key.pem
2021-02-23T18:30:25.655Z No ssl cert found. Expected path: /mnt/data/valetudo/cert.pem
}
cmd: '/usr/sbin/ntpd -n -q -p pool.ntp.org'
signal: null,
code: 127,
killed: false,
at Pipe.
/bin/sh: 1: /usr/sbin/ntpd: not found 2021-02-23T18:30:25.503Z ntpd exec error: Error: Command failed: /usr/sbin/ntpd -n -q -p pool.ntp.org 2021-02-23T18:30:25.389Z Loading configuration file: /mnt/data/valetudo/config.json Waiting for 30 sec after boot... done. 2021-02-23T18:22:22.594Z Timesync packet received 2021-02-23T17:52:22.594Z Timesync packet received 2021-02-23T17:22:22.594Z Timesync packet received 2021-02-23T16:52:22.594Z Timesync packet received 2021-02-23T16:22:22.594Z Timesync packet received 2021-02-23T15:52:22.594Z Timesync packet received 2021-02-23T15:22:22.594Z Timesync packet received 2021-02-23T14:52:22.594Z Timesync packet received 2021-02-23T14:22:22.594Z Timesync packet received 2021-02-23T13:52:22.594Z Timesync packet received 2021-02-23T13:22:22.594Z Timesync packet received 2021-02-23T12:52:22.594Z Timesync packet received 2021-02-23T12:32:08.333Z tgBot polling: Error: connect EHOSTUNREACH 149.154.167.220:443 2021-02-23T12:22:22.593Z Timesync packet received 2021-02-23T11:52:22.594Z Timesync packet received 2021-02-23T11:22:22.594Z Timesync packet received 2021-02-23T10:52:22.594Z Timesync packet received 2021-02-23T10:22:22.594Z Timesync packet received 2021-02-23T09:52:22.594Z Timesync packet received 2021-02-23T09:22:22.594Z Timesync packet received
I've also tried to save settings by hitting 'erase map' instead of save, resulting in the same error, but different message.
Well, as we know from the issue you've linked firmware version 1708 requires specific argument to set_lab_status
command, that is different from what was used in older gen2 devices. I guess maybe your device has firmware version lower than 1708, so it doesn't like the new formatting and wants the older one?
You're right, my robot is on firmware version 1558. Ill investigate on updating the firmware
Here's a probably dumb question, would simply updating the firmware trough the normal roborock app remove any rooting / ssh access, or is it just a matter of reinstalling valetudo after?
As far as I know, if you try to install stock update, you'll definitely loose your root access. For newer robots including S6 you need to flash some prepared image via dd or some other tool that directly writes to block device. Idk the details as I have the only S5.
Cool, I'll investigate, thanks for the help!
This same failure occurs with firmware 0358 (the latest from https://builder.dontvacuum.me/_s4.html) on the S4, running Valetudo from latest master
. As suggested, it is indeed an issue with the vacuums expecting an older command, as changing RoborockS4ValetudoRobot.js:22
to contain RoborockPersistentMapControlCapability
fixes the issue for me.
Describe the bug
Attempting to turn on 'lab mode' on roborock S6 results in error when trying to save. As such all associated functions of lab mode such as persistent maps are all inaccessible.
How to Reproduce
Steps to reproduce the behavior:
Expected behavior
Lab mode enabling properly without errors
Vacuum Model: roborock S6
Valetudo Version: 0.10.4
User-Agent brave browser
Additional context same bug existed on other build version, same fix should work as well? https://github.com/Hypfer/Valetudo/issues/540