Adapter Worx Landroid v3.x.x

[Neuschwansteini]

@lucky_esa

Ah ok, ich hatte nur von jsonl auf Redis umgestellt und den ioBroker zweimal neu gestartet.. anscheinend ging aber heute Morgen schon was schief..
dem Umzug habe ich nach 14 Uhr gemacht.

[Homoran]

@neuschwansteini sagte in Adapter Worx Landroid v3.x.x:

nach 14 Uhr g

die Zeit im Log ist Zulu-Zeit, da kommen noch +2h für MESZ drauf, also 16:xx

[Neuschwansteini]

@homoran

Ah, ist mir gar nicht aufgefallen, danke, na ich weiß ja, was ich getan habe..

[ITCrowd]

@lucky_esa
Der Adapter läuft super. Hier ist Worx der, der im Moment Mist baut.
Selbst die Landroids kommen kaum noch an den Server. (Sieht man im Netzwerkmitschnitt).
Besonders betroffen sind die Nutzer ohne öffentlich IPv4, da greift die Sperre in Sekunden und bleibt dann dauerhaft.
Wenn das die Folge eines verkorksten Lastmanagements ist, dann gute Nacht.

Die Hotline ist freundlich aber kann auch nicht helfen. Offensichtlich wird das Problem nicht verstanden.
Zitat: Ihr Landroid ist doch Online, dann brauchen sie ihn doch nur zu starten. Ähh Sorry ihre App funktioniert nicht. Ach so, ich gebe es an die Technik weiter.

Anfangs ging noch der Zugriff über's Mobilnetz. Seit heute Mittag auch nicht mehr.
Der Adapter ist seit einer Woche ausgeschaltet, entsperrt wird hier nichts. Anscheinend ist es unerwünscht, wenn man seinen Rasenmäher einmal am Tag starten will.

Telekom DSL Kunden bekommen ja beim Neuverbinden eine neue IPv4, kann da jemand mal testen ob er danach zumindest kurzzeitig wieder auf die Webseite kommt und ein Login machen kann? https://id.worx.com/

Ich sehe seit einer Woche: 429 TOO MANY REQUESTS

Vieleicht bleibt nur verschrotten und neu kaufen, aber nie wieder WORX.

Nachtrag. Habe gerade den Landroid Skill in Alaxa installiert. Schon vor der Verknüpfung mit dem Konto kommt: 429 TOO MANY REQUESTS

[Lucky_ESA]

Habe mir noch mal das letzte Issue von HomeConnect angeschaut. Hatte ja auch sofort die Aussage von Worx umgesetzt (Release 3.2.0 - Save session infos). Es gibt nur noch 1 Login und danach benutze ich den RefreshToken. Dieser darf nur zwischen 50-60 Minuten ausgeführt werden.
Auch darauf habe ich geachtet und auch umgesetzt.
Die Sperre soll kommen, wenn zu viele Loginversuche unter einer Minute ausgeführt werden. Aber das ist mit dem Adapter nicht möglich...Auch wenn euer System in einen Restart Loop kommt, wird der Adapter keine unötigen Requests senden ausser....Die Abfragen an die API für neue Daten...Was auch zu einer Sperrung führen könnte...Daran arbeite ich gerade..

Das Problem lag letztendlich nicht an Worx.

