Modul für Netgear Arlo-Kameras

[choetzu]

Der ssePollingInterval legt fest, wie häufig geprüft wird, ob Rückantworten von Arlo angekommen sind. Ein zu niedriger Wert kann die Prozessor-Last erhöhen, ein zu hoher Wert sorgt dafür, dass die Antworten evtl. zu träge verarbeitet werden. Wenn für dich z.B. eine schnelle Reaktion auf den Bewegungssensor wichtig ist, kannst du den ssePollingInterval auf 1.

Zum pingInterval: Arlo arbeitet mit Sessions, wie man sie häufig in Web-Anwendungen findet. Wenn man zu lange nichts tut, wird man automatisch abgemeldet. Daher sendet das Modul standardmäßig alle 90 Sekunden einen Request an den Server, damit die Session nicht beendet wird. Würde das Modul dies nicht tun, würden nach einer gewissen Zeit keine Events mehr vom Server kommen, also keine Bewegung mehr erkannt werden und keine Snapshots mehr übertragen werden. Der Ping ist in Wirklichkeit auch noch etwas mehr als ein reiner Ping: wenn man sich in der Arlo App oder über das Web bei Arlo anmeldet, verwirft Arlo die Session des FHEM-Moduls. Beim Ping wird das erkannt und das FHEM-Modul meldet sich wieder neu an.  Ein niedriger Wert als 90 sorgt dafür, dass dies schneller passiert, allerdings werden dann auch häufiger Requests an Arlo gesendet. Ich halte 90 Sekunden für einen guten Wert, der mir in der Praxis auch keinerlei Probleme bereitet.

jetzt ist es sonnenklar... ganz herzlichen Dank. Ich habe mal den ssInterval auf 0.5 gesetzt. Mal schauen, wie das auf die Last auswirkt. Danke nochmals.

[mi.ke]

Anbei nochmal eine neue Version, die den Status offline erkennt. Wenn das Gerät wieder online geht, sollte er den Status automatisch wieder aktualisieren. Ob es funktioniert, kann ich leider nicht validieren. Versuche es mal und gebe hier Rückmeldung.

Der Statuswechsel nach Online scheint nun zu funktionieren.

Aber wenn er Offline geht, wechselt das Modul auf nicht auf Offline, sondern nach disarmed (oder bleibt).

Im LOG steht:

Code Auswählen Erweitern

2019.06.30 16:44:36 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:44:51 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:45:11 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:46:05 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:47:35 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:49:06 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:50:36 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:52:05 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:53:36 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:55:06 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}
2019.06.30 16:56:36 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}


Cheers
mi.ke

[mi.ke]

@maluk

Habe heute morgen den Router Nighthawk nochmal mit Arlo-Ünterstützung betrieben und getestet.

Siehe da, wenn man lange genug wartet, schaltet das Modul doch auf "offline"!

Es gibt zwar ein Delay von mehreren Minuten (die Webanwendung und die APP reagieren sofort), aber damit kann man leben, da es sich ja eh um ein Mobiles Gerät handelt.

Ich habs jetzt in den Livebetrieb gehoben und hab ein Auge drauf.

Vielen Dank und Grüße

mi.ke

[m0urs]

@maluk:

Irgendwie habe ich leider immer noch Probleme beim Setzen eines Modes für eine Arlo-Bridge. Für mich stellt sich das Problem wie folgt dar:

1. Arm/Disarm einer Bridge funktionieren immer problemlos
2. "set BRIDGE mode xyz" funktioniert manchmal, aber oftmals nicht
3. Wenn es nicht funktioniert, wird bei Verbose=5 des Cloud-Devices auch keinerlei Logmeldung geschrieben. So als würde der Befehl gar nicht erst versucht auszuführen.
4. Wann es funktioniert kann ich nich tgenau sagen. Erst dachte ich, immer wenn ich vorher ein "set CLOUDDEVICE readModes" mache, aber das scheint nicht die Lösung zu sein.

Falls Du etwas Zeit erübrigen kannst, wäre ich Dir sehr dankbar, wenn Du da noch eine Idee hättest, wie man den Fehler eingrenzen kann (wie gesagt, ohne Logmeldung etwas schwer).

Vielen Dank!

P.S. Das setzen des Modes für ein Kamera-Device scheint mir immer zuverlässig zu funktionieren. Es betrifft wohl nur die Bridge.

Hallo maluk,

das Thema beschäftigt mich noch immer

Mittlerweile ist mir aber aufgefallen, woran das Problem liegen könnte. Mein Setup ist ja eine Basis-Station sowie zwei Bridges. Das Schalten und auslesen der Modes für Basis-Station sowie der 1. Bridge scheint soweit immer korrekt zu funktionieren. Bei der 2. Bridge funktionieren ARM und DISARM, aber Custom Modes nicht.

