Modul für Netgear Arlo-Kameras

[mi.ke]

also ich hab mal ein bisschen geschnüffelt...

In der arlo.pm wird in Zeile 1131 folgendes aufgerufen:

Code Auswählen Erweitern

system "python3 contrib/49_Arlo.py $hash->{helper}{username} $hash->{helper}{password} $mailServer $hash->{helper}{mailUser} $hash->{helper}{mailPassword} > /tmp/arlo &";
Das wiederrum würde bedeuten, dass der Aufruf über die Python Version 3.7.3 erfolgt, die ja funktioneiren soll.

Daran scheint es dann ja doch nicht zu liegen, oder muss man irgendwo noch etwas einstellen, das die höhere Verion verwendet wird?

[maluk]

Wenn du Python-Version 3.7.3 installiert hast, hast du vermutlich Debian 10 (Buster) auf deinem Raspberry laufen. Ich habe das Modul auf einem Raspberry mit Debian 11 (Bullseye) laufen und habe daher die Python Version 3.9.2. Bei Urs scheint es mit 3.7.3 zu laufen, also muss die Ursache woanders liegen.

Ein großes Problem war bisher immer, dass alte 2FA-Mails, die noch im Postfach vorhanden waren, dazu führten, dass das Modul sich mit dem falschen 2FA-Code angemeldet hat, was natürlich zu einem Fehler führt. Ich hatte zwar schon immer eine Routine implementiert, die alte Mails vor dem Login löschen sollte, aber die hatte nicht funktioniert. Falls du die Meldung "Invalid OTP" bekommst, ist das bei dir das Problem.

Den Fehler in der Lösch-Routine habe ich heute behoben und eingecheckt. Ab morgen sollte eigentlich die Datei im FHEM-Update mitkommen, aber vermutlich müsst Ihr 49_Arlo.py manuell aktualisieren:

Code Auswählen Erweitern

cd /opt/fhem/contrib
sudo wget https://svn.fhem.de/fhem/trunk/fhem/contrib/49_Arlo.py
@Urs: ich hoffe, dass die Stabilität sich dadurch verbessert. Falls nicht, nochmal melden.

[mi.ke]

Hallo maluk,

ja, bei mir läuft noch Buster.

ich hab jetzt zusätzlich die arlo.py von gestern verwendet und es funktionierte heute morgen einmalig (es waren allerdings schon vorher definitiv keine alten Mails im Account).
Seitdem stabil ohne Probleme.

Eben, bei einem erneuten Versuch zu reconnecten --> wieder nur "login timeout".
Auch nach einem Reboot und einem anschließendem reconnect --> "login timeout"

Was könnt ich noch probieren?

cheers
mi.ke

PS.
Über das Update kommen die Dateien aus dem Contrib nicht automatisch mit.

[StephanFHEM]

vermutlich müsst Ihr 49_Arlo.py manuell aktualisieren:

Code Auswählen Erweitern

cd /opt/fhem/contrib
sudo wget https://svn.fhem.de/fhem/trunk/fhem/contrib/49_Arlo.py

Achtung: vorher sudo rm 49_Arlo.py und dann erst wget absetzen. Ansonsten läd er die Datei als 49_Arlo.py.1 herunter und nutzt weiter die alte

[maluk]

Eben, bei einem erneuten Versuch zu reconnecten --> wieder nur "login timeout".
Auch nach einem Reboot und einem anschließendem reconnect --> "login timeout"

Was könnt ich noch probieren?

Was steht denn im Logfile, wenn der Timeout auftritt? Kam eine E-Mail mit dem 2FA-Code von Arlo?

[StephanFHEM]

bei mir das gleiche Problem. Früher hatte ich immer wieder Abbrüche. Seit dem Update der Dateien geht jetzt garnichts mehr. Es gibt ein Login Timeout und soweit ich das beurteilen kann kommen auch kein 2FA Mails mehr

Im Log steht folgendes:

Code Auswählen Erweitern

2023.10.30 13:30:04 2: Arlo call was not successful: {"success":false,"data":{"error":"2401","message":"Access token is empty or unauthorized request","reason":"Empty token"}}
ich hab gerade versucht mit mich meinem Arlo-Account für FHEM bei Arlo einzuloggen. Wenn mir über die Website ein Code geschickt wird scheint der auch nicht anzukommen. Kann es sein, dass durch deine Änderung die 2FA Mail schneller gelöscht wird als der Code abgegriffen werden kann?

edit: ich hab übrigens Python 3.9.2 installiert / Python 2 ist nicht drauf

[choetzu]

Guten Abend,

ich habe neuerdings das Problem, dass ich 1 -2 mal im Tag eine 100% Last kriege und mir dann FHEM abschmiert. Wenn ich während der Last ein lsof mache (list of files) sehe ich, dass ich extrem viele der folgenden Einträge habe:

Code Auswählen Erweitern

perl    16716 fhem  137u  IPv4             933367      0t0    TCP raspi4master.home:51608->172.64.148.188:https (CLOSE_WAIT)
perl    16716 fhem  138u  IPv4             933387      0t0    TCP raspi4master.home:46612->104.18.39.68:https (CLOSE_WAIT)
perl    16716 fhem  139u  IPv4             933451      0t0    TCP raspi4master.home:39684->104.18.39.68:https (CLOSE_WAIT)
perl    16716 fhem  140u  IPv4             933474      0t0    TCP raspi4master.home:44210->104.18.39.68:https (CLOSE_WAIT)
perl    16716 fhem  141u  IPv4             935968      0t0    TCP raspi4master.home:46044->172.64.148.188:https (CLOSE_WAIT)
perl    16716 fhem  142u  IPv4             934434      0t0    TCP raspi4master.home:40510->104.18.39.68:https (CLOSE_WAIT)
perl    16716 fhem  143u  IPv4             934495      0t0    TCP raspi4master.home:56284->172.64.148.188:https (CLOSE_WAIT)
Und ich habe nun herausgefunden, dass die IP Nummer 104.18.39.68 zu myapi.arlo.com gehört. Kann es sein, dass im Sript irgendetwas in einer Schlaufe landet und dies verursacht?