[Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest
-
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
Meinst Du die Warnung "Unhandled chargestatus: null" im Log?
Den "Fehler" (hat eigentlich keine negativen Auswirkungen) habe ich eben behoben - sollte mit der nächsten Version dann weg seinJepp, und ich weiß doch, deswegen auch "Joke", aber dann kriegste die 0.01 % auch noch
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
Wie kann ich das "zulassen"?
Mein JS ist ganz leidlich, für einen Adapter hat es bisher aber nie gereicht, ich bin in anderem einfach schneller ^^
Aber hier mal ein JS-Beispiel unter "0_userdata.0.Statistik"...
Wie man sieht lässt sich "Statistik" nicht editieren (per JS createState erzeugt), "Wetter" dagegen schon. Ich weiß nicht ob das gewollt ist oder ein Bug, zumindest wenn man zB.createState("0_userdata.0.Statistik", ...); createState("0_userdata.0.Statistik.Wetter", ...);ausführt, kann man "Statistik" editieren, wobei ein
createState("0_userdata.0.Statistik.Wetter", ...);dieselbe Struktur anlegt, "Statistik" aber dann nicht editierbar ist.
-
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
Wie kann ich das "zulassen"?
Mein JS ist ganz leidlich, für einen Adapter hat es bisher aber nie gereicht, ich bin in anderem einfach schneller ^^
Aber hier mal ein JS-Beispiel unter "0_userdata.0.Statistik"...
Wie man sieht lässt sich "Statistik" nicht editieren (per JS createState erzeugt), "Wetter" dagegen schon. Ich weiß nicht ob das gewollt ist oder ein Bug, zumindest wenn man zB.createState("0_userdata.0.Statistik", ...); createState("0_userdata.0.Statistik.Wetter", ...);ausführt, kann man "Statistik" editieren, wobei ein
createState("0_userdata.0.Statistik.Wetter", ...);dieselbe Struktur anlegt, "Statistik" aber dann nicht editierbar ist.
Das sind aber jetzt nur Ordner unterhalb von "0_userdata" - aber nicht die root-Ordner der Instanzen.
Ich sehe jetzt auch, dass der Benutzer z.B. beim admin, web, node-red und lovelace Adapter die Rechte hat was zu ändern.
Ich weiß nur noch nicht wie man das "zulassen" kann und ob ich das überhaupt will
Da können Benutzer dann auch Dinge treiben die dann u.a. Probleme verursachen. -
@mrbungle64 Das war auch nur als Beispiel, selbiges gilt aber auch im root, nur das man da eigentlich halt nicht so ganz direkt Ordner anlegen kann
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
Ich weiß nur noch nicht wie man das "zulassen" kann und ob ich das überhaupt will
Da können Benutzer dann auch Dinge treiben die dann u.a. Probleme verursachen.Ich brauche es nicht wirklich, ich habe nur einen + könnte es auch notfalls selbst editieren. Aber sämtliche ioBroker-eigen-Adapter erlauben es zum Beispiel
Aber dein Adapter, deine Entscheidung und es hat ja auch keinerlei Auswirkung auf die Funktionalität. Streich es einfach
...und nach dem ich getippt habe, könntest du nicht einfach "deviceModel oder -Name" in die Instanz-Beschreibung hineinschreiben lassen? "Dann wär der Käse gegessen..."
-
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
...und nach dem ich getippt habe, könntest du nicht einfach "deviceModel oder -Name" in die Instanz-Beschreibung hineinschreiben lassen? "Dann wär der Käse gegessen..."
Das Wörtchen "einfach" würde ich jetzt "einfach" mal streichen, aber ich bin gerade dabei herauszufinden wie das geht.
Das gehört meiner Meinung nach nicht zum Standardumfang eines Adapters -
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Das war auch nur als Beispiel, selbiges gilt aber auch im root, nur das man da eigentlich halt nicht so ganz direkt Ordner anlegen kann
Ich verstehe noch nicht so ganz, was Dein Beispiel dann damit zu tun hat
Grundsätzlich sind das zwar alles Objekte (also "objects" im Sinne des Core Concepts vom ioBroker) - aber der root-Ordner der Adapter Instanz (z.B. "ecovacs-deebot.0") wird initial vom ioBroker generiert und das Objekt beim Start der Instanz geladen.
Man arbeitet also zur Laufzeit mit einer Instanz dieses Objekts. Dieses dann zur Laufzeit zu modifizieren (also z.B. in dem Moment wo der Adapter den Namen des Devices per Event gemeldet bekommt) ist meiner Meinung nach mit Vorsicht zu genießen.Wenn mir das ein Adapter Entwickler erklären kann, wie man das quasi gefahrlos zur Laufzeit machen kann und man auch das gewünschte Ergebnis dabei bekommt, dann würde ich mich freuen.
Edit: Siehe nächster Post von mir
-
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Das war auch nur als Beispiel, selbiges gilt aber auch im root, nur das man da eigentlich halt nicht so ganz direkt Ordner anlegen kann
Inzwischen habe ich herausgefunden, warum es Adapter gibt, wo man den Namen der Instanz ändern kann - diese haben den "type"
meta.Beispiel aus der "io-package.json" vom Web Adapter:
"instanceObjects": [ { "_id": "", "type": "meta", "common": { "name": "user files and images for background image", "type": "meta.user" }, "native": {} }, ...Warum das so ist und ob das "richtig" ist kann ich nicht sagen. Müsste mir mal jmd erklären
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
Ich weiß nur noch nicht wie man das "zulassen" kann und ob ich das überhaupt will
Da können Benutzer dann auch Dinge treiben die dann u.a. Probleme verursachen.Ich brauche es nicht wirklich, ich habe nur einen + könnte es auch notfalls selbst editieren. Aber sämtliche ioBroker-eigen-Adapter erlauben es zum Beispiel
Aber dein Adapter, deine Entscheidung und es hat ja auch keinerlei Auswirkung auf die Funktionalität. Streich es einfach...und nach dem ich getippt habe, könntest du nicht einfach "deviceModel oder -Name" in die Instanz-Beschreibung hineinschreiben lassen? "Dann wär der Käse gegessen...
Darauf hatte ich mich in meinem vorherigen Post bezogen - wir sind da jetzt ein bisschen durcheinander gekommen
-
@mrbungle64 Ich weiß nicht wie es bei dir ist, aber mich "fuchst" das dann immer irgendwie an und ich will das hinkriegen. Im Grunde ist es aber nur ein "nice to have" (für wenige User mit mehreren Saugrobotern) und der Adapter erledigt seine Arbeit mehr als top.
Ggf. andere Idee (wie gesagt Adapter sind nicht meins): musst du die DPs sofort anlegen oder kann man das auf "später" verlagern? Könntest du dann nicht "einfach (^^)" in die Konfiguration noch ein Feld ala "Bezeichnung des Saugroboters" einfügen und dies dann als Name des Objekts benutzen und dann die DPs erzeugen?
btw: ja ich kenne "einfach" zur Genüge. Das letzte eines Users hat dann zwei Tage Entwicklung gekostet
...oder trete die ganze Idee einfach in die kleine, runde Papierablage auf dem Fußboden und gut is
-
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Ich weiß nicht wie es bei dir ist, aber mich "fuchst" das dann immer irgendwie an und ich will das hinkriegen. Im Grunde ist es aber nur ein "nice to have" (für wenige User mit mehreren Saugrobotern) und der Adapter erledigt seine Arbeit mehr als top.
Ja, deswegen habe ich es ja gestern auch mal probiert - ich hätte ja eben auch selbst Interesse dran, da ich 3 Geräte eingebunden habe (und manchmal zum Testen noch ein weiteres).
Ggf. andere Idee (wie gesagt Adapter sind nicht meins): musst du die DPs sofort anlegen oder kann man das auf "später" verlagern? Könntest du dann nicht "einfach (^^)" in die Konfiguration noch ein Feld ala "Bezeichnung des Saugroboters" einfügen und dies dann als Name des Objekts benutzen und dann die DPs erzeugen?
Habe ich auch schon dran gedacht. Müsste aber trotzdem erst mal weiter forschen, wie es überhaupt sauber (ohne zu tricksen) geht. Habe dazu werder was in der Doku noch im Forum gefunden.
btw: ja ich kenne "einfach" zur Genüge. Das letzte eines Users hat dann zwei Tage Entwicklung gekostet
So ist das
...oder trete die ganze Idee einfach in die kleine, runde Papierablage auf dem Fußboden und gut is
Ja, ich lege das zumindest erst mal auf Eis. Im Moment möchte ich diese Version erst mal stabil bekommen bzw. als solche veröffentlichen.
-
Seit heute ist die Version 1.0.13 verfügbar.
Es gibt nur ein paar kleinere Verbesserungen:
- Die "Unhandled chargestatus: null" Warnung im Log sollte nun bei den 950er Modellen (920/950/T8) nicht mehr kommen
- Beim Datenpunkt "map.deebotPositionCurrentSpotAreaID" sollte jetzt der Wert "void" erscheinen, wenn bei der Library das Canvas Modul nicht (korrekt) installiert ist. Das wurde geändert, damit man das von "unknown" unterscheiden kann.
Zur Erklärung: Bei "unknown" hat die Library versucht die SpotArea zu ermitteln - bei "void" nicht (da das Modul fehlt). Das Canvas Modul bleibt aber weiterhin eine optionale Abhängigkeit - daher diese Optimierung.
Ich hoffe weiterhin auf ein paar weitere Rückmeldung - auch positive Rückmeldungen natürlich sind willkommen
-
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
Die "Unhandled chargestatus: null" Warnung im Log sollte nun bei den 950er Modellen (920/950/T8) nicht mehr kommen
Zumindest beim 950er nicht mehr
Bisher lüppt alles, mal sehen was er am WE bei der nächsten Saug-/Wischrunde meint... -
Ich habe mal die Datenpunkte des Adapters (in deutscher Sprache) dokumentiert:
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/wiki/Datenpunkte-(DE)Auch hier würde ich mich über Rückmeldungen freuen, ob das alles so verständlich ist.
Falls Ihr Fragen dazu habt, kann ich die auch gerne hier beantworten
-
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
ob das alles so verständlich ist.
Ist es
Ev. höchstens "totalTime Dauer der Reinigungen (hh:mm:ss)" --> Gesamtdauer... oder wie bei "totalNumber" --> Dauer der Reinigungen (hh:mm:ss) gesamt
und
"Die Mehrzahl der Datenpunkte sind vom Modell anhängig." Wohl um ein Zeichen auf der Tastatur verrutscht
-
@sborg said in Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
@mrbungle64 sagte in Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
ob das alles so verständlich ist.
Ist es
Ev. höchstens "totalTime Dauer der Reinigungen (hh:mm:ss)" --> Gesamtdauer... oder wie bei "totalNumber" --> Dauer der Reinigungen (hh:mm:ss) gesamt
und
"Die Mehrzahl der Datenpunkte sind vom Modell anhängig." Wohl um ein Zeichen auf der Tastatur verrutschtDanke für das Feedback
Habe das entsprechend angepasst
-
Habe heute die Version 1.1.0 veröffentlicht. Die ist nahezu identisch mit der 1.0.13.
Wenn heute nichts dramatisches mehr auffällt wird das dann die Stable Version -
Eben auch mal saugen/wischen lassen, läuft alles perfekt, alle DPs wie es sein sollte
...jetzt muss ich nur noch meine Lieblingsarbeit verrichten und endlich mal eine VIS dazu bauen... -
@sborg said in [Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
Eben auch mal saugen/wischen lassen, läuft alles perfekt, alle DPs wie es sein sollte
...jetzt muss ich nur noch meine Lieblingsarbeit verrichten und endlich mal eine VIS dazu bauen...Vielen Dank noch mal für Dein regelmäßiges Feedback
Die Version 1.1.0 ist seit heute im Stable Repo -
@sborg sagte in [Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
...jetzt muss ich nur noch meine Lieblingsarbeit verrichten und endlich mal eine VIS dazu bauen...
Muss noch mal nachbohren
(ist noch nicht ganz fertig...)
ich muss mir also die JSON noch ein wenig umbauen. Werde ich wohl mal in NodeRED versuchen.- Unix-Timestamp in Nanosekunden
- Dauer in Minuten umrechnen
- Fläche m² anhängen
und die eigentliche Frage: was sind denn die Text-äquivalente zu stopReason?
"1" wahrscheinlich "Ohne Fehler", aber "2" und "3"...? Hast du da Infos für mich -
@sborg said in [Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest:
und die eigentliche Frage: was sind denn die Text-äquivalente zu stopReason?
"1" wahrscheinlich "Ohne Fehler", aber "2" und "3"...? Hast du da Infos für michHi @SBorg
für den OZMO 950 habe ich leider (noch) keine Infos dazu.
Für ein paar andere Modelle hatte ich mal was gefunden.
Die Lookup table sieht da folgendermaßen aus:exports.STOP_REASON = { 's': 'clean_successful', 'r': 'battery_low', 'a': 'stopped_by_app', 'i': 'stopped_by_remote_control', 'b': 'stopped_by_button', 'w': 'stopped_by_warning', 'f': 'stopped_by_no_disturb', 'm': 'stopped_by_clearmap', 'n': 'stopped_by_no_path', 'u': 'stopped_by_not_in_map', 'v': 'stopped_by_virtual_wall' };Vielleicht kannst Du davon ja was von zuordnen.
Wenn ich mal mehr Infos dazu habe, sage ich Dir gerne Bescheid. -
@mrbungle64 @SBorg ich hatte das auch mal gesucht und bin auch nur auf die Buchstaben gestoßen. Die Reasons sind die, die in der App im Cleaning Log in der Detailansicht (die einzelnen "Karten") angezeigt werden. Ich hatte mal angefangen zu sammeln, aber das dann nicht mehr groß verfolgt:
1 = "Cleaning complete" / "Reinigung abgeschlossen" (also von sich aus fertig geworden)
2 = "Cleaning has been ended manually" / "Reinigung wurde manuell beendet" (über die App, ich bin nicht sicher ob auch das stop über den iobroker Adapter dazu führt)
3 = "Cleaning has been ended" / hier hab ich keine deutsche Übersetzung aufgeschrieben und derzeit auch keinen in meinem Protokoll. @SBorg du hast noch die 3 in deinem Log stehen. Magst du mal schauen, was das Reinigungsprotokoll der App auf deutsch dazu sagt? Und weißt du noch, wie die Reinigung beendet wurde?
Außerdem werden 1 und 2 mit einem grünen Punkt im Log angezeigt, 3 wird orange/gelb angezeigt. -
Danke für die Infos
@boriswerner Leider habe ich gerade letzte Woche alle Logs gelöscht.
1+2 kann ich bestätigen (wobei ich bei "2" es auch noch nicht über den Adapter probiert habe, aber per Original Alexa-Skill setzt er ebenfalls eine 2)
...und 3? Gute Frage. Zumindest stimmen die m² nicht so ganz. Ich hatte bis dato aber nur einmalig einen "echten" Abbruch, als sich ein Stück Kabel um die Hauptbürste wickelte und diese blockierte.
...die NodeRED-Idee war zwar nicht schlecht, doch muss ich eigentlich mein scheitern eingestehen. Es ist zwar jetzt ein Flow, aber die Kernkomponente ist dann doch wieder eine JS-Funktion geworden...
Aber tut was es soll und ist so nun als JSON-Widget darstellbar:
