Robonect.de

Hallo,
mein Mower = Silenio-City-500, Robonect-WEB-Interface, Robonect-MQTT, Kamera
und auch parallel Gardena-Cloud-Connection.
Ich schließe mich den Feststellungen von versuchskaninchen an:
viewtopic.php?p=24763#p24763
und habe fast dasselbe Erscheinungsbild.
Die Vermutungen, dass das mit Netztwerkerei zu tun haben könnte, schließe ich ebenfalls komplett aus.

Das Verhalten stellt sich bei mir so dar, dass man es "fast" gar nicht bemerkt,
wenn man dem Mower nicht nachts beim Schlafen stört

Fall 1:
Mower arbeitet bis 20 Uhr, dann in Ladestation und laden,
alles ist noch gut (Status = Laden) , dann ist er fertig , zeigt den Status=Parkt und nach
einer kurzen Zeit schlafen (Status=schläft 17). Soweit okay.
Ab dann mache ich zyklisch so alle 30 sec im Browser mit http-API http://x.y.z.a/json?cmd=status.
Alles antwortet korrekt, immer mit Status 17, Webinterface läuft ebenso okay, Kamera übermittelt Bilder,
MQTT aktualisiert fleißig. Alles okay.
Macht man nach z.B. 15min (aktuell schläft der Mower) http://x.y.z.a/json?cmd=battery oder im Web-Interface dieselbe
Aktion, bekommt man im Browser nach einiger Zeit vom Return-Json nur die erste Klammer "{" zurück.
Im Web-Interface steht dann "bitte warten ... wird geweckt..." das läuft auch ins leere.
Versucht man mit der Browser-API oder im WEB-Interface nun nichts weiter, merkt man, dass nach einer gewissen Zeit der Mower wieder im Status "Schläft" ist. Ist man zu hektisch und sendet weitere Anfragen cmd=battery oder cmd=start oder im Web-Frontend /engines oder /loops , kommt der Mower nicht mehr klar, zeigt immer "bitte warten ... wird geweckt..."
und verabschiedet sich in Status 255 ohne Error-Eintrag in die Fehlerhistorie.
Nach "vielen" weiteren Versuchen Mode=home,Mode=Auto , Start, Stop klappts dann irgendwann doch wieder:
Mower ist im Status schläft und nimmt am nächsten morgen wieder okay die Mäharbeit in Angriff, ohne weitere Eingriffe.

Fall2:
Mower geht in Fehlerzustand bei Mähen "Fehler - Angehoben..." . Per Mqtt und Gardena-Cloud kommt die Fehlermeldung.
Fehlerursache ist behoben nach einer Stunde in diesem Zustand (mal angenommen, man kommt eher nicht dazu,
das Problem zu beseitigen).
Im Webinterface benutze ich die Funktion "Fehler zurücksetzen" . Das endet mit der Ausschrift
"Start fehlgeschlagen! (Zeitüberschreitung 33)" im Web-Interface.
Wenig später stellt sich als Ergebnis Status 255 Hardwarefehler ein.
Jetzt kann man wieder ein paar mal rumprobieren, irgendeine andere Funktion zu benutzen, z.B. Modus von Auto auf home umschalten oder so. Meist kommt der Mower nicht mehr klar und verabschiedet sich immer wieder nach Status 255, aber ohne Error-Eintrag in die Fehlerhistorie.
Immer kommt "bitte warten ... wird geweckt..." und dann passiert meist nichts mehr.
Irgendwann klappt dann doch mal "Fehler zurücksetzen", "Start" und "Mode = Auto" setzen.

In beiden Fällen hat der Mower richtig gutes WLAN. Die Mqtt-Status-Ansagen kommen auch permanent.
Wenn man nach zigfachen API-Aufrufen oder Aktionen im WEB-Frontend keinen Erfolg hatte,
konnte ich durch einen Neustart der Robonect-Schnittstelle: WEB: Robonect->Service->Neustart nach dem Neustart dann
gefühlt schneller wieder einen "ordentlichen" Zustand erreichen.

