NEWS
Adapter: Worx Landroid v2.x.x
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@falke69
Freut mich. Bitte immer daran denken das die u. a. Datenpunkte ohne Timeout gesetzt werden müssen.
wochentagname/borderCut
wochentagname/startTime
wochentagname/workTime
Danach ein Timeout von 1,1 Sek. und worx.0.xxxxxxxxxxx.calendar.calJson_tosend auf true setzen.Verständnisfrage:
Was meinst Du mit "Timeout", meinst Du Pause?
Also: Die 3 Werte beschreiben ohne zwischendurch eine Pause einzulegen, dann aber mindestens eine Pause von 1,1 Sek, um ..._tosend auf true zu setzen?Verständnisfrage:
Was meinst Du mit "Timeout", meinst Du Pause?
Also: Die 3 Werte beschreiben ohne zwischendurch eine Pause einzulegen, dann aber mindestens eine Pause von 1,1 Sek, um ..._tosend auf true zu setzen?Gneau so. Die 1,1 Sekunden dienen zur Sicherheit das alle Daten wirklich gesetzt sind. Wenn jemand am Sonntag alle 14 Zeiten für die Folgewoche setzt sind das viele Daten die erst verarbeitet werden müssen. Wie bereits gesagt kann ich ein STOPP für die Aktualisierungen hinzufügen, dann kann man sich Zeit nehmen. Das wäre dann aber einiges an Aufwand für mich da man diesen STOPP eventuell auch versehntlich setzen könnte. Dann würden keine Updates mehr kommen.
Gruß//Lucky
-
Verständnisfrage:
Was meinst Du mit "Timeout", meinst Du Pause?
Also: Die 3 Werte beschreiben ohne zwischendurch eine Pause einzulegen, dann aber mindestens eine Pause von 1,1 Sek, um ..._tosend auf true zu setzen?Gneau so. Die 1,1 Sekunden dienen zur Sicherheit das alle Daten wirklich gesetzt sind. Wenn jemand am Sonntag alle 14 Zeiten für die Folgewoche setzt sind das viele Daten die erst verarbeitet werden müssen. Wie bereits gesagt kann ich ein STOPP für die Aktualisierungen hinzufügen, dann kann man sich Zeit nehmen. Das wäre dann aber einiges an Aufwand für mich da man diesen STOPP eventuell auch versehntlich setzen könnte. Dann würden keine Updates mehr kommen.
Gruß//Lucky
@lucky_esa Alles klar, danke, es scheint zu funktionieren!!
-
Verständnisfrage:
Was meinst Du mit "Timeout", meinst Du Pause?
Also: Die 3 Werte beschreiben ohne zwischendurch eine Pause einzulegen, dann aber mindestens eine Pause von 1,1 Sek, um ..._tosend auf true zu setzen?Gneau so. Die 1,1 Sekunden dienen zur Sicherheit das alle Daten wirklich gesetzt sind. Wenn jemand am Sonntag alle 14 Zeiten für die Folgewoche setzt sind das viele Daten die erst verarbeitet werden müssen. Wie bereits gesagt kann ich ein STOPP für die Aktualisierungen hinzufügen, dann kann man sich Zeit nehmen. Das wäre dann aber einiges an Aufwand für mich da man diesen STOPP eventuell auch versehntlich setzen könnte. Dann würden keine Updates mehr kommen.
Gruß//Lucky
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
Wie bereits gesagt kann ich ein STOPP für die Aktualisierungen hinzufügen, dann kann man sich Zeit nehmen. Das wäre dann aber einiges an Aufwand für mich da man diesen STOPP eventuell auch versehntlich setzen könnte. Dann würden keine Updates mehr kommen.
Das kann man ja gut in Blockly abfangen. 1,1 s sind ja auch nicht so lange.
Bspw. könnte man eine "Belegt"-Variable setzen, die bei jedem Änderungsvorgang im Kalender gesetzt wird.
Ein Timeout von 1,1 s (oder besser 1,2 s) setzt diese Belegt-Variable zurück.
Bevor ein Wert geändert wird, muss die Belegt-Variable auf "nicht belegt" geprüft werden. Wenn "belegt" -> Datenpunkt nicht ändern. -
Verständnisfrage:
Was meinst Du mit "Timeout", meinst Du Pause?
Also: Die 3 Werte beschreiben ohne zwischendurch eine Pause einzulegen, dann aber mindestens eine Pause von 1,1 Sek, um ..._tosend auf true zu setzen?Gneau so. Die 1,1 Sekunden dienen zur Sicherheit das alle Daten wirklich gesetzt sind. Wenn jemand am Sonntag alle 14 Zeiten für die Folgewoche setzt sind das viele Daten die erst verarbeitet werden müssen. Wie bereits gesagt kann ich ein STOPP für die Aktualisierungen hinzufügen, dann kann man sich Zeit nehmen. Das wäre dann aber einiges an Aufwand für mich da man diesen STOPP eventuell auch versehntlich setzen könnte. Dann würden keine Updates mehr kommen.
Gruß//Lucky
wenn ich die worx.0.xxxxxxxxxxx.calendar.calJson_tosend mit einemmal direkt mit meinem Blockly fülle und dann zwei Sekunden oder mehr warte, dann kommt nur der Request Counter ohne eine "Fehlermeldung" das scheint auf jeden Fall zu funktionieren.
Jetzt können wir nur hoffen, dass dies die worxcloud milde stimmt und den User nicht wieder für 24 Stunden sperrt.
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@falke69
Freut mich. Bitte immer daran denken das die u. a. Datenpunkte ohne Timeout gesetzt werden müssen.
wochentagname/borderCut
wochentagname/startTime
wochentagname/workTimeAus diesem Grund habe ich mir vorerst ein Blockly erstellt, welches dann in einem Rutsch alle Einträge der Mähzeiten aus meinen Datenpunkten direkt in der worx.0.xxxxxxxxxxx.calendar.calJson_tosend setzt.
Das mit dem TimeOut schaue ich mir nchmal an. Danke für den Hinweis.
@falke69
Könntest du das Blocky hier veröffentlichen? Ich bin leider ein Laie und komme mit Json nicht zurecht.
Vielen Dank im voraus.Gruß
Martin
Intel NUCs mit Proxmox / Iobroker als VM unter Debian
Raspeberry mit USB Leseköpfen für Smartmeter
Homematic und Homematic IP -
@falke69
Könntest du das Blocky hier veröffentlichen? Ich bin leider ein Laie und komme mit Json nicht zurecht.
Vielen Dank im voraus.gerne, ich muss nur schauen, wie ich das in mein altes Script mit integriere. Mir war es aktuell wichtig, dass die Daten auch beim Mäher ankommen und ich nicht gesperrt werde.
Das einbetten als Code funktioniert leider nicht (code zu lang). Daher als *.txtIch bin auch kein Experte, vielleicht gibt es hier oder da auch noch Verbesserungsvorschläge (einfacher, übersichtlicher,...)
-
gerne, ich muss nur schauen, wie ich das in mein altes Script mit integriere. Mir war es aktuell wichtig, dass die Daten auch beim Mäher ankommen und ich nicht gesperrt werde.
Das einbetten als Code funktioniert leider nicht (code zu lang). Daher als *.txtIch bin auch kein Experte, vielleicht gibt es hier oder da auch noch Verbesserungsvorschläge (einfacher, übersichtlicher,...)
-
gerne, ich muss nur schauen, wie ich das in mein altes Script mit integriere. Mir war es aktuell wichtig, dass die Daten auch beim Mäher ankommen und ich nicht gesperrt werde.
Das einbetten als Code funktioniert leider nicht (code zu lang). Daher als *.txtIch bin auch kein Experte, vielleicht gibt es hier oder da auch noch Verbesserungsvorschläge (einfacher, übersichtlicher,...)
@falke69
Kannst du noch dein Hauptscript posten, ich habe eine andere Datenpunkt-Ordnung. Bei mir liegen alle DPs in einem Ordner:
Gruß
Martin
Intel NUCs mit Proxmox / Iobroker als VM unter Debian
Raspeberry mit USB Leseköpfen für Smartmeter
Homematic und Homematic IP -
@falke69
Kannst du noch dein Hauptscript posten, ich habe eine andere Datenpunkt-Ordnung. Bei mir liegen alle DPs in einem Ordner:
Ich habe zwei Scripte parallel laufen lassen, eins für die erste Zeit und eins für die zweite Zeit.
Ich habe damit immer nur den Kalender im Adapter für die erste Zeit befüllt. Da irgendwie die zweite Zeit im Kalender nicht funktioniert hatte.Du brauchst ja nur die Datenpunke im Script anklicken und gegen Deine zu tauschen.
Aktuell bin ich mir noch nicht ganz sicher, wie in Zukunft vorgehe. Wie gesagt, mir ging es aktuell nur darum, dass ich nicht gesperrt werde und die Daten auch übertragen werden.
Ich bin auch nicht der Experte.
In den anderen beiden Scripte werden Deine Datenpunke auch nicht mit meinen übereinstimmen.Schau mal hier im Forum.
Ich will auch nicht unhöflich erscheinen, aber hier geht es um den Adapter und nicht um das Script. -
Ich habe zwei Scripte parallel laufen lassen, eins für die erste Zeit und eins für die zweite Zeit.
Ich habe damit immer nur den Kalender im Adapter für die erste Zeit befüllt. Da irgendwie die zweite Zeit im Kalender nicht funktioniert hatte.Du brauchst ja nur die Datenpunke im Script anklicken und gegen Deine zu tauschen.
Aktuell bin ich mir noch nicht ganz sicher, wie in Zukunft vorgehe. Wie gesagt, mir ging es aktuell nur darum, dass ich nicht gesperrt werde und die Daten auch übertragen werden.
Ich bin auch nicht der Experte.
In den anderen beiden Scripte werden Deine Datenpunke auch nicht mit meinen übereinstimmen.Schau mal hier im Forum.
Ich will auch nicht unhöflich erscheinen, aber hier geht es um den Adapter und nicht um das Script. -
@Lucky_ESA es war tatsächlich ein Serverproblem die letzten Tage. Hat mir der Support bestätigt. Es sollte jetzt behoben sein.
-
worx.0 2023-04-07 17:46:52.197 info State value to set for "worx.0.1234.mower.firmware" has to be type "string" but received type "number"Kannst du bitte mal schauen was bei dir eingetragen wird.
worx.0.xxx.mower.firmwareWo die ganzen Nachkommastellen herkommen? Keine Ahnung. -> Gute Frage
Der Typ der Firmwaredatenpunkte ist Zahl und nicht Zeichenkette. Ist das Absicht? -> Ja, hatte mir tagelang Gedanken zu gemacht. Schau mal unter worx.0.xxx.mower.firmware_available_all, dort kommt so ein Format nicht vor.Kann der Entwickler ja vielleicht entscheiden, ob da noch Änderungen notwendig/sinnvoll sind, auch bezüglich Datentyp. -> Das soll eigentlich bei Number bleiben. Bitte weiter beobachten.
Bei mir tritt dieses Thema nicht auf.Auf dem GIT ist nun der Fehler "calJson_sendto" behoben.
Gruß//Lucky
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
Wo die ganzen Nachkommastellen herkommen? Keine Ahnung. -> Gute Frage
Ich könnte mir vorstellen, daß das mit dem "klassischen Problem" der Behandlung von Fließkommazahlen in Rechnern/CPUs zu tun hat. Die Darstellung einer solchen Fließkommazahl ist halt unter bestimmten Randbedingungen nicht exakt möglich. Dadurch "schummeln" sich am Ende manchmal ein paar Digits dazu.
Bei Integer-Zahlen tritt dieser Effekt in der Regel nicht auf. Bei Strings übrigens auch nicht, daher meine "vorsichtige Anfrage", ob der Typ String vielleicht besser geeignet wäre.
Wenn es dennoch bei Typ Zahl bleiben soll (weil Du davon ausgehst, daß ein Format wie 3.28.x nicht auftreten wird), könnte es vielleicht helfen, den Wert auf z. B. 2 Nachkommastellen zu runden (weil man dann ja auch davon ausgehen könnte, daß ein Format wie z. B. 3.28y nicht auftreten wird)?
Was spricht denn gegen den Typ Zeichenkette? Dort gäbe es die Ungenauigkeits-/Stellenproblematik doch gar nicht. Und letztendlich ist doch eine Firmwareversionsangabe nach meinem Verständnis von der Logik her auch keine Zahl, sondern eine Zusammensetzung aus zwei weitgehend unabhängig von einander bestehenden Einzelzahlen, weil nach 1.99 nicht zwangsweise 2.00, sondern z. B. 1.100 kommen kann.
Zeichenkette wäre aus meiner Sicht daher der (Zukunfts)"sichere" Typ, der immer funktionieren wird und nicht nur, wenn bestimmte Randbedingungen/Annahmen zutreffen - oder?
ioBroker auf Raspi4B 8GB Debian(12) 64Bit
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@iobroker2001 Ich versuche alle Befehle zu einen zu ändern. Scheiter aber schon an Areas. Habe keine Ahnung was man dort einstellen könnte. Kann das nicht testen da ich keine Areas habe. Dann werde ich Autolock zusammenführen und OneTime. Leider weiß ich auch noch nicht wofür OneTime sein soll. Habe mein Mäher auf automatischen Mähplan stehen und musste bis dato nie was ändern.
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.@iobroker2001 said in Adapter: Worx Landroid v2.x.x:
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@iobroker2001 Ich versuche alle Befehle zu einen zu ändern. Scheiter aber schon an Areas. Habe keine Ahnung was man dort einstellen könnte. Kann das nicht testen da ich keine Areas habe. Dann werde ich Autolock zusammenführen und OneTime. Leider weiß ich auch noch nicht wofür OneTime sein soll. Habe mein Mäher auf automatischen Mähplan stehen und musste bis dato nie was ändern.
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.Moin,
ich stelle mich gerade ganz doof an. Steuerst du den onetimestart mit dem Blockly Element „umschalten“ an?
Danke
-
@iobroker2001 said in Adapter: Worx Landroid v2.x.x:
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@iobroker2001 Ich versuche alle Befehle zu einen zu ändern. Scheiter aber schon an Areas. Habe keine Ahnung was man dort einstellen könnte. Kann das nicht testen da ich keine Areas habe. Dann werde ich Autolock zusammenführen und OneTime. Leider weiß ich auch noch nicht wofür OneTime sein soll. Habe mein Mäher auf automatischen Mähplan stehen und musste bis dato nie was ändern.
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.Moin,
ich stelle mich gerade ganz doof an. Steuerst du den onetimestart mit dem Blockly Element „umschalten“ an?
Danke
@muuulle Den One-Time-Scheduler verwende ich z. Zt. noch nicht in ioBroker, nur per App.
Aber von meinem Verständnis her müsste oneTimeWorkTime gesetzt werden (in Minuten), und oneTimeStart (ist ja boolean) auf true.
Ich würde es mit "Steuern" versuchen. -
@iobroker2001 said in Adapter: Worx Landroid v2.x.x:
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@iobroker2001 Ich versuche alle Befehle zu einen zu ändern. Scheiter aber schon an Areas. Habe keine Ahnung was man dort einstellen könnte. Kann das nicht testen da ich keine Areas habe. Dann werde ich Autolock zusammenführen und OneTime. Leider weiß ich auch noch nicht wofür OneTime sein soll. Habe mein Mäher auf automatischen Mähplan stehen und musste bis dato nie was ändern.
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.Moin,
ich stelle mich gerade ganz doof an. Steuerst du den onetimestart mit dem Blockly Element „umschalten“ an?
Danke
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
@iobroker2001 Ich versuche alle Befehle zu einen zu ändern. Scheiter aber schon an Areas. Habe keine Ahnung was man dort einstellen könnte. Kann das nicht testen da ich keine Areas habe. Dann werde ich Autolock zusammenführen und OneTime. Leider weiß ich auch noch nicht wofür OneTime sein soll. Habe mein Mäher auf automatischen Mähplan stehen und musste bis dato nie was ändern.
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.@iobroker2001 sagte in Adapter: Worx Landroid v2.x.x:
Mit OneTime kann man - ohne den Mähplan zu ändern - den Roboter für einstellbare, vorgegebene Schritte für 30, 60, 90,... Minuten einmal (deshalb "One"Time) zum Mähen schicken.
Ist ganz praktisch aus der App heraus zu bedienen, aber für eine ioBroker-Steuerung m. Mn. (!) nach nicht nötig.Es gibt viele Funktionen, die in der App praktisch zu bedienen sind und dennoch ihre Daseinsberechtigung im ioBroker haben. Nicht jeder mag halt die Worx App. Es gibt z.B. Anwender, die Start- und Endezeit einer Einmal-Mähsession in einen Google-Kalender eintragen. Dieser Eintrag wird dann in ioBroker ausgewertet und entsprechend der One-Time-Scheduler aus ioBroker heraus angesteuert.
-
@lucky_esa sagte in Adapter: Worx Landroid v2.x.x:
Wo die ganzen Nachkommastellen herkommen? Keine Ahnung. -> Gute Frage
Ich könnte mir vorstellen, daß das mit dem "klassischen Problem" der Behandlung von Fließkommazahlen in Rechnern/CPUs zu tun hat. Die Darstellung einer solchen Fließkommazahl ist halt unter bestimmten Randbedingungen nicht exakt möglich. Dadurch "schummeln" sich am Ende manchmal ein paar Digits dazu.
Bei Integer-Zahlen tritt dieser Effekt in der Regel nicht auf. Bei Strings übrigens auch nicht, daher meine "vorsichtige Anfrage", ob der Typ String vielleicht besser geeignet wäre.
Wenn es dennoch bei Typ Zahl bleiben soll (weil Du davon ausgehst, daß ein Format wie 3.28.x nicht auftreten wird), könnte es vielleicht helfen, den Wert auf z. B. 2 Nachkommastellen zu runden (weil man dann ja auch davon ausgehen könnte, daß ein Format wie z. B. 3.28y nicht auftreten wird)?
Was spricht denn gegen den Typ Zeichenkette? Dort gäbe es die Ungenauigkeits-/Stellenproblematik doch gar nicht. Und letztendlich ist doch eine Firmwareversionsangabe nach meinem Verständnis von der Logik her auch keine Zahl, sondern eine Zusammensetzung aus zwei weitgehend unabhängig von einander bestehenden Einzelzahlen, weil nach 1.99 nicht zwangsweise 2.00, sondern z. B. 1.100 kommen kann.
Zeichenkette wäre aus meiner Sicht daher der (Zukunfts)"sichere" Typ, der immer funktionieren wird und nicht nur, wenn bestimmte Randbedingungen/Annahmen zutreffen - oder?
@andersmacher sagte in Adapter: Worx Landroid v2.x.x:
Was spricht denn gegen den Typ Zeichenkette?
Nichts - außer dass bei einem derartigen Kompatibilitätsbruch hunderte (oder tausende?) Skripte in der Anwenderwelt auf die Nase fallen würden.
-
@andersmacher sagte in Adapter: Worx Landroid v2.x.x:
Was spricht denn gegen den Typ Zeichenkette?
Nichts - außer dass bei einem derartigen Kompatibilitätsbruch hunderte (oder tausende?) Skripte in der Anwenderwelt auf die Nase fallen würden.
@hsteinme Naja, das passiert dann aber nur genau einmal im Sinne eines "breaking change" zur Optimierung des Adapters, damit es dann später keine weiteren Probleme mehr gibt. Ich würde es nicht als Nachteil sehen, einen Datenpunkttyp zu ändern, wenn man irgendwann merkt, daß die bisherige Definition ungewollte Randeffekte erzeugt.
-
@falke69
Freut mich. Bitte immer daran denken das die u. a. Datenpunkte ohne Timeout gesetzt werden müssen.
wochentagname/borderCut
wochentagname/startTime
wochentagname/workTimeDanach ein Timeout von 1,1 Sek. und worx.0.xxxxxxxxxxx.calendar.calJson_tosend auf true setzen.
In dieser Zeit darf natürlich nicht automatisch ein Update kommen, da die geänderten Zeiten wieder glöscht werden. Wenn das zu oft vorkommt, dann muss ich leider einen weiteren Datenpunkt hinzufügen der Updates von MQTT oder den 10 Minuten Refresh unterbindet.Das gleich gilt natürlich auch für diese:
mower.oneTimeWithBorder
mower.oneTimeWorkTimeUnd dann nach 1,1 Sek. worx.0.xxx.mower.oneTimeStart setzen.
Noch einige Änderungen:
worx.0.xxx.mower.AutoLock setzen und worx.0.xxx.mower.AutoLockTimer ist 0, wird automatisch 300 genommen.
Ist worx.0.xxx.mower.AutoLock false und man setzt worx.0.xxx.mower.AutoLockTimer eine neue Zeit, wird worx.0.xxx.mower.AutoLock automatisch true gesetzt.Gruß//Lucky
habe aktuell die v2.1.1 installiert.
Jetzt war er das erste mal mit der Version des Adapters unterwegs.
Das kam dabei raus.Ob das nur eine einmalige Sache war, kann ich nicht beurteilen.
Ich beobahte einfach mal weiter.
Ansonsten sehr gute Arbeit
-
Habe mein Mäher auch mal wieder aktiviert und den Adapter upgedatet.
Nutzte die VIS mit Blockly und kann noch keinen Fehlereintrag oder Sperrung sehen. Habe am Blockly nix geändert
Support us
713
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge