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

[Thyraz]

Hallo zusammen,

kurze Beschreibung:
- Ermöglicht Backup / Restore der aktuellen Karte des Roboters über MQTT Messages
- Mehrere Karten speichern möglich (Sperrzonen und Absperrbänder werden mit gesichert / wiederhergestellt)

Wofür ist das gut?
- Wiederherstellen der Karte falls der Roboter sie fehlerhaft erweitert oder ganz verloren hat
- Laden von verschiedenen Karten z.B. für verschiedene Stockwerke. (Wahrscheinlich pro Stockwerk ein Lade-Dock nötig damit der Robo die Karte auch nutzt).
- Karte wieder auf "Masterkarte" zurücksetzen um z.B. in der Karte immer alle Türen als offen dargestellt zu bekommen. Fehlgeschlagenes Zone-Cleaning aufgrund von vormals verschlossenen Türen lässt sich so umgehen.

Was brauch ich dafür?
- Staubsauger muss gerootet sei
  Der Sauger darf aber ruhig weiter mit der Xiaomi Cloud und der Original App kommunizieren. Alternative lokale Clouds wie Valetudo oder Dustcloud sind nicht nötig.
- Etwas Zeit zum installieren.

Anleitung und Download:
https://github.com/Thyraz/MapLoader

Bisher nur von mir auf dem S50 getestet und mit heißer Nadel gestrickt.
Feedback ist gern gesehen. 😉

edit:
Schnellanleitung zum Rooten falls Ihr das bisher noch nicht gemacht habt:
Alles was benötigt wird ist ein Linuxrechner mit Debian oder Ubuntu um die Firmware zu erstellen und aufzuspielen. dürften die meisten FHEM Nutzer ja griffbereit haben.

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

export LC_ALL=C.UTF-8
export LANG=C.UTF-8

Testen ob Verbindung geht:
mirobo --ip <ip-adresse> --token <robo-token> status

Firmwarebuilder von Git holen:
cd ~
mkdir rockrobo
cd rockrobo

git clone https://github.com/dgiese/dustcloud.git
cd dustcloud/devices/xiaomi.vacuum/firmwarebuilder/