Hier eine Aussage:
Auth operations have another few throttle, beyond only IP address (including blocking user's login operations).

Bei einigen von euch vermute ich eine IP + Account Sperre.

Hier noch eine Erfahrung:
In my experience, the ban is lifted latest after 24 hours If you don't test a log in again in this time.

Da bei euch der Adapter bereits deaktiviert ist würde ich jetzt auch die APP (von jeden Handy) deinstallieren und erst nach 26 Stunden wieder installieren.

Edit: Änderung markiert

Gruß//Lucky

[Lucky_ESA]

Sorry hatte ich vergessen. Subject vom Issue: 429 Too Many Requests
Erstellt im April 2025.

Warum die APP deinstallieren?
Ich hatte die Zugangsdaten eines Users erhalten um neue Funktionen dem Adapter hinzuzufügen. Nach Abschluß hatte ich wie gewohnt alle Daten vom User gelöscht und mich in meiner Test APP ausgeloggt. Abends bekam ich dann Notifications, dass der Mäher startet etc... obwohl ich abgemeldet war. Daher immer die APP löschen, 26h warten und dann wieder installieren.

Gruß//Lucky

[eve11]

Sorry, ich habe teilweise nur Bahnhof verstanden

Also: App deinstallieren (Habe ich schon gestern gemacht) => 26 Stunden warten => App wieder installieren => Alles sollte wieder laufen.
=> Adapter starten.

Warum jetzt das Problem entstanden ist, und warum nur bei einigen, als auch warum die App nach 24 Stunden sofort wieder gesperrt wurde, habe ich leider nicht verstanden.

Trotzdem vielen Dank an alle beteiligten.

Heiko

[Lucky_ESA]

@eve11 Was die Sperrung verursacht hat kann ich nicht sagen. Es ist aber komisch, dass es bei anderen Plattformen noch kein Issue gibt und das es nur iobroker User betrifft (finde sonst nichts über Google).
Daher gibt es für mich nur 2 Erklärungen:

1. Adapter hat die Sperrung ausgelöst (wie auch immer) und diese wird durch die APP immer wieder verlängert
2. Die APP hat die Sperrung ausgelöst

Dem Adapter füge ich gerade zusätzlich Rate Limits hinzu die euch bei einem Restart Loop noch mehr schützen. Zusätzlich werde ich wahrscheinlich den Status Intervall noch ein wenig ändern. Aber das würde nur User berteffen die mehr als 1 Mäher haben.

Gruß//Lucky

[eve11]

@lucky_esa said in Adapter Worx Landroid v3.x.x:

@eve11 Was die Sperrung verursacht hat kann ich nicht sagen. Es ist aber komisch, dass es bei anderen Plattformen noch kein Issue gibt und das es nur iobroker User betrifft (finde sonst nichts über Google).

Das ist mir auch aufgefallen, ich habe auch Google bemüht aber nur das IoBroker Forum gefunden wo betroffene Personen sich diesbezlg. gemeldet haben.
=> Es muss irgendwas mit dem Adapter zu tun haben.
Wir werden sehen.

[Neuschwansteini]

@lucky_esa

Bei mir ist wohl auch der Account und Ip gesperrt, Frechheit sowas.
Hab die App nur auf meinem iPhone und den Adapter sonst keine Abfragen.

Und wenn ich den Adapter fünfmal hintereinander neu starte, sollte auch kein Problem sein..

Wenn hier nochmal einer schreibt, die haben n Kundenservice, dann erschlage ich den.. ️

Meine Geduld ist für die Asche erloschen.

[hsteinme]

@lucky_esa sagte in Adapter Worx Landroid v3.x.x:

@hsteinme Sollen wir den Issue mal erweitern?

Wissen wir denn schon genug von den hier vorliegenden Fällen, um uns guten Gewissens dort dran zu hängen? Ich meine: nein.

Was mich wundert: Eine Handvoll User hat das 429-Problem. Viele, viele andere aber nicht.

[hsteinme]

@neuschwansteini
Hier bemühen sich gerade einige, mit Sachlichkeit und Ruhe das gemeldete Problem zu untersuchen. Du gehörst nicht dazu. Es mag ja verständlich sein, dass sich jemand bei einem erlittenen Ärger Luft verschaffen möchte. Aber hier hilft das ehrlich gesagt niemanden weiter. Im Gegenteil: Es stört die sachlichen Bemühungen anderer.

[hsteinme]

@itcrowd sagte in Adapter Worx Landroid v3.x.x:

Selbst die Landroids kommen kaum noch an den Server.

Im Roboter-Forum tummeln sich ja nun sehr, sehr viele Landroid-User. Dort hat aber erstaunlicherweise noch niemand was von diesen Performanceproblemen bemerkt.

@itcrowd sagte in Adapter Worx Landroid v3.x.x:

Besonders betroffen sind die Nutzer ohne öffentlich IPv4, da greift die Sperre in Sekunden und bleibt dann dauerhaft.

Was meinst Du mit "ohne öffentliche IPv4"? Wieviele dieser gesperrten User gibt es Deines Wissens nach? Wo haben diese User von ihren Sperren berichtet? Sind dort nur ioBroker User betroffen?

[Armilar]

@hsteinme sagte in Adapter Worx Landroid v3.x.x:

Was mich wundert: Eine Handvoll User hat das 429-Problem. Viele, viele andere aber nicht.

Die Dunkelziffer ist wie immer etwas höher als eine Handvoll - Ich habe das gleiche Problem, kann aber auch aktuell nichts dazu beitragen... Mache im Moment den 26h Test... Sollte hier also jeder "ich auch" schreiben, wäre der Thread sicherlich sehr schnell voll ... Das Ergebnis wäre sicherlich nicht besser

[Bjoern77]

Moin
Ich mache auch gerade den 26h Test. Welche Adapterversion sollen wir nach den 26h denn starten?
Danke für eure Mühe und Arbeit.
Gruß
Björn

[Homoran]

Ich habe keine Worx und somit keine Möglichkeit zu testen.

Aber die Antwort, die @eve11 vom Worx Support erhalten hat, enthält eine Option, die Hersteller gerne ins Feld führen

Ich weiss nicht, ob das irgendwo in den AGB steht, und ob/warum anscheinend nur ioBroker betroffen ist.

Möglicherweise meldet sich der Adapter erkennbar an der cloud an, was ebenfalls möglicherweise zum dauerhaften Eintrag in einer Blacklist führt, auch wenn lt. Mail diese "Einschränkungen" nur 24h dauern sollten.

Alles Vermutungen!

[Lucky_ESA]

@armilar Kannst du mir bitte sagen mit welchem Release die Sperre eintritt und hast du noch das komplette Log vom Tag der ersten Sperre?
Super wäre auch wenn du nach der Sperre den iob nicht neu gestartet hast. Mir könnte auch die opt/iobroker/iobroker-data/states.jsonl helfen.

Gruß//Lucky

[Armilar]

@lucky_esa

Habe den Adapter v 3.2.4 installiert...

Das Problem ist bei mir schon ein paar Tage (ca. 5-6) alt und die Logs ab Start der Sperrung habe ich leider nicht mehr... Der ioBroker wurde seitdem auch mehrfach durchgestartet... Kann euch aber zumindest ab heute ca. 13:00 - 14:00 Uhr sagen, ob die Sperre aufgehoben wurde...

Edit: Sind aber die IP's unterschiedlicher Provider, sowie der Account betroffen... Hatte es vorgestern mit 5G versucht, die APP gelöscht, im Demo Mode funktionierte es, angemeldet und die App hat sofort die andere IP gesperrt. Zumindest ist sicher, dass Account und IP's bei Worx für die Sperrung verknüpft werden...

[Lucky_ESA]

@armilar Weißt du noch wie die Sperrung anfing? Lief der Adapter und plötzlich kam die Sperre, oder kurz nach einem Neustart vom Adapter, Neustart von iob oder nach Update auf das Release 3.2.4?

[NewPaint2]

Ich weiß nicht ob es hilft, bei mir kam die Meldung am 14.06.2025 das erste mal mitten in der Nacht. Schaut mal ob ihr weiter damit kommt.

2025-06-14 23:30:54.639  - info: worx.0 (258859) starting. Version 3.2.3 in /opt/iobroker/node_modules/iobroker.worx, node: v20.19.2, js-controller: 7.0.7
2025-06-14 23:30:54.839  - info: worx.0 (258859) Use new aws-iot-device-sdk-v2.
2025-06-14 23:30:54.840  - info: worx.0 (258859) Changed timeout for edgecut to 5000
2025-06-14 23:30:54.842  - info: worx.0 (258859) Login to worx
2025-06-14 23:30:55.004  - warn: javascript.0 (258721) getState "worx.0.2020302091010020598D.mower.status" not found (3)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at HandleScreensaverUpdate (script.js.common.NSPanel.NSPanelTS-test:12672:31)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at Object.<anonymous> (script.js.common.NSPanel.NSPanelTS-test:4043:17)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at step (script.js.common.NSPanel.NSPanelTS-test:33:23)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at Object.next (script.js.common.NSPanel.NSPanelTS-test:14:53)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at script.js.common.NSPanel.NSPanelTS-test:8:71
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at new Promise (<anonymous>)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at __awaiter (script.js.common.NSPanel.NSPanelTS-test:4:12)
2025-06-14 23:30:55.005  - warn: javascript.0 (258721)     at Object.<anonymous> (script.js.common.NSPanel.NSPanelTS-test:4039:12)
2025-06-14 23:30:55.283  - error: worx.0 (258859) AxiosError: Request failed with status code 429
2025-06-14 23:30:55.286  - error: worx.0 (258859) "429 TOO MANY REQUESTS"
2025-06-14 23:30:55.294  - info: worx.0 (258859) Start login
2025-06-14 23:30:55.584  - error: worx.0 (258859) AxiosError: Request failed with status code 429
2025-06-14 23:30:55.584  - error: worx.0 (258859) "429 TOO MANY REQUESTS"
2025-06-14 23:30:55.726  - error: worx.0 (258859) AxiosError: Request failed with status code 429
2025-06-14 23:30:55.726  - error: worx.0 (258859) "429 TOO MANY REQUESTS"
2025-06-14 23:30:55.747  - info: worx.0 (258859) Start MQTT connection
2025-06-14 23:30:55.748  - warn: worx.0 (258859) No mower found to start mqtt
2025-06-14 23:30:55.752  - info: worx.0 (258859) Start check devices object!