Adapter: Worx Landroid v2.x.x
-
Hier mein Text den ich im November geschrieben hatte.
Hallo zusammen,
kurz vor der Winterpause gibt es noch ein Update auf dem GIT was ich gerne noch erklären möchte.
Fix:- bei 2 Mäher mit Off Limit Modul
- versenden von calJson und calJson2
- edgeCut
Neu:
- Die 24h Sperre wird nun im Log angezeigt. Wenn ihr den u. a. Text im Log findet, dann öffnet bitte eure Worx APP und wischt mal von oben nach unten. Wenn dann ein "Verbindungsfehler" angezeigt wird, dann bitte iobroker bzw. den Worx Adapter nicht neu starten. Die Mqtt Verbindung wird automatisch getrennt und nach 24h wieder neu gestartet und alles ist GUT. Macht ihr einen Restart, löscht ihr den Intervall und müsst dann nach 24h manuelll den Adapter neu starten. Leider spreche ich aus eigener Erfahrung... Kommt kein Verbindungsfehler ist eventuell euer Worx Offline oder Worx hat ein Problem.
"Maybe your connection is blocked from Worx. Restart Mqtt connection automatic in 24h" - Wenn ihr Blocklys erstellt und Datenpunkte steuert, muss immer min. 1,1 Sekunden Timeout zwischen dem Setzen sein. Wer diese nicht einhält bekommt diese Meldung: "Time between requests within (die Zahl) ms is not allowed. STOP Request (Datenpunkt) with value (Wert)"
- Für den der automatischen Mähplan aktiviert hat sind die DB im Folder "Calendar" gesperrt. Wenn ihr diese ändert, wird die APP sofort seine geplanten Zeiten erneut zum Mower senden, daher diese Sperre. Meldung: "Automatic mowing plan active! Times cannot be changed."
- CMD Commands sind von 0 bis 9 begrenzt. Habe zum testen immer eine Zahl >9 verwendet und wurde gesperrt. Ob es wirklich daran lag, kann ich natürlich nicht bestätigen.
- Es gibt einen neuen Datenpunkt xx.mower.last_command. Hier werden eure Request und Response vom Worx gespeichert (Max. 20x). Diesen Inhalt könnt ihr auswerten und prüfen, ob euer Request vom Worx empfangen wurde. Die Daten könnt ihr auswerten und euch per VIS anzeigen lassen. Wie ihr das umsetzen könnt werde ich noch ein Blockly als Beispiel hier einfügen. Bei "user" kann nur iobroker oder APP stehen...
Wenn ich viel Zeit habe, werde ich ein korrigiertest Blockly für die Vis Darstellung zur Verfügung stellen.
Gruß//Lucky
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@saeft_2003 sagte in Adapter: Worx Landroid v2.x.x:
Ich hab gerade aktualisiert über git. Heißt das ich kann jetzt mein blockly nicht mehr verwenden, oder habe ich das falsch verstanden?
So ist es!
Kann ich nicht einfach die 2.0.3 drüber installieren? Sonst gehe ich mit einem snapshot zurück…
-
@saeft_2003 sagte in Adapter: Worx Landroid v2.x.x:
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@saeft_2003 sagte in Adapter: Worx Landroid v2.x.x:
Ich hab gerade aktualisiert über git. Heißt das ich kann jetzt mein blockly nicht mehr verwenden, oder habe ich das falsch verstanden?
So ist es!
Kann ich nicht einfach die 2.0.3 drüber installieren? Sonst gehe ich mit einem snapshot zurück…
Es werden einfach nicht die Zeiten gelöscht die um 00:01 gelöscht werden sollen. Das ist euch nie aufgefallen da es eigentlich keinen Impakt auf die Mähzeiten hat. Du kannst vom GIT laden...Ohne Mäher kannst du den Blockly sowieso nicht gebrauchen
Gruß//Lucky
-
Hallo zusammen,
es wird hier darüber berichtet, dass der Adapter eine 24h Sperre auslöst.
Woran es wirklich liegt kann ich derzeit leider nicht sagen. Hatte gestern gegen 18 Uhr meinen Mäher aufgestellt und den Adapter wieder aktiviert. Es lief alles min. 12 Stunden einwandfrei und aufgrund dieses Issues musste ich meinen Dev Server starten. Folglich im Live System Adapter deaktiviert und auf dem Dev gestartet. Nach 2 x absenden eines Befehls habe ich nun auch die 24h Sperre vor mir.Zur Sichertheit möchte ich noch das unötige Absenden von Befehlen reduzieren. Hierzu gibt es bald 2 neue Datenpunkte:
worx.0.xxx.calendar.calJson_tosend: Wenn ihr Zeiten eintragt (wahrscheinlich über Blockly) werden diese hier als JSON gesammelt.
worx.0.xxx.calendar.calJson_sendto Wenn ihr alle Änderungen vorgenommen habt. muss dieser Button zum versenden auf true gesetzt werden.Warum dieser Umstand?
Die Blocklys hier im Forum steuern alles einzeln.
Vortag borderCut -> Wird sofort versendet 1. MQTT Übertragung
Vortag startTime -> Wird sofort versendet 2. MQTT Übertragung
Vortag workTime -> Wird sofort versendet 3. MQTT Übertragung
Heute borderCut -> Wird sofort versendet 4. MQTT Übertragung
Heute startTime -> Wird sofort versendet 5. MQTT Übertragung
Heute workTime -> Wird sofort versendet 6. MQTT Übertragung
Und das ganze zeitgleich noch für den schedule2 diese sowieso nicht durchgehen da dieser zeitgleich gestartet wird.
Dann noch tagsüber mehrfache Zeitenänderung in der Reihenfolge 1-3 wie oben beschrieben.Ihr müsst dann nur worx.0.xxx.calendar.calJson_sendto am Ende eure 4 x schedules (2 x Datensetzung 3min vor Startzeit und 2 x Löschung des von vor zwei Tagen um 00:01) setzen...Am besten mit einem 3 Sekunden timeout.
Bei den minütlichen Interval bei jedem Tag hinzufügen und um Mitternacht am Ende der Funktion "Zeiten_setzen".Gruß//Lucky
-
@lucky_esa Zum Verständnis: Das passiert, wenn man über den Adapter was ändert? Nicht, wenn man nur liest?
-
@merlin123 sagte in Adapter: Worx Landroid v2.x.x:
@lucky_esa Zum Verständnis: Das passiert, wenn man über den Adapter was ändert? Nicht, wenn man nur liest?
Das kann ich leider nicht bestätigen. Das probiere ich gerade aus daher kann ich die Änderungen vom Code nicht testen. Das müsst ihr dann machen. Gebe bescheid wenn die Änderungen auf`m GIT sind.
Gruß//Lucky
-
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
-
hättest Du vielleicht ein fertiges Blockly mit den Datenpunkten, welches Du zur Verfügung stellen könntest?
Danke
-
@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?
-
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.
-
@falke69 sagte in Adapter: Worx Landroid v2.x.x:
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.
-
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
