X2: resume und error

[aski71]

Is there an existing issue for this?

• I have searched the existing issues and no issue is describing my issue

The problem

Hi,

ich stelle gerade fest, dass der resume Befehl auch noch nicht geht. (Ich hab's bisher mit mitm gechecked. Kann das sein, dass das analog zum stop auch wieder ein clean_V2 ist?)
Das Error Objekt wird auch noch nicht aktualisiert.

With which model does the problem occur?

Deebot X2 series

From which source you have installed the adapter?

GitHub

Version of the ioBroker adapter ("info.version")

1.4.14

Version of the ecovacs-deebot.js library ("info.library.version")

0.9.6-alpha.34

Version of the JS controller

5.0.19

Version of Node.js

18.19.1

Operating system

Linux

Anything in the logs that might be useful?

Der X2 geht auf Pause, wenn er ein Problem hat. Ich habe gerade das leidige Problem, dass er ständig gegen eine Ecke in der Wohnung dotzt (immer die selbe) und dann auf Pause geht mit "Meine Stoßschiene hängt fest". Ja klar, Du Idiot: Wenn Du Dich mit Gewalt gegen eine Ecke drückst und das nicht kapierst, hängt halt Deine Stoßschiene fest. 🙄 Bin da gerade mit dem Ecovacs Support am machen.

Dabei habe ich auch noch festgestellt, dass das "error" Objekt offenbar nicht aktualisiert wird. Das steht immer auf "NoError."

Im Log macht sich die ganze Situation wiefolgt bemerkbar:

`
ecovacs-deebot.0 | 2024-02-21 08:52:48.190 | warn | unknown errorCode:
-- | -- | -- | --
ecovacs-deebot.0 | 2024-02-21 08:52:34.431 | info | Run: resume
ecovacs-deebot.0 | 2024-02-21 08:50:43.543 | warn | BumpAbnormal: Bump sensor stuck

`

Also erst Bumper stuck. Dann habe ich in der App auf Fortsetzen gedrückt. Daraufhin hat er sein Reinigungsprogramm fortgesetzt.

Wenn der Bumper Stuck so einfach durch einen Resume zu beheben ist, würde ich das gerne automatisieren.

Viele Grüße
Alex

Additional information

No response

Which "other" models are you using?

No response

Ecovacs device class ("info.deviceClass")

No response

Communication protocol ("info.library.communicationProtocol")

None

Is the canvas module installed? ("info.library.canvasModuleIsInstalled")

None

[mrbungle64]

@aski71

ich stelle gerade fest, dass der resume Befehl auch noch nicht geht. (Ich hab's bisher mit mitm gechecked. Kann das sein, dass das analog zum stop auch wieder ein clean_V2 ist?)

Du könntest das im Adapter mal folgendermaßen testen:

command: clean_V2
payload:

{
    "act": "resume"
}

[mrbungle64]

@aski71

Das Error Objekt wird auch noch nicht aktualisiert.

Schau mal bitte, ob du hier was zurück bekommst:

command: getError
payload: leer

[aski71]

@aski71

Das Error Objekt wird auch noch nicht aktualisiert.

Schau mal bitte, ob du hier was zurück bekommst:

command: getError payload: leer

Ergebnis:
{"code":[]}

[aski71]

@aski71

ich stelle gerade fest, dass der resume Befehl auch noch nicht geht. (Ich hab's bisher mit mitm gechecked. Kann das sein, dass das analog zum stop auch wieder ein clean_V2 ist?)

Du könntest das im Adapter mal folgendermaßen testen:

command: clean_V2 payload:

{
    "act": "resume"
}

Das tut!

Bei dieser Gelegenheit: Das gilt auch für den "pause" Befehl. Der tut momentan auch nix, aber mit einem "act": "pause" eines "clean_V2" funktioniert auch der.

[mrbungle64]

@aski71

ich stelle gerade fest, dass der resume Befehl auch noch nicht geht. (Ich hab's bisher mit mitm gechecked. Kann das sein, dass das analog zum stop auch wieder ein clean_V2 ist?)

Du könntest das im Adapter mal folgendermaßen testen:
command: clean_V2 payload:

{
    "act": "resume"
}

Das tut!

Bei dieser Gelegenheit: Das gilt auch für den "pause" Befehl. Der tut momentan auch nix, aber mit einem "act": "pause" eines "clean_V2" funktioniert auch der.

Pause müsste seit der 1.4.15-alpha.1 eigentlich schon gehen, aber falls du die noch nicht installiert hast warte am besten noch bis ich Resume auch angepasst habe 😉

[aski71]

Ich bin noch auf 1.4.14.
Dann warte ich noch.
Konntest Du irgendwelche Erkenntnisse aus dem getError ziehen?

[mrbungle64]

@aski71

Konntest Du irgendwelche Erkenntnisse aus dem getError ziehen?

Noch nicht wirklich. Es wäre gut, wenn du das noch mal machen könntest während ein Fehler vorliegt.
Du könntest den Bot z.B. mal vom Boden hochheben/stellen oder den Staubbehälter entfernen.

[aski71]

Kein Staubbehälter: { "code": [110] }
Kein Bodenkontakt: { "code": [102] }

Und jetzt wird's interessant. Bei "Meine Stoßschiene hängt fest." kommt tatsächlich nichts zurück:
{ "code": [] }

Führt im Log zu:
ecovacs-deebot.0 | 2024-02-22 12:28:20.027 | warn | unknown errorCode:

Und im error Objekt steht dann tatsächlich einen Augenblick lang: "unknown errorCode".
Und kurz danach wieder: "NoError: Robot is operational"

[mrbungle64]

@aski71

Ich habe jetzt die 1.4.15-alpha.4 released.

Damit sollte auch der Resume Befehl funktionieren und es werden zusätzlich Events (Evt messages) geloggt.
Beispiel: Evt message: {"code":1021,"event":"Unhandled Evt code: '1021'"}
Du könntest mal schauen, ob statt einem Error für "Meine Stoßschiene hängt fest" ein Evt kommt (also mitgeloggt wird). Dem Evt-Code würde ich dann die Fehlermeldung zuweisen.

[aski71]

Danke. Probier ich gleich morgen.
Info reicht als Logging-Einstellung?

[mrbungle64]

@aski71

Info reicht als Logging-Einstellung?

Ja

[aski71]

Hier der aktuelle Log.
Nach dem Bumper Stuck kommt leider nur ein "Error parsing response data".

ecovacs-deebot.0 | 2024-02-23 09:43:13.926 | warn | Error parsing response data
ecovacs-deebot.0 | 2024-02-23 09:43:12.075 | warn | BumpAbnormal: Bump sensor stuck

Was ich auch immer wieder sehe ist das hier. Weiß aber nicht, ob das eine Bedeutung hat:
ecovacs-deebot.0 | 2024-02-23 09:43:07.192 | info | State value to set for "ecovacs-deebot.0.map.deebotPositionCurrentSpotAreaID" has to be type "string" but received type "number"

Dieses Event kam, als der Deebot die Heimreise angetreten hat:
ecovacs-deebot.0 | 2024-02-23 09:39:24.883 | info | Evt message: {"code":1021,"event":"Unhandled Evt code: '1021'"}

Dieses Event kam, als er losgefahren ist:
ecovacs-deebot.0 | 2024-02-23 09:00:24.891 | info | Evt message: {"code":1166,"event":"Unhandled Evt code: '1166'"}
ecovacs-deebot.0 | 2024-02-23 08:59:41.774 | info | Run: clean
ecovacs-deebot.0 | 2024-02-23 08:59:36.785 | info | Set cleaning mode: 1

Randnotiz: Was ich auch nebenbei mit schöner Regelmäßigkeit bekomme, ist das hier:
ecovacs-deebot.0 | 2024-02-23 04:54:38.470 | warn | Received error message: Request failed with status code 502 for command getCarpetInfo

Ich habe mir auch ein kleines Script gebaut, das auf Änderungen des error Objekts reagiert:
Da passierte bei Bumper Stuck folgendes:

javascript.0
2024-02-23 09:43:28.456 info script.js.MoX2.logMoX2error: NoError: Robot is operational

javascript.0
2024-02-23 09:43:13.932 info script.js.MoX2.logMoX2error: Error parsing response data

javascript.0
2024-02-23 09:43:12.104 info script.js.MoX2.logMoX2error: BumpAbnormal: Bump sensor stuck

Das heißt: Das Fehlerhandling und Schreiben in das error Objekt auf Deiner Seite scheint fein zu sein. Es wird nur vom Deebot sofort wieder was anderes kommuniziert und damit das error Objekt überschrieben.

[aski71]

Konntest Du damit irgendwas anfangen?

[mrbungle64]

@aski71

Konntest Du damit irgendwas anfangen?

Ja im Großen und Ganzen schon, aber es war halt viel Zeugs auf einmal 😉

Nach dem Bumper Stuck kommt leider nur ein "Error parsing response data".

Ja, besser wäre ein "Response data empty" oder so was, aber etwas greifbares kommt ja leider nicht von der API.

Dieses Event kam, als der Deebot die Heimreise angetreten hat ...

Die Evt Codes sind halt auch leider undokumentiert, so dass ich mir für jeden Code was überlegen müsste, was dann evtl. nicht genau zutrifft. Alles ein bisschen schwierig ...

Randnotiz: Was ich auch nebenbei mit schöner Regelmäßigkeit bekomme, ist das hier:
ecovacs-deebot.0 | 2024-02-23 04:54:38.470 | warn | Received error message: Request failed with status code 502 for command getCarpetInfo

Kommt das im Interval, oder eher "nur" wenige Male am Tag?

Es wird nur vom Deebot sofort wieder was anderes kommuniziert und damit das error Objekt überschrieben.

Ja, das Error Code Handling hat noch Luft nach oben. Man müsste an so vielen Stellen mal ran, wenn die Zeit dafür da wäre 😉

[aski71]

@aski71

Konntest Du damit irgendwas anfangen?

Ja im Großen und Ganzen schon, aber es war halt viel Zeugs auf einmal 😉

Haha, ja. Mea culpa. :)

Nach dem Bumper Stuck kommt leider nur ein "Error parsing response data".

Ja, besser wäre ein "Response data empty" oder so was, aber etwas greifbares kommt ja leider nicht von der API.

Dieses Event kam, als der Deebot die Heimreise angetreten hat ...

Die Evt Codes sind halt auch leider undokumentiert, so dass ich mir für jeden Code was überlegen müsste, was dann evtl. nicht genau zutrifft. Alles ein bisschen schwierig ...

Verstehe. Das ist natürlich doof.

Randnotiz: Was ich auch nebenbei mit schöner Regelmäßigkeit bekomme, ist das hier:
ecovacs-deebot.0 | 2024-02-23 04:54:38.470 | warn | Received error message: Request failed with status code 502 for command getCarpetInfo

Kommt das im Interval, oder eher "nur" wenige Male am Tag?

Das kommt wohl sporadisch. Heute noch gar nicht.

Es wird nur vom Deebot sofort wieder was anderes kommuniziert und damit das error Objekt überschrieben.

Ja, das Error Code Handling hat noch Luft nach oben. Man müsste an so vielen Stellen mal ran, wenn die Zeit dafür da wäre 😉

Wenn man's weiß, kann man Script-technisch damit umgehen.
Ist wohl eher von Ecovacs seltsam umgesetzt.