Das Verhalten habe ich seitdem ich in 06/2020 auf die neueste von Gardena
ausgelieferte Firmware umgestiegen bin. (Wie man die wieder downgraden kann, ist mir nicht bekannt,
somit kann ich auch nicht nachstellen, ob das stimmt, was ich behaupte)
Die Robonect Software-Versionen (siehe unten) hatte ich schon eher. Da lief meines Erachtens noch alles gut.

Stört man den Robbi allerdings nachts nicht und fährt er tagsüber auf kein Hindernis,
wo er sich dran in den Fehlerzustand begibt, läuft alles bestens und stabil, tagelang.

Software-Zusand:

Gardena:
MSW-Software: P0.1
MSW-Version: 20.25.00
MSW-Datum: 2020-05-27 15:56:12
SUB-Version: 6.05.00

Robonect:
Bootloader
Version: V1.0
Kompiliert: 17.03.2019 18:38
Bemerkung: Release V1.0
WLAN
AT-Version: V1.7.3
SDK-Version: V3.0.3
Kompiliert: 27.03.2020
ZeroConf
Version: V1.4
Kompiliert: 09.07.2019 22:49
Bemerkung: ZeroConf V1.4
Applikation
Version: V1.2
Kompiliert: 13.04.2020 20:33
Bemerkung: V1.2 RC0 (Beta-Version)

Können zu viele gleichzeitige Verbindungen zu Robonect als Ursache ausgeschlossen werden?

Ich glaube eher nicht daran, an meinen Zugriffs-Bedingungen hat sich seit einem Jahr nichts verändert,
zugegeben, einige Dinge reden schon mit Robonect:

-FHEM hat HTTP-Device und fragt alle 1 min den Status ab, benutze ich auch um den Robbi zu starten/stoppen,
wenn ich aus anderen Quellen weiß, das der Robbi jetzt lieber nicht arbeiten sollte
-FHEM hat Mower auch als Gardena-Device und macht auch irgendwas aber nicht mit Robonect
-Robonect sendet MQTT-Nachrichten zu eigenem MQTT-Broker im internen Netzwerk, FHEM hat dann noch ein Mower-MQTT-Device
-Manchmal benutze ich Robonect-Web-Frontend parallel noch dazu
-Zusätzlich besteht die Möglichkeit, das mehrere konkurrierende Web-Clients von der Mower-Kamera Bilder anfordern.

Alldies (ist schon ganz schön anstrengend) hat bisher aber nie zu Problemen geführt.
Es gibt schon mal temporäre Engpässe, die sehen aber im Ergebnis bisher anders aus: da läuft mal was in einen Timeout und gleich danach ist alles wieder gut. WLAN-Abrisse, wenn der Mower von der einen Grundstücks-Ecke in die andere fährt und zwischendurch vom einen Access-Point abreißt und sich mit einem anderen neuverbindet werden im Mähbetrieb auch völlig okay gehandelt, (habe kein Rooming, weiß auch nicht ob Robonect-Hx Wlan-Rooming unterstützen würde).

Die beschrieben "Probleme" passieren, so wie ich das "fühle", nur dann, wenn der Mower aus Gründen
(die ich in Ihrer Gesamtheit nicht überschaue) im Status"Schläft (17)" ist.

Ist der Mower z.B. tagsüber am Laden, kann ich den mit cmd=Stop in den Stopp-Zustand versetzen, sodass er nach dem Fertigladen eigentlich wieder losfahren sollte (wegen Zeitplan), aber wegen Stop das nicht tut. Wenn jetzt 100% geladen ist,
geht der Mower nie in den Zustand "Schläft", sondern immer in "Parkt(1)" und der Zustand ist "stopped": true.
Ich habe getestet: cmd=Stop aus den verschiedenen aktuellen Arbeits-Stati heraus: Laden, Parken, Mähen, Suchen.
Dann geht der Mower immer in Status 1 = Parkt und nimmt den Zustand "stopped": true" ein.
Der Status "Schläft" wird so nie erreicht und ich kann im Status "Parkt" immer alle Anfragen an Robonect,
sei es mit API oder im Webfrontend (/general, /battery, /hours, /error, /Health, /engines, /loops, /cam)
völlig okay, aber eben ohne Aufwachenprozedur immer machen, weil der Mower nie "geweckt" werden muss.
Irgendwie habe ich das Gefühl, dass mit dem "Aufwecken" irgendwas schief läuft, wenn es nötig ist, weil der Mower "Schläft".