Der Grund dafür scheint mir zu sein, dass beim Lesen und Schreiben von Custom Modes die Werte der Basis-Station genommen werden und nicht die Werte der 2. Bridge. ARM und DISARM funktionieren daher, da dies ja mode0 und mode1 bei allen Devices ist. Wenn ein Custom Mode auf der Bridge eingestellt ist, dann wird versucht, die Bezeichnung des Modes aus der Basis-Station zu lesen (also wenn dort z.B. ein Custom Mode "mode2" definiert ist, wird in der 2. Bridge die Bezeichnung des "mode2" der Basis-Station dargestellt. Beim Setzen des Mode dann analog ...

Hast Du eine Idee, wie man das beheben könnte? Wie kann ich Dich dabei unterstützen?

Nachtrag: Wie schon vor einiger Zeit mal vermutet: Es sieht so aus, als würde direkt nach einem Reconnect mit anschliessendem readModes und updateReadings erst mal alles, auch mit der 2. Bridge, funktionieren. Irgendwann scheint es dann aber wieder kaputt zu gehen nach einiger Zeit. Ich baue mal testweise einen regelmäßigen Reconnect ein ...

[choetzu]

kurze Frage, funktioniert bei Euch "set device siren on" ? Bei mir passiert grad gar nix..

[mi.ke]

kurze Frage, funktioniert bei Euch "set device siren on" ? Bei mir passiert grad gar nix..

ich kann mit eimen sch(m)erzhaften "JA" Deine Frage beantworten !!!
Auu, is des laut.

Cheers
mi.ke

[choetzu]

ich kann mit eimen sch(m)erzhaften "JA" Deine Frage beantworten !!!
Auu, is des laut.

hehe.. Hast du auch Arlo Ultra? Ich blaube da wird der Alarm über die Kameras gemacht. Via Basisstation habe ich nix gefunden. Im FHEM schon gar nicht.. Komisch.. Maluk?

[mi.ke]

Hast du auch Arlo Ultra?

Nein, sorry.
Ich hab an Kameras nur die "Arlo" und "Arlo Pro".
Und zwei Basisstationen mit Sirene. Dort werden auch die Sirenen getriggert.

[maluk]

hehe.. Hast du auch Arlo Ultra? Ich blaube da wird der Alarm über die Kameras gemacht. Via Basisstation habe ich nix gefunden. Im FHEM schon gar nicht.. Komisch.. Maluk?

Damit ich das Modul entsprechend erweitern kann, brauche ich ein paar Daten: bitte gehe über die Weboberfläche (https://arlo.netgear.com/) auf die Arlo Ultra, aktiviere die Entwickler-Tools (Tab Netzwerk) und aktiviere die Sirene. Anschließend die Siren deaktivieren. Schicke mir die Requests und Responses, die bei den Aktionen ausgelöst wurden, per privater Mitteilung zu.

[FrankieSOC]

Tach Zusammen,

habe in der letzte Woche zum testen Arlo Smart kostenpflichtig aktiviert, seit dem schweigen meine Kameras in fhem.
Gibt es einen Tipp oder klappt es einfach nicht zusammen?

Viele Grüße
Frank

[maluk]

Hi Frank,

ich kann leider nichts dazu sagen. Gibt es irgendwelche Hinweise im FHEM-Log? Falls nicht, bitte mal am Arlo Cloud Device das Attribut verbose auf 4 setzen. Falls dann immer noch nichts Aussagefähiges im Log steht, mal mit verbose 5 versuchen (und natürlich nicht vergessen, am Ende wieder auf verbose 3 zu wechseln ).

Gruß
maluk

[FrankieSOC]

Ich weiß nicht wo der Wurm drin war.
Habe die Kameras gelöscht und über Autocreate neu angelegt, trotzdem hat es nicht geklappt.

Im Log stand nur "Arlo Ping: Arlo_Cloud ACCOUNT 90"

Dann hatte ich auch das Cloud Device mitgelöscht und erneut angelegt.
Jetzt klappt es wieder.

Nochmals danke für das schöne Modul!

[durchstarter]

Hallo zusammen,

heute habe ich eine Mail von Arlo erhalten, mit dem Hinweis, das demnächst eine neue App verwendet werden muss, um die Arlos zu steuern - ausserdem wird wohl Zweifaktor-Authentifizierung aktiviert. Weiss schon jemand, ob das Auswirkungen auf das FHEM Modul haben wird?
Ich habe bisher einen eigenen User dafür angelegt, und hoffe das dieser sich nicht immer per 2FA anmelden muss...

LG
Thomas

[maluk]

Hallo Thomas,

Danke für den Hinweis. Ich habe jetzt mal ganz kurz zu dem Thema recherchiert: Arlo ist wohl von Netgear in eine eigene Firma ausgegründet worden. Die bisherige App lief noch unter dem Netgear-Label, bei der neuen App ist der Herausgeber Arlo Technologies Inc. Ich nutze für das Modul die REST-Services, die auch von der Webseite https://my.arlo.com/ verwendet werden. Wenn sich hier Änderungen ergeben, werde ich das Modul entsprechend anpassen.

Gruß
maluk

[choetzu]

Hallo

Bei mir erscheint seit neustem das Phänomen dass meine Cams auf den Status ,,initialized" switchen. Ich muss dann mit dem Cloud-device einen reconnect machen und manuell alle Cams dann einschalten. Dann gehts wieder eine zeitlang.
Passiert das bei Euch auch?

Lg c