OZMO 950: cleanstatus="unknown" (adapter v0.5.3)

[volkerverkamp]

Moin,
wollte gerade ein Skript schreiben, welches auf den Abschluss einer Reinigung triggert - aber offenbar wird "cleanstatus" nicht (mehr?) aktualisiert sondern hat dauerhaft den Wert "unknown". Bliebe nur noch der Weg über "chargestatus" oder "deviceStatus", aber das wäre ja nicht dasselbe.

Bin mir nicht sicher, ob das schon immer so war...

[mrbungle64]

Moin,
wollte gerade ein Skript schreiben, welches auf den Abschluss einer Reinigung triggert - aber offenbar wird "cleanstatus" nicht (mehr?) aktualisiert sondern hat dauerhaft den Wert "unknown". Bliebe nur noch der Weg über "chargestatus" oder "deviceStatus", aber das wäre ja nicht dasselbe.

Hi @volkerverkamp

ich habe das Probem gefunden.

Bin mir nicht sicher, ob das schon immer so war...

Der "cleanstatus" wird auch vorher schon "unknown" gewesen sein.

Ich denke das bekommen wir mit dem nächsten Release behoben.

[mrbungle64]

@volkerverkamp @boriswerner

Ich war mal so "frech" und "mutig" :)
Version 0.5.4 steht auf GitHub bereit

[mrbungle64]

@volkerverkamp

Du solltest aber direkt bedenken, dass es sehr wahrscheinlich ist, dass sich die Bezeichnungen in "cleanstatus" noch mal ändern werden. Ich habe das jetzt erst mal soweit (hoffentlich) zum Laufen gebracht, dass die Werte aus der Library soweit durchgereicht werden.

Ich werde diesen Issue aber erst schließen, wenn ich es entsprechend im Wiki dokumentiert habe. Dann kannst Du das auch für Dein Skript verwenden und jederzeit dort nachschauen.

[Opa0815]

Bei mir werden sämtliche Status nicht aktualisiert.
chargestatus: docked
cleanstatus: idle
deviceStatus: idle

Ozmo 950, Version 0.5.4

[volkerverkamp]

Bei mir gehen die Status jetzt mit der 0.5.4 (Roboter läuft gerade):

[mrbungle64]

@Opa0815
danke für die Rückmeldung

Bei mir werden sämtliche Status nicht aktualisiert.
chargestatus: docked
cleanstatus: idle
deviceStatus: idle

Bzgl. "chargestatus" hatte ich auch nichts geändert, aber "cleanstatus" und "deviceStatus" sollten sich eigentlich aktualisieren. Kann es selber ja leider nicht testen ...

Immerhin hat es sich wohl von "unknown" auf "idle" geändert ;)

Kannst Du vielleicht im Log mal schauen, ob da im Debug Modus was diesbezüglich auftaucht?

Ozmo 950, Version 0.5.4

[mrbungle64]

Bei mir gehen die Status jetzt mit der 0.5.4 (Roboter läuft gerade):

@volkerverkamp
Sehr gut! 👍

@Opa0815
Vielleicht auch noch mal einen Neustart vom Adapter probieren?

[mrbungle64]

@Opa0815 @volkerverkamp @boriswerner

Gibt es noch jmd. bei dem dieses Problem auftritt?

[Opa0815]

Hi Sascha, geht jetzt.
Ich bekomme jetzt allerdings noch ein "unknown" als Status wenn ein Reinigungsprogram abgeschlossen/-gebrochen wird und der Ozmo zur Ladestation zurückkehrt.
Ist er dann auf der Station geht er wieder auf "idle" (wäre hier "charging" nicht besser?).

[mrbungle64]

Hi @Opa0815

Hi Sascha, geht jetzt.

Sehr gut 👍
Ist das noch mit der 0.5.4 oder mit der aktuellen Version (0.5.5)?

Ich bekomme jetzt allerdings noch ein "unknown" als Status wenn ein Reinigungsprogram abgeschlossen/-gebrochen wird und der Ozmo zur Ladestation zurückkehrt.

"unknown" als Wert vom cleanstatus?

Ist er dann auf der Station geht er wieder auf "idle" (wäre hier "charging" nicht besser?).

