Test Adapter mihome-vacuum v2.0.x

[dirkhe]

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?

[Neuschwansteini]

@dirkhe die Karte funktioniert anscheinend nur, wenn der Sauger über die mihome App registriert ist.

[radierer]

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

[D3ltoroxp]

@Xenon said in Test Adapter mihome-vacuum v2.0.x:

@dirkhe

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=true

Ok, 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-dev

Ich hatte gleich noch upgrade mit gemacht, aber wenn sich bestehende SW updatet, ändert sich doch nicht einfach der Port oder ?

[Jaschkopf]

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]

@radierer

Genau so. Hatte bisher immer funktioniert.

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

Jetzt hat er zwar die Karte geladen, diese wird aber nicht aktualisiert wenn der Roboter saugt. Hat jemand noch eine Idee?

Gruß Jaschkopf

[dirkhe]

Einmal in die mihome App einloggen und nen Moment warten

[radierer]

@backfisch88 said in Test Adapter mihome-vacuum v2.0.x:

@radierer

Genau so. Hatte bisher immer funktioniert.

Besten Dank! Funktioniert wie gewünscht ..

[Jaschkopf]

@dirkhe Ein Traum jetzt klappt es. Vielen Dank

[backfisch88]

@radierer bei mir sagt er nur „unknown command“

[radierer]

@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!?

[D3ltoroxp]

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

http://192.168.178.31:54321/mihome-vacuum.admin/actualMap_0.png

Habs auch mit dem Standardport probiert, ging auch nicht. Es ging aber mal so, was fehlt hier noch ?

[Knallochse]

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

Falls 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

[Kueppert]

@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).

[Jaschkopf]

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

[Diginix]

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

[Coffeelover]

@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.)

[Knallochse]

@Kueppert die Instanz versucht wohl (laut @dirkhe) auch nach Ende des Saugvorgangs die Karte im Millisekundenbereich abzuholen. Das hört erst auf, indem man die Instanz neu startet.
Hier das dazugehörige Issues auf Github
https://github.com/iobroker-community-adapters/ioBroker.mihome-vacuum/issues/149
Da kann wohl nur @Meistertr helfen.

Knallochse created this issue in iobroker-community-adapters/ioBroker.mihome-vacuum

closed gleichbleibende Hohe Prozesslast nach Saugvorgang #149

[Coffeelover]

@Knallochse @Kueppert Ich habe mir der Einfachkeit halber einen Cron zum Neustart der Instanz angelegt. Gerade einfach stumpf einmal täglich in der Nacht. Zukünftig vielleicht mal über ein Script, sobald der Sauger wieder beim Laden ist.