Firmware für Roborock S50 (ACHTUNG: für Xiaomi Mi Vaccum anderes Image suchen, nicht kompatibel):
wget https://cdn.awsbj0.fds.api.mi-img.com/rubys/updpkg/v11_001720.fullos.pkg
(Weitere Mirrors siehe hier: https://github.com/dgiese/dustcloud/wiki/Xiaomi-Vacuum-Firmware)

SSH Key für erstes Einloggen ohne Passwort:
ssh-keygen -t rsa -b 4096 -C "<email@adresse.xyz>"

SSH Key in aktuelles Verzeichnis kopieren
cp ~/.ssh/id_rsa.pub .

Image erstellen:
sudo ./imagebuilder.sh -f v11_001720.fullos.pkg  -k id_rsa.pub -t Europe/Berlin
Image Flashen:
sudo python3 flasher.py -a <ip-adresse> -t <robo-token> -f output/v11_001720.fullos.pkg

Warten bis Robo Update beendet hat. Meldet dies dann per Sprachausgabe. Robo ist dann in der Xiaomi App wieder online/bereit.
ssh root@<ip-adresse>

Per SSH auf dem Robo:
apt-get update
apt-get install nano
Mit "passwd" Root Passwort setzen, um per SSH ohne Key File einloggen zu können (z.B. um von anderen Rechnern als dem Debian/Ubuntu System zugreifen zu können.)

Grüße,
Tobias

[Thyraz]

So, nachdem es gestern schon spät war, noch ein paar Worte dazu:

Grund für das Ganze war die "Robo zerschießt sich die Karte und erstellt sie beim nächsten Reinigen in einer anderen Orientierung" Geschichte.
So kann man nun einfach die Karte wiederherstellen, damit die Zonen-Koordianten für das FHEM Xiaomi Modul sich nicht ändern.

Was noch zu beachten ist (ist auch in der Github Readme beschrieben):
Die wiederhergestellte Karte wird vom Roboter erst bei der nächsten Reinigung in den Speicher geladen.
Taucht also auch dann erst in der Xiaomi Home App auf.

Es reicht aber einmal kurz die Reinigung zu starten und nach ein paar Sekunden wieder abzubrechen.
In der Zeit fährt der Robo bei mir nichtmal los, bleibt beim Kartenwechsel also im Dock stehen.

Lässt sich in Verbindung mit dem Xiaomi Modul von Markus M. auch weiter automatisieren.

Zum Beispiel um die Karte immer gleich zu halten (z.B. weil wegen Kinderspielzeug oft Hindernisse da sind, oder damit die Türen zwecks Zonenreinigung immer als offen eingezeichnet bleiben damit der Robo den Weg in alle Räume findet).

Kam bei mir noch nicht dazu es komplett umzusetzen, aber die Idee ist ein Notify darauf zu setzen, wenn der Robo nach einer Reinigung ins Dock zurückommt.
Dann die "Masterkarte" wiederherstellen, Reinigung starten + Stoppen damit die Karte auch vom Robo geladen ist.

Eine andere Anwendung wären mehrere Docks in mehreren Stockwerken.
Über schaltbare Steckdosen den Stromverbrauch der Docks überwachen und so erkennen, wenn der Robo in eine der Docks gesetzt wird.
Dann automatisch die richtige Karte für das Stockwerk laden.

Da mit der Karte auch Sperrzonen / virtuelle Absperrbänder gespeichert bzw. wiederhergestellt werden,
erhält man so auch die Möglichkeit Sperrzonen auf mehreren Stockwerken einzusetzen.

edit: Somit fällt mir noch eine weiterer Anwendungsmöglichkeit ein:
Identische Karten mit verschiedenen Sperrzonen laden z.B. Saugkarte und Wischkarte bei der er dann Teppiche auslässt.

[steffen83]

Habe noch keinen Sauger von denen aber verfolge es mehrfach. Finde die Funktion Klasse und somit wäre der T6 eigentlich überflüssig da man hiermit die gleichen Funktionen abbilden kann, richtig?

Gesendet von meinem MI 8 mit Tapatalk

[isy]

Hallo Tobias,
dazu werden vermutlich Root Rechte am Xiaomi benötigt?

Gruß Helmut

[Thyraz]

Ja, aber wirklich nur einfach rooten reicht.
Abklemmen von der China-Cloud womit man dann andere Tools zum steuern braucht anstatt der Original Smartphone App oder Ähnliches ist nicht nötig.

Nachdem ich das Rooten auch erst vor ein paar Tagen gemacht habe, hab ich oben mal noch meinen Mitschrieb reingehängt.
Ist bei den Saugern echt eine einfache Sache und mit der obigen Anleitung in weniger als 30min zu schaffen denke ich.

[MadMax-FHEM]

edit: Somit fällt mir noch eine weiterer Anwendungsmöglichkeit ein:
Identische Karten mit verschiedenen Sperrzonen laden z.B. Saugkarte und Wischkarte bei der er dann Teppiche auslässt.

Das ginge auch jetzt schon mit dem Modul von Markus...
(bzw. ging es mal mit einer Prototyp-Version / mit der aktuellen Version vom Update habe ich es nicht hinbekommen / siehe den Xiaomi-Thread gegen Ende)

Nachdem ich das Rooten auch erst vor ein paar Tagen gemacht habe, hab ich oben mal noch meinen Mitschrieb reingehängt.
Ist bei den Saugern echt eine einfache Sache und mit der obigen Anleitung in weniger als 30min zu schaffen denke ich.

Ja, ist wirklich kein Ding...

Bin nicht sicher aber gefühlt fehlen ein paar Sachen in der Anleitung (müsste mal meinen Mitschrieb prüfen   ):

1. muss man nicht, um die "mirobo-Tools" nutzen zu können ein virtuelles Environment anlegen: python3 -m venv .venv und dieses auch "betreten" . .venv/bin/activate !?

2. braucht man nicht auch ein Sprachpaket (gut könnte optional sein, vermutlich wird dann das genommen, was in der runtergeladenen FW drin ist/bleibt   )

Ansonsten bin ich hiernach vorgegangen: https://github.com/dgiese/dustcloud/wiki/VacuumRobots-manual-update-root-Howto

Habe auf einer SD-Karte eine "Root-Umgebung", wenn ich also rooten will oder was ausprobieren will, dann stecke ich einfach die Karte in einen PI und schon kann's los gehen...

Achja: VIELEN DANK!!

Ich schau mir das mit den Karten mal an...
...jetzt kommt ein wenig freie Zeit

Gruß, Joachim

[Thyraz]

Hi Joachim

Bin nicht sicher aber gefühlt fehlen ein paar Sachen in der Anleitung (müsste mal meinen Mitschrieb prüfen   ):

1. muss man nicht, um die "mirobo-Tools" nutzen zu können ein virtuelles Environment anlegen: python3 -m venv .venv und dieses auch "betreten" . .venv/bin/activate !?

Also bei mir war das nicht nötig. Wofür ist das denn normal gut?
Ist das ne Art VM, kann es evtl. je nach Architektur nötig sein?

2. braucht man nicht auch ein Sprachpaket (gut könnte optional sein, vermutlich wird dann das genommen, was in der runtergeladenen FW drin ist/bleibt   )

Das ist laut diversen Anleitungen mittlerweile nicht mehr nötig, da sie schon enthalten sind.

[MadMax-FHEM]

So genau weiß ich das auch nicht...
Aber es ist eher keine VM, eher sowas wie ein "Uset-Environment" (denke ich) wo eben bestimmte "Umgebungseinstellungen" gegeben sind ..
In meiner verlinkten Anleitung steht das halt so (und die klingt ähnlich deinem Mitschrieb) und bei mir gingen die mirobo-Befehle nur nachdem ich eben in das "env" gewechselt bin...

D.h. mittlerweile sind alle Sprachen/Sprachpakete bereits in der FW!?

"Früher" musste man die noch auf den Sauger runter laden (glaube ich mich zu erinnern)...

Gibt da mittlerweile bereits Deutsch zum Auswählen?
(ich habe noch Englisch und bleibe verm. dabei   )
Zum Runterladen als Sprachpaket gibt's das ja...

EDIT: hier noch ein Thread meiner bisherigen Versuche https://forum.fhem.de/index.php/topic,86535.msg789573.html#msg789573 leider aktuell wegen fehlender Zeit etwas gestockt...

EDIT2: und wenn man dann gerootet hat (dazu braucht man ihn ja in keiner App bzw. geht es am einfachsten, wenn er frisch zurückgesetzt ist   ), dann lässt sich so ganz einfach der Token auslesen:

Code Auswählen Erweitern

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

Und jetzt bin ich erst mal wieder ruhig...

Gruß, Joachim

[Thyraz]

Habe noch keinen Sauger von denen aber verfolge es mehrfach. Finde die Funktion Klasse und somit wäre der T6 eigentlich überflüssig da man hiermit die gleichen Funktionen abbilden kann, richtig?

Hi Steffen, sorry den Post hab ich irgendwie übersehen.

Kommt drauf an was man vom T6/S6 will.

Er kann Raumaufteilung per App und "irgendwie" mehrere Karten.
Allerdings ist letzteres Feature in der aktuellen Umsetzung wohl nicht wirklich nutzbar wenn man sich die Threads im Roboter-Forum mal anschaut.
Außerdem hat er eine Raumerkennung/-aufteilung um Einzelräume dauerhaft als Zonen gespeichert zu halten.
Beim S50 muss man die Zonen in der App ja jedes mal neu zeichnen.

Aber auch das lässt sich mit FHEM besser regeln, da man hier die Zonen ja auch programmatisch übergeben kann.
Hier geht dann sogar Zonenreinigung per Alexa, was mit dem T6/S6 von Haus aus ohne Anbindung an ein SmartHome System wie Fhem ja auch nicht geht.

Der S6/T6 ist dafür nicht rootbar bisher und man weiß noch nicht ob er es sein wird.

In Verbindung mit einem SmartHome System wie FHEM sehe ich beim T6/S6 im Moment keine Vorteile.
Durch die Möglichkeit mit gerootetem S5 die Karten beliebig zu wechseln, ist dieser in dem Fall eher von Vorteil.

Ich hab mein S5 ja auch erst 2 Wochen und bei mir der Grund mir das Geld zu sparen, dass man bei der Bedienung über FHEM an sich keine Vorteile beim neuen Gerät hat.

[MadMax-FHEM]

Hi Tobias,

so nun hatte ich ein wenig Zeit (nicht so viel wie ich wollte aber immerhin   ) und mir das Map-Save/-Restore mal angesehen...

Also bei meinen V1 Saugern gibt es nur folgende Dateien/Verzeichnisse:

Code Auswählen Erweitern


-rw-r--r--   1 root root     40 May 30 18:50 ChargerPos.data
-rw-r--r--   1 root root    350 May 30 19:07 RoboController.cfg
-rw-r--r--   1 root root     38 May 30 18:50 StartPos.data
-rw-r--r--   1 root root    282 Apr 27  2018 Update.pkg.inf
-rw-r--r--   1 root root     43 Aug 15  2017 VacuumAndBrush.cfg
-rw-r--r--   1 root root  55573 May 30 19:07 appproxy.map
-rw-r--r--   1 root root    149 Aug 15  2017 apptimer.cfg
-rw-r--r--   1 root root 207516 May 30 19:07 last_map
-rw-r--r--   1 root root     44 May 30 18:50 lds_info.txt
-rw-r--r--   1 root root   2309 Oct 31  2018 localtime
drwxr-xr-x   2 root root   4096 Jan  1  1970 map
-rw-r--r--   1 root root  89088 May 30 19:07 robot.db
drwxr-xr-x 161 root root  36864 Jun 12 22:05 rrlog
-rw-r--r--   1 root root     81 May 30 19:07 slam_info.cfg
drwxr-xr-x   2 root root   4096 Apr 27  2018 sounds
drwxr-xr-x   2 root root   4096 Aug 15  2017 sounds.old
-rw-r--r--   1 root root     13 Oct 31  2018 timezone


Es fehlen also die PersistData_1.data und PersistData_2.data und es gibt auch keine user_map0.
Und zwar egal, ob es ein Sauger ist, der "einfach nur reinigt" (Raum geschlossen ohne Zone) oder ob es sich um einen handelt, der "nur Zonenreinigung" macht...

(ja ich habe ein paar von den Xiaomis   )

Bei meinen V2 habe ich auch einen Unterschied.
Und zwar bei dem, wo ich schon mal "Sperrzonen" eingerichtet hatte (zum Test von save_map über das Xiaomi-Modul), da habe ich eine user_map0 bei dem V2 der noch nie eine Sperrzone "gesehen" hat, fehlt diese Datei...

Die anderen beiden, also PersistData_1.data und PersistData_2.data sind auf den V2 aber auf beiden da...

Wenn ich wieder Zeit habe werde ich mal rumspielen, mal sehen.
Allerdings erst mal ohne MQTT, sondern nur mal so mit ssh...

Hast du das "MapLoad" auch mal bei einem V1 ausprobiert?

Gruß und vielen Dank für die Infos, Joachim

[Thyraz]

Hallo Joachim,

hast du die Kartenspeicherung bei allen Robos in den Optionen der Xiaomi Home App aktiviert?

Die user_map0 ist eigentlich diese gespeicherte Karte, während last_map wahrscheinlich die letzte Reinigung beinhaltet (also die gefahrenen Wege).
Ohne Kartenspeicherung gibt es logischerweise auch kein Backup/Restore.
PersistData_2.data scheint mit Absperrbändern und Sperrzonen zusammenzuhängen. Somit nicht unbedingt verwunderlich, dass die beim V1 nicht existiert.
Evt. gilt das Selbe für PersistData_1.data?

Einen V1 hab ich leider nicht zum Testen.
hab bisher auch noch keine Rückmeldung von jemand mit einem V1.

Grüße,
Tobias

[MadMax-FHEM]

Hallo Tobias,

also es ist so:

beim V1 gibt es das Feature "Karte speichern" (leider!!) nicht...
...da hätte ich es gerne...
...aber deswegen einen V2 kaufen und den V1 ersetzen will ich auch nicht...

bei einem V2 hab ich tatsächlich "Karte speichern (Beta)" aktiviert (eben für Tests des Xiaomi-Moduls: save_map), dort gibt es die Dateien...
...also gab: habe eben ein reset Map durchgeführt, weil ich gesehen habe, dass die letzte Zeit immer noch mit den "Spiel-Sperrzonen" geputzt wurde...
Jetzt sind die Dateien (nat.) weg...

bei dem 2ten V2 habe ich das Feature noch nicht aktiviert, daher (wohl) auch keine user_map0...

Allerdings habe ich noch bei allen nicht die aktuellste FW drauf.
Aktueller FW-Stand:

V1: 3.3.9_003194

V2: 3.3.9_001632 (vermutlich eine der ersten mit dem "Karte speichern" Feature)

alle gerootet (klar   )...

Sperrzonen hätte ich gerne bei einem meiner V1...
...bei den V2 brauche ich das eigentlich nicht...
...da aber die V2 da sind wo ich die Wischfunktion brauche kann ich auch nicht einfach tauschen...

Warum hab ich mehrere: weil ich "rumspielen" wollte aber auch sicherstellen will/wollte, dass ich eine zuverlässige Reinigung habe (trotz "rumspielen", es kann ja immer mal was schief gehen   )...

Wenn ich Zeit habe gehe ich auch mal auf eine neuere FW (nat. gerootet)...
...wobei ich mit der aktuellen eigentlich zufrieden bin...
Und wenn ich noch mehr Zeit habe, "spiele" ich mal mit dem V1, mal sehen, ob man da nicht auch was "wegspeichern" und weder "laden" kann...
Würde dann zumindest gegen "gedrehte Karten" helfen...
...oder auch mehrere Stockwerke mit einem Sauger möglich machen...
Und wenn noch ganz viel mehr Zeit ist, dann schaue ich mir das mit der "eigenen Cloud" auch (noch) mal an...

Wenn ich das vorher gewußt hätte, hätte ich mir den einen oder anderen sparen können

Gruß, Joachim

[Thyraz]

Ach die Unterscheidung von V1 vs. V2 was gespeicherte Karte angeht kannte ich gar nicht.
Aber der V1 hat doch auch Zonenreinigung anhand der letzten Karte, was macht das "gespeicherte" Karte denn dann überhaupt bei V2, was V1 nicht kann?

Oder hilft das nur, wenn ich ihn per Hand wo hinsetze und Spotreinigung mache,
dass er beim nächsten Start vom Dock dann wieder die volle Karte hat?

Verwirrend.

Aber ja, dann reicht beim V1 ein Restore der last_map evtl. schon und es könnte da auch klappen.

[MadMax-FHEM]

Ach die Unterscheidung von V1 vs. V2 was gespeicherte Karte angeht kannte ich gar nicht.
Aber der V1 hat doch auch Zonenreinigung anhand der letzten Karte, was macht das "gespeicherte" Karte denn dann überhaupt bei V2, was V1 nicht kann?

Jep Zonen gehen beim V1 genauso wie beim V2...
...dazu ist das wohl nicht nötig.

Der V2 kann aber eben auch "Sperrzonen" (also richtige Sperrzonen wie "Reinigungszonen" nur mit einem "Minus" davor   und "Sperrlinien", so wie die Magnetstreifen)...
Das Feature wird in der App nur angeboten, wenn "Karte Speichern (Beta)" aktiviert ist.
Eben geprüft, der V2 wo das Feature (noch) nicht aktiviert ist, hat auch den Knopf für Sperrbereiche nicht...
Komischerweise aber die "PersistData" Dateien...

...in der Tat: verwirrend...

Oder hilft das nur, wenn ich ihn per Hand wo hinsetze und Spotreinigung mache,
dass er beim nächsten Start vom Dock dann wieder die volle Karte hat?

Verwirrend.

Nein, wie geschrieben geht bei dem V1 alles was beim V2 auch geht bzgl. "GoTo" und "Zonen"...
...leider nur nicht "Sperrzonen"...
Von der Ansteuerung aus fhem heraus ist kein Unterschied (zumindest keiner den ich gemerkt habe bzw. meine Art der Verwendung betrifft)...

Aber ja, dann reicht beim V1 ein Restore der last_map evtl. schon und es könnte da auch klappen.

Das war mein Plan für "wenn mal wieder Zeit ist" oder war es "wenn mal wieder viel Zeit ist"?

Gruß, Joachim

[MadMax-FHEM]

Also ich hab mir eben mal ein wenig Zeit "zum Spielen" genommen

Leider mit mäßigem Erfolg 

Also zurückspeichern von last_map bringt beim V1 nichts (nicht das gewünschte Ergebnis)...

Ich habe auch mal geschaut und es werden zum Ende des Reinigungsvorgangs folgende Dateien geschrieben:

ChargerPos.data (ok, ist klar!? Da stehen wohl die Koordinaten zur Ladestation   )
StartPos.data (hmm, auch klar!? Da steht die Startposition drin... Abhängig bzw. "relativ" zur Position der Ladestation oder tatsächliche Koordinaten!?)
appproxy.map (?)
last_map (Letzte/aktuelle Karte!?)
slam_info.cfg (da stehen wohl Daten bzgl. des Lasers bzw. "Laserkoordinaten" drin? Dummerweise mit "Timestamp")

Nicht ganz genau zusammen mit diesen Daten aber auch "gegen Ende" noch folgende:
robot.db (welche u.a. auch Karten enthält und zwar die der letzten Reinigungen. Dafür gibt es auch ein "Extraktionsprogramm")
RoboController.cfg (nicht zusammen mit den anderen aber auch "am Ende". Da stehen ein paar Statistikdaten drin!?)

und dann nat das Log...
und im Unterordner 'map' noch alle möglichen Dateien...

Dann habe ich mal alle Dateien, die immer zusammen geschrieben werden (am Ende der Reinigung) zurückgespielt: leider auch nicht das erhoffte Ergebnis... 

Gut vielleicht hat es auch was mit dem Timestamp in der einen Datei zu tun...
...ich bleibe dran...
Brauche aber erst mal wieder Zeit...

Wäre schon schön, wenn man auch beim V1 Karten speichern und wieder laden könnte
(Schon alleine um etwas gegen die ab und an gedrehten Karten [gut hatte ich erst 1-2 mal] tun zu können / bzw. um sicher gehen zu können, dass auch tatsächlich die gewünschte Zone [und nicht "irgendwas"] gereinigt wird [oder gar etwas über den Haufen gefahren wird])

Und dann musste ich feststellen, dass wenn man den Sauger "einsperrt" (siehe Bild) und Zonen reinigen will es besser ist (bzw. bei mir gar nicht anders ging) als dass die Station Teil der Zone ist bzw. die Zone mindestens knapp vor der Station beginnt.
Ansonsten muss ich ihn erst rausfahren lassen und dann mit der Zonenreinigung beginnen...
...weil er sonst wie wild rückwärts "in die Station" fährt, bis er rot blinkend und sich beschwerend "aufgibt"...

Dieser Sauger hatte dort noch nie Zonen gereinigt, immer nur den ganzen Raum...

Gruß, Joachim

[Thyraz]

Nach dem Zurückspielen müsstest du beim V1 ja auch wieder einmal kurz die Karte laden indem du die Komplettreinigung einmal startest und wieder stoppst nachdem die Karte auftaucht (etwa 2s bei mir).

Ist die Frage ob das bei V1 halt funktioniert, oder ob der V2 in diesem Moment die Saved Map lädt.
Sprich die Last_Map beim V2 verworfen wird und dadurch das Laden der ausgetauschten Dateien funktioniert.

Wenn der V1 eben von sich aus bei einer weiteren Reinigung die Karte eben nicht neu vom Dateisystem lädt, sondern einfach schon im Arbeitsspeicher hat, könnte das ein Problem sein.

Wäre dann die Frage ob ein Reboot evtl. hilft, dass die last_map neu geladen wird?


Ich würde die cfg und db nicht ersetzen erstmal, im Netz hab ich da schon gelesen, dass das zu Problemen geführt hat, wenn man da zu alte Dateien reinkopiert.

[MadMax-FHEM]

Ah, ok...
Dann versuche ich das mal...
...also "anstarten" oder booten...

Die robo.db hab ich nicht ersetzt...
...nur die anderen Dateien...
Nachdem das mit der Karte alleine nicht geklappt hat...

Bin allerding grad unterwegs...
...später mehr...

Vielleicht klappt's ja doch...

Danke, Joachim

[MadMax-FHEM]

Also Anstarten hat irgendwie nicht funktioniert...
Da ist immer die Karte weg bzw. halt nur das Wenige da, was er halt in den paar Sekunden erkennt...

Ein Reboot funktioniert...
...allerdings muss wohl die ChargerPos.data bzw. StartPos.data oder/und die slam_info.cfg passen...

Einmal stand er nach dem Reboot schön grün blinkend "irgendwo" in der schön geladenen Karte...

Heißt: die Karte war die gewünschte aber irgendwie hat die Position des Saugers nicht gepasst...

Allerdings (gut vielleicht hätte ich alle zusammen kopieren sollen, wollte herausfinden welche denn nun [evtl.] wirklich zusätzlich wichtig ist und hab mal eine nach der anderen kopiert) hat auch das Kopieren der zugehörigen Dateien zur Karte nicht geholfen (also nat. mit Reboot jeweils)...

Habe ihn dann kurz angestartet und gewartet bis die genannten Dateien wieder da waren (die werden bei zu kurzem Anstarten irgendwie nicht [immer?] angelegt / zumindest waren sie bei einem Versuch "einfach weg") und habe dann die Karte neu runtergespielt und gebootet, danach war es wieder wie gewünscht...

Fraglich was passiert, wenn man anstartet, die Karte eigentlich gedreht wäre (man sieht ja auch bei kleinen Teilen der Karte schon wie sie liegt/liegen würde) und man dann "nur" die Karte runterspielt und bootet...
...da passen ja dann evtl. die anderen Positionen (Ladesation etc.) nicht wirklich dazu...

Hatte den Fall erst einmal, allerdings ohne, dass ich da schon mit der Karte "rumgespielt" hätte geschweige denn eine Kopie gehabt hätte...

Werde wohl noch mal testen müssen...

Aber immerhin: es scheint irgendwie zu gehen!

Gruß, Joachim

[Thyraz]

Ok, kannst ja deine Erkentnisse hier weiter abkippen wenn du noch was rausfindest.
Dann bau ich die Dateien vom V1 noch in das Copy-Script mit ein.

Das mit ChargerPos und StartPos muss ich mir dann beim Drehen auch mal anschauen.
Wenn man die Karte beim V2 löscht und dann statt mit einer Vollreinigung direkt mit der Fernsteuerung startet,
bekommt man das ja ganz gut manipuliert, je nachdem in welche Richtung man erstmal losfährt...

[MadMax-FHEM]

Ok, kannst ja deine Erkentnisse hier weiter abkippen wenn du noch was rausfindest.
Dann bau ich die Dateien vom V1 noch in das Copy-Script mit ein.

Ok, danke.
Mache ich, sollte ich noch was rausfinden...
...dazu muss aber erst mal die Zeit für Tests anhalten

Das mit ChargerPos und StartPos muss ich mir dann beim Drehen auch mal anschauen.
Wenn man die Karte beim V2 löscht und dann statt mit einer Vollreinigung direkt mit der Fernsteuerung startet,
bekommt man das ja ganz gut manipuliert, je nachdem in welche Richtung man erstmal losfährt...

Werde ich evtl. auch mal bei den V2 schauen...
...und den Trick vielleicht auch mal beim V1 testen, vielleicht kann ich ja da was "erzwingen" und dann sehen was man nun braucht damit das mit dem Karten speichern/laden auch da funktioniert...

Vielleicht finde ich auch noch was damit es ohne Reboot geht...

Ich habe auch mal im Xiaomi Device Thread gepostet (https://forum.fhem.de/index.php/topic,73052.msg948759.html#msg948759), weil ich entdeckt habe, dass es im Modul auch einige Funktionen bzgl. maps gibt...
...mal sehen.

Gruß, Joachim

[mark79]

Ich habe am Wochende mein v1 auf die neuste FW upgedated und Valetudo mit in das FW Image gepackt.

Im Valetudo Github steht etwas über die save_map Features: https://github.com/Hypfer/Valetudo/issues/132

Um das nutzen zu können, muss man das glaube ich vorher aktivieren, mit: echo -n "1" > /mnt/data/rockrobo/lab.cfg

Jedenfalls habe ich das mal aktiviert und bei mir speichert er die MAP für immer, auch wenn ich den Robi ausschalte.
Mehr konnte ich noch nicht wirklich ausprobieren.


Viele Grüße
Mark

[MadMax-FHEM]

Mist!

Noch mehr was man ausprobieren/anschauen kann...

Danke, da "muss" ich dann wohl durch...

EDIT: @Mark: welche FW hast du nun drauf?

EDIT2: ich hab das mal überflogen. Bist du sicher, dass es mit dem V1 Sauger auch geht!? Das Feature "No-Go" gibt's (offiziell) nur beim V2... Einige der genannten Funktionen gehen auch mit dem fhem Xiaomi Device Modul (siehe mein Link oben)... Die Karte hält auch bei mir einen Reboot etc. durch. Gut wäre, wenn man eine Karte "holen" kann und dann wieder runter speichern kann, sodass der Sauger diese wieder nimmt (falls mal was schief läuft: z.B. Karte gedreht / oder generell vor dem Reinigen: sicher ist sicher   ). Aber ich muss mir das Valetudo generell noch anschauen. Aber kostet halt alles Zeit (steht schon [lange] auf meiner ToTest äh ToDo Liste   )...

Gruß, Joachim

[mark79]

Gerngeschehen Im Wiki steht auch noch was dazu: https://github.com/Hypfer/Valetudo/wiki/FAQ

Es gibt auch ein Webservice von dgiese, der das Image für einen baut (auf Wunsch sogar mit Valetudo), das spart Zeit: https://dustbuilder.xvm.mit.edu/

Seit ich Valetudo drauf habe, kann ich den Robi nicht mehr mit der Xiaomi APP anbinden, der letzte Schritt schlägt immer fehl.
Daher sollte man sich vorher am besten überlegen, was man nutzen möchte. Ich glaube nämlich das ist so gewollt, scheint eine dummy Cloud zu sein.

EDIT: @Mark: welche FW hast du nun drauf?

Diese hier: v11_003468

EDIT2: ich hab das mal überflogen. Bist du sicher, dass es mit dem V1 Sauger auch geht!? Das Feature "No-Go" gibt's (offiziell) nur beim V2... Einige der genannten Funktionen gehen auch mit dem fhem Xiaomi Device Modul (siehe mein Link oben)... Die Karte hält auch bei mir einen Reboot etc. durch. Gut wäre, wenn man eine Karte "holen" kann und dann wieder runter speichern kann, sodass der Sauger diese wieder nimmt (falls mal was schief läuft: z.B. Karte gedreht / oder generell vor dem Reinigen: sicher ist sicher   ). Aber ich muss mir das Valetudo generell noch anschauen. Aber kostet halt alles Zeit (steht schon [lange] auf meiner ToTest äh ToDo Liste   )...

Ich habe einen v1, also was ich meinte, das die Karte mit obigen Befehl dauerhaft gespeichert wird, das ging vorher bei mir nicht. Ich hatte aber noch eine sehr alte Firmware drauf, vielleicht lag das auch daran.
Und so wie ich das verstehe, das man wohl mehrere Karten verwenden kann (das habe ich aber noch nicht getestet).
No-Go Zonen gehen derzeit beim v1 meines Wissens nicht.


Viele Grüße
Mark

[Thyraz]

Verstehe ich das richtig?
Offiziell hat der V1 keine Speicherung der Karte wie man sie vom V2 kennt, über die mirobo Kommandos aus der Valetudo FAQ kann man das Feature aber freischalten?

Wenn ja ist die Frage: Taucht hier dann nach einer Reinigung auch die user_map0 Datei auf?
Falls ja könnte ein Starten und nach c.a. 2 Sekunden wieder Stoppen der Reinigung evlt. auch zum Laden dieser gespeicherten Map führen (kein Reboot nötig).

Die Frage ist allerdings: Kann man dann über die offizielle App die gespeicherte Karte bei Bedarf zurücksetzen?
Wobei das ja auch durch Löschen von user_map0 gehen würde oder vielleicht sogar über reset_map cmd des FHEM Moduls.

Die PersistData_1.data und PersistData_2.data für virtuelle Sperrbändern und Nogo-Zonen wird es natürlich nicht geben, die hat nur der V2.

@mark79: Ja, Valetudo ist ja an sich nur aus dem Grund entstanden um die China Cloud loszuwerden soweit ich das verstanden habe.
Es wird also per Firewall auf dem Robo oder was auch immer der Zugriff auf die Xiaomi Server geblockt.
Dass die Original App nicht mehr geht ist also ein Feature und kein Bug.

Da sich meine bessere Hälfte an die original App gewöhnt hat,
hab ich davon erstmal abgesehen.

[MadMax-FHEM]

Gerngeschehen Im Wiki steht auch noch was dazu: https://github.com/Hypfer/Valetudo/wiki/FAQ

Es gibt auch ein Webservice von dgiese, der das Image für einen baut (auf Wunsch sogar mit Valetudo), das spart Zeit: https://dustbuilder.xvm.mit.edu/

Hab ich mal überflogen aber auch da ist nicht ersichtlich (bzw. explizit zu finden / zumindest nicht für mich) ob nun V1 oder V2...

Das mit dem "extern" bauen der FW kannte ich aber ich habe bereits eine Umgebung für "FW-Bau" eingerichtet...
...evtl. schaue ich mir das bzgl. Valetudo noch mal an, wenn ich mal Zeit habe mir das (gründlich) anzuschauen...
Danke!

Seit ich Valetudo drauf habe, kann ich den Robi nicht mehr mit der Xiaomi APP anbinden, der letzte Schritt schlägt immer fehl.
Daher sollte man sich vorher am besten überlegen, was man nutzen möchte. Ich glaube nämlich das ist so gewollt, scheint eine dummy Cloud zu sein.

War abzusehen, damit kann ich leben...
Nutze die "Original-App" gar nicht mehr (bzw. halt nur noch bei Tests, um zu sehen welche Karte nun da ist   / bzw. eigentlich nutze ich die Flole-App / die originale App eigentlich nur, wenn ich was kontrollieren will oder schauen will, wenn die Flole nicht so das macht was ich will/erwarte   )

Get die Flole App noch?
Hast du die in Benutzung!?

Dort ist es halt schön, die Zonen-Koordinaten zu "kopieren"...
Ist eigentlich der einzige Grund überhaupt (neben Testläufen) in "irgendeine" App zu gehen...
...ansonsten erfolgt alles über das fhem-Modul...

Oder geht das mit Valetudo auch einfach!?

Diese hier: v11_003468
Ich habe einen v1, also was ich meinte, das die Karte mit obigen Befehl dauerhaft gespeichert wird, das ging vorher bei mir nicht. Ich hatte aber noch eine sehr alte Firmware drauf, vielleicht lag das auch daran.

Also ich habe ja (noch) 3.3.9_003194 auf meinen V1ern mit ssh-Zugang (also "gerootet" aber [noch] ohne Valetudo)...
Ein reboot stellt (stellte bislang) auch ohne irgendwelche "Entwickler-Optionen" kein Problem dar...

Wie alt war denn deine davor?

Auch das Speichern einer eigenen gesichterten Karte mit den "Mechanismen" (allerdings ohne MQTT sondern per scp   ) von Tobias funktioniert (irgendwie), nur damit der Sauger diese "frisst" muss ich (aktuell [noch]) booten...

Und so wie ich das verstehe, das man wohl mehrere Karten verwenden kann (das habe ich aber noch nicht getestet).
No-Go Zonen gehen derzeit beim v1 meines Wissens nicht.

Bzgl. mehrerer Karten bin ich beim V1 auch nicht so sicher...
...wäre aber ja egal, wenn man die Karte(n) abspeichern und je nach Bedarf wieder laden kann...

Ja leider wird es wohl so sein/bleiben, dass "No-Go" nur für V2 ist/bleibt... 

Tja: das Los der "early adopters"... Aber jetzt deswegen "tauschen" mache ich dann doch nicht...

Gruß, Joachim

[Shojo]

Dort ist es halt schön, die Zonen-Koordinaten zu "kopieren"...
Ist eigentlich der einzige Grund überhaupt (neben Testläufen) in "irgendeine" App zu gehen...
...ansonsten erfolgt alles über das fhem-Modul...
Oder geht das mit Valetudo auch einfach!?

Ja einfach die Zonen über die Map einzeichnen und abspeichern, dann die URL http://<ip vom Robo>/api/get_config aufrufen und die Areas aus dem JSON kopieren.

Oder mal unter der URL http://<ip vom Robo>/zone/ schauen. 

#Edit
Sorry hatte ganz vergessen zu erwähnen das ich die selbst kompilierte Version aus dem Git nutze!

[mark79]

Ich muss das jetzt noch richtig stellen.. die Funktionen save_map und co. scheint wohl bisher nur für die v2 Sauger zu sein: https://github.com/Hypfer/Valetudo/pull/247
Das soll zudem verhindern, das sich die Karte dreht...

Bei mir hat sich heute die Karte gedreht und dazu wurde die Karte neu aufgebaut, also scheint das wohl mit meinem v1 Robi nicht wirklich zu funktionieren. Sorry dafür, wie gesagt, ich hatte das erst ein paar mal probiert (4-5mal) und da hat die Speicherung der Karte funktioniert und die Zonenreinigung.
Ich bzw. Fhem schaltet den Robi nach Benutzung immer aus, per eingelöteten esp8266.

Daher werde ich wohl Thyraz Lösung installieren.

Die Frage ist allerdings: Kann man dann über die offizielle App die gespeicherte Karte bei Bedarf zurücksetzen?
Wobei das ja auch durch Löschen von user_map0 gehen würde oder vielleicht sogar über reset_map cmd des FHEM Moduls.

Die PersistData_1.data und PersistData_2.data für virtuelle Sperrbändern und Nogo-Zonen wird es natürlich nicht geben, die hat nur der V2.

Das müssten die v2 User ausprobieren und vorher die LAB Funktion aktivieren, beim v1 scheint das bisher nicht Möglich zu sein.

Geht die Flole App noch?
Hast du die in Benutzung!?

Das mit den Zonen ist noch nicht so toll umgesetzt, das ändert sich aber wohl bald: https://github.com/Hypfer/Valetudo/pull/157

Ich mache das bisher so, das ich das log level hoch setzte und dann mit tail mir die Zonen aus der Shell raus kopiere.
Aber da hatte Shojo noch ein besseren Tipp, danke dafür.

Die FloeVac APP scheint nicht mehr zu funktionieren. Weil man dort nur die IP vom Robi und Benutzername + Passwort angeben kann, aber was trägt man dort als user+pw ein?

Wie alt war denn deine davor?

Die war schon alt, min. über ein Jahr. Ich habe den v1 Robi ende 2017 bekommen.

[MadMax-FHEM]

Ich muss das jetzt noch richtig stellen.. die Funktionen save_map und co. scheint wohl bisher nur für die v2 Sauger zu sein: https://github.com/Hypfer/Valetudo/pull/247

Macht nichts...
...dachte ich mir ja (leider) bereits...

Das soll zudem verhindern, das sich die Karte dreht...

Bei mir hat sich heute die Karte gedreht und dazu wurde die Karte neu aufgebaut, also scheint das wohl mit meinem v1 Robi nicht wirklich zu funktionieren. Sorry dafür, wie gesagt, ich hatte das erst ein paar mal probiert (4-5mal) und da hat die Speicherung der Karte funktioniert und die Zonenreinigung.
Ich bzw. Fhem schaltet den Robi nach Benutzung immer aus, per eingelöteten esp8266.

Daher werde ich wohl Thyraz Lösung installieren.

Also da habe ich ja etwas getestet...
...die Lösung von Tobias/Thyraz wird für V1 (aktuell) nicht funktionieren: es gibt bestimmte Dateien beim V1 einfach nicht...

Und auch das Verhalten des Karten-Ladens ist wohl irgendwie anders...

Aber ich habe es immerhin geschafft nach dem Löschen der Karte (reset_map durch das Modul bzw. nein ich glaube das habe ich per App gemacht) eine abgespeichterte wieder auf den Sauger zu laden, sodass er sie auch richtig nimmt...

Allerdings weiß ich (noch) nicht genau was (genau) man braucht, damit die Karte "passt".
Leider muss (aktuell) noch gebootet werden, damit der Sauger die neu auf den Sauger geladene Karte übernimmt...

Das müssten die v2 User ausprobieren und vorher die LAB Funktion aktivieren, beim v1 scheint das bisher nicht Möglich zu sein.

Also löschen/zurücksetzen der Karte geht, habe ich ja zum Testen mal gemacht
Mit dem fhem-Modul habe ich das bislang nur beim V2 getestet...

Bin nicht sicher, ob das mit der LAB Funktion nötig ist...
...weil man ja das Feature Karte speichern auch per App aktivieren kann...
Gut mit Valetudo dann nat. nicht mehr

Das mit den Zonen ist noch nicht so toll umgesetzt, das ändert sich aber wohl bald: https://github.com/Hypfer/Valetudo/pull/157

Ich mache das bisher so, das ich das log level hoch setzte und dann mit tail mir die Zonen aus der Shell raus kopiere.
Aber da hatte Shojo noch ein besseren Tipp, danke dafür.

Ja, das mit dem Logfile hab ich auch schon gemacht, ist aber nicht schön...
Die Idee von Shojo werde ich mir mal ansehen, sobald ich mal einen Sauger auf Valetudo "hochgezogen" habe...
Die FW gebaut habe ich schon mal

Die FloeVac APP scheint nicht mehr zu funktionieren. Weil man dort nur die IP vom Robi und Benutzername + Passwort angeben kann, aber was trägt man dort als user+pw ein?
Die war schon alt, min. über ein Jahr. Ich habe den v1 Robi ende 2017 bekommen.

Soweit ich mich erinnere (bzw. so hab ich das gemacht):

Daten aus der App löschen

Starten, dann kommt eine Import-Frage

Dort dann den Server aussuchen wo die Sauger hängen (Cloud)

Da dann eben User/Passwort für den Zugang zum Server (Cloud) eingeben und dann werden die Daten/Sauer von dort importiert...

Anders habe ich noch keinen Sauger in die App gebracht...


Zu Beginn war V1 auch noch auf dem China-Server, der V2 ging aber nur mit Europa-Server...
...daher musste ich erst mal die V1 auf Europa umziehen...

Und bei jedem neuen Sauger dann das selbe Spielchen: löschen und wieder importieren...

Gruß, Joachim

[MadMax-FHEM]

So ich hab jetzt einen V1 mal mit Valetudo "versorgt"...

3.3.9_003468

Werde ich mal testen und dan sehen, ob ich einen V2 auch "umrüste"...

Gruß, Joachim

[mark79]

Also da habe ich ja etwas getestet...
...die Lösung von Tobias/Thyraz wird für V1 (aktuell) nicht funktionieren: es gibt bestimmte Dateien beim V1 einfach nicht...

Und auch das Verhalten des Karten-Ladens ist wohl irgendwie anders...

Mhh das ließt nicht gut...   Ich habe nach der Datei gesucht und er findet nichts, nur irgendwelche Scripts:

root@rockrobo:~# find / -name *ersist*
/lib/udev/rules.d/60-persistent-storage-dm.rules
/lib/udev/rules.d/60-persistent-storage-tape.rules
/lib/udev/rules.d/60-persistent-input.rules
/lib/udev/rules.d/75-persistent-net-generator.rules
/lib/udev/rules.d/60-persistent-storage.rules
/lib/udev/rules.d/60-persistent-serial.rules
/lib/udev/rules.d/60-persistent-v4l.rules
/lib/udev/rules.d/60-persistent-alsa.rules
/etc/udev/rules.d/70-persistent-net.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-storage-dm.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-storage-tape.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-input.rules
/mnt/updbuf/lib/udev/rules.d/75-persistent-net-generator.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-storage.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-serial.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-v4l.rules
/mnt/updbuf/lib/udev/rules.d/60-persistent-alsa.rules

In den Github Foren habe ich dazu auch noch nix gefunden, außer das es für den v1 noch kommen "könnte"...
Du hast ein Bild gepostet, wo der Robi nur nach vorne fahren kann. Hilft das zu 99% bei dir, oder hattest du trotzdem schon mal eine gedrehte Karte?

Ich habe das mit den Zonen erst vor ein paar Tagen wieder gestest. Davor habe immer eine komplette Reinigung gestartet, aber eine Zonereinigung, z.B. unter dem Küchentisch über alexa zu starten ist schon coll (sofern es funktioniert).

Soweit ich mich erinnere (bzw. so hab ich das gemacht):

Daten aus der App löschen

Starten, dann kommt eine Import-Frage

Dort dann den Server aussuchen wo die Sauger hängen (Cloud)

Da dann eben User/Passwort für den Zugang zum Server (Cloud) eingeben und dann werden die Daten/Sauer von dort importiert...

Anders habe ich noch keinen Sauger in die App gebracht...

Da bin ich gespannt ob es bei dir klappt, mit Valetudo. Ich habe das bisher nicht hinbekommen.


Viele Grüße
Mark

[MadMax-FHEM]

Mhh das ließt nicht gut...   Ich habe nach der Datei gesucht und er findet nichts, nur irgendwelche Scripts:

Ja die Dateien sind nicht da...
Es gibt praktisch nur die last_map Datei...

Wenn die Startkoordinaten oder die Dockingkoordinaten (das weiß ich noch nicht) passen, dann geht auch das runterladen einer gespeicherten last_map...


Also: noch nicht gleich aufgeben

In den Github Foren habe ich dazu auch noch nix gefunden, außer das es für den v1 noch kommen "könnte"...
Du hast ein Bild gepostet, wo der Robi nur nach vorne fahren kann. Hilft das zu 99% bei dir, oder hattest du trotzdem schon mal eine gedrehte Karte?

Ja da habe ich auch immer drauf gehofft...
Aber ich kenne das auch von Vorwerk (hatte mal mit einem VR200 begonnen): kaum ist das Nachfolgemodell (angekündigt oder) da, gibt es (meist) keine Features mehr beim "alten" Sauger...
War also zu erwarten (aber sehr schade, weil ich eben für den V1 das Feature eher brauchen könnte als für meine V2: die putzen immer nur bei geschlossener Tür komplett weil sie auch wischen)...

Du hast ein Bild gepostet, wo der Robi nur nach vorne fahren kann. Hilft das zu 99% bei dir, oder hattest du trotzdem schon mal eine gedrehte Karte?

Nein der eingeparkte Sauger macht Probleme beim "Zonenreinigen"...
Er fährt wie verrückt nach hinten "in" die Station und geht dann in Fehler...

Ein anderer, der in einem (noch) längeren "Schlauch" "wohnt" funktioniert...
Da muss ich mal noch mal "kucken"...

Bei meiner letzten gerooteten FW hat geholfen, wenn ich die Zone "an" der Station beginnen habe lassen...

Mit der FW inkl. Valetudo geht das NICHT mehr.
Damit kriege ich den gar nicht mehr zu einer vernünftigen Zonenreinigung...

Aber evtl. habe ich auch etwas durch meine Tests "zerschossen"...
Werde den mal noch mal komplett zurück setzen und dann mal noch mal mit meiner letzten "guten" FW testen und dann noch mal mit der selben FW-Version wie jetzt mit Valetudo allerdings OHNE Valedtudo...

Und dann noch mal mit...

Mal sehen.


Wobei mein Testsauger (also der auf dem Foto) eigentlich immer nur Vollreinigung macht (Tür zu und los   )...
Daher hatte ich da wohl noch nichts bemerkt.

D.h. gedrehte Karte wäre mir hier egal bzw. war mir bislang egal.
Für einen Test habe ich sie mal "drehen lassen" und dann eben wieder einige gesicherte Dateien zurück gespielt und nach dem ein oder anderen Reboot hat es dann geklappt: alte Karte war da und Zone hat ach wieder gepasst (die kam aus fhem).

Ging aber irgendwie nur das eine mal und ich weiß noch nicht genau welche Dateien nötig sind/waren usw.


Flole geht mit Valetudo so halb: steuern etc. geht aber Karte abfragen und damit setzen von Zonen (nat. leider) nicht mehr...
Gut das Auslesen der Koordinaten mit der Valetudo-Oberfläche (Browser Entwickleroptionen) geht nat auch ganz ok.
Bzw. habe ich sie da dann gleich am PC und somit leichter in fhem

Ich schaue mir das mal an, vielleicht bastle ich einen "Kopier-Knopf"

EDIT: oder nat. mittels http://<ip vom Robo>/api/get_config (eben mal ausprobiert, das ist fast schon wie ein Copy-Knopf   )

Aber dazu muss das ganze erst mal (wieder) mit Valetudo funktionieren...

Ich habe das mit den Zonen erst vor ein paar Tagen wieder gestest. Davor habe immer eine komplette Reinigung gestartet, aber eine Zonereinigung, z.B. unter dem Küchentisch über alexa zu starten ist schon coll (sofern es funktioniert).

Da bin ich gespannt ob es bei dir klappt, mit Valetudo. Ich habe das bisher nicht hinbekommen.


Viele Grüße
Mark

Ja so eine Reinigung mit Alexa hab ich auch: sauge um den Wohnzimmertisch
Funktioniert gut, wenn mich Alexa dann mal verstanden hat

Allerdings sind dort noch "alte" gerottete FWs drauf...
...und das rühre ich auch erst mal nicht an.
Das Einlernen der Zonen hat viel Zeit gekostet...

Was bei mir hilft (um gedrehte Karten zu vermeiden / hatte ich mal, als ich den Sauger "zur Wartung" aufgehoben und einfach wieder nur ungefähr an die Position gesetzt habe):

Wenn ich Sauger habe die Zonenreinigung machen sollen, dann machen die NUR Zonenreinigung.
Also einmal komplett wegen Karte und dann nur noch Zonen.
D.h. ich habe dann für eine "Vollreinigung" einfach eine große Zone...

Wenn ich den Sauger reinige, leere, etc. dann nehme ich in aus der Station (rausfahren lassen geht noch) ud stelle ihn dann wieder in die Station...

(als ich das mal anders gemacht hatte war die Karte weg und die neu erstellte Karte war dann gedreht    )

Was ich nicht weiß, da es bei mir nicht zutrifft: wenn Türen mal offen oder geschlossen sind weiß ich nicht, ob der "Trick" (mit nur Zonenreinigung" funktioniert...
Habe ich auch schon anders gelsen...

Ansonsten teste ich mal noch etwas bzgl. Valetudo (habe ja jetzt meine FW-Umgebung   ) und auch noch mal bzgl. Karten speichern/laden bei V1...

@Tobias: sorry für das (viele) "fast Off-Topic"! Wenn es dich stört oder den Thread "kaputt" macht einfach sagen, dann lagere ich aus...

Gruß, Joachim

[mark79]

Da hast du viel geschrieben, ich habe jetzt leider nicht die Zeit auf alles einzugehen, müssen noch was vorbereiten und gleich gehts zum Grillen.
Aber ein bisschen was habe ich noch ausprobiert.

Wenn die Startkoordinaten oder die Dockingkoordinaten (das weiß ich noch nicht) passen, dann geht auch das runterladen einer gespeicherten last_map...
Also: noch nicht gleich aufgeben

Das funktioniert, ich habe das gerade ausprobiert. Also wenn man mal eine Karte hat und die Zonen dafür eingerichgtet sind, kann man die last_map Datei sichern und diese durch zurück kopieren + einem reboot wiederherstellen.
Anstatt eines reboots müsste das auch anders gehen, wenn man irgendeinen bestimmten Dienst neustartet.

Aber ich kenne das auch von Vorwerk (hatte mal mit einem VR200 begonnen): kaum ist das Nachfolgemodell (angekündigt oder) da, gibt es (meist) keine Features mehr beim "alten" Sauger...
War also zu erwarten (aber sehr schade, weil ich eben für den V1 das Feature eher brauchen könnte als für meine V2: die putzen immer nur bei geschlossener Tür komplett weil sie auch wischen)...

Ein paar Sachen haben sie nachgerüstet, glaube das waren die Zonenreinigung, also nachdem die Version 2 schon auf dem Markt war.
Für Wischen habe ich ein Medion Wischrobotor, der hat eine rotierende Bürste und zwei Tanks für Frisch- und Schmutzwasser. Allerdings muss man viel per Hand eingreifen, weil der Tank meistens nur für 1 1/2 Räume reicht und man ihn dann reinigen, nachfüllen und in den anderen Raum tragen muss muss.

Wenn ich den Sauger reinige, leere, etc. dann nehme ich in aus der Station (rausfahren lassen geht noch) ud stelle ihn dann wieder in die Station...

(als ich das mal anders gemacht hatte war die Karte weg und die neu erstellte Karte war dann gedreht    )

Was ich nicht weiß, da es bei mir nicht zutrifft: wenn Türen mal offen oder geschlossen sind weiß ich nicht, ob der "Trick" (mit nur Zonenreinigung" funktioniert...
Habe ich auch schon anders gelsen...

Das wäre die Frage, wenn man nur auf Zonereinigung setzt und dann Türen mal geschlossen sind, ob er dann die Reinigung abbricht, oder er wie bekloppt einen Weg sucht, um dort hin zu kommen.
Daher könnte man eine ganz normale Reinigung über "Start" starten und wenn er mit der Reinigung fertig ist, kann man die gesicherte Karte wieder zurück kopieren und dann würden die alten Zonen Koordinaten wieder funktionieren.

Und FloeVac funktioniert bei mir nicht, liegt wohl daran, das auch die Xiaomi APP nicht mehr funktioniert. Bestimmt kann man die DummyCloud auch irgendwie abschalten, so das auch die Xiaomi APP wieder funktioniert.
Aber im Grunde brauch ich beides nicht wirklich, weil mein Robi immer aus ist, wenn er nicht saugt und ich ihn via Telegram starten kann.

FloeVac hatte ich auch nur installiert, um die Zonen damit auszulesen, aber das hat nicht geklappt. Habe es dann ganz Oldschool so gemacht: https://forum.fhem.de/index.php/topic,73052.msg792092.html#msg792092
Aber mit Valetudo gehts einfacher.


Viele Grüße
Mark

[MadMax-FHEM]

Das funktioniert, ich habe das gerade ausprobiert. Also wenn man mal eine Karte hat und die Zonen dafür eingerichgtet sind, kann man die last_map Datei sichern und diese durch zurück kopieren + einem reboot wiederherstellen.
Anstatt eines reboots müsste das auch anders gehen, wenn man irgendeinen bestimmten Dienst neustartet.

Einen Dienst konnte ich noch nicht ausmachen, hier mal die Liste der Dienste:

Code Auswählen Erweitern


[ ? ]  console-setup
[ + ]  cron
[ - ]  dnsmasq
[ + ]  haveged
[ - ]  hostapd
[ ? ]  killprocs
[ ? ]  kmod
[ ? ]  networking
[ ? ]  ondemand
[ - ]  procps
[ ? ]  rc.local
[ + ]  resolvconf
[ - ]  rsync
[ + ]  rsyslog
[ ? ]  sendsigs
[ - ]  ssh
[ - ]  sudo
[ + ]  udev
[ ? ]  umountfs
[ ? ]  umountnfs.sh
[ ? ]  umountroot
[ - ]  urandom



Ich glaube aber, dass es das "Programm" "player" ist
(ist ja auch ein nettes Spielzeug   )

Ich hab sie mal gekilled in der Hoffnung, dass sie autom. wieder gestartet wird...
...war ein Schuß in den Ofen

Ich versuch mal mit kill und manuellem nachstarten...
...oder einem Service-Script welches das automatisch macht...

Sollte das dazu führen, dass die Karte dadurch geladen werden kann...
...wobei mir hier ein Reboot fast besser erscheint, wer weiß was der Kill und Restart so macht oder eben nicht macht...

Zumindest funktioniert der Sauger jetzt überhaupt wieder (vernünftig)...
...war schon drauf und dran zu meiner letzten "guten" FW zurück zu gehen.

Aber jetzt gebe ich Valetudo noch eine Chance...

Wobei das mit get_config bei mir nicht geht (evtl. nur gespeicherte Zonen?) aber beim Anlegen ("malen" in der Karte) gibt es ja keinen Speichern Knopf!?
Und dort wo man Zonen angeben/speichern kann werden Koordinaten verlangt (die ich aber ja nicht habe   ).

Aber mit F12 (Entwickleroptionen) und dann den "start_cleaning_zone" HTTP-Request auslesen, da stehen die Koordinaten dann drin...

Ein paar Sachen haben sie nachgerüstet, glaube das waren die Zonenreinigung, also nachdem die Version 2 schon auf dem Markt war.
Für Wischen habe ich ein Medion Wischrobotor, der hat eine rotierende Bürste und zwei Tanks für Frisch- und Schmutzwasser. Allerdings muss man viel per Hand eingreifen, weil der Tank meistens nur für 1 1/2 Räume reicht und man ihn dann reinigen, nachfüllen und in den anderen Raum tragen muss muss.

Ja, Zonenreingung kam noch...
...aber das war es dann.

Beim Vorwerk glaub ich kam dann die Karte doch noch...
...aber das war's dann.

Zonen usw. kam dann eben nur noch beim VR300...

Ja, ich hatte auch schon einen iRobot Wischdingens mit "Feuchtlappen"...
...aber der Xiaomi V2 ist da schon deutlich besser.

Der schafft ca. 4-6x Küche oder Bad bevor ich nachfüllen muss.

Das wäre die Frage, wenn man nur auf Zonereinigung setzt und dann Türen mal geschlossen sind, ob er dann die Reinigung abbricht, oder er wie bekloppt einen Weg sucht, um dort hin zu kommen.
Daher könnte man eine ganz normale Reinigung über "Start" starten und wenn er mit der Reinigung fertig ist, kann man die gesicherte Karte wieder zurück kopieren und dann würden die alten Zonen Koordinaten wieder funktionieren.

Da gibt es einiges in dem "Xiaomi Device" Thread...

Beim Karte-sichern probier ich noch ein wenig rum...
...aber ich denke es wird (bei mir) beim kopieren und rebooten bleiben (außer ich finde noch was)...

Aber zuerst muss ich mal sehen, ob ich bei Valetudo bleibe...

Und FloeVac funktioniert bei mir nicht, liegt wohl daran, das auch die Xiaomi APP nicht mehr funktioniert. Bestimmt kann man die DummyCloud auch irgendwie abschalten, so das auch die Xiaomi APP wieder funktioniert.
Aber im Grunde brauch ich beides nicht wirklich, weil mein Robi immer aus ist, wenn er nicht saugt und ich ihn via Telegram starten kann.

FloeVac hatte ich auch nur installiert, um die Zonen damit auszulesen, aber das hat nicht geklappt. Habe es dann ganz Oldschool so gemacht: https://forum.fhem.de/index.php/topic,73052.msg792092.html#msg792092
Aber mit Valetudo gehts einfacher.

Da der Sauger bei mir schon in der Flole-App drin war (war ja vorher in der Cloud) funktioniert das Steuern etc. noch (sind wohl die "normalen" Kommandos per TCP/IP), Karte anzeigen geht halt nicht...

Das Auslesen der Koordinaten war mit der Flole-App schon schön: einfach lange auf den "Start-Knopf" drücken und dann wurden sie in die Zwischenablage kopiert

Das mit dem Log hab ich auch schon gemacht ist aber schon mühsam...

Mit Valetudo geht auch, aber man muss zuerst mindestens mal die Zonenreinigung starten, um die Koordinaten zu bekommen...
...oder bin ich da zu doof?


Wenn das mit kopieren und zurückspielen der Karte "last_map" (ohne weitere Daten/Dateien) auch bei/nach gedrehtem Sauger/Sauger-Karte geht, kann das Script ja für V1 angepasst werden:

Karte holen/ablegen plus reboot...

Ich teste noch ein wenig mal sehen...

EDIT: also bei mir stimmen die Koordinaten die ich über die Valetudo-Webseite bekomme (vielleicht mache ich da auch was falsch) nicht, wenn ich diese mit dem fhem-Modul nutze... Ich habe mal Valetudo "deaktiviert" (hosts-Einträge gelöscht und in rc.local die iptables-Einträge [bzw. einfach zu beginn exit 0   ]), um mit der Flole-App wieder sehen zu können, wo er denn langfahren würde (das geht ja leider mit Valetudo [noch] nicht [wurde als Feature-Request irgendwann letztes Jahr September oder so eingetragen]) und da sind die Zonen ganz anders. Gleiches mit Goto... Ich hab schon X und Y gedreht etc. aber da scheint noch mehr anders zu sein!? So kann ich Valetudo leider nicht nutzen... Habe aktuell 3.3.9_003468 mit Valetudo (von gestern oder so)... Wenn ich (wie früher) die Koordinaten aus der Flole-App kopiere passt das prima im fhem-Modul...

Gruß, Joachim

[mark79]

Ich glaube aber, dass es das "Programm" "player" ist

Gut geraten.. Bei mir reicht ein killall player aus. Irgendein Dienst startet dann innerhalb Sekunden den player automatisch neu und die last_map Karte wird aktualisiert.


Bei mir ergibt: http://<ip>/api/get_config
Das hier: 

Code Auswählen Erweitern

{"spots":[],"areas":[["My zone",[[500,500,1000,1000,2],[500,500,1000,1000,2]]],["Schlafzimmer",[[500,500,1000,1000,2],[500,500,1000,1000,2],[500,500,1000,1000,2],[500,500,1000,1000,2]]],["My zone",[[500,500,1000,1000,2]]]],"mqtt":{"enabled":true,"identifier":"rockrobo","topicPrefix":"valetudo","autoconfPrefix":"homeassistant","broker_url":"mqtt://192.168.2.40:1883","provideMapData":false},"dummycloud":{"spoofedIP":"203.0.113.1","bindIP":"127.0.0.1"},"map_upload_host":"http://127.0.0.1"}
Und dort stehen nur die Zonen drin, die ich vorher gespeichert habe. Also in meinen Fall nur die Default Werte, weil ich nicht herausgefunden habe, wie man die Werte aus dem markierten Bereich auf der Karte speichert.

Mit Valetudo geht auch, aber man muss zuerst mindestens mal die Zonenreinigung starten, um die Koordinaten zu bekommen...
...oder bin ich da zu doof?

Wie man die Zonen in Valetudo speichert, also auf der Karte markiert und speichert, habe ich ehrlich gesagt auch noch nicht geblickt. 
Vielleicht geht das nicht, oder wir sind zu blöd.  In Version 0.4 soll das verbessert werden: https://github.com/Hypfer/Valetudo/pull/157
EDIT: schau mal hier rein, Shojo hat die Lösung schon gepostet (http://<ip vom Robo>/zone/): https://forum.fhem.de/index.php/topic,101197.msg948927.html#msg948927

Ja, ich hatte auch schon einen iRobot Wischdingens mit "Feuchtlappen"...
...aber der Xiaomi V2 ist da schon deutlich besser.
Der schafft ca. 4-6x Küche oder Bad bevor ich nachfüllen muss.

Ja die Navigation vom Medion Robi ist nicht gut und die Akkuleistung könnte auch besser sein (sind nur 4x 18650 Akkus drin), aber das ganze ist ausreichend.
Das gute ist halt, das er keinen feuchten Lappen hinter sich herzieht, sondern er eine Bürste hat und das Schmutzwasser direkt abgesaugt wird: https://www.medion.com/de/shop/p/saugroboter-medion-wischroboter-md-18379-mit-intelligenter-navigation-vollautomatische-nassreinigung-0-8-l-wasserbehaelter-bis-zu-80-min-laufzeit-50062051A1
Das hat glaube ich kein anderer Robi.


Viele Grüße
Mark

[MadMax-FHEM]

Das mit killall player (und warten, vielleicht war ich zu ungeduldig   ) probiere ich noch mal...

EDIT: ja wird auch bei mir nachgestartet. War wohl wirklich nur zu ungeduldig... (wobei es schon einige mehr Sekunden sind   )


Damit wäre dann ein "Restore" auch beim V1 machbar:

last_map sichern

last_map zurückspielen und dann mit killall player die Karte wieder laden


Ok, das mit: http://ip-sauger/zone hatte ich irgendwie überlesen, danke für die Unterstützung des "blinden Mannes"
Aber wenn die Koordinaten nicht für das fhem Modul brauchbar passen, dann werden Valetudo und ich keine Freunde... 

Ja das dort kommende Feature ist dann auch ganz nett aber wie geschrieben an die Koordinaten komme ich ja...
...aber sie passen nicht für die fhem-Modul-Zonen (oder Goto)...
(zumindest bei mir nicht)

Bei einem V2 hab ich das noch nicht getestet...
...will nicht gleich alle auf Valetudo umstellen bzw. nur, wenn V1 und V2 damit so funktionieren wie ich es ohne Valetudo gewohnt bin...
...da lasse ich die lieber mit der Cloud schwatzen...

Danke, Joachim

[mark79]

EDIT: ja wird auch bei mir nachgestartet. War wohl wirklich nur zu ungeduldig... (wobei es schon einige mehr Sekunden sind

Bei mir dauert das etwa 10 bis 20 Sekunden, bis der player neustartet und die Map in Valtudo angezeigt wird.

Damit wäre dann ein "Restore" auch beim V1 machbar:

last_map sichern

last_map zurückspielen und dann mit killall player die Karte wieder laden

Bis jetzt sieht das gut aus, ob das auch zuverlässig funktioniert, muss man aber noch testen.
Ich mache jetzt mit meinem V1 dann nur noch Zonenreinigungen und dann mal schauen.

...aber sie passen nicht für die fhem-Modul-Zonen (oder Goto)...
(zumindest bei mir nicht)

Vielleicht hat sich deine Karte geändert, oder durch eine neue Firmware die Koordinaten?
Bei mir funktionieren die Zonen und auch das Goto, via Valtudo und Fhem.

Allerdings die Goto Koordinaten kriege ich nur über die Shell ausgelesen (vorher Log Level hochsetzen): tail -f /mnt/data/rockrobo/rrlog/miio.log | grep goto


Viele Grüße
Mark

[MadMax-FHEM]

Hallo Mark,

danke für die Antworten!

Funktionieren die selben Koordinaten in Valetudo UND fhem?

Wie bekommst du die Koordinaten?
(immer noch) auslesen aus dem Log oder über Valetudo?

Wenn ich die Koordinaten aus Valetudo in fhem eingebe fährt er ganz anders...

Karte sieht (bzgl. Drehung etc.) in Flole-App (wenn ich die "Umleitung" kurz ausschalte) und in Valetudo gleich aus...

Wenn ich Koordinaten aus der Flole-App kopiere und in fhem eingebe, fährt der Sauger wie erwartet.

Auch schön zu sehen, weil man das eben in der Flole-App mitverfolgen kann...

Das geht bei Valetudo leider ja (noch) nicht...
Also man bekommt nicht eingeblendet welche Zone er reinigen würde...
...außer man startet Zone-Clean über Valetudo in der Kartenansicht...

Aber jetzt ist erst mal Ruhe, bin dann mal ein paar Tage weg...

Gruß, Joachim

[rakete123]

Hab das eben auch mal getestet. Via Valetudo fährt er korrekt eine Zone ab. Via FHEM mit identischen Koordinaten fährt er einfach irgendwo anders lang.

Komisch ist, er scheint einfach zu weit "oben" zu fahren, also wenn ich ihn in Valetudo beobachte. Kann aber zufall sein.

[Thyraz]

Lustig, der von euch identifizierte Player Service den man neustarten muss,
scheint OpenSource zu sein und nichts von Xiaomi selbst.

http://playerstage.sourceforge.net/wiki/Main_Page

Schon interessant wie so ein Gerät gestrickt wird mit Linuxsystem und OpenSource Komponenten.

[MadMax-FHEM]

Dachte ich mir auch...

Aber wenn man sich evtl. nicht unbedingt vielleicht an Open Source Regeln hält kann man nat. schnell einiges auf die Beine stellen...

EDIT: hätte vielleicht erst kucken/lesen sollen... Ist ja für Roboter gedacht...

Und player passt doch ganz gut...

Gruß, Joachim

[mark79]

Hallo,

Wie bekommst du die Koordinaten?
(immer noch) auslesen aus dem Log oder über Valetudo?

Entweder mit http://<ip>/zone
oder über das Log via tail.

Ich habe beides schon ausprobiert, wobei das aus dem Log besser mit copy/paste funktioniert.
Bei den Valetudo Zone Koordinaten fehlt am Ende noch die Anzahl der Reinigungen z.B. ,1] .. das besagt, wie oft gereinigt werden soll und evtl. muss man die Leerzeichen löschen.
Die GoTo Koordination kriegt man meine ich nur via Log heraus, aber das weiß ich nicht zu 100%.

Wenn ich die Koordinaten aus Valetudo in fhem eingebe fährt er ganz anders...
Karte sieht (bzgl. Drehung etc.) in Flole-App (wenn ich die "Umleitung" kurz ausschalte) und in Valetudo gleich aus...

Mhh das ist komisch? Das sollten doch die gleichen Koordinaten sein. Vielleicht wie gesagt, eine ,1] am Ende hinzufügen?
Ich verwende keine Xiaomi/Floevac APP mehr (lässt sich auch nicht mehr pairen) und bei mir funktionieren die Zonen.
Habe mir das Image aber auch generieren lassen und habe es nicht selbst gebaut.

Also man bekommt nicht eingeblendet welche Zone er reinigen würde...

Die Zone sieht man nicht, aber man sieht wo der Saugi derzeit ist und er aktualisiert die abgefahrene Strecke mit strichen.

Lustig, der von euch identifizierte Player Service den man neustarten muss,
scheint OpenSource zu sein und nichts von Xiaomi selbst.

http://playerstage.sourceforge.net/wiki/Main_Page

Schon interessant wie so ein Gerät gestrickt wird mit Linuxsystem und OpenSource Komponenten.

Ja ist fast alles Opensource, da haben die schon was schönes gezaubert.

Was mich noch interessieren würde ob die Clone genau so aufgebaut sind, wie z.B. BlitzWolf BW-VC1 oder 360 S6.


Viele Grüße
Mark

[rakete123]

Mhh das ist komisch? Das sollten doch die gleichen Koordinaten sein. Vielleicht wie gesagt, eine ,1] am Ende hinzufügen?
Ich verwende keine Xiaomi/Floevac APP mehr (lässt sich auch nicht mehr pairen) und bei mir funktionieren die Zonen.
Habe mir das Image aber auch generieren lassen und habe es nicht selbst gebaut.

Hilft bei mir nicht. Irgendwie gibts da ein Mismatch zwischen Valetudo und pyhton-miio.

[rakete123]

Okay ich habe das Problem gefunden. Es ist die Art und Weise wie Valetudo die Koordinaten anzeigt und dann später wieder anpasst:
Dafür ist dieser Teil relevant:

Code Auswählen Erweitern


            const yFlippedZone = [
                zone[0],
                Tools.DIMENSION_MM - zone[1],
                zone[2],
                Tools.DIMENSION_MM - zone[3],
                zone[4]
            ];

            // it seems as the vacuum only works with 'positive rectangles'! So flip the coordinates if the user entered them wrong.
            // x1 has to be < x2 and y1 < y2
            return [
                yFlippedZone[0] > yFlippedZone[2] ? yFlippedZone[2] : yFlippedZone[0],
                yFlippedZone[1] > yFlippedZone[3] ? yFlippedZone[3] : yFlippedZone[1],
                yFlippedZone[0] > yFlippedZone[2] ? yFlippedZone[0] : yFlippedZone[2],
                yFlippedZone[1] > yFlippedZone[3] ? yFlippedZone[1] : yFlippedZone[3],
                yFlippedZone[4]
            ]


DIMENSION_MM ist 51200. Also müssen y1 und y2  von 51200 abgezogen werden.
Und dann muss zusätzlich x1 kleiner x2 sein und y1 kleiner y2. Wenn nicht, müssen die Koordinaten getauscht werden.

Jetzt geht es bei mir
Kann man das evtl. ins FHEM Module einbauen? Vllt. sowas wie valetudo_zone_names als Attribute oder so?

[MadMax-FHEM]

Hey danke!

Probiere ich morgen gleich mal aus...

Vielleicht sollte ich öfter mal wegfahren und andere "basteln und testen" lassen...

Gruß, Joachim

[MadMax-FHEM]

Ich habe beides schon ausprobiert, wobei das aus dem Log besser mit copy/paste funktioniert.
Bei den Valetudo Zone Koordinaten fehlt am Ende noch die Anzahl der Reinigungen z.B. ,1] .. das besagt, wie oft gereinigt werden soll und evtl. muss man die Leerzeichen löschen.
Die GoTo Koordination kriegt man meine ich nur via Log heraus, aber das weiß ich nicht zu 100%.

Über die Entwickleroptionen des Browsers geht beides: Zonen und GoTo...

Also F12 und dann in Valetudo Zonen "malen" bzw. einen Goto-Punkt "setzen" und dann eben Zone-Clean oder GoTo aufrufen/starten und aus der Anfrage (F12 Entwickleroptionen kommen ja die abgesendeten HTTP-Requests) dann die Koordinaten kopieren...

Und bei dir passen tatsächlich die Koordinaten aus Valetudo auch für das fhem Modul!?

Weil mir geht es wie rakete123. Bei mir passt das nicht...

Ich werde aber jetzt mal den "Algorithmus" von rakete123 testen...

EDIT: eben getestet... Funktioniert!   Gott sei Dank legt man Zonen (ich zumindest) nicht so oft fest...

Gruß, Joachim

[MadMax-FHEM]

Und weil ich grad dabei war hab ich ne Sub gebastelt...
...kann man sicher besser machen (ich halt nicht   )...

Code Auswählen Erweitern


sub my_makeFHEMcoordinates($)
{
  my ($ValetudoCoordinates) = @_;
  my $Result = "";
 
  $ValetudoCoordinates = (split(/\[/,$ValetudoCoordinates))[1]; # "rauslösen" des Inhalts innerhalb der Eckigen Klammer(n)
  my $X1 = int((split(/,/,$ValetudoCoordinates))[0]); # int() ist vermutlich nicht nötig. War der erste Versuch die "führende" eckige Klammer "loszuwerden" hat leider nicht geklappt / hab's aber drin gelassen schadet ja nicht ;-)
  my $Y1 = int((split(/,/,$ValetudoCoordinates))[1]);
  my $X2 = int((split(/,/,$ValetudoCoordinates))[2]);
  my $Y2 = int((split(/,/,$ValetudoCoordinates))[3]);

  $Y1 = 51200 - $Y1;
  $Y2 = 51200 - $Y2;

  if($X1 > $X2)
  {
    my $X = $X1;
    $X1 = $X2;
    $X2 = $X;
  }
  if($Y1 > $Y2)
  {
    my $Y = $Y1;
    $Y1 = $Y2;
    $Y2 = $Y;
  }
 
  $Result = "[" . $X1 . "," . $Y1 . "," . $X2 . "," . $Y2 . ",1]";
 
  return $Result;
}


Aufruf dann so:

Code Auswählen Erweitern


my_makeFHEMcoordinates("[24540, 25827, 26244, 26448, 1]")


Mit oder ohne 1 am Ende ist egal.
Leerzeichen (weil die beim Rauskopieren bei Valetudo [zumindest bei mir] drin sind) sollten kein Problem sein...

Wichtig sind halt die eckigen Klammern, ansonsten muss der erste Split-Aufruf weg...
...bzw. irgendwas mit RegEx (war mir aber zu wild   ) was evtl. vorhandene Klammern etc. "rausnimmt"...
und die Anführungszeichen (also Übergabe eines Strings)!

Hab's aber jetzt nicht intensiv getestet...

Gruß, Joachim

[gsbox]

Hi.
Hat jemand eine Idee, wie ich die Karte vom letzten Saug-Vorgang in FHEM anzeigen lassen kann ? Wie kann ich das PNG bekommen ? Ich habe mir schon das https://github.com/Hypfer/ICantBelieveItsNotValetudo Projekt angeschaut, aber irgendwie blicke ich da nicht durch... Gibt es da nicht einen einfacheren Weg ?

Viele Grüße
Guido

[MadMax-FHEM]

Hallo Marcel/rakete123,

ich nehme hier mal Bezug zu dort: https://forum.fhem.de/index.php/topic,73052.msg950459.html#msg950459 (damit das nicht verloren geht bzw. dort evtl. OT wird / ok, dann ist es hier wohl OT / auch nicht besser )...

Hallo zusammen,

wäre es ggf. sinnvoll das Module zu erweitern damit es mit der Valetudo API auf den Vaccums sprechen kann?
Wir hatten da eine kleine Diskussion wegen der Koordinaten, siehe: https://forum.fhem.de/index.php/topic,101197.msg950415.html#msg950415

Aktiveren mit einem Attribute wie use_valetudo_api und dann könnte man über /api/get_config die Zonen aus Valetudo auslesen und automatisch in das zone_names Attribute übernehmen. Irgendwie mit einem SET Command z.b.

Ich würde auch selber mal versuchen das Module zu erweitern wenn das erlaubt ist.

mfg
Marcel

Das mit /api/get_config geht aber nur (zumindest bei mir), wenn man schon Zonen in Valetudo gespeichert hat...
...um das zu tun muss man entweder per /IP-Sauger/zone welche anlegen und die Koordinaten speichern...
...oder eben per "Entwickleroptionen" den HTTP-Aufruf "zone_clean" von Valetudo an den Sauger "abgreifen" und dort die Koordinaten nehmen...

Was ich überlege ist aus meiner Funktion mittels Notify und userattr beim Sauger folgendes zu ermöglichen:

neues Attribut "valetudo_zones" (userattr)...
Aufbau (praktisch wie zone_names): Zone1Name:[X1,Y1,X2,Y2,Anzahl] Zone2Name:[X1,Y1,X2,Y2,Anzahl]

Dann ein Notify auf "Änderung im Attribut 'valetudo_zones'" wo dann die Berechnung stattfindet und "zone_names" gesetzt wird...

Würde aber dann dort eingetragene (also die NICHT von valetudo_zones kommenden) Zonen "löschen" bzw. halt immer mit den Einträgen von "valetudo_zones" überschreiben...

Nur so als Idee...
...wenn ich das habe poste ich es mal.

@gsbox:

geht es nur um die Anzeige in fhem also beispielsweise in FhemWeb?
Evtl. geht sowas wie weblink, also einfach auf Valetudo "verlinken" oder per iFrame etc.

Ansonsten müsste man sich mal anschauen was dort gemacht wird um das Bild/Karte anzuzeigen.
Glaube nicht, dass das "nur" ein png ist...

EDIT: hab gerade geschaut. Ist kein png (gut dachte ich mir schon) und es ist einiges an Script notwendig um das Bild/Karte anzuzeigen... Evtl. iFrame und dann halt die gesamte Webseite einblenden...

EDIT2: folgendes geht für FhemWeb (RawDefinition) / die Attribute (v.a. bzgl. width/height nat. entsprechend anpassen)

Code Auswählen Erweitern


defmod AnzeigeValetudo weblink iframe http://IP-Adresse-Sauger
attr AnzeigeValetudo htmlattr width="480" height="560"
attr AnzeigeValetudo room Valetudo


Gruß, Joachim

[gsbox]

Hallo Joachim.

geht es nur um die Anzeige in fhem also beispielsweise in FhemWeb?

Nein, ich möchte das Bild via Telegram an mich senden. Mal schauen, ob das geht.

Ansonsten müsste man sich mal anschauen was dort gemacht wird um das Bild/Karte anzuzeigen.

Ok. Ich versuche mal, das herauszufinden. Falls ich erfolg habe, poste ich das Ergebnis.

Danke erstmal für Deine Antwort.
VG

[Shojo]

Ich nutze das aktuell schon mit Telegram.
Die Vorgehensweise ist recht simpel, Valetudo sendet über MQTT die Map Daten an ICantBelieveItsNotValetudo und dort kann man dann einfach die Map via URL als Bild abfragen.

Kann man z.B. so im FHEM verarbeiten :

Code Auswählen Erweitern

set TelegramBot cmdSend {GetFileFromURL("http://IP:PORT/api/map/image")}

[gsbox]

Hallo shojo.
Vielen Dank. Das hört sich ja gut an. Hm, kann ich den Dienst von ICantBelieveItsNotValetudo auch auf meinem raspberry pi laufen lassen? Ich habe keinen anderen Rechner, der die ganze Zeit läuft😕.
Oder läuft das direkt auf dem Robi? Aber das ist ja glaube ich nicht so sinnvoll...

Danke für die Info.
Vg

[Shojo]

"Früher" lief der Dienst auch direkt auf dem Robi, aber da das rendern der Bilder doch schon etwas Leistung braucht  (und davon hat der Robi auch nicht viel von über) wurde dieser Dienst in ICantBelieveItsNotValetudo  ausgelagert.

Bei mir läuft alles in Docker Containern und daher war es kein Aufwand den Dienst mal eben mit laufen zu lassen.
Aber auf den Raspi sollte das auch kein großes Problem darstellen, man muss halt nur NodeJS am laufen haben.

[gsbox]

Ok. Danke. Ich werde es mal versuchen.
Viele Grüße

[rakete123]

Das mit /api/get_config geht aber nur (zumindest bei mir), wenn man schon Zonen in Valetudo gespeichert hat...
...um das zu tun muss man entweder per /IP-Sauger/zone welche anlegen und die Koordinaten speichern...
...oder eben per "Entwickleroptionen" den HTTP-Aufruf "zone_clean" von Valetudo an den Sauger "abgreifen" und dort die Koordinaten nehmen...

Was ich überlege ist aus meiner Funktion mittels Notify und userattr beim Sauger folgendes zu ermöglichen:

neues Attribut "valetudo_zones" (userattr)...
Aufbau (praktisch wie zone_names): Zone1Name:[X1,Y1,X2,Y2,Anzahl] Zone2Name:[X1,Y1,X2,Y2,Anzahl]

Dann ein Notify auf "Änderung im Attribut 'valetudo_zones'" wo dann die Berechnung stattfindet und "zone_names" gesetzt wird...

Würde aber dann dort eingetragene (also die NICHT von valetudo_zones kommenden) Zonen "löschen" bzw. halt immer mit den Einträgen von "valetudo_zones" überschreiben...

Ich hab ein kleines Skript geschrieben, welches die Valetudo API ausliest und dann den passenden Output für FHEM erzeugt. Das kann dann einfach in das Attribute zone_names kopiert werden.

Skript liegt auf github: https://github.com/marcelfischer/fhem_stuff/blob/master/valetudo2fhem.pl

Genial wäre, wenn man das in das XiaomiDevice Module übernehmen würde, dann könnte ich mit einem simplen SET Command die Zonen aus Valetudo übernehmen.

BTW: Ich benutze das Teil ausschließlich über Valetudo aktuell.

[MadMax-FHEM]

@rakete123

Muss ich mir mal anschauen...
...allerdings ist jetzt erst mal "Urlaubspause"... 

Ich hab meine noch in der Europacloud von Xiaomi und steuere per fhem-Modul...

Einen hab ich jetzt mal mit Valetudo-FW geflasht...
...nutze ihn aber eigentlich auch nur per fhem-Modul...

Außer zum Karte kucken (geht ja dann nicht mehr anders) und "rumspielen"...
...da schaue ich dann mal "über" Valetudo rein...

Gruß, Joachim

[gsbox]

@Shoho
Hier meine Rückmeldung :
Ich habe es nun hinbekommen und ein laufendes NodeJS auf meinem Raspi 3 installiert. MQTT ist sowohl auf dem Sauger, als auch auf dem Raspi aktiviert und ich kann meine Karte mittels deines Kommandos "getFileFromUrl()" wunderbar auslesen und senden. Danke nochmal für die Hilfe.

Installieren von NodeJS via folgender Anleitung : https://crycode.de/installation-von-node-js

@rakete123
Vielen Dank für dein tolles perl-Skript für die Konvertierung der Koordinaten. Funktioniert super 

VG

[AET_FHEM]

=> bin da noch nicht ganz durch und bekomme das ICantBelieveItsNotValetudo nich so richtig ans laufen => hab leider bis jetzt keine Anleitung gefunden
kann mal einer erklären wie ich das auf einem Raspi 3 zum laufen bekomme 

[KurtK]

So, dank diesem Thread habe ich jetzt auch endlich ein Restore der Karte beim V1 geschafft. Vielen Dank.

Wer dies bei seinem V1 auch machen möchte, hier meine Lösung:

Ein Shell-Script mit folgendem Inhalt als User fhem anlegen:

Code Auswählen Erweitern

#!/bin/bash
roboip='<IP des Roboters>'
privatekey='<Speicherpfad + Dateiname des privaten Schlüssels>'
lastmap='<Speicherpfad + Dateiname der Karte>'
echo "reload map"
scp -i $privatekey $lastmap root@$roboip:/mnt/data/rockrobo/
echo "restart process"
ssh -i $privatekey root@$roboip 'killall player'
echo "finished"

Das Skript einmal in der Konsole ausführen um den Roboter zu den bekannten Hosts hinzuzufügen.


Abschließend lasse ich mit einem DOIF bei Rückkehr des Roboters in die Station die Karte resetten.

Bsp:

Code Auswählen Erweitern

([MQTT2_kueche_robo] eq "docked") ({system('/opt/fhem/roboter/roboter.sh&');;})
Dabei das Reading des Roboter auf jeden Fall zu event-on-change-reading hinzufügen, damit nicht alle 2 Minuten die Karte neu geladen und der Roboter abgeschossen wird.

[laberlaib]

Hallo,
nachdem hier das Homeoffice mit 2 Kindern immer überall Krümmel macht, möchte ich jetzt auch fixe Karte und Zonen auf meinem V1 möglich machen.

Aber ich komme bei der Installation nicht weiter:

Sauger hat Valetudo, ich hab root zugriff etc.
Wenn ich node testen will:

Code Auswählen Erweitern

node -v
Dann kommt bei mir folgender Fehler:

Code Auswählen Erweitern

node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
Googeln sagt mir, dass eine Datei fehlt, welche node benötigt in gewissen Versionen - die aktuelle für ARMv7 ist 12.16.2, die habe ich auf den Sauger geladen.

Bevor ich den Sauger jetzt mit Dateien zumüll - wovon ich gar nicht genau weiß, wie es geht - könnt Ihr mir sagen, mit welcher node-Version es bei Euch klappt?
Die würde ich dann unter "Previous Releases" ja finden und dann mit dieser Version weiter machen (und hoffentlich nur noch zum Danke sagen hier aufschlagen...).

Grüße
laberlaib


Edit: Hat sich erledigt - ich hab das dann ebenfalls per Skript erledigt.

[dominik]

So, dank diesem Thread habe ich jetzt auch endlich ein Restore der Karte beim V1 geschafft. Vielen Dank.

Wer dies bei seinem V1 auch machen möchte, hier meine Lösung:

Ein Shell-Script mit folgendem Inhalt als User fhem anlegen:

Code Auswählen Erweitern

#!/bin/bash
roboip='<IP des Roboters>'
privatekey='<Speicherpfad + Dateiname des privaten Schlüssels>'
lastmap='<Speicherpfad + Dateiname der Karte>'
echo "reload map"
scp -i $privatekey $lastmap root@$roboip:/mnt/data/rockrobo/
echo "restart process"
ssh -i $privatekey root@$roboip 'killall player'
echo "finished"

Das Skript einmal in der Konsole ausführen um den Roboter zu den bekannten Hosts hinzuzufügen.


Abschließend lasse ich mit einem DOIF bei Rückkehr des Roboters in die Station die Karte resetten.

Bsp:

Code Auswählen Erweitern

([MQTT2_kueche_robo] eq "docked") ({system('/opt/fhem/roboter/roboter.sh&');;})
Dabei das Reading des Roboter auf jeden Fall zu event-on-change-reading hinzufügen, damit nicht alle 2 Minuten die Karte neu geladen und der Roboter abgeschossen wird.

Danke für die Anleitung!

Könnte man das auch direkt am Saugroboter lösen? Die lastmap kann man in einem anderen Verzeichnis wegspeichern, aber mir fehlt noch die Information im Saugroboter wann er lädt. Hast du da vielleicht eine Idee?

//Edit
Ich glaube last_map wird immer am Ende des Saugvorgangs geschrieben - noch nicht 100% verifiziert. Wenn das der Fall ist, dann braeuchte man last_map nur alle paar Minuten pruefen und wenn es unterschiedlich zur gespeicherten Version ist einfach ueberschreiben.

[MadMax-FHEM]

Danke für die Anleitung!

Könnte man das auch direkt am Saugroboter lösen? Die lastmap kann man in einem anderen Verzeichnis wegspeichern, aber mir fehlt noch die Information im Saugroboter wann er lädt. Hast du da vielleicht eine Idee?

Entweder beim Booten oder man "schießt" die player "App" ab...
...startet autom. nach...

Gruß, Joachim

[dominik]

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:

Code Auswählen Erweitern

#!/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.

[MadMax-FHEM]

Nach dem Booten ist zu selten, da der Saugroboter fast nie neu startet.

Ich weiß aber du wolltest ja wissen "wann"

Viel Erfolg!

Gruß, Joachim

[dominik]

Achso, macht der Saugroboter bei jedem neu laden in der Dock einen Reboot?

[MadMax-FHEM]

Achso, macht der Saugroboter bei jedem neu laden in der Dock einen Reboot?

Denke nicht...

Das mit dem "killen" der "player App" ist schon der richtige Weg...

Gruß, Joachim

[dominik]

Ich hab es jetzt mal in die rc.local mit aufgenommen und das Script wird erfolgreich beim Starten geladen. Mal sehen ob morgen dann alles automatisch klappt.

Hier meine Anpassungen:

/opt/rockrobo/scripts/lastmaprestore.sh

Code Auswählen Erweitern

#!/bin/bash

sleep 600

NAVMAP=/run/shm/navmap*.ppm
SAVEDMAP=/mnt/data/rockrobo/top40_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

Code Auswählen Erweitern

chmod +x /opt/roborock/scripts/lastmaprestore.sh

/etc/rc.local

Code Auswählen Erweitern

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" 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.

/opt/rockrobo/scripts/lastmaprestore.sh &

exit 0

Bei rc.local sollte man gut aufpassen, ein Tippfehler kann dazu fuehren, dass man einen Factory Reset machen muss! Das sleep 600 nach dem Start soll nur dafuer sorgen, dass man in jeglichem Fehlerfall noch 10min Zeit hat sich per ssh zu connecten.

[dominik]

Ganz perfekt ist es leider noch nicht, wenn der Saugroboter beim Fahren die Karte komplett dreht, dann sind die Spuren spaeter mit last_map ausserhalb der Karte. Ich glaube man muss die robot.db vielleicht auch noch genauer analysieren.
ChargerPos.data und StartPos.data ebenfalls zu ueberschreiben bringt keine Aenderung.

Hat sich schon jemand die robot.db mit einem SQLite Viewer angeschaut?

[dominik]

In der robot.db sind 3 Tabellen drin:
- cleanmaps
- cleanrecords
- snapshots

cleanmaps:
Beinhaltet glaub ich die "Spuren".

cleanrecords:
Letzten 20 Reinigungen (m2, Zeit, Flaeche)

snapshots:
leer

Vielleicht bringt es etwas wenn man eine alte robot.db nimmt um die Karte zu drehen.

[MadMax-FHEM]

Was ich kenne ist, dass man aus der DB die Karten und Wege!? rausextrahieren kann...

Habe da irgendwo ein "Tool", muss ich mal suchen...

EDIT: so hier das "Tool" (paython script):

Code Auswählen Erweitern


#!/usr/bin/env python3
# See https://github.com/marcelrv/XiaomiRobotVacuumProtocol/blob/master/RRMapFile/RRFileFormat.md

import sqlite3, gzip, io, struct, sys, argparse
from datetime import datetime


def make_file_name(output_folder, timestamp, map_index):
    return '%s/%s_%d' % (output_folder, datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d_%H.%M.%S'), map_index)


def read_int(data):
    return struct.unpack('<i', data.read(4))[0]


def read_short(data):
    return struct.unpack('<h', data.read(2))[0]


def charger(data):
    pos_x = read_int(data)
    pos_y = read_int(data)
    return (pos_x, pos_y)


def grayscale_color(pixel):
    if pixel == 1:  # wall pixel
        return 128  # gray color
    else:  # outside, inside or unknown pixel
        return pixel


def rgb_color(pixel):
    if pixel == 1:  # wall pixel
        return [105, 207, 254]
    elif pixel == 255:  # inside pixel
        return [33, 115, 187]
    else:  # outside or unknown pixel
        return [pixel, pixel, pixel]


# http://netpbm.sourceforge.net/doc/pgm.html
def export_image_grayscale(data, image_len, timestamp, map_index, output_folder):
    file_name = make_file_name(output_folder, timestamp, map_index) + '.pgm'

    if image_len == 0:
        print('Warning: %s - empty image. Will not extract.' % file_name, file=sys.stderr)
        return
    else:
        print('Extracting: %s' % file_name)

    top = read_int(data)
    left = read_int(data)
    height = read_int(data)
    width = read_int(data)

    pixels = [grayscale_color(p) for p in data.read(image_len)]

    with open(file_name, 'wb') as file:
        file.write(('P5\n%d %d\n255\n' % (width, height)).encode())
        for h in range(height)[::-1]:
            file.write(bytes(pixels[h * width: h * width + width]))


# http://netpbm.sourceforge.net/doc/ppm.html
def export_image_colored(data, image_len, timestamp, map_index, output_folder):
    file_name = make_file_name(output_folder, timestamp, map_index) + '.ppm'

    if image_len == 0:
        print('Warning: %s - empty image. Will not extract.' % file_name, file=sys.stderr)
        return
    else:
        print('Extracting: %s' % file_name)

    top = read_int(data)
    left = read_int(data)
    height = read_int(data)
    width = read_int(data)
    rgb_width = width * 3

    pixels = [rgb for pixel in data.read(image_len) for rgb in rgb_color(pixel)]

    with open(file_name, 'wb') as file:
        file.write(('P6\n%d %d\n255\n' % (width, height)).encode())
        for h in range(height)[::-1]:
            file.write(bytes(pixels[h * rgb_width: h * rgb_width + rgb_width]))


def path(data, path_len, charger_pos, timestamp, map_index, output_folder):
    set_point_length = read_int(data)
    set_point_size = read_int(data)
    set_angle = read_int(data)
    image_width = (read_short(data), read_short(data))
   
    # extracting path
    path = [(read_short(data), read_short(data)) for _ in range(set_point_length)]

    # rescaling coordinates
    path = [((p[0]) // 50, (p[1]) // 50) for p in path]
    charger_pos = ((charger_pos[0]) // 50, (charger_pos[1]) // 50)

    # Creating image
    width, height = image_width[0] // 25, image_width[1] // 25

    file_name = make_file_name(output_folder, timestamp, map_index) + '_path.pgm'
   
    pixels = [0] * width * height

    for x, y in path:
        pixels[y * width + x] = 155

    for off_x in range(-2, 2):
        for off_y in range(-2, 2):
            idx = (charger_pos[1] + off_y) * width + charger_pos[0] + off_x
            pixels[idx] = 255

    with open(file_name, 'wb') as file:
        file.write(('P5\n%d %d\n255\n' % (width, height)).encode())
        for h in range(height)[::-1]:
            file.write(bytes(pixels[h * width: h * width + width]))


def parse(timestamp, bytes, do_coloring, output_folder):
    data = gzip.GzipFile(fileobj=bytes)

    magic = data.read(2)
    header_len = read_short(data)
    checksum_pointer = data.read(4)
    major_ver = read_short(data)
    minor_ver = read_short(data)
    map_index = read_int(data)
    map_sequence = read_int(data)

    while True:
        block_type = read_short(data)
        unknown = data.read(2)
        block_size = read_int(data)

        if block_type == 1:
            charger_pos = charger(data)
        elif block_type == 2:
            if do_coloring:
                export_image_colored(data, block_size, timestamp, map_index, output_folder)
            else:
                export_image_grayscale(data, block_size, timestamp, map_index, output_folder)
        elif block_type == 3:
            path(data, block_size, charger_pos, timestamp, map_index, output_folder)
        else:
            break


def main():
    parser = argparse.ArgumentParser(description='Map Extractor for Xiaomi Vacuum.\n'.format(sys.argv[0]))
    parser.add_argument('-c', '--color', dest='color', action='store_true', help='Color extracted image')
    parser.add_argument('-o', '--output', dest='output', type=str, default='.', help='Output folder')
    parser.add_argument('-f', '--file', dest='file', type=str, required=True,
                        help="Path to database file (found in '/mnt/data/rockrobo/robot.db' on vacuum)")

    args, external = parser.parse_known_args()

    file = args.file
    do_coloring = args.color
    output_folder = args.output

    with sqlite3.connect(file) as conn:
        for row in conn.cursor().execute('SELECT * FROM cleanmaps'):
            parse(row[0], io.BytesIO(row[2]), do_coloring, output_folder)


if __name__ == '__main__':
    main()


Ob man da was reinsropfen kann oder ob der sauger überhaupt danach geht, also auch reinschaut oder nur Historie reinschreibt...

Gruß, Joachim

[dominik]

Habs gefunden:
https://github.com/dgiese/dustcloud/blob/master/devices/xiaomi.vacuum.gen1/mapextractor/extractor.py

Laut dem Code, duerfte die ChargePosition auch in der Map hinterlegt sein.

[dominik]

Ich habe gerade eine alte robot.db drueber geschrieben. Funktioniert!

History ist dann natuerlich weg. Ich muss nochmals eine Drehung der Karte hinbekommen, dann sehe ich auch ob sich damit die Karte wieder sauber zurueck stellt.

//Edit
Ich glaube man braucht sowohl robot.db den richtigen Plan als letzten Eintrag und die passende last_map dazu. Dann sollte es auch 100% genau passen. Weil last_map zurueck schreiben, erzeugt meistens keine 100% richtige Darstellung der Spuren.

[MadMax-FHEM]

Ich hatte allerdings schon mal das Problem, dass (beim V1) nur ein laden der gespeicherten Karte nicht genügt hat...

Da war wohl sein internes Koordinatensystem "durcheinander"...

Ich musste ihn mal kurz aus dem Dock rauslassen und wieder zurückschicken...
Dann die Karte "drüberbügeln"
Erst dann hat die Karte wieder gepasst...

Hmmm, evtl. muss ich dann (langsam) doch mal einen meiner Sauger auf MQTT-Anbindung umstellen...

Aktuell bin ich dabei das "Firmware-Erstellungs-Script" zu "zerpflücken"...
Eigentlich ganz einfach was da gemacht wird

Habe schon mal das FW-Image gemounted...
...jetzt kann man ja "lustig" rumfuhrwerken etc.

Gruß, Joachim

[MadMax-FHEM]

Ich habe gerade eine alte robot.db drueber geschrieben. Funktioniert!

History ist dann natuerlich weg. Ich muss nochmals eine Drehung der Karte hinbekommen, dann sehe ich auch ob sich damit die Karte wieder sauber zurueck stellt.

Drehung weiß ich nicht aber prüfen, ob das mit der Karte geht:

einfach ganz böse aus der Doking aufheben und rumtun und irgendwo absetzen...

Dann stand zumindest meiner "im Wald"...

Wollte mal die Bürste reinigen und dachte gut stell ich ihn halt wieder ab und lass ihn zurücklaufen...
...hat nicht geklappt

Danach hat die Karte nicht mehr gepasst...
Zum Glück hatte ich eine Sicherung

Viel Erfolg, Joachim

[dominik]

robot.db ueberschreiben bringt leider nix. Bringt nur die History durcheinander, aber die Karte wird leider nicht zurueck gedreht. Hmm...ich weiss noch nicht wo das gespeichert wird.

[MadMax-FHEM]

robot.db ueberschreiben bringt leider nix. Bringt nur die History durcheinander, aber die Karte wird leider nicht zurueck gedreht. Hmm...ich weiss noch nicht wo das gespeichert wird.

Wo was gespeichert wird!?

Gruß, Joachim

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

[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

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

[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

[KurtK]

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:

Code Auswählen Erweitern

#!/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?

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

[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

[Cruiser79]

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/

[eckibrecki]

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:

Code Auswählen Erweitern

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