Neues Modul: BOTVAC (für Neato BotVac Connected)

[schnuddel]

Hallo VuffiRaa,

ich habe mal beide Neatos deaktiviert und ein paar Tage gewartet. Seitdem kein einziger Freeze.

Zu der Regelmäßigkeit: Ja, die ist erkennbar, aber nicht durchgängig. Zum Beispiel: 20:27, 20:47, 20:57, 21:57, 22:07. Oder auch: 0:04, 0:24, 0:34, 0:44, 2:14.
Freezes habe ich bei beiden festgestellt, auch wenn einer von beiden deaktiviert ist.

Grüße
schnuddel

[schnuddel]

Kann ich mit weiteren logs helfen, das Problem zu analysieren?

[vuffiraa]

Ich habe den Freezemon-Thread mal gelesen. Nachdem was dort steht, wollte ich mal etwas mit dem Aufbau der Verbindungen im Modul spielen. Während eines Intervals kommuniziert das Modul schon öfter mit den Neato-Servern.

Falls das gelingt, würde ich das Modul zum Testen bereitstellen. Bei mir halten sich die Freezes in Grenzen und wenn dann auch nicht gleich 180 Sekunden. Leider kann ich dadurch aber auch nicht gut selber testen.

[Mort]

Gibt's dazu etwas neues? Ich habe seit einiger Zeit dasselbe Problem. Dachte erst, es läge am Umzug auf einen neueren RasPi, aber das war wohl eher Zufall (außer der Pi 4B bzw. das neuere Raspian hätte irgendwelche Probleme in dem Bereich, aber sonst sind mir keine aufgefallen)...
Im freezemon-Log bleibt der Request zu nucleo.neatocloud.com:4443 für 180 Sekunden hängen, danach kommt "SSL want's a read first".
Klingt für mich danach, als würde der Server erst dann reagieren, wenn ein Token o.ä. nicht mehr gültig ist.
Bei mir ist das relativ regelmäßig ca. alle 4,5 Minuten (allerdings nicht sekundengenau), öfter mal auch mit einem "Aussetzer", also dem nächsten Hänger erst ca. 9 Minuten später. Ab und an läuft's auch mal für längere Zeit problemlos.
FHEM friert für die Zeit komplett ein. Selbst ein shutdown/restart des Service' bleibt einige Sekunden hängen, hat aber wohl 'nen kürzeren Timeout.

[vuffiraa]

Hallo Mort,

wenn die Aussetzer bei dir so oft auftreten, wäre ich mal an einem Log mit verbose = 5 im Gerät interessiert.
Wie viele Neatos hast du in FHEM eingebunden? Wie hast du das Intervall im Gerät konfiguriert?

Meine aktuelle Testversion des Moduls versucht alle Intervallupdates über eine Verbindung abzuwickeln. Damit sollte die SSL Aushandlung nur noch ein mal pro Intervall stattfinden und hoffentlich so das Problem mit dem Freeze beheben oder zumindest stark verringern.

Ich die Entwicklung des Moduls in die FHEM-Gruppe auf Github umgezogen (https://github.com/fhem/BOTVAC/tree/dev). Jede stabile und getestete Version landet dann aber auch natürlich im FHEM SVN und wird mit dem normalen Update verteilt.

Ich würde mich über ein paar Tester freuen. Installation des Modul per

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/fhem/BOTVAC/dev/controls_BOTVAC.txt
Beim nächsten "normalen" Update der FHEM-Installation wird das Modul dann wieder mit der Version aus dem SVN überschrieben.

Gruß VuffiRaa

[rabehd]

Wir haben seit knapp einer Woche einen neato. Der wurde auch gleich mit dem Modul eingebunden.
Das war noch vor dem Firmwareupdate des neato. Danach war der Zugriff weg. Löschen und ein neues Define haben Abhilfe geschaffen.

Das Einfrieren von 179.xxx Sekunden habe ich auch.
Durch das Mitlesen hier war auch mein Verdacht auf den neato gefallen. Seit gestern Morgen ist das Device disabled und es gibt seit dem auch kein Einfrieren mit einer solch großen Dauer mehr.
Ich werde versuchen mich auch am Testen zu beteiligen.

[Mort]

wenn die Aussetzer bei dir so oft auftreten, wäre ich mal an einem Log mit verbose = 5 im Gerät interessiert.

Kann ich heute Abend nachliefern. Zumindest im freezemon-Log fällt eigentlich nicht viel auf. HttpUtils url=..., IP: nucleo.neatocloud.com -> 54.90.247.80, ---- log skips <~180.00> secs., und dann "Can't connect(2) ... SSL want's a read first".

Wie viele Neatos hast du in FHEM eingebunden?

Nur einen.

Wie hast du das Intervall im Gerät konfiguriert?

Gar nicht. Angezeigt wird 85, das dürfte die Vorgabe sein. 3 Minuten Freeze + 85 Sekunden haut dann auch relativ gut hin. Allerdings läuft's dann zwischendurch wohl doch öfter hin als befürchtet. (Den Abstand hatte ich noch ohne freezemon-Log beobachtet, also nur die Hänger im FHEM-Log.)

Ich würde mich über ein paar Tester freuen. Installation des Modul per

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/fhem/BOTVAC/dev/controls_BOTVAC.txt
Beim nächsten "normalen" Update der FHEM-Installation wird das Modul dann wieder mit der Version aus dem SVN überschrieben.

Da muss wohl noch 'ne Kleinigkeit angepasst werden :

Code Auswählen Erweitern

Got 89248 bytes for FHEM/70_BOTVAC.pm, expected 88148

[MadMax-FHEM]

Eventuell helfen die "Analysen" bzgl. echodevice-Modul bzgl. Freezes:

https://forum.fhem.de/index.php/topic,107465.msg1015237.html#msg1015237

https://forum.fhem.de/index.php/topic,83909.msg1013242.html#msg1013242

Gruß, Joachim

[Mort]

Noch ein Hinweis: Nach einer Antwort in diesem Thread habe ich mal den dnsServer gesetzt und zumindest bisher keine Hänger mehr. Am DNS-Request selbst kann's eigentlich nicht liegen, die IP erschien im Log immer gleich nach dem HttpUtils url=.... Aber wenn es nicht nur Zufall ist (ab und an lief's ja auch bisher zwischenzeitlich problemlos) scheint etwas in der Folge anders zu sein.