Wann der Staus "Schläft" wirklich genau eingenommen wird, würde mich mal interessieren.
Ich werde mal weitetesten: Ich versuche mal den Status "Schläft" zu umgehen, um zu sehen, ob meine Theorie stimmt.
Weiterhin werde ich den Mower mal von der Gardena-Cloud entbinden, wozu habe ich denn Robonect ...

--------------------------------------

Ich betreibe den Mower bisher generell so:
Modus permanent auf "Auto",

In "/settings" ist eingestellt:
Display-Beleuchtung: Auto
Kollision mit Ladestation vermeiden: ja
Mähzeitbeschränkungen deaktivieren: ja
Frost Sensor: ja

In "/behavior" ist eingestellt:
Gartenform: komplex
Spiralschnitt: Aus

In "/wire" ist eingestellt:
Modus: Normaler Betrieb
Schleife überfahren: 35 cm

Timer: Montag bis Sonntag 08-20 Uhr arbeiten,

OpenWeatherMap unterbricht bei Bedarf mit "Wetterpause",
"Nicht Nachts mähen" ist aktiv

Weitere Einflussfaktoren, die meine "Hilfs-KI" bereitstellt oder ich von Hand entscheide, machen
zwischen 08 und 20 Uhr schon mal -> ...json?cmd=Stop
Sind diese "Einflussfaktoren" dann nicht mehr relevant, gibt meine "Steuerungsintelligez" dann wieder ein json?cmd=start und wenn dann der Zusatnd "stopped": true" nach "stopped": false gewechselt ist , "zur Sicherheit" immer noch
extra ein "json?cmd=mode&mode=Auto".

Grad getestet. Mäher wird einwandfrei geweckt. Evtl. habt ihr euer Request Timeout zu kurz? Bis der Response kommt, kann es schon mal 10 Sekunden dauern.

Ansonsten schicke mir doch bitte mal das Loguch.

Danke, guter Hinweis, baue ich mal dort mit ein, wo ich via CURL direkt die API benutze und somit
das Timeout-Verhalten beeinflussen kann.
Komisch nur, dass die Robonect-Web-Oberfläche dann auch das Problem hätte...

Hi,

gleiches Phänomen mit robonect 1.2 oder 1.1 und meinem alten R40li seit gestern.
Bisher wurde über die API minütlich der Ladestand der Batterie und der Status abgefragt sowie ein Ping abgesetzt.
Wettertimer ebenfalls aktiv. Akku rausnehmen hat nix gebracht, Status ist immer 255 Hardwarefehler.
Ansonsten genau die selben Effekte wie oben beschrieben.

Grüße
Ralf

Kleine Ergänzung: hab doch die Nerven verloren und alles auseinandergebaut. alle Stecker raus und wieder rein und wieder zusammengebaut. Und siehe da: läuft wieder wie wenn nie was gewesen wäre. Auffällig ist, dass im Fehlerspeicher seit dem ersten Auftreten des „Hardwareproblems“ extrem oft > 30x der Fehler „Batterieproblem“ zu sehen ist.

Kann ich bestätigen. Robonect wacht via http-Request-API nicht auf.
Habe einen neuen Gardena City smart 250 und eine nagelneue Roboenct-Platine. Der Automower und die Robonect-Platine sind jeweils mit der aktuellen Firmware bestückt.

Aufwecken geht bei mir lediglich über das Robonect-Webinterface.

Gruss,
tholle

tholle hat geschrieben:Kann ich bestätigen. Robonect wacht via http-Request-API nicht auf.
...

Robonect schläft nie. Es ist der Mäher der schläft und, von Robonect durch das Abrufen von Daten aus dem Mäher, geweckt wird.

Ah, ok. Danke fuer den Hinweis.
Kann man den sleep-mode des Maehers irgendwie unterbinden oder deaktivieren?

Gruss,
tholle