Test Adapter mihome-vacuum v2.0.x
-
@seppel786 Bei mir genau das Setting von @Diginix Auch ein 1S, auch Xiaomi Cloud.
-
@All: Hat jemand ein ähnliches Setting wie ich, wo die Karte in Verbindung mit Valetudo funktioniert?
@Meistertr
Ist ein "Problem" mit Valetudo bekannt?! -
Bei den Karten kenne ich mich nicht so gut aus, aber kann es sein, dass man nicht auf die roborock App zurück darf, wenn man ioBroker nutzen möchte?
-
@dirkhe die Karte funktioniert anscheinend nur, wenn der Sauger über die mihome App registriert ist.
-
@backfisch88 said in Test Adapter mihome-vacuum v2.0.x:
Map reset hab ich noch nicht ausprobiert, aber eine Vorhandene Map widerherstellen lassen geht auf alle fälle nicht (zumindest nicht über den recover_map;[xxx] Befehl
Moin .. wie genau und wo hast du denn den Befehl "recover_map;[xxx]" ausgeführt?
-
@Xenon said in Test Adapter mihome-vacuum v2.0.x:
damit habe ich die Canvas Fehler beseitigt
sudo iobroker stop cd /opt/iobroker sudo apt update sudo apt-get install build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-dev sudo npm install canvas --unsafe-perm=trueOk, das scheint bei mir auch funktioniert zu haben. Leider scheint jetzt Port 80 belegt zu sein, den ich eigentlich für Alexa und Node.js benötige...
Kann das was mit dem Canvas Update zu tun haben oder mit dem hier ?
sudo apt-get install build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devIch hatte gleich noch upgrade mit gemacht, aber wenn sich bestehende SW updatet, ändert sich doch nicht einfach der Port oder ?
-
Servus. Ich habe zwei Roborock S50 im Betrieb. Beide laufen über das selbe Xiaomi Konto auf dem Europa Server. Jedoch bekomme ich bei einem keine Karte geladen. Instanz 0 (Erdgeschoss) lädt sie einfach nicht. Bei Instanz 1 (Obergeschoss) klappt das wunderbar. Beide Roboter laufen mit stock Firmware 3.5.7_002008.
Das Update von canvas hab ich schon Probiert, hat jedoch nichts gebracht. Hat jemand eine Idee?
Gruß Jaschkopf
-
-
@backfisch88 Habe das auch gerade mal probiert und bekomme im Log folgenden Fehler:
mihome-vacuum.0 2020-06-05 18:18:00.833 warn (28716) Could not receive Mappointer, giving up mihome-vacuum.0 2020-06-05 18:16:56.282 error (28716) [69](X_send_command) -> response time out mihome-vacuum.0 2020-06-05 18:16:52.783 info (28716) send message: Method: recover_map Params: [1] mihome-vacuum.0 2020-06-05 18:16:51.820 info (28716) send message: Method: get_recover_mapsJetzt hat er zwar die Karte geladen, diese wird aber nicht aktualisiert wenn der Roboter saugt. Hat jemand noch eine Idee?
Gruß Jaschkopf
-
Einmal in die mihome App einloggen und nen Moment warten
-
@backfisch88 said in Test Adapter mihome-vacuum v2.0.x:
Genau so. Hatte bisher immer funktioniert.
Besten Dank! Funktioniert wie gewünscht ..
-
@dirkhe Ein Traum jetzt klappt es. Vielen Dank
-
@radierer bei mir sagt er nur „unknown command“
-
@backfisch88 said in Test Adapter mihome-vacuum v2.0.x:
@radierer bei mir sagt er nur „unknown command“
Hm .. seltsam. Ich hab ja nix anderes gemacht .. außer zusätzlich noch den Befehl zum zurückfahren an die Ladestation.
Evtl. mal den Haken bei "eigene Befehle zulassen" in der Adapterkonfig raus- und wieder reinmachen!?
-
Sagt mal, wie kann ich denn noch mal die Map anschauen ?
Das war doch irgendwie so im Browser ?
http://192.168.178.31/mihome-vacuum.admin/actualMap_0.pnghttp://192.168.178.31:54321/mihome-vacuum.admin/actualMap_0.pngHabs auch mit dem Standardport probiert, ging auch nicht. Es ging aber mal so, was fehlt hier noch ?
-
Habe heute gemerkt, das die Prozessorlast meiner Synonolgy DS918+ erhöht war.
Ich habe mir dann die Prozesse im IoBroker Docker angeschaut und dabei festgestellt, dass die 2 Instanzen des mihome-vacuum Adapters (2 Stück MiVacuum 1) die meiste Last (aller Adapter) beanspruchen. Ich hatte die Version vor 3 Tagen von 1.10.5 auf 2.0.9 angehoben. Nach einem Restart der Instanzen hat sich die Prozesslast wieder deutlich beruhigt.Mein System :
Docker auf Syn918+
Admin 4.0.9
JS Controller 3.1.4
Node.js 10.20.1Falls es weiter Informationen braucht, bitte melden.
Ich beobachte es auf jeden Fall weiter.Edit: Habe gerade mal die Datenaufzeichnung der Prozessorlast meiner Synology DS918+ in Grafana angeschaut, und habe festgestellt das die Instanz des Saugers, welcher heute morgen seine Arbeit verrichtete, mit start des Saugvorgangs eine deutlich erhöhte Last verursachte, und dass ganze dann auf diesen Niveau blieb (auch nach Ende des Saugvorgangs bis zum Neustart der Instanz)
Edit2: gerade hat ein Zeitgesteuerter Saugvorgang stattgefunden. Danach das gleiche Problem mit der ansteigenden Prozesslast.
Ich hatte Log auf Debug gestellt, es kamen aber keine auffälligen Meldungen
-
@Knallochse genau das gleiche habe ich auch bereits beobachtet als mein Saugi lief. Ich musste unter Putty die Instanz killen. Nachdem der Saugi wieder in seiner Station stand und ich den Adapter wieder gestartet hab, war die Last wieder weg.
Ich hatte dazu ein Git-Issue erstellt. Allerdings ließen meine Logs nur auf fehlenden Speicher (RAM) deuten (ich habe 3,5GB für ioBroker auf meinem NUC). -
Servus. Gibt es eine Möglichkeit die Map für die Vis etwas zuzuschneiden? Bei mir wird an den Bodentiefen Fenstern teilweise der Außenbereich mit aufgezeichnet was in der Vis dann ziemlich doof aus sieht. Hat da jemand einen Tipp?
Gruß Jaschkopf
-
@Jaschkopf Hab keine VIS, aber sowas löst man idR in dem man das Bild in einem div o.ä. anzeigt und das div kleiner darstellt als das Bild und mit negativen margin Werten schiebt man sich den anzuzeigenden Bildausschnitt zurecht.
So kann man auch hineinzoomen, falls nötig. -
@Jaschkopf Alternativ zu der Lösung von Diginix: HTML-Boxen über die unschönen Seitenränder platzieren und deren Z-Index minimal höher als den Bildwert einstellen. Das hilft insbesondere bei nicht rechteckigen Grundflächen. (Verschiebt sich allerdings möglicherweise, wenn die Karte neu aufgebaut wird. Aber das sollte bei der DIV-Lösung nicht anders sein.)
