MQTT2 für Worx Landroid Mähroboter

[GreenFHEMfan]

Danke - ich habe das Device nicht gleich gefunden!

[GreenFHEMfan]

Hallo,
Eine Frage zu der Aktuallisierung der Daten vom Landroid-MQTT-Server.
Meines Erachtens ist dafür das Reading "mowerTimeCorrection" im MQTT-Device zuständig.
Es scheint so, daß die Readings sich nur sporatisch bzw. bei einer Änderung einiger Readings  aktuallisiert.
Darunter scheint der Akkustand nicht zu sein.
Es wäre schön, wenn man die Aktuallisierung über das "mowerTimeCorrection" Reading beeinflussen kann.
Bei mir stehen 10sec in dem Reading ohne das dies irgendein Einfluss hat.
Wäre es möglich, daß man die Aktualisierungzeit selbst beeinflussen kann? - ich kenn das so aus einem anderen Landroid-FHEM Modul, das momentan nicht mehr rund läuft.

Gruß Maik

[GreenFHEMfan]

Danke ! Das ging aber schnell 

Leider hat die Änderung nicht die gewünschte  Auswirkung.

Ich denke eine Lösung wäre, wenn aus dem Modul in der eingetragenen Zeit x von Reading "mowerTimeCorrection" ein Befehl (z.B.: set mowerTimeCorrection") Richtung Landroid-Server geschickt wird.

Alternativ kann man sich sicherlich etwas in FHEM basteln!

Gruß

[Flachzange]

mowerTimeCorrection hat nichts mit der Aktualisierung von Readings zu tun. Wie kommst Du drauf? Es ist die Mähzeitanpassung für den Mäher/Mähplan.

Was möchtest Du denn überhaupt erreichen? Die Readings werden dann aktualisiert, wenn sich die Werte ändern und natürlich wird der Akkustand (regelmäßig) aktualisiert. Bei mir alle ~10 Minuten, auch wenn sich nichts ändert.

[GreenFHEMfan]

Der Grund für mein Anliegen ist vielfältig - eine ist z.B. die Auswertung, wenn sich der Mäher auf der Heimfahrt festfrist und die Räder drehen munter weiter. Selbst bei 10 minütlicher Aktualisierung wäre die Zeitspanne zu lange um einen Fehler über den Akkustand zu generieren.
Wie gesagt, es sollte ein Reading geben oder ein Anstoßer an den Landroid-Server über das Modul.
Leider habe ich die alte andere LANDROID Installation gelöscht, wo das möglich war.

[Flachzange]

eine ist z.B. die Auswertung, wenn sich der Mäher auf der Heimfahrt festfrist und die Räder stehen munter weiter.

Und welches Reading liefert dir Diese Information?

Bei meinem Vision kann ich über

Code Auswählen Erweitern

{"cmd":0}
einen manuellen refresh auslösen.

[frober]

Wenn die Räder durchdrehen, würde ich das Drehmoment reduzieren (torqueSetting).
Bei mir steht das z.B. auf -30.
Wenn er dann auf Störung geht, wertest du mowerErrorTxt aus und sendest dir eine Nachricht.

Das häufige Anfordern von Daten führt zu einer 24h-Sperre.

[StephanFHEM]

Wurde das folgende Problem schon gelöst? Bei mir werden pausenlos Fehlermeldung wie die u.s in den Log geschrieben. Hab die Reconnects im Worx Client auch schon auf 21 gestellt und die Zahl im Log hat sich entsprechend geändert. Wird also definitiv von Worx ausgelöst

Code Auswählen Erweitern

2023.09.21 00:00:00 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:01 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:01 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:01 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:02 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:02 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:02 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:02 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:05 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:07 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:07 2: maxFailedConnects (20) reached, no more reconnect attemtps
2023.09.21 00:00:08 2: maxFailedConnects (20) reached, no more reconnect attemtps

[rudolfkoenig]

Bei mir werden pausenlos Fehlermeldung wie die u.s in den Log geschrieben.

Ich kann so eine "pausenlose" Fehlermeldung nachstellen, wenn ich waehrend der Reconnect-Phase die MQTT2_CLIENT Instanz umbenenne.
War das hier auch der Fall?

Hab die Reconnects im Worx Client auch schon auf 21 gestellt und die Zahl im Log hat sich entsprechend geändert. Wird also definitiv von Worx ausgelöst

Das habe ich nicht verstanden.

"(20)" im Log kommt aus dem maxFailedConnects Attribut, das wird im LandroidUtils.pm auf 20 gesetzt, falls es nicht vorhanden ist.
Es wird 20-mal in jeweils 3 Minuten Abstand versucht, eine Verbindung aufzubauen.
Falls das nicht zum Erfolg fuehrt, dann kommt einmal die Meldung ins Log, und der Benutzer muss neue Versuche mit "set m2c connect" starten.
So jedenfalls die Theorie.

[Flachzange]

Es wird 20-mal in jeweils 3 Minuten Abstand versucht, eine Verbindung aufzubauen.
Falls das nicht zum Erfolg fuehrt, dann kommt einmal die Meldung ins Log, und der Benutzer muss neue Versuche mit "set m2c connect" starten.
So jedenfalls die Theorie.

Das wäre ja OK, aber zumindest im Log taucht diese Meldung im ms-Abstand auf.

[StephanFHEM]

ist bei mir genau so im ms Abstand. Das bremst dann auch FHEM ganz schön aus. Das Attribut steht auf 20. Da ich nicht sicher war von welchem Device es kommt hab ich im Worx-Device bzw. Client das Attribut auf 21 gesetzt. Im Log tauchte dann auch die 21 auf. War für mich nur die Eingrenzung, dass es wirklich von Worx kommt.

Ich hab beim Reconnect kein Rename gemacht. Nach Neustart läuft das ganze teilweise auch fehlerlos für eine bestimmte Zeit (1-2 Tage) und erst dann geht es mit dauerhaft Fehlermeldungen los

[rudolfkoenig]

Koennt Ihr bitte die angehaengten Dateien einspielen, und damit einen neuen Versuch starten?
Vmtl. gibt es keine Endlosschleife damit, und im Problemfall steht im Log ein Text der Art:

RFN ERROR: m2s.localhost:1883 ne m2c.localhost:1883

Auf die konkrete Ausgestaltung des Textes bin ich in eurem Fall neugierig.

Das schuetzt nicht davor, dass die die Verbindung nicht hergestellt werden kann, nur von der Endlosschleife.

[Flachzange]

Danke, habe ersetzt und beobachte mal. Da es bei mir nur sporadisch auftrat kann es mit der Rückmeldung ggf. dauern.

[mabula]

Bitte Fehlermeldung nicht überbewerten, teils erwartbar.
Wegen Endlosmeldung habe ich auch die zwei Routinen übernommen. Ich habe folgende Meldung erhalten:

Code Auswählen Erweitern

2023.10.18 22:01:32.335 1: ERROR: Landroid_connect MQTT_Worx - read from https://id.worx.com:443 timed out
2023.10.18 22:04:33.079 1: ERROR: Landroid_connect MQTT_Worx - read from https://id.worx.com:443 timed out
Allerdings wurde der Landroid tags zuvor in den Winterschlaf gesetzt, durch Ausschalten am Button und danach erst Akku entfernt.

Gruß Hans-Jörg

[StephanFHEM]

Die Endlos-Fehlermeldungen im Log waren weg. Jetzt sind sie wieder da. Wahrscheinlich aber nur, weil ich vor ein paar Tagen ein FHEM Update gemacht habe und die Daten evnt. wieder mit den offiziellen Versionen ersetzt wurden. Kann der Workaround gegen die Endlosschleife in die offizielle Version überführt werden?

Diese RFN Error Fehlermeldung habe ich übrigens in der ganzen Zeit auch nicht bekommen und die Verbindung lief fehlerfrei