Mein Roborock S50 hat sich gestern selbst zurückgeflasht.

[einbi]

Hallo
Jetzt entwickelt mein Robi ein eigenleben.
Habe meinen Robi gerootet und die 1792 Fimrware mit 0.9 Valetudo drauf.
Habe gestern Spätschicht gehabt, heute früh sagt meine Frau dass gestern um ca 22:00 Uhr der robi gesprochen hat.
Heute früh möchte ich mit RRcc und mit dem Webinterface darauf zugreifen , geht aber nicht und der robi sricht jetzt wieder Englisch statt deutsch.
Habe den Robi jetzt nochmal mit dem Xiaomi Server Verbunden.Also IP Tabels auch futsch. Sehe mir die Firmware an , es ist wieder das Backup vom robi selbst das 1702.
Robi war ständig an der Ladestation.
;(

Der macht mich noch verückt der Kerl.
Hat jemand auch so ein seltsames Verhalten?

Gruß
einbi

 

[Mansen]

vllt hat das haustier ja die tasten für den resett gedrückt von selber sollte er das nicht machen

 

[einbi]

hallo
Habe kein Haustier, der Pumuckl vielicht

 

[Mansen]

hallo
Habe kein Haustier, der Pumuckl vielicht

oder die Frau hat dran rum gedrückt und gibts nicht zu

 

[einbi]

Kann sein, man kann ja nie wissen!

 

[Henne78]

Die müsste dann aber mit dem Kugelschreiber am Resetknopf herum gepopelt haben. Das wäre schon höchst merkwürdig.

 

[MicroDevil]

Hab zwar schon in einen anderen Thread auch reingeschrieben, aber vlt. meldet sich hier ja Jemand mit einer guten Idee.
Auch ich bin davon betroffen (GEN 1). Seitdem gehen auch keine Timer mehr, egal was ich mache.
Hab schon mehrfach factroy reset gemacht und neu geflascht.
Bin ziemlich ratlos.

 

[MicroDevil]

GELÖST!!


Nach nun den 4. Mal neu flashen ist mir aufgefallen, dass in der Ausgabe von date [kbd]Fri Feb 15 18:43:20 SGT 2019[/kbd]steht, was Singapur heißt.
Das machte mich stutzig, denn ich habe eigentlich eine EU Version gehabt, wieso also Singapur. Der Blick in /mnt/default/roborock.conf zeigte aber, dass der Scheißer irgendwie auf Timezone Singapur steht und deshalb rumspinnt

GEN1: Vacuum Robots CCC to CE conversion · dgiese/dustcloud Wiki
GEN2: dustcloud/devices/xiaomi.vacuum.gen2/CN_to_EU_script at master · dgiese/dustcloud

Habe dann gemäß den Links oben auf EU gestellt, Reboot und siehe da....Timer gehen wieder

Das Problem mit WLAN-Verlust und teils Sekunden langer Aussetzer war anscheinend ein spinnender Prozess von dummycloud. der mio client schmiert dann ab und der Robi spinnt.
Das könnte auch der Grund sein, dass er sich resetet hat um wieder Verbindung herzustellen.

Check if dummycloud is correctly set up​

Assuming you are logged into your robot, we can check if the dummycloud is correctly set up.First, we need to examine if the dummycloud executable is running via

pgrep dummycloud

The result should be a process id number, e.g. 397.Next, we have to check the firewall rules, the port 8053 needs to be redirected to127.0.0.1, so that the robot is communicating with the dummycloud.Execute

iptables -t nat -L

The result should contain the following:

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         DNAT       udp  --  anywhere             ot.io.mi.com         udp dpt:8053 to:127.0.0.1:8053

Furthermore, one can verify if the dummycloud is working directly on the robot. If the WiFi LED is constantly on (~30 s after startup), everything is working as expected.



MANN MANN MANN!!

 

[Henne78]

Sehr schön. Danke für deine ausführliche Rückmeldung und toll, dass du die Lösung selbst erwirken konntest.

 

[Jogile]

Hallo Einbi,

bei mir hat sich der Roborock S50 in der Nacht vom 21. auf den 22.02.19 einfach zurückgesetzt. Es war definitiv niemand da, der ihn reseted hat. Ich hatte die Firmware 1780 und Valetudo 0.9 installiert. Das ganze lief so ca. 1 Monat problemlos, bis eben zum 21.02.19.

Ich kann mir das Verhalten bis jetzt noch nicht erklären, ich hatte jedenfalls die richtige Zeitzone eingestellt.

Seit 25.02.19 habe ich nun die Firmware 1792 und Valetudo Beta 0.2.0 am Laufen. Bis heute habe ich keine Probleme, bis das Valetudo sehr häufig die Map vergisst. Ist mir aber nicht so wichtig, da ich Zonen definiert habe.

Falls das Problem wieder auftritt, dass sich der Roborock wieder einfach zurücksetzt, werde ich hier davon berichten.

 

[stauber]

Hallo zusammen,
gestern hat sich mein 1 Wochen alter, gerooteter S50 anscheinend auch zurückgesetzt. Ich war nicht im Raum aber meine Frau meinte er sagte etwas von "5 minutes" und "initializing"
Jetzt meldet er sich wieder mit dem unverschlüsselten Standard WLAN und per 192.168.8.1 ist auch kein Valetudo mehr erreichbar... Ich vermute er hat jetzt wieder die Standard Firmware, nur woher? Das Internet habe ich dem S50 über die FritzBox gesperrt.
Gibt es hier schon neue Erkenntnisse wie sowas passiert?

 

[Henne78]

Die Ur-Firmware wird doch auf dem Roboter selbst bereit gehalten. Ist der Speicher voll gelaufen?

 

[stauber]

Das kann ich jetzt leider nicht mehr herausfinden Ich werde ihn nochmal flashen und den speicher beobachten.

 

[Henne78]

Wie sieht es denn aktuell aus? Läuft er wieder normal ohne weiteres autonomes Zurücksetzen?

 

[Jogile]

Ich wollte euch mal auf den neuesten Stand bringen.

Seit dem 25.02.19 bis heute (26.03.19) läuft der Roborock S50 ohne Reset mit Firmware 1792.

Was ich seitdem angepasst habe:
Auch ich habe (wie Stauber) dem Roborock über meine Fritzbox den Zugang zum Internet verweigert. Um aber sicher zu gehen, habe ich im Roborock meine /etc/rc.local wie folgt angepasst (die fett markierten Zeilen sind hinzugekommen):

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.


# Add this before the "exit 0" command to /etc/rc.local on the robot

iptables -F OUTPUT
ip6tables -F OUTPUT
iptables -t nat -F OUTPUT
iptables -t nat -A OUTPUT -p tcp --dport 80 -d 203.0.113.1 -j DNAT --to-destination 127.0.0.1:8053
iptables -t nat -A OUTPUT -p udp --dport 8053 -d 203.0.113.1 -j DNAT --to-destination 127.0.0.1:8053
iptables -A OUTPUT -d 203.0.113.1/32 -j REJECT
ip6tables -A OUTPUT -d 2001:db8::1/128 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -j DROP

exit 0




Nur für den Fall, dass es mal wieder zum RESET kommen sollte, habe ich auch die Orginal Firmware bei mir ebenfalls wie folgt gepatcht:

mkdir /mnt/recovery
mount /dev/mmcblk0p7 /mnt/recovery
mkdir /mnt/recovery/root/.ssh
chmod 700 /mnt/recovery/root/.ssh
cp /root/.ssh/authorized_keys /mnt/recovery/root/.ssh/authorized_keys
chmod 600 /mnt/recovery/root/.ssh/authorized_keys
sed -e '/ iptables -I INPUT -j DROP -p tcp --dport 22/s/^/#/g' -i /mnt/recovery/opt/rockrobo/watchdog/rrwatchdoge.conf
umount /mnt/recovery
rmdir /mnt/recovery

Damit habe ich dann zumindest wieder den SSH-Zugang und somit direkten Zugang zum neuen TOKEN, WLAN Einstellungen usw., falls es doch mal wieder zu einem RESET kommen sollte.


Und der Vollständigkeit halber, inzwischen habe ich auf Valetudo 0.2.3 upgegradet.

 

[Jogile]

Heute morgen 03.04.19, es war so ungefähr um 4 Uhr, ist es leider wieder passiert. Alles wieder zurückgesetzt. Immerhin konnte ich mir dieses mal das Rooten und die Herstellung der SSH Verbindung schenken (s. Bemerkung von mir o.). Also direkt, nachdem ich den Roborock wieder ins WLAN aufgenommen hatte, mit SSH auf den Roborock verbinden und Token mit

printf $(cat /mnt/data/miio/device.token) | xxd -p

auslesen. Damit wieder die Firmware 1792 aufgespielt und die rc.local um die Einträge (s.o.) erweitert. Jetzt läuft er wieder...mal sehen wie lange.

Jetzt zu meiner Vermutung. Ich habe den Hostnamen "rockrobo" verändert. Vielleicht ist da ja irgendwo ein Watchdog, der den RESET deshalb auslöst, weil er diesen Namen verwendet. Deshalb habe ich diese Änderung dieses mal nicht gemacht und auf dem Original belassen. Ich werde berichten, falls dies das Problem gelöst hat.

Falls jemand schon eine Lösung des Problems hat, bitte melden! Vielen Dank!!!

 

[Jogile]

Am 28.04.19 ist es wieder passiert. Der Roborock hat sich wieder zurückgesetzt. Hatte ein paar Tage zuvor auf das Valetudo 3.1 upgedatet. Jetzt bin ich auf die empfohlene Firmwareversion 1748 umgestiegen (Anleitung s. GitHub - Hypfer/Valetudo: Open source cloud replacement for vacuum robots enabling local-only operation).

Da es sonst keine Meldungen zu diesem Problem gibt, muss der Grund für den Firmware-Reset evtl. in der Fritzbox zu suchen sein. Dort habe ich die Kommunikation des Roborock ins Internet komplett gesperrt. Habt ihr das auch gemacht oder habt ihr dem Roborock Internetzugriff erlaubt?

Für Rückmeldungen wäre ich dankbar, auch von Leuten, bei denen alles funktioniert

 

[MicroDevil]

Jogile
Hatte auch schon Resets, komischerweise ca. alle 8 Wochen. Alles identisch zu Dir.
Was ich gefunden habe ist eine übrigbleibende Update-Datei /mnt/data/.temp/update.pkg die den Roboter ggf. dazu bringt ein heimliches Rollback zu machen. Wird aktuell geprüft.
Es gibt übrigens genügend Meldungen zu dubiosen Resets des Robots, allerdings kreuz und quer in Untiefen diverser Threads versteckt
Bei V3.1 hat man auch genau deshalb ein Patch eingebaut: "Possibly fixed random firmware rollbacks"
Gruß
MD

 

[NullP0interEx]

Den Anhang pasted-from-clipboard.png betrachten
Den Anhang pasted-from-clipboard.png betrachten

So wie das für mich aussieht kann der WatchDog Prozess einen Reset auslösen. Die Frage ist nur warum. Ob es jetzt ein schwerwiegender Fehler ist oder einfach nur die System Partition voll ist, weiß ich noch nicht. Eventuelle schaltet er auch nur auf die reserve Partition um. (Die Funktion kann das Boot Partitions Flag ändern)

Jogile
Was ich gefunden habe ist eine übrigbleibende Update-Datei /mnt/data/.temp/update.pkg die den Roboter ggf. dazu bringt ein heimliches Rollback zu machen. Wird aktuell geprüft.
Den Anhang 54501 betrachten
Hier wird auch ggf. nach dieser Datei gesucht....

Den Anhang pasted-from-clipboard.png betrachten

Es gibt einen "ipc_com_rcv_thread" der so etwas auch auslösen könnte (lässt zumindest die Ausgabe vermuten). Ob vom Benutzer gewollt oder nicht...

 

[Jogile]

Vielen Dank für die Rückmeldungen!

Hier nun das Update. Seit 02.05.19 bis heute (31.05.19) läuft der Roborock mit Firmwareversion 1748 und Valetudeo 0.3.1 ohne Probleme (bis auf die anfänglich üblichen MAP Rotation Probleme in Valetudo - und bevor ihr schreibt, das dies kein Valetudo Problem ist, ich weiß).

@NullP0interEx
An dieser Stelle vielen Dank für die Infos! Mir ist dieser Watchdog Prozess auch schon aufgefallen. Stoppen wollte ich ihn allerdings nicht, da ich nicht weiß, was er noch alles an Funktionalität mitbringt.

Da ich weiter vermute, dass es an der fehlenden Internetfreigabe des Roborocks liegt und der Watchdog dies prüft, habe ich kurzerhand dem Roborock Zugriff aufs Internet erlaubt. Sollte das weiter alles laufen, werde ich die Freigabe wieder entziehen und schauen was passiert.

Also - Stay tuned - bin selbst gespannt, ob das Problem daher rührt.