Adapter: Worx Landroid v2.x.x

Lucky_ESA

Auch auf die Gefahr hin hier als Alleinunterhalter von einem Admin gesperrt zu werden, mache ich trotzdem weiter.
Auf`m GIT sind nun die o. g. Änderung implementiert. Ihr müsst eure Blocklys wie oben beschrieben anpassen. Aktualisierungen der Datenpunkte xx.calendar.wochentag können dann ohne "Timeout" gesetzt werden.
Es gibt allerdings noch die Möglichkeit, dass beim Ausführen euer Blockys der Interval für die Aktualisierung startet. Dann werden eure Daten eventuell fehlerhaft übertragen.
Wenn das zu oft vorkommt, muss ich dann noch einen dritten Datenpunkt hinzufügen, der die automatische Aktualisierung unterbindet.
Des Weiteren haben wir eine kleine Änderung hinzugefügt um die 24h Sperre eventuell zu verhindern.

Ihr müsst nun die aktuelle Version vom GIT laden um zu testen.

Gruß//Lucky

falke69

@lucky_esa

hättest Du vielleicht ein fertiges Blockly mit den Datenpunkten, welches Du zur Verfügung stellen könntest?

Danke

iobroker2001

@lucky_esa
Ich verwende meine eigenen Blocklys für die Mähzeitänderung/Kantenschnitt per VIS und Regenerkennung -> mowTimeExtend auf -100% setzen etc. Die zugehörigen Datenpunkte in "worx" werden aber nicht wie in den zitierten Blocklys häufig gesetzt, schon garnicht minütlich oder viele direkt hintereinander.
Und dennoch bin ich gestern wieder ausgesperrt worden, warte z. Zt. auf Wiederfreigabe. Also meiner Beobachtung nach scheint es nicht unbedingt ein Problem der häufigen Befehle in kurzer Zeit zu sein. Im Gegensatz zu meinem obigen Post konnte ich durch Stoppen des Worx-Adapters die Sperre nicht wieder aufheben.

Das soll bitte nur ein Hinweis für die Fehlersuche sein! Vielen Dank dafür, dass Du Dich darum kümmerst!

P.S.: Sollen die neuen JSON-Objekte dann zwingend immer für Zeitenänderung gesetzt werden oder nur alternativ, wenn viele Änderungen übertragen werden müssen? Bleiben dann die alten Datenpunkte "...workTime" etc. erhalten?

falke69

@iobroker2001

ich vermute bei mir das selbe Problem.
Selbst eine neue IP, bringt mir nichts und über die App kann ich den Landroid auch nicht starten.
Ich bekomme da immer Verbindungsfehler. Der Status vom Landroid hingegen, wird mir aber korrekt angezeit. Ich vermute, dass wenn etwas gesperrt wird, das das die SN ist, die für weitere Befehle gesperrt wird.

Mir bleibt dann nur die Möglichkeit den Mähvorgang dierekt am Gerät zu starten.
Also kurz gesagt, Befehle senden geht nicht - Befehle empfangen hingegen schon.

So zumindest das was ich bisher bei mir feststellen konnte.

iobroker2001

@falke69 sagte in Adapter: Worx Landroid v2.x.x:

@iobroker2001

ich vermute bei mir das selbe Problem.
Selbst eine neue IP, bringt mir nichts und über die App kann ich den Landroid auch nicht starten.
Ich bekomme da immer Verbindungsfehler. Der Status vom Landroid hingegen, wird mir aber korrekt angezeit. Ich vermute, dass wenn etwas gesperrt wird, das das die SN ist, die für weitere Befehle gesperrt wird.

Mir bleibt dann nur die Möglichkeit den Mähvorgang dierekt am Gerät zu starten.
Also kurz gesagt, Befehle senden geht nicht - Befehle empfangen hingegen schon.

So zumindest das was ich bisher bei mir feststellen konnte.

Kann ich exakt so bestätigen.

Lucky_ESA

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

iobroker2001

@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"

Lucky_ESA

@iobroker2001

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

iobroker2001

@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.

falke69

@lucky_esa

.... 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.

iobroker2001

@falke69 sagte in Adapter: Worx Landroid v2.x.x:

@lucky_esa

.... 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?

falke69

@iobroker2001

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.

Lucky_ESA

@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

Lucky_ESA

@iobroker2001

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

falke69

@lucky_esa

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.

Andersmacher

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?

Lucky_ESA

@andersmacher

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

Andersmacher

@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.

? Offline

@andersmacher

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..

arteck

@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

NEWS

Adapter: Worx Landroid v2.x.x

Support us

756

32.4k

81.4k

1.3m