Ja vielleicht - aktuell wäre das so aber "richtig" ;)
(Ich nehme mal an, dass Du weiter vom cleanstatus sprichst)

Im deviceStatus sollte aber "charging" als Wert sein, oder?

[Opa0815]

Ist das noch mit der 0.5.4 oder mit der aktuellen Version (0.5.5)?

In beiden Versionen

Ich nehme mal an, dass Du weiter vom cleanstatus sprichst
Im deviceStatus sollte aber "charging" als Wert sein, oder?

Steht bei beiden Status auf "idle"

[mrbungle64]

Ist das noch mit der 0.5.4 oder mit der aktuellen Version (0.5.5)?

In beiden Versionen

ok, gut 👍

Im deviceStatus sollte aber "charging" als Wert sein, oder?

Steht bei beiden Status auf "idle"

Ich hatte da wohl was durcheinander gebracht, weil ich ja keinen Ozmo 950 habe. Bei dem Modell sind die Status im Moment ein bisschen anders.

Ich hatte das mal angefangen in eine Übersicht zu bringen:

• chargestatus
• cleanstatus

Die jeweils 1. und 2. Spalte sollte zusammen passen. Dort wo "Ozmo 950 implementation" in der 3. Spalte steht, wäre dann im Zweifelsfall für dich relevant.

Du kannst gerne Verbesserungsvorschläge machen - wir sind ja noch relativ am Anfang :)
Alle anderen sind natürlich auch gerne eingeladen ;)

[boriswerner]

Ich hab das nun mal durchgetestet und die Infos werden im Moment nicht korrekt verarbeitet (hier hatte ich zum Teil nur die states durchgegeben, die sind dann tlw. eben nicht bekannt und tlw. stumpf auf einen Wert gemappt, damit überhaupt etwas ankommt).
Dann kommt noch dazu, dass die Reihenfolge der eingehenden Messages entscheidend ist (der cleanstatus "idle" überschreibt direkt den chargestatus, wenn der Bot an der Station angedockt hat).
Das werde ich voraussichtlich am Wochenende mal an die anderen Status lt. Doku anpassen.

[Opa0815]

Wenns einfach wäre, könnt's jeder. ;)
Super, es wird immer besser.
Danke

[smarteule]

Hallo,
ich finde hier im Thema passt meine Frage vielleicht besser.
Es kann natürlich auch sein, ich bin wieder mal betriebsblind, aber ich habe folgendes Problem.

Im "DeviceStatus" wird seit der Version 0.5.5 alles super angezeigt, aber leider in Englisch. Nun möchte ich in meinem VIS alles in Deutsch anzeigen lassen. Für diesen "DeviceStatus" würde ich im VIS gern das Widget "basic-Value" verwenden wollen. Zur Auswertung werden in diesem ja die Zahlenwerte genutzt, wie zum Beispiel beim "waterLevel", welcher mit 1 bis 4 zuweisbar ist.

Könnt Ihr auch dort im "DeviceStatus" eine Zahlenzuweisung machen oder gibt es eine andere Variante dies umzuwandeln ohne Skript?

[mrbungle64]

@smarteule

Im "DeviceStatus" wird seit der Version 0.5.5 alles super angezeigt, aber leider in Englisch. Nun möchte ich in meinem VIS alles in Deutsch anzeigen lassen. Für diesen "DeviceStatus" würde ich im VIS gern das Widget "basic-Value" verwenden wollen. Zur Auswertung werden in diesem ja die Zahlenwerte genutzt, wie zum Beispiel beim "waterLevel", welcher mit 1 bis 4 zuweisbar ist.

Könnt Ihr auch dort im "DeviceStatus" eine Zahlenzuweisung machen oder gibt es eine andere Variante dies umzuwandeln ohne Skript?

Zahlenzuweisung finde ich schwierig, weil es sich um keine klare Reihenfolge oder Skala handelt.
Ich kann dir aber gerne kurz eine Vorlage für ein Skript schreiben welches den Wert unter '0_userdata.0' oder 'javascript' ablegt und Du die Zuweisung dann nach Deinen eigenen Vorstellungen machen kannst.

[smarteule]

