UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[tombox]

@saeft_2003 Probier mal die GitHub version zu installieren ob das verhalten dann weg ist.

[saeft_2003]

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

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

@lucky_esa

Alles klar. Funktioniert dann wieder alles wenn Robby wieder online ist, oder muss am Adapter was gefixt werden?

Wird wieder funktionieren wenn der Mower wieder Online ist. Aber für den nächsten Winterschlaf werde ich das trotzdem fixen.

Gruß//Lucky

Ok alles klar jetzt hab ichs kapiert 👍

[Lucky_ESA]

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

@saeft_2003 Probier mal die GitHub version zu installieren ob das verhalten dann weg ist.

Das war jetzt für mich nicht so gut. Habe doch viele Veränderungen auf`m Git die die fehlerhaften Abfragen blockiert und somit das Blockly umbrauchbar macht. Habe eigentlich den Text für die neuen Funktionen fertig und das neue Blockly zu 90%...Aber du hast ja Recht, ihr werdet jetzt über Sentrys zugespamt...

[saeft_2003]

@lucky_esa

Ich hab gerade aktualisiert über git. Heißt das ich kann jetzt mein blockly nicht mehr verwenden, oder habe ich das falsch verstanden?

[Lucky_ESA]

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

@lucky_esa

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!

[Lucky_ESA]

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

Beispiel

   "request": 1667452500820,
   "response": 1667452501610,
   "action": "worx.0.xxxx.calendar.calJson",
   "user": "iobroker"

Wenn ich viel Zeit habe, werde ich ein korrigiertest Blockly für die Vis Darstellung zur Verfügung stellen.

Gruß//Lucky

[saeft_2003]

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

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

@lucky_esa

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…

[Lucky_ESA]

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

@lucky_esa

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

[Lucky_ESA]

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

[Merlin123]

@lucky_esa Zum Verständnis: Das passiert, wenn man über den Adapter was ändert? Nicht, wenn man nur liest?

[Lucky_ESA]

@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

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