Mein Roborock S50 hat sich gestern selbst zurückgeflasht.

  • 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

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

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

  • GELÖST!!



    Nach nun den 4. Mal neu flashen ist mir aufgefallen, dass in der Ausgabe von date Fri Feb 15 18:43:20 SGT 2019 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 =O


    GEN1: https://github.com/dgiese/dust…bots-CCC-to-CE-conversion

    GEN2: https://github.com/dgiese/dust…cuum.gen2/CN_to_EU_script


    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

    Code
    1. 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

    Code
    1. iptables -t nat -L

    The result should contain the following:

    Code
    1. Chain OUTPUT (policy ACCEPT)
    2. 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!! <X

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

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

  • 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?

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

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

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

  • 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!!!

  • 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. https://github.com/Hypfer/Vale…Installation-Instructions).


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

  • 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

  • pasted-from-clipboard.png

    pasted-from-clipboard.png


    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.

    roboter-forum.com/core/index.php?attachment/54501/

    Hier wird auch ggf. nach dieser Datei gesucht....


    pasted-from-clipboard.png


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

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