Roborock/Xiaomi Vacuum: Backup und Restore der gespeicherten Karte über MQTT

Begonnen von Thyraz, 05 Juni 2019, 23:09:57

Vorheriges Thema - Nächstes Thema

dominik

Die Position des Chargers. Weil wenn der Saugroboter mit einer verkehrten Karte losfährt, danach eine schöne last_map bekommt, ist die Charger Position auf der Karte falsch positioniert. Diese Position müsste man noch korrigiert bekommen. ChargerPos.data ist es leider nicht, das wird scheinbar nicht gelesen.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

MadMax-FHEM

Ja aber ich glaube Charger-Pos ist nur ein Teil.
Es gibt ja auch noch irgendwelche LIDAR-Dateien etc.

Ich hab auch schon mal versucht (ist aber schin eine Weile her) herauszufinden, was alles gesichert werden muss, damit das passt...

Ich glaube es gab hier mal eine Lösung für den V2...
...leider nicht passend für meinen V1...

EDIT: äh war das nicht sogar hier!? Bin ich jetzt "verwirrt"!? ;)

Und meinen V2 hab ich bis auf rooten noch nicht "gequält"...
...dazu ist/war er mir dann doch zu teuer...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dominik

Ja, genau hier :)

Meiner ist ein V1, beim V2 war die Loesung mit last_map und den weiteren Persist* Daten ausreichend. Beim V1 scheinbar nicht.

Wenn jemand den V2 hat, koennt ihr bestaetigen, dass beim Restore auch die Charger Position IMMER korrekt gesetzt wird?

Siehe anbei, da ist mal die Karte verdreht gewesen, dann habe ich last_map wiederhergestellt und dann sieht es so aus wie im Screenshot. (rot waere die richtige Charger Position)

//Edit
appproxy.map koennte noch ein Ansatzpunkt sein. Gibt es die auf dem V2 auch?
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

MadMax-FHEM

Ja V1 ist schwierig...

Weil da das Map-Speichern eigentlich noch gar nicht drin ist...
...also FW-seitig...

Ich hatte auch mal eine komplett "verdrehte" Karte und wie geschrieben: ich habe ihn sich mal kurz orientieren lassen, danach dann die gesicherte Karte zurück und es hat (bei mir) gepasst...

Ich speichere auch keine Karte autom.
Sondern ich hab die halt jetzt mal weggespeichert...
...und wenn ich merke, dass er wieder mal "im Wald" steht, dann mache ich beschriebene Prozedur...

Allerdings, seit ich ihn "gut behandle", also nicht mehr einfach aus dem Dock nehme und dann wieder "irgendwo" hinstelle (jetzt schiebe ich ihn in die Dock zurück ;)  ) hatte ich kein Problem mehr...

Ich hab auch mal mit den anderen vorhanenen Dateien "rumprobiert", war aber eher kontraproduktiv...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

KurtK

Zitat von: dominik am 16 Mai 2020, 19:20:35
Nach dem Booten ist zu selten, da der Saugroboter fast nie neu startet.

Ich habe schon einen Weg gefunden. Man kann in /run/shm/navmap* monitoren. Solange diese Datei vorhanden ist, ist der Roboter unterwegs, wenn die Datei weg ist, kann man die last_map ersetzen.

Hier mal meine Testversion:
#!/bin/bash

NAVMAP=/run/shm/navmap*.ppm
SAVEDMAP=/mnt/data/rockrobo/saved_map
LASTMAPPATH=/mnt/data/rockrobo/last_map

while true; do
  if ls $NAVMAP 1> /dev/null 2>&1; then
    echo "Roborock cleaning, do not update last_map"
  else
    echo "Roborock docked or stopped, check last_map update"
    if cmp -s "$SAVEDMAP" "$LASTMAPPATH"; then
      echo "No new last_map, everything ok"
    else
      echo "New last_map found, overwrite last_map with saved one"
      cp $SAVEDMAP $LASTMAPPATH
      killall player
    fi
  fi
  sleep 60
done


Ich lass das mal morgen in der Console per SSH laufen und wenn es funktioniert, bau ich den Start in rc.local ein, damit laeuft es dann automatisch und macht alle 60s den Check.

Wie läuft das denn mit navmap wenn man den Roboter nur zu einer Position fahren lässt (z.B. zum ausleeren)? Bleibt navmap vorhanden solange der Roboter außerhalb des Docks ist oder nur während er sich in Bewegung befindet?
- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

dominik

Ich glaube auch im Pause Status gibt es noch die navmap. Ich hatte gerade den Ausleer Fall getestet.
- Vacuum zum Punkt navigiert
- Ausgeleert und paar Minuten gewartet
- Zurück zur Dock

Hat problemlos funktioniert.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

dominik

Alle mit V1 die die Karte regelmaessig restoren wollen, die Loesung hier laeuft bei mir bislang ohne Probleme:
https://forum.fhem.de/index.php/topic,101197.msg1054827.html#msg1054827
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

Cruiser79

Zitat von: dominik am 19 Mai 2020, 20:45:46
Alle mit V1 die die Karte regelmaessig restoren wollen, die Loesung hier laeuft bei mir bislang ohne Probleme:
https://forum.fhem.de/index.php/topic,101197.msg1054827.html#msg1054827
Du sprachst doch in einem deiner älteren Beiträge darüber, das die Roboterposition mit dieser Lösung nicht korrekt ist. Geht das bei dir mittlerweile? Ich kann zwar mit dem Restoren aller Dateien unter /mnt/data/rockrobo/ und killall player auch meine Karte wiederbekommen, der Roboter steht dann aber leider nicht auf der Karte in seiner Station. Wo auch immer diese Information hinterlegt ist, wohl nicht in einer der Dateien unter /mnt/data/rockrobo/
FHEM auf Raspberry Pi
HM-CFG-LAN mit HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-WDS10-TH-O, HM-LC-SW1-FM, HM-LC-Bl1-FM
Signalduino mit Elro AB440, LOGILINK WS0002, IT CMR-1000

eckibrecki

Zitat von: Thyraz am 05 Juni 2019, 23:09:57
Auf einem Debian oder Ubuntu System folgendes ausführen:

sudo apt-get update
sudo apt-get install libffi-dev libssl-dev ccrypt git wget dos2unix python3-pip
sudo pip3 install -U setuptools
sudo pip3 install python-miio
...

Hallo,
ich habe mir nochmal einen Xiaomi Vaccum V1 angeschafft und wollte die Installationsanleitung auf der ersten Seite ausführen. Leider gab es bei der Installation von python-miio Installationsfehler. Die Rede war hier von:
- error: can't find Rust compiler
- This package requires Rust >=1.48.0.
- ERROR: Failed building wheel for cryptography
- Failed to build cryptography

Nach einiger Suche bin ich auf einen Lösungsvorschlag gestoßen, der mir geholfen hat python-miio zu installieren:
Failed to build cryptography
pip3 install -U python-miio -r /tmp/requirements.txt


Dadurch trat die Fehlermeldung nicht mehr auf und die Installation von python-miio konnte fehlerfrei beendet werden.

Evtl. hilft es jemandem, der auch über dieses Problem stolpert.

Grüße
Carsten