Okay danke, das ist lieb von dir, aber ich wollte es nur vermeiden.
Ich dachte, dass als Beispiel paused immer die 1 hat, charging die 2, idle die 3, usw.
Ich schreib den Skript natürlich auch selbst, weil ich habe noch festgestellt, dass das Gleiche auch bei "ChargeStatus" ist. Dann werde ich mal was schreiben. Ich dachte nur man hätte es umgehen können. Danke.

[boriswerner]

Das Thema ist garnicht mal so einfach zu vereinheitlichen.
Es gibt 3 events, die hier zusammenspielen:
onCleanInfo: hier gibt es beim state "clean" die Info pause oder working (mit dem jeweiligen Reinigungstyp), oder den state "goCharging" (mit trigger "workInterrupt" oder "workComplete") oder den state "idle"
onChargeState: hier gibt es nur enable: 0 oder 1, kein returning (und einen mode, der aber bisher bei mir immer nur "slot" war)
reportStats: hier gäbe es dann die Info ob gestoppt wurde und ein stopReason (1 für erfolgreich abgeschlossen oder 2 für unterbrochen)

Ich versuche das mal ein bisschen sinnvoll unterzubringen, aber das schicken der richtigen events zur richtigen Zeit aus der richtigen Nachricht ist schon nicht so einfach, da ggf. wieder überschrieben wird.
alert habe ich auch weiterhin als cleanState. Die Alternative wäre auch da idle anzuzeigen, da der Bot den state dann mitschickt.

Mit meiner derzeitigen Änderung (noch nicht in github verfügbar, derzeit nur bei mir im Fork) wäre es wie folgt. Ist das in eurem Sinne?:

custom_area Reinigung aus der Station gestartet:
CleanReport: custom_area
ChargeState: charging
nach Verlassen der Station:
ChargeState: idle

Steht irgendwo rum (gestoppt):
CleanReport: idle
ChargeState: idle

Spot Area Cleaning:
CleanReport: spot_area
ChargeState: idle

Auto Cleaning:
CleanReport: auto
ChargeState: idle

Pausiert:
CleanReport: pause
ChargeState: idle

Zurück zur Station geschickt:
CleanReport: returning
ChargeState: returning

An der Station:
CleanReport: idle
ChargeState: charging

"idle" könnte man generell in "stop" übersetzen, aber dann zeigt er das auch nach getaner Arbeit in der Station an. Ansonsten könnte man noch "workInterrupt" oder "workComplete" auswerten.

[Opa0815]

Was ist eigentlich mit Meldungen wie "Seitenbürste blockiert", "Antriebsrad blockiert", ... Kommen die dann auch über die Status oder gibt es dann noch einen?

[boriswerner]

Die states sind in der neuen GitHub Version nun umgestellt. Ein bisschen was läuft im Log immer noch auf unhandled. Siehe aber insgesamt glaube ich schon ganz gut aus.
Für die Fehler gibt es schon einen separaten State. Das wird mit der neuen Version auch für den 950 sprechend gesetzt.

[mrbungle64]

Die states sind in der neuen GitHub Version nun umgestellt.
...

@boriswerner

• "docked" und "not charging" fallen nun ja komplett weg als chargestatus - ich nehme die dann mal im Adapter aus der Liste der validen Ladestatus.
• "custom_area" habe ich im Adapter zur Liste der validen Reinigungsstatus hinzugefügt.

[boriswerner]

Aus meiner Sicht ergeben die states jetzt ein sinnvolles Bild. Das einzige was nicht abgebildet ist, ist wenn man bei der Rückkehr zur Ladestation auf Pause drückt. Da bekommt man aber auch keine sinnvolle Info von Bot (er bleibt entsprechend auch auf returning stehen). Man kann ihn dann auch mit resume weiter schicken. Das ist allerdings auch keine Funktion, die über die App unterstützt wird. Von daher würde ich das jetzt Mal so stehen lassen. Statt Pause und resume sollte man dann einfach Stop und Charge nutzen, wenn man den Weg unterbrechen will.
Jemand sonst Einwände gegen die Schließung des issues?

[mrbungle64]

@boriswerner

Jemand sonst Einwände gegen die Schließung des issues?

nope 👍