NEWS
[Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest
[Beendet] Ecovacs Deebot Adapter v1.0.13 Beta/Latest
-
@sborg said in Test Adapter ecovacs-deebot v1.0.11 Latest:
@mrbungle64 Kann man den ggf. noch abfangen:
ecovacs-deebot.0 2021-01-27 12:28:01.791 error (8853) Exception-Code: ECONNREFUSED: connect ECONNREFUSED 47.254.143.26:8883 ecovacs-deebot.0 2021-01-27 12:28:01.791 error at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) ecovacs-deebot.0 2021-01-27 12:28:01.791 error (8853) Error: connect ECONNREFUSED 47.254.143.26:8883 ecovacs-deebot.0 2021-01-27 12:28:01.791 error (8853) uncaught exception: connect ECONNREFUSED 47.254.143.26:888330 Sekunden später hatte er dann seine Verbindung
Hat der Adapter sich nach dem Verbindungsproblem selbständig wieder gefangen oder musstest Du die Adapter Instanz neu starten?
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
Danke für die Infos, ich schaue mir das später mal an
-
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
@sborg said in Test Adapter ecovacs-deebot v1.0.11 Latest:
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
Normalerweise kann der Adapter mit einem "Request Timeout" umgehen - die kommen bei mir mehrmals am Tag. Die Ecovacs Server sind ja leider nicht gerade für 100% Verfügbarkeit bekannt - das merkt man ja auch immer wieder mal in der Mobile App.
In diesem Fall kam es ja schon beim Adapter-Start zu einem Problem den MQTT-Server zu erreichen und danach kam zusätzlich der Timeout bei einem Post Request. Das hat der Adapter dann wohl nicht mehr geschafft sich von alleine zu reconnecten, da es ja beim Start schon gehakt hatte.
Ich muss mal schauen, wie mal das perspektivisch noch optimaler gelöst bekommt, wenn die Server oder ein Teil davon nicht erreichbar sind. Es ist ja leider nicht einfach damit getan den Fehler abzufangen - der Reconnect muss ja auch dann sauber funktionieren, wenn die Server mal längere Zeit nicht erreichbar sind. Und das leider bei mehreren Gerätetypen die auch noch unterschiedliche Protokolle benutzen
Was ich u.a. damit sagen wollte: das ist kein spezielles Problem der aktuellen Version. Aber danke auf jeden Fall für das Feedback - ich werde auf jeden Fall weiter an der Stabilität des Adapters und der Library arbeiten.
-
@sborg said in Test Adapter ecovacs-deebot v1.0.11 Latest:
@mrbungle64 Zum Teil. Gestartet hat er sich zwar, wurde dann aber nicht mehr "grün" (blieb auf "gelb"). Da ich schon meine Probleme mit dem Restart hatte, gehe ich dann eigentlich her und stoppe + starte den entsprechenden Adapter wieder.
Hier mal das kpl. Log:
Normalerweise kann der Adapter mit einem "Request Timeout" umgehen - die kommen bei mir mehrmals am Tag. Die Ecovacs Server sind ja leider nicht gerade für 100% Verfügbarkeit bekannt - das merkt man ja auch immer wieder mal in der Mobile App.
In diesem Fall kam es ja schon beim Adapter-Start zu einem Problem den MQTT-Server zu erreichen und danach kam zusätzlich der Timeout bei einem Post Request. Das hat der Adapter dann wohl nicht mehr geschafft sich von alleine zu reconnecten, da es ja beim Start schon gehakt hatte.
Ich muss mal schauen, wie mal das perspektivisch noch optimaler gelöst bekommt, wenn die Server oder ein Teil davon nicht erreichbar sind. Es ist ja leider nicht einfach damit getan den Fehler abzufangen - der Reconnect muss ja auch dann sauber funktionieren, wenn die Server mal längere Zeit nicht erreichbar sind. Und das leider bei mehreren Gerätetypen die auch noch unterschiedliche Protokolle benutzen
Was ich u.a. damit sagen wollte: das ist kein spezielles Problem der aktuellen Version. Aber danke auf jeden Fall für das Feedback - ich werde auf jeden Fall weiter an der Stabilität des Adapters und der Library arbeiten.
@mrbungle64 Ich dachte auch gar nicht, dass das ein "echtes" Problem ist. Den fehlerhaften Neustart hatte ich da noch gar nicht bemerkt. Hatte ich bis dato auch noch nicht. Meine Intention war eher der Art, wenn er den Server nicht erreicht, dann lieber nur eine Info oder Warnung. Error sieht immer so "erschreckend"
aus.Aber auf jeden Fall ein Thx für den tollen Adapter
-
Aktuelle Version 1.1.0 Veröffentlichungsdatum 11.02.2021 Repository/Verwahrungsort Beta (latest) Hallo zusammen,
ich würde gerne die Version
1.0.91.0.13 des Adapters als Stable veröffentlichen.Dazu wollte ich zum einen mal ein Zusammenfassung bereitstellen, was sich seit der Version 1.0.3 getan hat
und zum anderen Euer Feedback einholen, ob es vielleicht noch Probleme mit der Version1.0.91.0.13 (Beta/Latest) gibt.Ein paar Anmerkungen vorab
- Wichtig wäre vor allem, wenn eine bereits vorher genutzte Funktion mit der aktuellen Version nicht mehr (zuverlässig) gegeben ist. Natürlich sollten neue Funktionen ebenfalls zuverlässig funktionieren
- Für die als experimentell gekennzeichneten Funktionen nehme ich gerne Feedback entgegen - diese sind aber für die Stable nur eingeschränkt ausschlaggebend
- Der Adapter wird regelmäßig mit folgenden Modellen gestestet:
- Deebot 901
- Deebot OZMO 930
- Deebot OZMO 920/950
- Bei allen anderen Modellen bin ich auf Feedback angewiesen, denn es gibt weiterhin keine öffentlich zugängliche Dokumentation der Ecovacs API
Ich freue mich auf Euer Feedback
Version 1.1.0 (11.02.2021)
- Stabile Version (entspricht quasi Version 1.0.13)
Version 1.0.13 (10.02.2021)
- 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
Version 1.0.12 (30.01.2021)
- Es wurden wieder ein paar Sachen optimiert und Fehler (hoffentlich) behoben
Version 1.0.11 (24.01.2021)
- Es wurden ein paar Kleinigkeiten verbessert und der "map" Channel wurde für den OZMO 900 freigegeben.
Version 1.0.10 (20.01.2021)
- Es wurden ein paar kleinere Fehler behoben und noch ein paar Sachen "unter der Haube" optimiert
Änderungen seit Version 1.0.3
Neu unterstütze Modelle
- Deebot U2 Serie
- Sämtliche Varianten vom Deebot OZMO T8
Neue Funktionen
- Die SpotAreas aus dem "map"-Kanal können autom. mit dem "control"-Kanal synchronisiert werden
- Es werden Datenpunkte für virtuelle Begrenzungen erstellt (900/920/930/950/T8, aktuell aber nur read-only)
- Einstellung für die Sprache (de, en) der von Ecovacs vorgegebenen Bezeichnungen der Bereiche (920/950/T8)
- Zurücksetzen von Verbrauchsmaterial (900/920/930/950/T8)
- Anpassen der Lautstärke (920/950/T8)
- Versch. experimentelle Funktionen (müssen explizit aktiviert werden und sind nur für ein paar Modelle verfügbar):
- GoTo-Funktion ("control.extended.goToPosition")
- Einmalig pausieren, kurz bevor der Roboter auf die Ladestation fährt ("control.extended.pauseBeforeDockingChargingStation")
- Immer vor dem Laden pausieren, wenn Wassertank eingesetzt ("control.extended.pauseBeforeDockingIfWaterboxInstalled")
- Einmalig pausieren, wenn ein bestimmter Bereich ereicht ist ("control.extended.pauseWhenEnteringSpotArea")
- Einmalig pausieren, wenn ein bestimmter Bereich verlassen wird ("control.extended.pauseWhenLeavingSpotArea")
Verbesserungen und Fehlerbehebungen
- Das Reinigungsprotokoll wird bei den 950 basierten Modellen wieder korrekt bezogen (920/950/T8)
- Bei mehreren Instanzen (also mehreren Geräten) wurden Probleme mit der Authentifizierung behoben
- "unknown" kann als Wert für "map.deebotPositionCurrentSpotAreaID"/"Name" unterdrückt werden
- Die Adapter Einstellungen wurden ein bisschen aufgeräumt
- Canavas ist nun eine optionale Abhängigkeit
- Ein paar Anpassungen als Vorbereitung auf den js-controller ab 3.2.x
Weggefallene Funktionen
- Einstellung für eine feste Anzahl von SpotAreas unter "control"
Bekannte Probleme
- Bei der T8 Serie werden "info.chargestatus" und "info.cleanstatus" noch nicht in allen Fällen korrekt eingetragen.
- Der Deebot 710 scheint seit der 0.6.0 nicht mehr vollständig zu funktionieren. Problem wird gerade untersucht.
- Es gibt einen einzelnen Issue, dass bei einem Deebot 900 die "map.deebotPositionCurrentSpotAreaID"/"Name" oft "unknown" ist
Es gibt einen einzelnen Issue, dass bei einem Deebot OZMO 950 die Daten nach einiger Zeit nicht mehr aktualisiert werden
Die 2 aufgeführten Issues beim Deebot 900 und OZMO 950 treten bei meinen quasi baugleichen Modellen nicht auf.
@mrbungle64 said in Test Adapter ecovacs-deebot v1.0.12 Latest:
Version 1.0.12 (30.01.2021)
Es wurden wieder ein paar Sachen optimiert und Fehler (hoffentlich) behoben
Seit heute steht die Version 1.0.12 zur Verfügung.
Es wurden noch ein paar Sachen optimiert und damit hoffentlich u.a. noch ein paar Fehler behoben.
Würde mich (insbesondere von Benutzern der T8 Serie) über Feedback freuen. -
Vielen Dank @mrbungle64, das wusste ich nicht. Jetzt funktioniert es bestens. Vielen Dank für Deine Hilfe. Viele Grüsse Axel
@webzimm said in Test Adapter ecovacs-deebot v1.0.12 Latest:
Vielen Dank @mrbungle64, das wusste ich nicht. Jetzt funktioniert es bestens. Vielen Dank für Deine Hilfe. Viele Grüsse Axel
Hallo Axel,
wie sind denn bisher Deine Erfahrungen mit der aktuellen Version?
-
Aktuelle Version 1.1.0 Veröffentlichungsdatum 11.02.2021 Repository/Verwahrungsort Beta (latest) Hallo zusammen,
ich würde gerne die Version
1.0.91.0.13 des Adapters als Stable veröffentlichen.Dazu wollte ich zum einen mal ein Zusammenfassung bereitstellen, was sich seit der Version 1.0.3 getan hat
und zum anderen Euer Feedback einholen, ob es vielleicht noch Probleme mit der Version1.0.91.0.13 (Beta/Latest) gibt.Ein paar Anmerkungen vorab
- Wichtig wäre vor allem, wenn eine bereits vorher genutzte Funktion mit der aktuellen Version nicht mehr (zuverlässig) gegeben ist. Natürlich sollten neue Funktionen ebenfalls zuverlässig funktionieren
- Für die als experimentell gekennzeichneten Funktionen nehme ich gerne Feedback entgegen - diese sind aber für die Stable nur eingeschränkt ausschlaggebend
- Der Adapter wird regelmäßig mit folgenden Modellen gestestet:
- Deebot 901
- Deebot OZMO 930
- Deebot OZMO 920/950
- Bei allen anderen Modellen bin ich auf Feedback angewiesen, denn es gibt weiterhin keine öffentlich zugängliche Dokumentation der Ecovacs API
Ich freue mich auf Euer Feedback
Version 1.1.0 (11.02.2021)
- Stabile Version (entspricht quasi Version 1.0.13)
Version 1.0.13 (10.02.2021)
- 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
Version 1.0.12 (30.01.2021)
- Es wurden wieder ein paar Sachen optimiert und Fehler (hoffentlich) behoben
Version 1.0.11 (24.01.2021)
- Es wurden ein paar Kleinigkeiten verbessert und der "map" Channel wurde für den OZMO 900 freigegeben.
Version 1.0.10 (20.01.2021)
- Es wurden ein paar kleinere Fehler behoben und noch ein paar Sachen "unter der Haube" optimiert
Änderungen seit Version 1.0.3
Neu unterstütze Modelle
- Deebot U2 Serie
- Sämtliche Varianten vom Deebot OZMO T8
Neue Funktionen
- Die SpotAreas aus dem "map"-Kanal können autom. mit dem "control"-Kanal synchronisiert werden
- Es werden Datenpunkte für virtuelle Begrenzungen erstellt (900/920/930/950/T8, aktuell aber nur read-only)
- Einstellung für die Sprache (de, en) der von Ecovacs vorgegebenen Bezeichnungen der Bereiche (920/950/T8)
- Zurücksetzen von Verbrauchsmaterial (900/920/930/950/T8)
- Anpassen der Lautstärke (920/950/T8)
- Versch. experimentelle Funktionen (müssen explizit aktiviert werden und sind nur für ein paar Modelle verfügbar):
- GoTo-Funktion ("control.extended.goToPosition")
- Einmalig pausieren, kurz bevor der Roboter auf die Ladestation fährt ("control.extended.pauseBeforeDockingChargingStation")
- Immer vor dem Laden pausieren, wenn Wassertank eingesetzt ("control.extended.pauseBeforeDockingIfWaterboxInstalled")
- Einmalig pausieren, wenn ein bestimmter Bereich ereicht ist ("control.extended.pauseWhenEnteringSpotArea")
- Einmalig pausieren, wenn ein bestimmter Bereich verlassen wird ("control.extended.pauseWhenLeavingSpotArea")
Verbesserungen und Fehlerbehebungen
- Das Reinigungsprotokoll wird bei den 950 basierten Modellen wieder korrekt bezogen (920/950/T8)
- Bei mehreren Instanzen (also mehreren Geräten) wurden Probleme mit der Authentifizierung behoben
- "unknown" kann als Wert für "map.deebotPositionCurrentSpotAreaID"/"Name" unterdrückt werden
- Die Adapter Einstellungen wurden ein bisschen aufgeräumt
- Canavas ist nun eine optionale Abhängigkeit
- Ein paar Anpassungen als Vorbereitung auf den js-controller ab 3.2.x
Weggefallene Funktionen
- Einstellung für eine feste Anzahl von SpotAreas unter "control"
Bekannte Probleme
- Bei der T8 Serie werden "info.chargestatus" und "info.cleanstatus" noch nicht in allen Fällen korrekt eingetragen.
- Der Deebot 710 scheint seit der 0.6.0 nicht mehr vollständig zu funktionieren. Problem wird gerade untersucht.
- Es gibt einen einzelnen Issue, dass bei einem Deebot 900 die "map.deebotPositionCurrentSpotAreaID"/"Name" oft "unknown" ist
Es gibt einen einzelnen Issue, dass bei einem Deebot OZMO 950 die Daten nach einiger Zeit nicht mehr aktualisiert werden
Die 2 aufgeführten Issues beim Deebot 900 und OZMO 950 treten bei meinen quasi baugleichen Modellen nicht auf.
Irgendwie hält sich das Feedback hier bisher doch sehr in Grenzen
Bevor ich eine Stable veröffentliche (und dann wieder die Weiterentwicklung starte) müsste ich schon ein bisschen mehr Feedback bekommen.
Vor allem interessieren mich aktuell die folgenden Punkte.
Bestehen die bei anderen Benutzern ebenfalls oder sind es Einzelfälle?Zum OZMO T8 gibt es einen Issue, wo seit einer der letzten Versionen der Fehler "Error: The id is empty! Please provide a valid id" kommt (ggf. nur mit dem JS-Controller 3.2.x):
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/issues/122
Der Fehler sollte eigentlich mit der Version 1.0.12 behoben sein.Leider bekomme ich dort gerade keine Rückmeldung dazu.
Edit: Das scheint auch so zu sein. Der Issue wurde inzwischen geschlossen.Zum Deebot 900 gibt es einen Issue, wo seit Version 1.0.7 (ggf. auch früher) der Datenpunkt "map.deebotPositionCurrentSpotAreaID" nicht mehr aktualisiert wird:
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/issues/112Zum OZMO 950 gibt es einen Fall, wo von den Ecovacs Servern der Error code 1 gemeldet wird ("Error message received: unknown errorCode: 1" im Log). Es scheint aber keine negativen Auswirkungen zu geben.
https://forum.iobroker.net/topic/38584/mrbungle64-neuer-deebot-adapterIch selbst habe sowohl einen Deebot 901 (quasi identisch mit dem 900) als auch einen OZMO 920 (ein 950 mit kleinerem Akku) - habe beide Probleme aber nicht und bekomme die auch nicht nachgestellt.
Vielen Dank im Voraus für Euer Feedback
closed Error: The id is empty #122
closed Current Spot Area Name und diverse andere Sachen #112
-
Irgendwie hält sich das Feedback hier bisher doch sehr in Grenzen
Bevor ich eine Stable veröffentliche (und dann wieder die Weiterentwicklung starte) müsste ich schon ein bisschen mehr Feedback bekommen.
Vor allem interessieren mich aktuell die folgenden Punkte.
Bestehen die bei anderen Benutzern ebenfalls oder sind es Einzelfälle?Zum OZMO T8 gibt es einen Issue, wo seit einer der letzten Versionen der Fehler "Error: The id is empty! Please provide a valid id" kommt (ggf. nur mit dem JS-Controller 3.2.x):
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/issues/122
Der Fehler sollte eigentlich mit der Version 1.0.12 behoben sein.Leider bekomme ich dort gerade keine Rückmeldung dazu.
Edit: Das scheint auch so zu sein. Der Issue wurde inzwischen geschlossen.Zum Deebot 900 gibt es einen Issue, wo seit Version 1.0.7 (ggf. auch früher) der Datenpunkt "map.deebotPositionCurrentSpotAreaID" nicht mehr aktualisiert wird:
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/issues/112Zum OZMO 950 gibt es einen Fall, wo von den Ecovacs Servern der Error code 1 gemeldet wird ("Error message received: unknown errorCode: 1" im Log). Es scheint aber keine negativen Auswirkungen zu geben.
https://forum.iobroker.net/topic/38584/mrbungle64-neuer-deebot-adapterIch selbst habe sowohl einen Deebot 901 (quasi identisch mit dem 900) als auch einen OZMO 920 (ein 950 mit kleinerem Akku) - habe beide Probleme aber nicht und bekomme die auch nicht nachgestellt.
Vielen Dank im Voraus für Euer Feedback
closed Error: The id is empty #122
closed Current Spot Area Name und diverse andere Sachen #112
@mrbungle64 Ich habe zwei Instanzen, einen Ozmo 950 sowie einen Slim2. Das einzige kleine Problem, was ich bisher feststellen konnte: In der "Objekte" Übersicht werden beide Instanzen mit dem gleichen Symbol (Ozmo 950) dargestellt. Es wäre natürlich schöner, wenn man auf dem ersten Blick beide unterscheiden könnte.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@mrbungle64 Ich habe zwei Instanzen, einen Ozmo 950 sowie einen Slim2. Das einzige kleine Problem, was ich bisher feststellen konnte: In der "Objekte" Übersicht werden beide Instanzen mit dem gleichen Symbol (Ozmo 950) dargestellt. Es wäre natürlich schöner, wenn man auf dem ersten Blick beide unterscheiden könnte.
@marc-berg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Ich habe zwei Instanzen, einen Ozmo 950 sowie einen Slim2.
Hallo @Marc-Berg
vielen Dank für das Feedback
Das einzige kleine Problem, was ich bisher feststellen konnte: In der "Objekte" Übersicht werden beide Instanzen mit dem gleichen Symbol (Ozmo 950) dargestellt. Es wäre natürlich schöner, wenn man auf dem ersten Blick beide unterscheiden könnte.
Ich wüsste jetzt nicht, wie man das Icon der einzelnen Instanzen ändern könnte. Der Admin Adapter zeigt da meines Wissens nach immer das Icon des Adapters an.
Ich habe selbst mehrere Geräte und würde mich ebenfalls dafür interessieren, ob das möglich ist.
Vielleicht kann mir ja jemand einen Tipp geben -
@marc-berg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Ich habe zwei Instanzen, einen Ozmo 950 sowie einen Slim2.
Hallo @Marc-Berg
vielen Dank für das Feedback
Das einzige kleine Problem, was ich bisher feststellen konnte: In der "Objekte" Übersicht werden beide Instanzen mit dem gleichen Symbol (Ozmo 950) dargestellt. Es wäre natürlich schöner, wenn man auf dem ersten Blick beide unterscheiden könnte.
Ich wüsste jetzt nicht, wie man das Icon der einzelnen Instanzen ändern könnte. Der Admin Adapter zeigt da meines Wissens nach immer das Icon des Adapters an.
Ich habe selbst mehrere Geräte und würde mich ebenfalls dafür interessieren, ob das möglich ist.
Vielleicht kann mir ja jemand einen Tipp geben@mrbungle64 Gibt halt nix zu berichten, funktioniert einfach zu 99.99% perfekt
0.01% = beim starten + Ozmo 950 "charge status" (aber das ist eher ein Joke
)...und meines Wissens auch ja, ist nicht die Instanz, sondern der Adapter. Ergibt ja auch Sinn, denn es ist derselbe Adapter, nur eben mit mehreren Instanzen. Aber kein Problem, man könnte den Namen ja auch selbst eintragen, wenn der Creator des Adapters so nett wäre und es zulässt <-- feature request
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@mrbungle64 Gibt halt nix zu berichten, funktioniert einfach zu 99.99% perfekt
0.01% = beim starten + Ozmo 950 "charge status" (aber das ist eher ein Joke
)...und meines Wissens auch ja, ist nicht die Instanz, sondern der Adapter. Ergibt ja auch Sinn, denn es ist derselbe Adapter, nur eben mit mehreren Instanzen. Aber kein Problem, man könnte den Namen ja auch selbst eintragen, wenn der Creator des Adapters so nett wäre und es zulässt <-- feature request
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Gibt halt nix zu berichten, funktioniert einfach zu 99.99% perfekt
Das freut mich
Vielen Dank für Dein regelmäßiges Feedback0.01% = beim starten + Ozmo 950 "charge status" (aber das ist eher ein Joke
)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 sein...und meines Wissens auch ja, ist nicht die Instanz, sondern der Adapter. Ergibt ja auch Sinn, denn es ist derselbe Adapter, nur eben mit mehreren Instanzen. Aber kein Problem, man könnte den Namen ja auch selbst eintragen, wenn der Creator des Adapters so nett wäre und es zulässt <-- feature request
Wie kann ich das "zulassen"?
Würde mich schon interessieren, welche Möglichkeiten ich da hätte in Bezug auf die Instanzen. -
@sborg said in Ecovacs Deebot Adapter v1.0.12 Beta/Latest:
@mrbungle64 Gibt halt nix zu berichten, funktioniert einfach zu 99.99% perfekt
Das freut mich
Vielen Dank für Dein regelmäßiges Feedback0.01% = beim starten + Ozmo 950 "charge status" (aber das ist eher ein Joke
)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 sein...und meines Wissens auch ja, ist nicht die Instanz, sondern der Adapter. Ergibt ja auch Sinn, denn es ist derselbe Adapter, nur eben mit mehreren Instanzen. Aber kein Problem, man könnte den Namen ja auch selbst eintragen, wenn der Creator des Adapters so nett wäre und es zulässt <-- feature request
Wie kann ich das "zulassen"?
Würde mich schon interessieren, welche Möglichkeiten ich da hätte in Bezug auf die Instanzen.@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.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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. -
@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..."
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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
-
@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:
@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
-
@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
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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.
-
Aktuelle Version 1.1.0 Veröffentlichungsdatum 11.02.2021 Repository/Verwahrungsort Beta (latest) Hallo zusammen,
ich würde gerne die Version
1.0.91.0.13 des Adapters als Stable veröffentlichen.Dazu wollte ich zum einen mal ein Zusammenfassung bereitstellen, was sich seit der Version 1.0.3 getan hat
und zum anderen Euer Feedback einholen, ob es vielleicht noch Probleme mit der Version1.0.91.0.13 (Beta/Latest) gibt.Ein paar Anmerkungen vorab
- Wichtig wäre vor allem, wenn eine bereits vorher genutzte Funktion mit der aktuellen Version nicht mehr (zuverlässig) gegeben ist. Natürlich sollten neue Funktionen ebenfalls zuverlässig funktionieren
- Für die als experimentell gekennzeichneten Funktionen nehme ich gerne Feedback entgegen - diese sind aber für die Stable nur eingeschränkt ausschlaggebend
- Der Adapter wird regelmäßig mit folgenden Modellen gestestet:
- Deebot 901
- Deebot OZMO 930
- Deebot OZMO 920/950
- Bei allen anderen Modellen bin ich auf Feedback angewiesen, denn es gibt weiterhin keine öffentlich zugängliche Dokumentation der Ecovacs API
Ich freue mich auf Euer Feedback
Version 1.1.0 (11.02.2021)
- Stabile Version (entspricht quasi Version 1.0.13)
Version 1.0.13 (10.02.2021)
- 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
Version 1.0.12 (30.01.2021)
- Es wurden wieder ein paar Sachen optimiert und Fehler (hoffentlich) behoben
Version 1.0.11 (24.01.2021)
- Es wurden ein paar Kleinigkeiten verbessert und der "map" Channel wurde für den OZMO 900 freigegeben.
Version 1.0.10 (20.01.2021)
- Es wurden ein paar kleinere Fehler behoben und noch ein paar Sachen "unter der Haube" optimiert
Änderungen seit Version 1.0.3
Neu unterstütze Modelle
- Deebot U2 Serie
- Sämtliche Varianten vom Deebot OZMO T8
Neue Funktionen
- Die SpotAreas aus dem "map"-Kanal können autom. mit dem "control"-Kanal synchronisiert werden
- Es werden Datenpunkte für virtuelle Begrenzungen erstellt (900/920/930/950/T8, aktuell aber nur read-only)
- Einstellung für die Sprache (de, en) der von Ecovacs vorgegebenen Bezeichnungen der Bereiche (920/950/T8)
- Zurücksetzen von Verbrauchsmaterial (900/920/930/950/T8)
- Anpassen der Lautstärke (920/950/T8)
- Versch. experimentelle Funktionen (müssen explizit aktiviert werden und sind nur für ein paar Modelle verfügbar):
- GoTo-Funktion ("control.extended.goToPosition")
- Einmalig pausieren, kurz bevor der Roboter auf die Ladestation fährt ("control.extended.pauseBeforeDockingChargingStation")
- Immer vor dem Laden pausieren, wenn Wassertank eingesetzt ("control.extended.pauseBeforeDockingIfWaterboxInstalled")
- Einmalig pausieren, wenn ein bestimmter Bereich ereicht ist ("control.extended.pauseWhenEnteringSpotArea")
- Einmalig pausieren, wenn ein bestimmter Bereich verlassen wird ("control.extended.pauseWhenLeavingSpotArea")
Verbesserungen und Fehlerbehebungen
- Das Reinigungsprotokoll wird bei den 950 basierten Modellen wieder korrekt bezogen (920/950/T8)
- Bei mehreren Instanzen (also mehreren Geräten) wurden Probleme mit der Authentifizierung behoben
- "unknown" kann als Wert für "map.deebotPositionCurrentSpotAreaID"/"Name" unterdrückt werden
- Die Adapter Einstellungen wurden ein bisschen aufgeräumt
- Canavas ist nun eine optionale Abhängigkeit
- Ein paar Anpassungen als Vorbereitung auf den js-controller ab 3.2.x
Weggefallene Funktionen
- Einstellung für eine feste Anzahl von SpotAreas unter "control"
Bekannte Probleme
- Bei der T8 Serie werden "info.chargestatus" und "info.cleanstatus" noch nicht in allen Fällen korrekt eingetragen.
- Der Deebot 710 scheint seit der 0.6.0 nicht mehr vollständig zu funktionieren. Problem wird gerade untersucht.
- Es gibt einen einzelnen Issue, dass bei einem Deebot 900 die "map.deebotPositionCurrentSpotAreaID"/"Name" oft "unknown" ist
Es gibt einen einzelnen Issue, dass bei einem Deebot OZMO 950 die Daten nach einiger Zeit nicht mehr aktualisiert werden
Die 2 aufgeführten Issues beim Deebot 900 und OZMO 950 treten bei meinen quasi baugleichen Modellen nicht auf.
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
Support us
121
Online32.4k
Users81.3k
Topics1.3m
Posts