Adapter: Worx Landroid v2.x.x
-
Meine o. g. Änderungen verhindert die 24h Sperre nicht sondern reduziert den Traffic Verbrauch.
Wir wissen derzeit nicht warum und wann die 24h Sperre einsetzt. Ich test gerade keine Befehle zu senden und bin seit 36h connected.
Wenn uns jemand helfen möchte kann folgendes machen.
Erforderlich 2 x Handy:
Auf jedem Handy sich mit der APP anmelden und versetzt auf jedem Handy durch nach unten wischen seine Daten aktualisieren.
Möchte hier eine Login Limitierung ausschließen.Fakt ist, dass Worx was geändert hat aber wir nicht wissen was geändert wurde.
Gruß//Lucky
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
Wenn uns jemand helfen möchte kann folgendes machen.
Erforderlich 2 x Handy:
Auf jedem Handy sich mit der APP anmelden und versetzt auf jedem Handy durch nach unten wischen seine Daten aktualisieren.
Möchte hier eine Login Limitierung ausschließen.Nachdem ich soeben wieder freigeschaltet wurde, habe ich die App, die auf 2 Handys installiert ist, im Wechsel 3 Minuten durch nach unten Wischen aktualisiert. Also einmal Handy 1 auffrischen, dann Handy 2, dann wieder Handy 1, usw
Dadurch wurde keine Sperrung ausgelöst.
Update:
Im Protokoll kommt öfter diese Warnung vor:worx.0 2023-04-01 19:08:44.004 warn Object of state "worx.0.2018xxxxx.rawMqtt.auto_schedule_settings" is missing the required property "common.type" -
worx.0 2023-04-01 19:08:44.004 warn Object of state "worx.0.2018xxxxx.rawMqtt.auto_schedule_settings" is missing the required property "common.type"Danke für die Infos. Kannst du mal bitte auf debug stellen und mir das Protokoll an github@luckyskills.de zusenden.
Ist zwar auf dem GIT behoben aber ich mnöchte die Ursache verstehen,Gruß//Lucky
-
@lucky_esa
Hatte das gerade schon auf GitHub geschrieben, deshalb Entschuldigung für den Doppelpost, aber die Antwort gehört ja hierhin.Rückmeldung:
Nachdem ich seit über 12 Std. wieder freigeschaltet bin und im Protokoll in der Nacht ca. alle 20 - 30 Minuten die obige Warnung bekommen habe, habe ich heute die Debugprotokollierung aktiviert. Seitdem kam die Warnung aber nicht mehr vor (über ca. 3 Stunden). Ich kann z. Zt. also kein Debugprotokoll mit der Warnung reproduzieren. Ich melde mich aber, sobald sie wieder auftritt. Kann es sein, dass der Warntext unterdrückt wird, wenn Debuginfos ausgegeben werden?
Installiert ist z. Zt. die Nicht-Git-Version. -
.... also, nachdem ich nach 24 Stunden jetzt auch wieder mitspielen darf, habe ich auf zwei Handys versucht, mindestens 20 Minuten gleichzeitig die Daten zu Aktualisieren. Bisher alles bestens - aber auch kein Log im iobroker, der mir etwas anzeigt.
Ich bin mir aber auch nicht sicher, ob es etwas bringt, die Zeit im Adapter etwas hochzusetzen.
Meine Vermutung ist und bleibt, dass Worx im System filtert, ob ein Befehl von der App oder vom iobroker gesendet wird und die SN blockert wird. Ich kann mich noch an letztes oder vorletztes Jahr erinnern, wo es gereicht hat, die IP zu erneuern.
Was mich aber verwundert, ist, dass ich mir dem ersten Aktuallisieren in der App den Mähvorgang gestartet habe. Es sind alle Profile im iobroker deaktiviert und auf den Startbutton bin ich definitiv auch nicht gekommen. Vielleicht war es noch der gestrige Befehl, der in der Pipeline hing, wo ich gesperrt war.
-
@falke69 sagte in Adapter: Worx Landroid v2.x.x:
.... also, nachdem ich nach 24 Stunden jetzt auch wieder mitspielen darf, habe ich auf zwei Handys versucht, mindestens 20 Minuten gleichzeitig die Daten zu Aktualisieren. Bisher alles bestens - aber auch kein Log im iobroker, der mir etwas anzeigt.
Dito.
Mir ist aufgefallen, dass - obwohl man nicht ausgesperrt ist, es beim Aktualisieren der App vorkommen kann, dass 1 mal "Verbindungsfehler" angezeigt wird. Beim 2. Auffrischen wieder alles ok. Also nicht direkt die Flinte ins Korn werfen.Meine Vermutung ist und bleibt, dass Worx im System filtert, ob ein Befehl von der App oder vom iobroker gesendet wird und die SN blockert wird. Ich kann mich noch an letztes oder vorletztes Jahr erinnern, wo es gereicht hat, die IP zu erneuern.
Wäre es nicht möglich, einfach mal bei Positec diesbezüglich anzufragen, was geändert wurde? Im Roboterforum zum Landroid sind die Entwickler ja auch zugetan?
-
Verbindungsfehler wurde mir in der App nur während der Sperre angezeigt. Heute kam lediglich ne Meldung, das der Landroid offline ist Ich vermute, das dies am Server liegt, da die App ja regelmäßig automatisch aktuallisiert wird und wahrscheinlich in dem Moment gerade die Daten an die andere App gingen.
aber @lucky_esa wie trage ich die Daten in den
worx.0.xxxxxxxxxxx.calendar.calJson_tosend ein?Hättest Du da eventuell einen Blocky Auszug, den Du mir zur Verfügung stellen kannst?
Denn so wie ich es verstanden habe, trägt man jetzt dort die Daten ein und diese werden dann über worx.0.xxxxxxxxxxx.calendar.calJson_sendto in "einem Rutsch" übertragen. -
@falke69
worx.0.xxxxxxxxxxx.calendar.calJson_tosend ein? Nichts. Dieser wird automatisch erstellt wenn du die Datenpunkte in den Wochentagen füllst.worx.0.xxxxxxxxxxx.calendar.calJson_sendto Das ist richtig. Sobald alles gefüllt wurde dann diesen Button drücken. Dafür gibt es hier im Forum genug Blockly Vorlagen. Habe jetzt leider keinen Link, sorry. Bitte den automatischen Restart löschen. Alle Daten werden automatisch aktualisiert.
Gruß//Lucky
-
Installiert ist z. Zt. die Nicht-Git-Version.
Aber die GIT Version sollte den Fehler eigentlich beheben. Allerdings glaube ich, dass ich ein Promise Problem habe. Werde das mal korrigieren.
Gruß//Lucky
-
Aktuell habe ich die 24 Stunden Sperre wieder. So zeigt es mir die App und der Log im iobroker an.
Es sind alle Datenpunke für die Mähzeiten deaktiviert. Das einzige ist das Programm selbst, welches mir die Daten über den Status per Telegram sendet.
Vielleicht liegt es aktuell auch daran, das der Adapter durch die Aktualisierung über git. sich mit dem Server von Worx neu verbunden hat. Oder es liegt an den Staten die in den voreingestellten Zeiten abgefragt werden.Der Mäher wurde heute nur über die App zum Mähen animiert.
-
Ich möchte in den nächsten Tagen meinen M500 aus dem Winterschlaf holen. Den Adapter hatte ich seit Herbst 2022 wegen der Winterpause nicht genutzt und die Instanz daher abgeschaltet.
Nun habe mich seit gestern ´mal durch diesen Thread gearbeitet und den Adapter auf V2.0.3 aktualisiert. Neu Anmelden in der Worx-App war erforderlich und hat auch funktioniert. Ebenso scheint die Instanz zu funktionieren und die View, die ich gebastelt hatte, scheint auch noch immer das zu tun, was sie soll.
Tatsächlich nutze ich da bisher aber auch noch keine Befehle zur Eingabe von Zeitplänen via ioBroker, sondern habe diese bisher noch über die Worx-App erstellt. Mit ioBroker nutze ich via vis derzeit nur Dinge wie Anzeige der Mäher- und Akkuzustände, Befehle geben wie z. B. spontanen Kanten-/Einzelschnitt, Partymodus, ... (also nur "Einzelbefehle").Habe ich die letzten Inhalte des Threads richtig verstanden, daß ich dann erstmal keine Probleme mit der 24h-Sperre erwarten brauche, weil die bei Euch bisher nur aufgetreten sind, wenn Ihr via Skript/Blockly regelmäßige/häufige Schreibaktionen durchführt?
-
Habe ich die letzten Inhalte des Threads richtig verstanden, daß ich dann erstmal keine Probleme mit der 24h-Sperre erwarten brauche, weil die bei Euch bisher nur aufgetreten sind, wenn Ihr via Skript/Blockly regelmäßige/häufige Schreibaktionen durchführt?
Die letzte Firmware von Worx hat schon den Traffic reduziert. Vermutlich wurde über den Winter hinweg weiter reduziert auf Kosten von 3 Anbieter wie iobroker.
Bin jetzt ca. 80 Std. Online ohne einen Befehl abzusenden und habe keine Probleme.
Vorher war ich ca. 36 Std. Online, dann musste ich oft den Adapter neu starten und dann 2 Befehle abgesetzt. Direkt danach wurde ich gesperrt.
Mehr Informationen kann ich dir leider nicht geben.Gruß//Lucky
-
@lucky_esa Danke für die Rückmeldung!
Ich habe noch nie einen Adapter entwickelt und kann daher den Aufwand überhaupt nicht abschätzen. Außerdem kenne ich die Mechanismen/Protokolle der Kommunikation zwischen Mäher, Cloud und Adapter nicht. Daher nur mal so als Gedankenspiel, wobei ich hoffe, daß ich da nicht zu naiv rüberkomme:
Wenn Worx es "Externen" durch "ständige unveröffentliche/undokumentierte Änderungen der API" offenbar schwer machen will, kann man dann nicht versuchen, ohne API auszukommen?
Der Mäher befindet sich doch bei jedem Anwender im WLAN (wenn man mal von den vermutlich wenigen Fällen von "Long-Range"-Modulen absieht) und alles was die Cloud an Daten sammelt und was der Adapter von der Cloud abrufen kann, muß doch vorher irgendwie vom Mäher durchs WLAN zur Cloud geschickt werden. Auch Befehle, die der Adapter vermutlich nicht "direkt", sondern via Cloud an den Mäher schickt, müssen doch letztendlich dann auch wieder durchs WLAN zum Mäher. Kann man da nicht "sniffen" und mit den Erkenntnissen den Adapter dann so gestalten, daß er den "Umweg" über die Cloud "einfach weg läßt"?
Das wäre bestimmt nicht einfach und vermutlih erstmal ein hoher Aufand. Aber danach wäre man dann von Worx / der Cloud unabhängig - oder?
Wie gesagt: Nur Gedanken von jemandem, der das noch nie selber probiert hat.
-
Hello
nee, ganz so einfach ist das nicht.. natuerlich kann man den Netzwerkverkehr mit Wireshark sniffen, findet auch das Protokoll, sofern es nicht codiert/verschluesselt ist.. und selbst wenn man das hackt, dann muss jeder User
a) einen Worx-Server in seinem Netzwerk simulieren, das koennte evtl. noch der Adapter tun..
b) im Netzwerk das Routing und DNS soweit aendern, dass der Maeher annimmt, der iobroker-Adapter ist der Server, also dns-anfragen umlenken..
c) muss man dann wiederrum herausfinden, wie denn der Maeher angesprochen wird..also ein komplettes Revers-Engineering ... ich glaube, da ist es einfacher, gleich ne neue Software fuer den Maeher zu schreiben ..
Nachteile: aendert Worx in der naechsten Firmware etwas... ist alles wieder hinfaellig...
Vorteil: Dein Maeher bleibt lokal im Netzwerk..
-
@andersmacher sagte in Adapter: Worx Landroid v2.x.x:
Das wäre bestimmt nicht einfach und vermutlih erstmal ein hoher Aufand. Aber danach wäre man dann von Worx / der Cloud unabhängig - oder?
kurz und knapp .. NEIN
-
Vorteil: Dein Maeher bleibt lokal im Netzwerk..
Das war natürlich auch ein "Hintergedanke" von mir.
Aber danke für die "Aufklärung"!
Mein Denkfehler war wohl, daß mir nicht klar war, daß der Mäher ja vermutlich nicht einfach so per UDP/Broadcast seine Daten ins WLAN "pustet", sondern nur dann sendet, wenn er die passende Gegenstelle im Netzwerk (im speziellen Fall eben via Internet den WORX-Server) findet.Nachteile: aendert Worx in der naechsten Firmware etwas... ist alles wieder hinfaellig...
Ja, das könnte man dann wohl nur vermeiden, wenn man dem Mäher den Internetzugriff / automatische Firmwareupdates verbietet und die bis dahin vorhandene Firmware als endgültig akzeptiert.
Aber verstanden: Ist nicht so einfach/praktikabel, wie ich zuerst dachte.
-
habt ihr hier schon gelesen? Dort schreiben sie was von mqtt umstellung auf https usw.
-
@dirkhe sagte in Adapter: Worx Landroid v2.x.x:
habt ihr hier schon gelesen? Dort schreiben sie was von mqtt umstellung auf https usw.
Hat tombox bereits letzte Jahr im Oktober gewechselt.
Wir müssen einfach nur die Requests stark reduzieren. Bin bereits 6 Tage ohne Probleme online allerdings ohne einen Request zu versenden.Gruß//Lucky
-
@lucky_esa Wie willst Du weiter vorgehen? Vielleicht im 1. Schritt einen Request/Stunde senden, das Intervall dann verkürzen auf 1/2 Stunde?
Ich frage, weil wir ja zu mehreren Anwendern ähnlich vorgehen könnten und unterschiedliche Requests/Zeit versuchen könnten.Ich spinne nur rum:
Möglich, dass Worx/Positec auch eine Art Punktesystem realisiert hat, so eine Art rollierenden Negativwert: Wenn innerhalb von 10 Minuten mehr als x Requests abgesetzt waren, und vom vorherigen Beobachtungsintervall noch Negativpunkte vorhanden sind, können diese die Grenze überschreiten, und man wird gesperrt. Hat man noch keine Negativpunkte, weil diese weit genug zurückreichen, würden die x Requests pro 10 Minuten ohne Sperre durchgehen. Das wäre dann schwer zu durchschauen.
So eine Art Wohlverhalten à la chinesischem Sozialbonus
-
@lucky_esa Ich habe in die github version nochmal ein request counter eingebaut damit man besser sehen kann wieviele request man so macht