[MadMax-FHEM]

Noch ein Hinweis: Nach einer Antwort in diesem Thread habe ich mal den dnsServer gesetzt und zumindest bisher keine Hänger mehr. Am DNS-Request selbst kann's eigentlich nicht liegen, die IP erschien im Log immer gleich nach dem HttpUtils url=.... Aber wenn es nicht nur Zufall ist (ab und an lief's ja auch bisher zwischenzeitlich problemlos) scheint etwas in der Folge anders zu sein.

Das wurde in den verlinkten Threads ebenfalls erläutert...
...falls es interessiert (was es macht etc.)...

Gruß, Joachim

[Mort]

Das wurde in den verlinkten Threads ebenfalls erläutert...
...falls es interessiert (was es macht etc.)...

Wenn ich das recht verstehe, gibt's da zwei Probleme:
- Freezemon sorgt selbst für Hänger bei http(s)-Requests (oder nur Fehlalarme?), Workaround per fm_catchHttp (scheint beim offiziellen Stand aber noch nicht enthalten zu sein).
- DNS-Requests können bei der Variante ohne dnsServer blockieren.

So richtig erklärt sich mir damit aber nicht, was da los war:
- Wenn freezemon jetzt an den Hängern schuld wäre, hätte es vorher auch keine geben sollen. Ich habe das freezemon-Device ja nur wegen denen definiert.
- Wenn der DNS-Request ohne dnsServer geklemmt hätte, warum wurde die IP dann im freezemon-Log sofort nach dem url=... ausgegeben? Und sollte ein freezemon-Bug nicht auch damit weiter existieren?

Wilde Vermutung: Könnte es sein, dass die Systemlösung ohne dnsServer die Requests an verschiedene IPs schickt und die Neato-Server bei ungültigen Authentifizierungen (bzw. halt vom falschen Rechner) die Antwort 180 Sekunden blockieren um Brute-Force-Attacken zu vermeiden?

[MadMax-FHEM]

Ich denke (bzw. habe ich das nicht so gelesen) nicht, dass FreezeMon selbst freezes "erzeugt"...

Im 2ten Link wird etwas ausführlicher analysiert...
...es gibt auch noch einen Thread bzgl. https etc.

Ich glaube im Rahmen von Telegram...

In das echodevice Modul wurde wohl ("prototypisch" oder auch schon in die "normale" Variante) etwas eingebaut bzgl. DNS-cache...
...danach war (etwas mehr Ruhe) bzgl. Freezes...

Wollte nur einen evtl. weiteren Hinweis bzgl. Freezes bei Abfragen von "externen Quellen" geben

Gruß, Joachim

[Mort]

Ich denke (bzw. habe ich das nicht so gelesen) nicht, dass FreezeMon selbst freezes "erzeugt"...

So ganz schlau wurde ich daraus eben auch nicht. Irgendwie kommt es wohl zu Konflikten durch Multithreading und Callbacks (wo nicht...  ), was das genauer zur Folge hat habe ich aber nicht rauslesen können.

In das echodevice Modul wurde wohl ("prototypisch" oder auch schon in die "normale" Variante) etwas eingebaut bzgl. DNS-cache...

