[HOWTO] Rockrobo mit Valetudo (komplett ohne Cloud Verbindung)

  • 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

  • MicroDevil


    Klasse, dass Du das Problem so lösen konntest! :)

    Und vielen Dank für das Teilen dieser Lösung!


    Auf mich persönlich trifft es allerdings nicht zu - mein Robi ist schon ab Werk in der EU-Version unterwegs.

    Das Anpassen der Zeitzone von UTC auf GMT+1 hat leider auch nicht geholfen die WLAN-Verbindung über Nacht aufrecht zu erhalten.


    Ich habe jetzt einfach nochmal den Robi neu betankt (nach vorherigem Factory-Reset). Vielleicht hilft das ja schon, ansonsten werde ich eine andere Firmware testen.


    VG

    maval1ty

  • Hallo zusammen,


    ich habe bei mir jetzt endlich die modifizierte Firmware geflasht :)


    Im Tutorial gibt es zum Schluß ja noch den Part wo man prüfen kann ob dummycloud korrekt aufgesetzt ist. Dabei ist mir aufgefallen das bei mir die Ausgabe von iptables ganz anders aussieht. Die iptables Datei ist "komplett leer".

    Was muss ich tun um die entsprechenden Einträge da rein zu bekommen?


    Gruß holybabel

  • holybabel

    Möglicherweise stimmt etwas mit der Datei /etc.rc.local nicht und die iptables werden nicht sauber geladen.

    Hier ab dem Punkt Systemdateien prüfen:: Xiaomi Mi 1gen downgrades sich selbst…


    Aber Vorsicht. Fallst Du den Internetzugang sperrst, stelle sicher, dass der Inhalt /opt/rockrobo/watchdog/ntpserver.conf stimmt und nur Deine Fritz.Box als Time Server drin steht.

    Sonst verschluckt sich der Robbi: Bitte um Unterstützung: Mekrwürdige Angaben in /mnt/data/rockrobo/rrlog/watchdog.log

  • MicroDevil Das war genau das Problem, danke :-)


    Jetzt habe ich in der IPTables Ausgabe auch was drin stehen.

    Zugriff auf das Internet hat der Robbie aber immer noch:

    Code
    1. root@rockrobo:~# ping google.de
    2. PING google.de (216.58.213.227) 56(84) bytes of data.
    3. 64 bytes from ham04s01-in-f3.1e100.net (216.58.213.227): icmp_seq=1 ttl=56 time=6.71 ms

    Theoretisch finde ich das auch nicht schlimm, wichtig ist mir nur das das gefunke nach China aufhört.

  • Was sollte man denn eigentlich tun, wenn man das token in nem frischen S50 net erhält mit dem Befehl


    Code
    1. mirobo --debug discover --handshake true

    Die Ausgabe ist bei mir jedes mal nur


    Code
    1. INFO:miio.vaccuum_cli:Debug mode active
    2. INFO:miio.device:Sending discovery to <broadcast> with timeout of 5s..
    3. INFO:miio.device:Discovery done

    Das wars nix token nix sonst was :(

  • Was sollte man denn eigentlich tun, wenn man das token in nem frischen S50 net erhält mit dem Befehl


    Code
    1. mirobo --debug discover --handshake true

    Die Ausgabe ist bei mir jedes mal nur


    Code
    1. INFO:miio.vaccuum_cli:Debug mode active
    2. INFO:miio.device:Sending discovery to <broadcast> with timeout of 5s..
    3. INFO:miio.device:Discovery done

    Das wars nix token nix sonst was :(

    Vielleicht noch zum hinzufügen. Habs auf nem centos 7 host ebenfalls getestet. Gleiche Ergebnis :(

    Und ja, auch da war nur das WLAN mit dem 192.168.8.0er Netz vorhanden.

  • Hab mir jetzt das Token aus nem iPhone Backup geschnappt und es damit versucht. Ergebnis:


    Code
    1. (venv) [root@host rockrobo]# mirobo --ip 192.168.8.1 --token 7150343162784154496b4a7969764679 update-firmware image/output/v11_001844.fullos.pkg
    2. Going to update from image/output/v11_001844.fullos.pkg
    3. INFO:miio.updater:Serving on 0.0.0.0:40207, timeout 10
    4. INFO:miio.updater:Using local image/output/v11_001844.fullos.pkg (md5: 0529d86a11b7fdb7123dfdff7866a378)
    5. Hosting file at http://192.168.8.140:40207/v11_001844.fullos.pkg
    6. ERROR:miio.updater:No request was made..
    7. ERROR:miio.device:Got error when receiving: timed out
    8. Error: No response from the device

    Leider finde ich auch nix passendes bei google für

    Code
    1. miio.updater:No request was made..

    Hat hier wer Rat?

  • Was nutzt Du für ein System? Im Falle einer VM versuche, das Netzwerk auf Bridge zu stellen (bei manchen hat auch NAT funktioniert, bei mir allerdings nicht). Danach entweder die Netzwerkverbindung trennen und wiederherstellen oder alternativ die VM neu starten.

  • Was nutzt Du für ein System? Im Falle einer VM versuche, das Netzwerk auf Bridge zu stellen (bei manchen hat auch NAT funktioniert, bei mir allerdings nicht). Danach entweder die Netzwerkverbindung trennen und wiederherstellen oder alternativ die VM neu starten.

    Ich habs mit nem direkten Host mit centOS7 probiert (siehe 1 post darüber)
    Ich habs mit VM probiert (das war die Lösung von früher womit es IMMER geklappt hatte), diese wurde mit Hyper-V erstellt.

    Keine der beiden Lösungen hat einen Fortschritt gebracht :(

  • nicedevil

    Die Befehlszeile von Dir mit mirobo spuckt bei mir auch nur Fehler aus.

    Versuche es mal mit flasher.py. Ich mache meine Updates grundsätzlich nur damit und passe dann SSID und Passwort einmalig über die GUI von valetudo an.

    python3 flasher/flasher.py -f image/output/v11_003468.fullos.pkg

    siehe https://github.com/dgiese/dust…upload-the-firmware-image

    Die benötigten Pakete sind ganz oben beschrieben https://github.com/dgiese/dust…e-root-Howto#general-idea


    Achja, flasher.py ist Teil von Imagebuilder und in der Zip-Datei: https://github.com/dgiese/dustcloud/releases


    Gruß

    MD

  • adam@ubuntu:~/rockrobo/firmware/image$ sudo ../dustcloud/devices/xiaomi.vacuum/firmwarebuilder/imagebuilder.sh \

    > --firmware=../firmware/v11_001748.fullos.pkg \

    > --public-key=$HOME/.ssh/id_ed25519.pub \

    > --valetudo-path=../valetudo \

    > --disable-firmware-updates \

    > --ntpserver=192.168.178.1 \

    > --replace-adbd

    sudo: ../dustcloud/devices/xiaomi.vacuum/firmwarebuilder/imagebuilder.sh: command not found


    hab eine ubuntu vm..


    wieso klappt das nicht ?

  • hat sich erledigt.

    benutzerfehler :-)