Valetudo: Alternatives cloudfreies Webinterface ohne Dustcloud mit Livemap auf dem Saugroboter

  • fhortner Nachdem Valetudo dank der Hinweise und Unterstützung in diesem Forum nun endlich läuft (Valetudo 0.3.1, FW 1748), habe ich dieses Problem auch beobachtet. Wenn man den Saugvorgang manuell stoppt, wird die Karte offenbar gelöscht und der Roboter findet nicht zur Station zurück. Es wird stattdessen eine neue Karte angelegt und der Roboter erwartet die Station etwa an der Position, an der er sich befunden hat, als man auf 'Stop' drückte. Dort findet er sie natürlich nicht, sodass er ziellos zu suchen beginnt.

    Außerdem ist mir aufgefallen, dass die Zeit des manuell abgebrochenen Saugvorgangs, die vor dem Stoppen noch korrekt hochgezählt wurde, durch den Abbruch verfälscht wird (im beobachteten Fall von rund 50 Minuten auf etwa 8 Minuten - wo dieser Wert herkommt, ist mir nicht klar... Die wahllose Suche nach der Station hatte ich schon nach ca. 1 Minute abgebrochen).

    Handelt es sich um einen Bug in der aktuellen Valetudo-Version?

  • Klingt als hättest du dummycloud ebenfalls installiert.

    fhortner Nachdem Valetudo dank der Hinweise und Unterstützung in diesem Forum nun endlich läuft (Valetudo 0.3.1, FW 1748), habe ich dieses Problem auch beobachtet. Wenn man den Saugvorgang manuell stoppt, wird die Karte offenbar gelöscht und der Roboter findet nicht zur Station zurück. Es wird stattdessen eine neue Karte angelegt und der Roboter erwartet die Station etwa an der Position, an der er sich befunden hat, als man auf 'Stop' drückte. Dort findet er sie natürlich nicht, sodass er ziellos zu suchen beginnt.

    Außerdem ist mir aufgefallen, dass die Zeit des manuell abgebrochenen Saugvorgangs, die vor dem Stoppen noch korrekt hochgezählt wurde, durch den Abbruch verfälscht wird (im beobachteten Fall von rund 50 Minuten auf etwa 8 Minuten - wo dieser Wert herkommt, ist mir nicht klar... Die wahllose Suche nach der Station hatte ich schon nach ca. 1 Minute abgebrochen).

    Handelt es sich um einen Bug in der aktuellen Valetudo-Version?

    Kein Valetudo Problem. Das gleiche beobachte ich aber auch :/

  • Hypfer Danke für den Hinweis, gut zu wissen, dass es nicht an Valetudo liegt. Gibt es irgendeinen Workaround?

    Seltsam ist allerdings auch, dass die Saugzeit durch den manuellen Abbruch ebenfalls verfälscht wird (wird dann auch falsch auf die Consumables-Counters angerechnet).


    Mit der Original-Firmware und der Xiaomi-App habe ich es nicht probiert, aber ich nehme an, dass es dort wohl funktionieren wird. Andernfalls könnte man die Zonenreinigung ja nur nutzen, wenn der vorherige Saugvorgang vollständig abgeschlossen wurde, da ansonsten ja keine Karte mehr da ist, auf der man die Zone markieren könnte.

    Hat es denn in früheren Valetudo-Versionen funktioniert?

  • Kein Valetudo Problem. Das gleiche beobachte ich aber auch :/

    dann haben dieses Problem also mehrere, was ganz gut zu wissen ist.


    Zur Info: ich habe FW 1712 am S2.

    Wenn Luis123 es bei 1748 hat, dann wäre es interessant mal auf einer niedrigeren FW zu testen. Ich werde das bei gelegenheit mal testen und auf eine niedrigere FW downgraden. Gebe dann bescheid


    lg

  • Ein Hallo in die Runde.


    Bin dabei, meinen S50 mit Valetudo zu flashen. Habe mich an die Anweisungen in https://github.com/Hypfer/Vale…Installation-Instructions gehalten.


    Habe Lubuntu in einer VM auf meinem Mac aufgesetzt, Dustcloud und Valetudo eingerichtet und erfolgreich die Firmware v11_001748.fullos.pkg generiert.


    Habe mich dann in den Hotspot des S50 eingehängt und mirobo --debug discover --handshake true erbrachte Folgendes:


    Wenn ich dann aber mirobo --ip 10.0.2.2 --token XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX update-firmware image/output/v11_001748.fullos.pkg absetze, erhalte ich:

    Code
    1. Going to update from image/output/v11_001748.fullos.pkg
    2. INFO:miio.updater:Serving on 0.0.0.0:33521, timeout 10
    3. INFO:miio.updater:Using local image/output/v11_001748.fullos.pkg (md5: 7c0...)
    4. Hosting file at http://10.0.2.15:33521/v11_001748.fullos.pkg
    5. ERROR:miio.device:Unable to discover a device at address 10.0.2.2
    6. Error: Unable to discover the device 10.0.2.2
    7. ERROR:miio.updater:No request was made..


    Anzumerken sei, dass ein Ping sowohl auf 10.0.2.2 (Roborock) als auch 10.0.2.15 (meine VM) aus der VM heraus problemlos ist, allerdings nicht von meinem Host (MacOS). Die VM (VirtualBox) läuft im Netzwerkmodus NAT, als Bridge konfiguriert war noch nicht einmal ein Ping erfolgreich.


    Was mir auffällt, ist der Umstand, dass meine IPs des Roborock-Hotspots anders sind als in den üblichen Anleitungen, also nichts im Bereich 192.168.8.x.


    Hat jemand eine Idee, was hier schiefläuft?


    Danke im Voraus für jeden sachdienlichen Hinweis.

  • btx Diese Problematik konnte ich in sehr ähnlicher Weise auch beobachten (ebenfalls bei Verwendung einer VM mit VirtualBox auf einem Mac-Host). Ich vermute, es hängt eben genau mit der Verwendung eines Mac als Wirtssystem zusammen. Offenbar verhindern irgendwelche Einstellungen bzw. die Art, wie dort vom Gastsystem aus die Daten über WLAN nach Außen geführt werden, dass Letzteres korrekt funktioniert (Netzwerkbrücke funktioniert gar nicht, NAT anscheinend nur eingeschränkt).


    Nach etlichen Versuchen habe ich es aufgegeben und die Schritte in gleicher Weise auf einem Gerät mit real installiertem Ububtu wiederholt. Dort lief alles so, wie im Wiki angegeben.

  • Kein Valetudo Problem. Das gleiche beobachte ich aber auch :/

    Du hast das Problem mit FW 1748?

    Habe es mit FW 1712


    Habe jetzt mal wieder 1518 geflasht, mal sehen was dabei rauskommt.


    Was mir aber definitiv die letzten Tage auffällt ist, dass Valetudo im Browser das Dock überall anzeigt, nur nicht dort, wo das Dock ist.

    RoboRock Controll Center zeigt es jedoch korrekt an.

  • Also ich habe es jetzt beobachtet:

    Firmware: egal welche. aktuell 1518

    Valetudo: 0.3.1


    Wenn ich den Saugvorgang starte, wird die Karte zurückgesetzt. Dann zeigt er die ersten 2-3 Sekunden die Position der Docking Station korrekt an.

    Danach wird die Karte wieder komplett zurückgesetzt. Also während er schon saugt, wird die Karte wieder resettet. Die Docking Station positioniert er dabei irgendwo hin.

    ____


    Ok, mit FW 1518 hatte ich das Problem mit Stop/Home nicht


    Nachdem ich wieder 1712 geflasht habe, war auch die Docking Station korrekt.

    Dann wieder getestet STOP / HOME. Stop stoppt nur. Erst nachdem man ihn heim schickt, löscht er die Karte.

    Dabei setzt er die Position der Docking Station in Valetudo vom Startpunkt wo er versucht Heim zu fahren.


    Habe den Robo dann "heim" getragen --> "Charging..."


    Sodann wieder den Saugvorgang neu gestartet. Diesmal aber dann auf PAUSE.

    Robi bleibt stehen und macht eine Pause.

    Schicke ich Ihn jetzt heim, fährt er schnur stracks heim, die Karte bleibt erhalten.



    Was ich jetzt noch beobachtet habe ist, dass bei jedem Start, die Karte zufällig irgendwie unbestimmt um 90° dreht.

    Da die Position der Docking Station aber scheinbar in der Karte konstant bleibt bei der Rotation, wird die Docking Station auf der Karte dann auch irgendwo positioniert, wo sie nicht ist.


    Soweit meine Beobachtungen.

    Edited 2 times, last by fhortner: Ergänzung ().

  • Guten Tag,


    versuche seid 2 Tagen auch meine Mi Vacuum Robot (1.Gen) mit Valetudo zu flashen. Habe das Image auch basteln können. Nur leider klappt das mit dem flashen nicht.


    Verbindung zum Robo ist hergestellt und ich kann mit mirobo auch das Token auslesen und den Status. Nur bei starten des Updates kommt gleich ne Fehlermeldung (an dem Punkt eigentlich der Robo das Image vom temporären Webserver abrufen müsste).


    Der Robo hat die Firmware 3.5.0_003476 - Habe gelesen, dass Xiaomi ab der 3.5er Version irgendwas an der Verschlüsselung der Firmware geändert hat.


    Kann es sein, dass ab dieser Firmware das flashen mit mirobo nichtmehr funktioniert?

    Kann man die Firmware irgendwie downgraden?

  • Danke für den Hinweis Mataschke... Funktioniert leider auch nicht. In dem Moment wo der Update-Prozess anfangen sollte, als wenn der Robo die Firmware vom temporären Webserver laden soll, passiert nichts und es kommt ein Timeout-Fehler.

  • Hi,

    wenn du eine VM verwendest, nicht im NAT modus! Der Staubsauger muss den HTTP server (flasher) erreichen. Dh du solltest das Netzwerk bridgen. Ansonsten alle Netzwerkadapter deaktivieren (außer WLAN und Bridge Interface...).


    Für Windows: Ein beliebtes Problem sind Firewalls und mehrere verbundene Netzwerkinterfaces.

  • Hallo zusammen,


    danke für die Rückmeldungen!

    Ich habe es gestern mit einem Macbook und deaktivierter Firewall versucht. Werde es heute nochmal mit nem "frischen" Raspberry Pi probieren.


    Ich möchte nur ausschließen, dass mit der Firmware 3.5.0 irgendeine Sperre in den Roboter eingebaut wurde, der das flashen verhindert. (siehe https://github.com/dgiese/dustcloud/issues/211) - Also wenn jemand schreibt das er mit RRCC und Firmware 3.5 auf dem Robot schon erfolgreich geflashed hat würde mir das schon reichen.

  • Bisher konnte ich über Docker die aktuelle git-Version von Valetudo bauen und nutzen.


    Bauen geht zwar immer noch, aber es startet nun nicht mehr:

    Code
    1. valetudo: relocation error: valetudo-git: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

    Weder am Robo noch am PC wurde aber etwas geändert. Auch ein checkout einer älteren Version vom git läuft nun nicht mehr. :/


    Jemand eine Idee?

  • Zeige die Map in ioBroker Vis an. Läuft ohne Probleme.

    Wieso kann ich die Map in Valetudo nicht mehr sehen, wenn der Robo in der Dock steht ?

    Gibt es einen Ort der gespeicherten Karte ?