Das würde dann auch für meine Theorie bzgl. verschiedener IPs für Follow-Up-Requests sprechen. Wobei aber laut allem was ich gelesen habe, der Request doch eigentlich non-blocking sein sollte. Aber dann war da noch irgendwas mit Ausnahmen für https...
Wenn es das wäre (da mir die Interna fehlen, kann ich natürlich meilenweit daneben liegen) wäre es dann aber vielleicht besser, einen DNS-Cache in HttpUtils zu implementieren (oder den der dnsServer-Variante auch bei System-Calls zu verwenden?). Es scheinen ja auch andere Module betroffen zu sein. Wenn ich richtig liege, alle, die https verwenden und bei denen das Load Balancing über den DNS läuft. Bei manchen gibt es dann vermutlich auch "nur" Verbindungsprobleme ohne Freezes.
Die Nacht lief übrigens völlig ohne Freezes durch, das dnsServer-Attribut hat also definitiv eine Wirkung.
(Wäre natürlich noch interessant zu wissen, warum da manche Anwender mehr und andere weniger betroffen sind. Evtl. (fehlendes) Caching bei den DNS-Servern des jeweiligen Providers?)

Wollte nur einen evtl. weiteren Hinweis bzgl. Freezes bei Abfragen von "externen Quellen" geben

Könnte ja geholfen haben. Ich bin hier ja auch nur "betroffener Anwender" und etwas neugierig, aber kein Entwickler. Mit Perl hab ich mich zuletzt näher rumgeschlagen als Backends grob geschätzt zu 80% Perl, zu 18% kompilierter Code (üblicherweise C(++)) und zu 2% Zeug für Masochisten (Shell-Scripts, awk, ...) waren... (Gut, ein paar Zeilen in DOIFs u.ä. habe ich auch...)

[rabehd]

Das Attribut dnsServer in global ist auf meine Fritzbox gesetzt.
Trotzdem macht das Device des neato Schwierigkeiten und fiert alles für 179.xxx Sekunden ein.
Wenn das Device enable ist, dann sehe ich sehr oft Verbindungsabbrüche zu meinen ESPLedControllern. Diese sind per WLAN angebunden und scheinbar gibt es nur mit denen Probleme, die nicht direkt an der Fritzbox hängen.
Setze ich neato auf disable, dann ist der Spuk weg.

[MadMax-FHEM]

So ganz schlau wurde ich daraus eben auch nicht. Irgendwie kommt es wohl zu Konflikten durch Multithreading und Callbacks (wo nicht...  ), was das genauer zur Folge hat habe ich aber nicht rauslesen können.
Das würde dann auch für meine Theorie bzgl. verschiedener IPs für Follow-Up-Requests sprechen. Wobei aber laut allem was ich gelesen habe, der Request doch eigentlich non-blocking sein sollte. Aber dann war da noch irgendwas mit Ausnahmen für https...
Wenn es das wäre (da mir die Interna fehlen, kann ich natürlich meilenweit daneben liegen) wäre es dann aber vielleicht besser, einen DNS-Cache in HttpUtils zu implementieren (oder den der dnsServer-Variante auch bei System-Calls zu verwenden?). Es scheinen ja auch andere Module betroffen zu sein. Wenn ich richtig liege, alle, die https verwenden und bei denen das Load Balancing über den DNS läuft. Bei manchen gibt es dann vermutlich auch "nur" Verbindungsprobleme ohne Freezes.
Die Nacht lief übrigens völlig ohne Freezes durch, das dnsServer-Attribut hat also definitiv eine Wirkung.
(Wäre natürlich noch interessant zu wissen, warum da manche Anwender mehr und andere weniger betroffen sind. Evtl. (fehlendes) Caching bei den DNS-Servern des jeweiligen Providers?)
Könnte ja geholfen haben. Ich bin hier ja auch nur "betroffener Anwender" und etwas neugierig, aber kein Entwickler. Mit Perl hab ich mich zuletzt näher rumgeschlagen als Backends grob geschätzt zu 80% Perl, zu 18% kompilierter Code (üblicherweise C(++)) und zu 2% Zeug für Masochisten (Shell-Scripts, awk, ...) waren... (Gut, ein paar Zeilen in DOIFs u.ä. habe ich auch...)

So ein DNS-cache könnte schon Sinn machen in HTTPUtils...

Aber das müssen wohl die "Kern-Entwickler" tun und die waren ja in dem Thread beteiligt...

Bei mir war ein Unterschied (Testsystem mit Freezes / Hauptsystem ohne Freezes): LAN (Hauptsystem) - WLAN (Testsystem)

Ob das entscheidend war/ist: keine Ahnung.

Nachdem ja dann etwas in echodevice eingebaut wurde war/ist ja zumindest dort Ruhe...

Evtl. halt auch die Entwickler dieses Moduls mal "dort" nachschauen und wenn es generell hilft, dann evtl. noch mal auf die "Kern-Entwickler" einwirken...

Gruß, Joachim