FHEM Forum

Arlo Sicherheitskameras von NETGEAR werden über eine Basisstation an die Arlo Cloud angebunden. Diese kann über eine REST-API angesprochen werden und liefert Ereignisse (wie z.B. erkannte Bewegungen oder sonstige Statusänderungen) über Server-Sent Events (SSE) zurück.

Dieses Modul ersetzt mein bisherigen Arlo-Modul, das die Verbindung zur Arlo Cloud über ein Python-Modul hergestellt hat (siehe https://forum.fhem.de/index.php/topic,87602.0.html). Die neue Version benötigt keine externe Installation mehr sondern funktioniert direkt in FHEM. Das Modul wird jetzt auch automatisch mit FHEM installiert und aktualisiert. Eine ausführliche Beschreibung findet Ihr auch im Wiki (https://wiki.fhem.de/wiki/Arlo).

Nun muss die Verbindung zur Arlo Cloud hergestellt werden. Dies erfolgt in FHEM mit folgendem Befehl:

define Arlo_Cloud Arlo ACCOUNT hans.mustermann@xyz.de meinPasswort

hans.mustermann@xyz.de durch die E-Mail-Adresse ersetzen, mit der man bei Arlo registriert ist, meinPasswort durch das Passwort dort.

Nach der erfolgreichen Definition des Account kann auf dem neu erzeugten Device set Arlo_Cloud autocreate aufgerufen werden. Dies legt die Basistation(en) und Kameras an, die zu dem Arlo Account zugeordnet sind. Die neuen Devices befinden sich initial im Raum Arlo.

Aufgrund der SSE-Schnittstelle ist es notwendig, dass dauerhaft im Hintergrund eine Verbindung zum Arlo-Server gehalten wird. Falls dies nicht gewünscht ist, da Arlo z.B. vorübergehend nicht genutzt wird, kann der Hintergrund-Job verhindert werden, indem das Attribut "disable" des Arlo_Cloud-Device auf 1 gesetzt wird. Standardmäßig wird alle 2 Sekunden geprüft, ob neue Daten in der SSE-Schnittstelle angekommen sind. Über das Attribut ssePollingInterval am Account-Device kann dieser Wert verändert werden.

Folgende Funktionen stehen für die Devices zur Verfügung:

Account:

• autocreate => Liest alle dem Arlo-Account zugeordneten Geräte und legt dafür FHEM-Devices an, falls es diese nicht schon gibt.
• reconnect => Neuaufbau der Verbindung zum Arlo-Server. Zunächst loggt sich FHEM neu bei Arlo ein, danach wird die SSE-Verbindung aufgebaut. Wird nur benötigt, falls unerwartete Verbindungsabbrüche auftreten.
• updateReadings => Aktuelle Daten aller Basisstationen und Kameras aus der Cloud abrufen. Dies passiert einmal stündlich automatisch, falls dies nicht durch Setzen des Attributes disabled=1 am Cloud-Device unterbunden wird. Den Abruf-Intervall kann man durch Setzen des Attributs updateInterval anpassen (Angabe von Sekunden, also z.B. 600 für Abruf alle 10 Minuten oder 7200 für Abruf alle 2 Stunden).

Basisstation:

• arm => Aktivieren der Bewegungserkennung
• disarm => Deaktivieren der Bewegungserkennung
• subscribe => Basisstation für die SSE-Schnittstelle registrieren. Muss normalerweise nie manuell aufgerufen werden, da dies beim Login automatisch passiert.
• unsubscribe => Registrierung einer Basisstation für die SSE-Schnittstelle rückgängig machen.

Kamera:

• on => Kamera einschalten
• off => Kamera ausschalten
• snapshot => ein Standbild aufnehmen. Dieses kann über die URL aus dem Reading snapshotUrl aufgerufen werden. Damit der Befehl funktioniert, muss die Kamera den Status on haben.
• startRecording => Aufnahme starten. Damit der Befehl funktioniert, muss die Kamera den Status on haben.
• stopRecording => Aufnahme stoppen. Die Aufnahme kann über lastVideoUrl abgerufen werden, das Standbild dazu unter lastVideoThumbnailUrl.

Noch einige Hinweise zur Funktionsweise:
Die SSE-Schnittstelle läuft ständig im Hintergrund und bekommt Änderungen vom Arlo Cloudserver mit. Wenn z.B. Bewegung erkannt wird, ändert sich der activityState der betroffenen Kamera auf alertStreamActive. Wenn man in FHEM Events bei Bewegung auslösen möchte, muss man dieses Reading überwachen. Standardmäßig werden die SSE-Antworten alle 2 Sekunden abgefragt. Dieses Intervall kann durch Setzen des Attributs ssePollingInterval am Cloud-Device geändert werden (z.B. 0.5 für Abfrage jede halbe Sekunde).

Außerdem wird im Hintergrund regelmäßig ein Ping an den Server geschickt, damit die Session nicht ausläuft. Standardmäßig passiert dies alle 90 Sekunden. Dieses Intervall kann durch Setzen des Attributs pingInterval am Cloud-Device geändert werden (z.B. 60 = alle 60 Sekunden).

Normalerweise bekommt FHEM alle Änderungen über die SSE-Schnittstelle mit. Trotzdem ist ein Auto-Polling implementiert, das jede Stunde den Status aller Basisstationen und Kameras abfrägt. Um das Poll-Intervall anzupassen, muss am Cloud-Device in FHEM das Attribut updateInterval gesetzt werden (in Sekunden, also 1 Stunde = 3600).

Historie:
07.03.2019: Fehler-Handling bei Netzwerk-Problemen weiter optimiert, Modul wird jetzt automatisch mit FHEM installiert und aktualisiert
02.01.2019: Unterstützung für BabyCam, Status disabled für Account-Device
27.12.2018: neues Attribut "motionDetected" für Kameras und Lights, Readings für Lights, neue Funktion Get Recordings für Kameras
23.12.2018: Unterstützung für ArloQ, Bug bzgl. regelmäßigem updateReadings behoben
18.12.2018: Verbessertes Fehler-Handling bei Netzwerk-Problemen, Logging angepasst
14.12.2018: Betrieb von mehrere Basestations ermöglicht, Umstellung Intervalle (alle Intervalle an Could-Device + Umbenennung), updateReadings in Cloud-Device verschoben
10.12.2018: Umstellung setMode auf neue API, automatischer Reconnect bei abgelaufener Session.
09.12.2018: Erkennung von Arlo Bridges für Security Lights, Umstellung des Lesen der Modes auf neue Arlo API, Kopieren der Bilder und Videos vom Server optimiert (weniger Hauptspeicherverbrauch)
06.12.2018: Folgende Bugs behoben: Absturz bei Autocreate, Kamera ein-/ausschalten, Brightness bei Kamera setzen
05.12.2018: ssePollingInterval eingeführt, Bug bei mehrzeiligen Responses behoben, FHEM-Stop bei fehlerhaftem JSON verhindern
03.12.2018: Unterstützung mehrere Basisstationen optimiert, Bug bei benutzerdefinierten Modi behoben

Klasse, ich lass es morgen mal auf einem Testsystem laufen.

Vielen Dank und Grüße

mi.ke

so, erster schneller Testlauf

Sieht schon gut aus. Die Devices 2 Basestationen und die Kameras werden erkannt. Umschalten zu den Standard Modis funktioniert. Keine "Spam" Einträge im Log. Bisher keine "Heartbeat" Ausfälle.

Was noch nicht zu funktionieren scheint . . .
- die "Mode" Umschaltung zu eigenerstellten "Benutzerdefinierter Modus" ist nicht möglich
- Kein STATE bei einer Basis, keine Readings bei den dazu gehörenden Kameras.
   Bei mir (2 Basestation) werden beide erkannt, aber eine bekommt keine Readings.
- downloadDir und downloadLInk werden noch nicht übernommen

Test später weiter . . .

Vielen Dank für das Modul und das umprogrammieren. Bin gepannt was die anderen sagen.

PS.
wenn ich eine Basis Station (fhem Device) lösche ist das Verhalten anders.
Es werden in der Basis Readings erzeugt und auch die Umschaltung zu "Benutzerdefinierten Modis" funktioniert. Es scheint immer nur "die Letzte" bedient zu werden.
Über die Software (arlo.netgear.com) getätigte Anderungen werden nicht im Modul aktuallisiert. Auch nicht nach einen manuellen "updateReadings".

Mit den benutzerdefinierten Modus hast du genau den wunden Punkt erwischt ;). Das habe ich bisher nur quick&dirty implementiert, es steht noch auf meiner Todo-Liste. Probleme macht die aktuelle Implementierung in der Tat mit mehreren Basisstationen, da die Modi in einer globalen Variable gespeichert sind statt in der Basisstation und dadurch die Werte der einen Basisstation durch die andere überschrieben werden.

Wegen der 2 Basisstationen muss ich vermutlich etwas umprogrammieren. Ich hatte jetzt erstmal eine Variante gebaut, bei der ich mir nicht ganz sicher war, ob sie funktionieren wird. Nach deiner Schilderung muss wohl doch der etwas kompliziertere Weg umgesetzt werden. Das werde ich auf jeden Fall nachholen und ich bin guter Dinge, es mit der neuen Version zum Laufen zu bekommen. Leider habe ich nur eine Basisstation und kann daher nicht testen.

downloadDir und downloadLink müssen am Arlo_Cloud Device gesetzt werden und funktionieren bei mir dort auch. Was genau ist das Problem?

Herzlichen Dank, sehr cool soweit..

Was mir aufgefallen ist:

- activityState geht noch nicht zuverlässig. Z.t. Geht es nicht zurück in den idle und bleibt auf alertStreamAlert... kann es sein, dass zudem diese Events später ankommen als beim Phyton. Bei mir gehen bei Bewegung Lapen an. früher ging das flott, jetzt ca 1-2 Sekunden später

Downloadlinks gehen bei mir.

Benutzerdefinierte Modes ebenso.

Ich teste weiter, resp. Überwache..

Wie kann man die Logs interpretieren?

2018.12.03 22:29:06 3: EnOcean set Steingarten_D_FUD61 off
2018.12.03 22:29:28 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
[Mon Dec  3 22:30:45 2018] fhem.pl: Use of uninitialized value $attrVal in concatenation (.) or string at ./FHEM/49_Arlo.pm line 100.
2018.12.03 22:30:57 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
[Mon Dec  3 22:31:01 2018] fhem.pl: Use of uninitialized value $attrVal in concatenation (.) or string at ./FHEM/49_Arlo.pm line 100.
[Mon Dec  3 22:31:12 2018] fhem.pl: Use of uninitialized value $attrVal in concatenation (.) or string at ./FHEM/49_Arlo.pm line 100.
2018.12.03 22:32:27 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:33:58 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:35:29 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:36:57 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:38:28 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:39:58 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:41:28 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:42:59 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:44:27 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:45:58 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:46:42 3: Process Arlo event modes for 48E3577FA00FD
2018.12.03 22:46:46 3: Invalid Arlo event response: 1ec8
2018.12.03 22:46:46 3: Process Arlo event cameras for 48E3577FA00FD
2018.12.03 22:47:29 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:48:59 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:50:27 4: Notify 48E3577FA00FD, action: set subscriptions/316-3892157_web
2018.12.03 22:50:27 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:51:57 4: Notify 48E3577FA00FD, action: set subscriptions/316-3892157_web
2018.12.03 22:51:58 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:53:27 4: Notify 48E3577FA00FD, action: set subscriptions/316-3892157_web
2018.12.03 22:53:28 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:54:57 4: Notify 48E3577FA00FD, action: set subscriptions/316-3892157_web
2018.12.03 22:54:59 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD
2018.12.03 22:55:01 3: (Re)starting Arlo event listener.
2018.12.03 22:55:32 4: Notify 48E3577FA00FD, action: get modes
2018.12.03 22:55:33 3: Process Arlo event modes for 48E3577FA00FD
2018.12.03 22:55:36 4: Notify 48E3577FA00FD, action: get cameras
2018.12.03 22:55:39 3: Invalid Arlo event response: 1ec8
2018.12.03 22:55:39 3: Process Arlo event cameras for 48E3577FA00FD
2018.12.03 22:56:27 4: Notify 48E3577FA00FD, action: set subscriptions/316-3892157_web
2018.12.03 22:56:28 3: Process Arlo event subscriptions/316-3892157_web for 48E3577FA00FD

@mi.ke: ich habe eine neue Version hochgeladen. Versuche mal, ob du jetzt beide Basisstationen richtig funktionieren. Auch das Setzen des benutzerdefinierten Modus sollte jetzt klappen.

@choetzu: bei dem activityState kann es sein, dass es noch Probleme gibt, falls du nicht downloadDir und downloadLink nutzt. Die Verzögerung kann ich nachvollziehen, weil die Events nur alle 2 Sekunden geprüft werden. Ich werde in der nächsten Version einen Parameter einbauen, mit dem du das auf 1 Sekunde verkürzen kannst. Nachteil ist eine etwas höhere CPU-Belastung, daher würde ich die gewünschte Reaktionszeit jedem selbst überlassen. Die Logs sehen gut aus. Den Fehler in Zeile 100 behebe ich noch, das ist aber nur Kosmetik. Wichtig ist, dass spätestens alle 90 Sekunden "Process Arlo event" kommt.

Ich wäre dabei, sobald die Custom Modes implementiert sind. Die brauche ich leider unbedingt ... Der Support für die Security Lights wäre dann aber erst Prio 2 ;-)

Die Custom Modes haben mit einer Basisstation schon die ganze Zeit funktioniert, seit gestern Abend sind sie sauber implementiert.

Zitat von: maluk am 03 Dezember 2018, 23:24:29
@choetzu: bei dem activityState kann es sein, dass es noch Probleme gibt, falls du nicht downloadDir und downloadLink nutzt. Die Verzögerung kann ich nachvollziehen, weil die Events nur alle 2 Sekunden geprüft werden. Ich werde in der nächsten Version einen Parameter einbauen, mit dem du das auf 1 Sekunde verkürzen kannst. Nachteil ist eine etwas höhere CPU-Belastung, daher würde ich die gewünschte Reaktionszeit jedem selbst überlassen. Die Logs sehen gut aus. Den Fehler in Zeile 100 behebe ich noch, das ist aber nur Kosmetik. Wichtig ist, dass spätestens alle 90 Sekunden "Process Arlo event" kommt.

Danke. Sehr gut.

Das selbe gilt übrigens auch für die anderen Readings. Wenn ich z.B: disarm mache, bleibt es auch nach einem updateReading auf dem custom mode "Aussen" in meinem Falle. Im Hintergrund wurden aber gemäss Arlo-App die Kameras disarmed... Also, der Befehl kommt zwar an, aber er wird nicht zurückgespielt.

Ok, ich habe nun mal geswitched auf das neue Modul. Funktioniert soweit auch prächtig. Beim Umschalten der Custom Modes habe ich aber noch ein Problem:

Ich habe die Modes:

Terrasse
Garten_1
Garten_2
Garten_Alle

in Arlo definiert.

Ein "set Arlo_Home mode xyz" funktioniert auch mit allen Modes bis auf "Garten_Alle". Ob es Namen liegt weiss ich nicht wirklich. Habe es testweise in Arlo mal in "Garten" umbenannt, aber das hat auch nicht geklappt.   

Update: Das geht irgendwie jetzt auch mit der Python-Version nicht mehr!

Update2: Es liegt daran: Wenn in dem Mode einmal eine Aktion mit einem Arlo Security Light definiert war, dann lässt sich der Modus via FHEM nicht mehr einstellen. Auch nicht, wenn man die Aktion mit dem Security Light später wieder entfernt. Man muss den Mode komplett neu erstellen, dann geht es wieder ...)

Hast Du eine Idee?

Der Befehl für Brightness scheint auch noch nicht so ganz zu funktionieren. Er wird von der Kamera ignoriert. Wenn ich, während ich den Befehl in FHEM ausführe, einen Live View in Arlo Web offen habe auf die Kamera, dann erscheint dort im Bild "Invalid message syntax.: brightness"

nur zur Info: jetzt kommen gar keine Events mehr an. Auch bei event-on-change-reading nicht...

Ich fürchte, ich muss doch wieder zurück auf die Python-Version. Heute Nacht und eben wieder ist mein FHEM komplett abgestürzt. Die letzten Log-Meldungen waren jeweils:

2018.12.05 09:26:01 4: Notify 4RD3837TA2965, action: get cameras
Can't locate object method "carp" via package "invalid character encountered while parsing JSON string, at character offset 5772 (before "\r") at ./FHEM/49_Arlo.pm line 698.
" (perhaps you forgot to load "invalid character encountered while parsing JSON string, at character offset 5772 (before "\r") at ./FHEM/49_Arlo.pm line 698.
"?) at ./FHEM/49_Arlo.pm line 703.
2018.12.05 09:26:02 1: SONOS0: Last Listener seems to be died and process started by fhem... stopping Threads and process...
2018.12.05 09:26:02 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...


Muss mal sehen, ob ich mir doch irgendwo noch eine FHEM-Testinstanz installieren kann, um das Perl-Modul zu testen. Auf dem produktiven System geht es derzeit eher noch nicht.

Zitat von: choetzu am 03 Dezember 2018, 22:58:18
- activityState geht noch nicht zuverlässig. Z.t. Geht es nicht zurück in den idle und bleibt auf alertStreamAlert... kann es sein, dass zudem diese Events später ankommen als beim Phyton. Bei mir gehen bei Bewegung Lapen an. früher ging das flott, jetzt ca 1-2 Sekunden später

Ich habe eine neue Version hochgeladen. Dort kannst du am Device Arlo_Cloud ein Attribut ssePollingInterval setzen. Standardmäßig wird alle 2 Sekunden abgefragt, wenn du attr Arlo_Cloud ssePollingInterval 0.5 angibst, wird jede halbe Sekunde geprüft. Prüfe mal, ob damit die Reaktion wieder ähnlich schnell ist wie bei der Python-Variante.

Zitat von: m0urs am 05 Dezember 2018, 09:33:35
Ich fürchte, ich muss doch wieder zurück auf die Python-Version. Heute Nacht und eben wieder ist mein FHEM komplett abgestürzt. Die letzten Log-Meldungen waren jeweils:

Code Auswählen Erweitern

2018.12.05 09:26:01 4: Notify 4RD3837TA2965, action: get cameras
Can't locate object method "carp" via package "invalid character encountered while parsing JSON string, at character offset 5772 (before "\r") at ./FHEM/49_Arlo.pm line 698.
" (perhaps you forgot to load "invalid character encountered while parsing JSON string, at character offset 5772 (before "\r") at ./FHEM/49_Arlo.pm line 698.
"?) at ./FHEM/49_Arlo.pm line 703.
2018.12.05 09:26:02 1: SONOS0: Last Listener seems to be died and process started by fhem... stopping Threads and process...
2018.12.05 09:26:02 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...


Muss mal sehen, ob ich mir doch irgendwo noch eine FHEM-Testinstanz installieren kann, um das Perl-Modul zu testen. Auf dem produktiven System geht es derzeit eher noch nicht.

Ich hatte den Fehler auch schon und er ist in der Version, die ich gerade hochgeladen habe, behoben. Es gab 2 Probleme: Hauptauslöser war, dass manchmal die JSON-Antworten in 2 Zeilen statt einer Zeile kommen. Hier sorge ich jetzt dafür, dass die 2 Zeilen wieder zu einer zusammengefasst werden. Außerdem führten Fehler beim Parsen des JSON zu einem Stop von FHEM. Solche Fehler werden jetzt abgefangen und geloggt.

Hab mal versucht ein FHEM-Testsystem in Docker auf einem anderen Raspi aufzusetzen. Ist noch ein ganz leeres System und nur das Arlo-Cloud-Device definiert. Das geht dort auch noch. Wenn ich dann aber ein Autocreate für Arlo aufrufe restartet FHEM sofort und vorher dieser fehler:

2018.12.06 08:51:33.047 3: (Re)starting Arlo event listener.
Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/49_Arlo.pm line 390.

Stimmt da auf meinem Testsystem noch was nicht oder ist da noch ein Fehler im Modul?

Hab die Version vom 5.12. aufgespielt und kurz getestet

- Die Mode Umschaltung funktioniert sehr gut (mit beiden Basisstationen)
- Nach dem Neustart werden die Readings aktuallisiert und mit aktuellem Timestamp angezeigt

Allerdings gibts auch Probleme:
- An der Base "updateReadings" --> keine Aktuallisierung der Camera Readings
- Bei Bewegung --> keine Aktuallisierung der Camera Readings
- Bei Modeumschaltung --> keine Aktuallisierung der Base Readings (wird aber zuverlässig ausgeführt)
- Bei Cloud"autocreate" --> Absturz (fhem schmiert ab, Neustart des RPi notwendig) letzte Meldung im Log:
Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/49_Arlo.pm line 390.
- Bei jedem Neustart des RPi bei initialisieren im Log die Meldung:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/49_Arlo.pm line 183.

Zitat von: m0urs am 06 Dezember 2018, 08:55:15
Hab mal versucht ein FHEM-Testsystem in Docker auf einem anderen Raspi aufzusetzen. Ist noch ein ganz leeres System und nur das Arlo-Cloud-Device definiert. Das geht dort auch noch. Wenn ich dann aber ein Autocreate für Arlo aufrufe restartet FHEM sofort und vorher dieser fehler:

Code Auswählen Erweitern

2018.12.06 08:51:33.047 3: (Re)starting Arlo event listener.
Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/49_Arlo.pm line 390.

Stimmt da auf meinem Testsystem noch was nicht oder ist da noch ein Fehler im Modul?

Das war ein Bug. Ich habe gerade eben eine korrigierte Version hochgeladen, bitte nochmal versuchen.

Zitat von: m0urs am 04 Dezember 2018, 18:07:12
Der Befehl für Brightness scheint auch noch nicht so ganz zu funktionieren. Er wird von der Kamera ignoriert. Wenn ich, während ich den Befehl in FHEM ausführe, einen Live View in Arlo Web offen habe auf die Kamera, dann erscheint dort im Bild "Invalid message syntax.: brightness"

Der Fehler ist jetzt auch behoben.

Zitat von: maluk am 06 Dezember 2018, 20:31:30
Das war ein Bug. Ich habe gerade eben eine korrigierte Version hochgeladen, bitte nochmal versuchen.

Danke, funktioniert jetzt!

Zitat von: maluk am 06 Dezember 2018, 21:25:55
Der Fehler ist jetzt auch behoben.

Kann ich bestätigen. Auch das geht jetzt!

Ich lass das Modul jetzt mal über Nacht auf dem Testsystem laufen, ob es stabil bleibt.

Ich habe eine neue Version hochgeladen, die jetzt auch die Arlo Bridges für die Security Lights erkennen sollte. Außerdem habe ich das Herunterladen der Videos und Bilder optimiert, damit weniger Hauptspeicher beim Download verbraucht wird.

@m0urs: ich brauche hier deine Mitarbeit, da ich selbst keine Security Lights besitze. Versuche bitte, ob die Bridge gefunden wird und ob du arm/disarm ausführen und modes setzen kannst. Ich habe so gut es geht versucht, die Anpassungen von Jeffrey Walter zu übernehmen. Allerdings konnte ich mit der neuen API keine Modes für meine Basisstation setzen. Vielleicht klappt es ja mit deiner Bridge. Außerdem wäre es noch wichtig zu wissen, ob für die Security Lights auch Devices angelegt werden soll und was für diese angezeigt werden soll bzw. welche Aktionen darauf möglich sein sollen.

Vielen Dank schon mal für Deine schnelle Reaktion mit den Bridges :-)

Ich habe mal getestet. Also: Meine 1. Bridge wird korrekt erkannt, die 2. Bridge allerdings noch nicht.

Das Arm und Disarm bzw. setzen der Modes funktioniert auch noch nicht. Bekomme folgende Logmeldungen:

2018.12.09 22:25:11.577 0: Server started with 14 defined entities (fhem.pl:17779/2018-11-18 perl:5.024001 os:linux user:fhem pid:30040)
2018.12.09 22:25:14.832 3: (Re)starting Arlo event listener.
2018.12.09 22:25:16.888 3: Process Arlo event subscriptions/TPWWZZ2-183-34356703_web for 4RD3837TA2965
2018.12.09 22:25:18.892 3: Process Arlo event subscriptions/TPWWZZ2-183-34356703_web for 4RD3837TA2965
2018.12.09 22:25:35.520 3: Process Arlo event cameras for 4RD3837TA2965
2018.12.09 22:26:00.510 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/49_Arlo.pm line 412.
2018.12.09 22:26:00.513 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/49_Arlo.pm line 404.
2018.12.09 22:26:00.517 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/49_Arlo.pm line 396.
2018.12.09 22:26:44.347 2: Arlo call was not successful: {"data":{"error":"AUTO-5050","message":"Failed to update Automation Definitions","reason":"Unable to upload active automation. Please try again"},"success":false}
2018.12.09 22:26:46.138 3: Process Arlo event subscriptions/TPWWZZ2-183-34356703_web for 4RD3837TA2965
2018.12.09 22:27:13.836 2: Arlo call was not successful: {"data":{"error":"AUTO-5050","message":"Failed to update Automation Definitions","reason":"Unable to upload active automation. Please try again"},"success":false}
2018.12.09 22:27:23.284 3: Could not set arlo mode Abends, because modes for basestation have to be loaded. Please try a again in a few seconds.
2018.12.09 22:28:13.142 2: Arlo call was not successful: {"data":{"error":"AUTO-5050","message":"Failed to update Automation Definitions","reason":"Unable to upload active automation. Please try again"},"success":false}
2018.12.09 22:28:16.970 3: Process Arlo event subscriptions/TPWWZZ2-183-34356703_web for 4RD3837TA2965
2018.12.09 22:28:22.792 3: Set Arlo basestation mode to mode3
2018.12.09 22:28:22.992 2: Arlo call was not successful: {"data":{"error":"AUTO-5050","message":"Failed to update Automation Definitions","reason":"Unable to upload active automation. Please try again"},"success":false}


Lass mich wissen, was genau ich wie testen soll!

Ich habe eine neue Version hochgeladen. Das Problem mit Arm / Disarm / Modes setzen sollte jetzt behoben sein. Warum die 2. Bridge nicht erkannt wird, kann ich nicht ganz nachvollziehen.

Du kannst mal folgende Befehl eingeben, um das Log Level zu erhöhen:
attr Arlo_Cloud verbose 4

Danach nochmal autocreate ausführen und im Logfile nach "Response from Arlo" suchen. Dort bitte prüfen, ob deine 2. Bridge enthalten ist.

Hallo,

habe eben das Modul eingespielt. Es findet meine Basisstation, aber leider nicht meine Kameras ....

Allerdings erkennt das Modul sie irgendwie, generiert aber keine Devices.

2018.12.10 13:30:55 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:30:55 3: Fritzbox_Smarthome: read from http://fritz.box:80 timed out
2018.12.10 13:30:57 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:31:01 2: AttrTemplates: got 10 entries
2018.12.10 13:31:10 3: Process Arlo event cameras for 4RD3877LA267A
2018.12.10 13:31:23 1: OWX_CCC::Detect: 1-Wire bus ow_cuno interface DS2482 / CUNO detected in cuno
2018.12.10 13:32:19 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:33:52 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:34:17 3: (Re)starting Arlo event listener.
2018.12.10 13:34:19 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:34:51 3: cuno: Unknown code FF, help me!
2018.12.10 13:35:48 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:36:31 3: Received Arlo logout event.
2018.12.10 13:36:33 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:36:35 3: Process Arlo event cameras for 4RD3877LA267A
2018.12.10 13:36:37 3: Process Arlo event storage for 4RD3877LA267A
2018.12.10 13:36:39 3: Process Arlo event siren for 4RD3877LA267A
2018.12.10 13:36:41 3: Process Arlo event cameras/5JX18778A054D/motionZones for 4RD3877LA267A
2018.12.10 13:36:43 3: Process Arlo event cameras/5JX1877FA2576/motionZones for 4RD3877LA267A
2018.12.10 13:36:45 3: Process Arlo event cameras/5JX1877TA25F1/motionZones for 4RD3877LA267A
2018.12.10 13:37:19 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A
2018.12.10 13:38:47 4: Notify 4RD3877LA267A, action: set subscriptions/259AY2NQ-100-41938557_web
2018.12.10 13:38:49 3: Process Arlo event subscriptions/259AY2NQ-100-41938557_web for 4RD3877LA267A


Um jede Hilfe dankbar.

Liebe Grüße
Oli

Hallo ojb,

ich habe gerade nochmal eine neue Version mit erweitertem Logging hochgeladen. Bitte installiere diese Version und schaue dann im Logfile, welche Devices er beim autocreate findet.  Jedes gefundene Device vom Typ basestation, arlobridge oder camera sollte danach im Raum Arlo angelegt worden sein.

Zitat von: maluk am 10 Dezember 2018, 10:41:43
Ich habe eine neue Version hochgeladen. Das Problem mit Arm / Disarm / Modes setzen sollte jetzt behoben sein. Warum die 2. Bridge nicht erkannt wird, kann ich nicht ganz nachvollziehen.

Du kannst mal folgende Befehl eingeben, um das Log Level zu erhöhen:

Code Auswählen Erweitern

attr Arlo_Cloud verbose 4

Danach nochmal autocreate ausführen und im Logfile nach "Response from Arlo" suchen. Dort bitte prüfen, ob deine 2. Bridge enthalten ist.

Also erst mal die gute Nachricht: Arm/Disarm und Mode für die Bridge funktionieren jetzt! Super!

Allerdings wird weder die zweite Bridge noch wird das zweite Licht meiner ersten Bridge gefunden. Ausserdem wird kein device für das eine gefundene Light erzeugt. Das ist aber so gewollt derzeit, oder?

Das ist der Output mit verbose=4.

2018.12.10 15:44:15.575 5: URL: https://arlo.netgear.com/hmsweb/users/devices
2018.12.10 15:44:15.802 3: Found device siren with name Home.
2018.12.10 15:44:15.803 3: Found device camera with name Garten_2.
2018.12.10 15:44:15.805 3: Found device camera with name Terrasse.
2018.12.10 15:44:15.805 3: Found device camera with name Garten_1.
2018.12.10 15:44:15.807 3: Found device lights with name Licht_Terrasse.
2018.12.10 15:44:15.808 3: Found device arlobridge with name Bridge_AZMichael.
2018.12.10 15:44:15.809 3: Found device basestation with name Home.


Deine zweite Bridge wird über die API von Arlo nicht mitgeliefert. Siehst du sie, wenn du dich über https://arlo.netgear.com einloggst? Falls ja: könntest du mal den Netzwerk-Verkehr mitprotokollieren? Es müsste einen Eintrag GET https://arlo.netgear.com/hmsweb/users/devices?t=1544459511973 (T ist wohl der Timestamp) geben. Wenn du diesen anklickst, müsstest du in der Antwort prüfen, ob dort alle Geräte inkl. der zweiten Bridge geliefert werden. Ich rufe beim Autocreate genau diese URL auf und lege für jedes Gerät (außer Siren und Light), das hier geliefert wird, ein FHEM-Device an.

Zu Thema Light: ich kann dafür natürlich ein FHEM-Device anlegen, aber du müsstest mir hier ein paar Tipps geben, welche Readings davon interessant wären und welche Aktionen man darauf ausführen können soll.

Zitat von: maluk am 10 Dezember 2018, 17:37:15
Deine zweite Bridge wird über die API von Arlo nicht mitgeliefert. Siehst du sie, wenn du dich über https://arlo.netgear.com einloggst? Falls ja: könntest du mal den Netzwerk-Verkehr mitprotokollieren? Es müsste einen Eintrag GET https://arlo.netgear.com/hmsweb/users/devices?t=1544459511973 (T ist wohl der Timestamp) geben. Wenn du diesen anklickst, müsstest du in der Antwort prüfen, ob dort alle Geräte inkl. der zweiten Bridge geliefert werden. Ich rufe beim Autocreate genau diese URL auf und lege für jedes Gerät (außer Siren und Light), das hier geliefert wird, ein FHEM-Device an.

Ja, bei diesem Aufruf sind beide Bridges und alle Lights enthalten.

ZitatZu Thema Light: ich kann dafür natürlich ein FHEM-Device anlegen, aber du müsstest mir hier ein paar Tipps geben, welche Readings davon interessant wären und welche Aktionen man darauf ausführen können soll.

Also, wenn es nicht zu viel Arbeit wird, wäre das schön. Ist aber erst mal nicht Prio 1!

Readings:

Status (an / aus)
Batteriestand

Aktionen:

Einschalten
Ausschalten

Ist aber wie gesagt nicht Prio 1. Das Schalten der Modi für die Bridges wäre mir erst mal wichtiger.

Vielleicht macht es Sinn irgendwie als Debug-Output mal den kompletten Traffic des Moduls mitzuloggen?

hallo,

ich habe immer noch ein grundlegendes Problem. Die Abhandlung von activityState scheint nicht zu funktionieren. Ich habe dein Modul gestern neu angelegt. Leider kommen die activityState nur bei einem Device an... Siehe Bild.

Woran könnte das liegen?

Lg c

Guten Morgen,

jetzt funktioniert alles. Ich denke der Fehler war die Bezeichnung der Kamera's. Ich habe von 'Wohnzimmer Cam 1' auf 'Wohnzimmer_Cam_1' gewechselt und jetzt werden die Devices auch erzeugt.

Liebe Grüße und vielen Dank für das Modul
Oli

Hallo Leute,

ich möchte gerne auf meiner Arlo Seite regelmäßige Bilder meiner Cam's haben. Also z.B. alle 15 Minuten aktualisiert. Ich habe per Weblink geschafft einzelne Snapshots anzeigen zu lassen, aber die Snapshots haben ja jedesmal eine andere ID.

Hat jemand eine Idee wie man immer den letzten Snapshot anzeigen lassen könnte?

Liebe Grüße
Oli

Zitat von: ojb am 11 Dezember 2018, 10:29:17
ich möchte gerne auf meiner Arlo Seite regelmäßige Bilder meiner Cam's haben. Also z.B. alle 15 Minuten aktualisiert. Ich habe per Weblink geschafft einzelne Snapshots anzeigen zu lassen, aber die Snapshots haben ja jedesmal eine andere ID.

Wenn du downloadDir und downloadLink verwendest, werden die Bilder immer unter der Seriennummer der Kamera in dem angegebenen Verzeichnis abgelegt. Du kannst also mit festen URLs immer auf das Bild derselben Kamera zugreifen.

Zitat von: choetzu am 10 Dezember 2018, 19:37:51
ich habe immer noch ein grundlegendes Problem. Die Abhandlung von activityState scheint nicht zu funktionieren. Ich habe dein Modul gestern neu angelegt. Leider kommen die activityState nur bei einem Device an... Siehe Bild.

Woran könnte das liegen?

Kommen grundsätzlich keine activityStates für die Kameras an? Was passiert wenn du manuell "set Kamera snapshot" oder "set Kamera startRecording" und "set Kamera stopRecording" aufrufst?

Generell brauche ich für die Fehleranalyse immer die Auszüge aus dem Logfile von dem betroffenen Zeitraum. Wenn Bewegung erkannt oder manuell eine Aufnahme ausgelöst wird, sollte am Ende immer ein Eintrag "Process Arlo event mediaUploadNotification" kommen. Dieser Event setzt den activityState wieder auf idle.

Zitat von: m0urs am 10 Dezember 2018, 18:18:14
Vielleicht macht es Sinn irgendwie als Debug-Output mal den kompletten Traffic des Moduls mitzuloggen?

Das wäre gut. Setze mal verbose am Cloud-Device auf 4 und rufe nochmal autocreate auf. Wichtig ist die JSON-Response für den Abruf der Devices. Mich wundert, dass im Web Client offensichtlich mehr Devices geliefert werden als bei meinen Aufruf über die API.

EDIT: mir ist gerade aufgefallne, dass das Logging hier nicht richtig funktioneirt. Das muss ich erst korrigieren und eine neue Version hochladen.

Zitat von: m0urs am 10 Dezember 2018, 18:18:14
Vielleicht macht es Sinn irgendwie als Debug-Output mal den kompletten Traffic des Moduls mitzuloggen?

So, jetzt habe ich den Fehler korrigiert und noch gleich das Anlegen der Light-Devices integriert. Allerdings sind diese gerade noch ganz dumm, daher brauche ich deine Log-Ausgaben.

Bitte im Cloud-Device verbose temporär auf 5 setzen, dann wird jetzt ganz viel mitgeloggt. Für mich relevant ist die Antwort auf das Autocreate und die Antwort auf ein UpdateReadings der Bridge. Dort sollte ich dann erkennen können, wo die von dir gewünschten Eigentschaften der Lights stehen. Für das Ein- und Ausschalten müsstest du mir die Requests aus der Arlo-Web-Anwendung senden, die dort ausgelöst werden, wenn du das Licht ein- oder ausschaltest.

Hi wie setzt man den Mode ausserHaus?
set arlo mode ausserHaus

funktioniert bei mir nicht

set arlo arm oder set arlo disarm funktioniert tadelos

funktioniert doch !!!!!
Muss ich immer ein set arlo Updatereading hinterherwerfen bis fhem die info erhält  ?

Zitat von: maluk am 11 Dezember 2018, 21:12:21
So, jetzt habe ich den Fehler korrigiert und noch gleich das Anlegen der Light-Devices integriert. Allerdings sind diese gerade noch ganz dumm, daher brauche ich deine Log-Ausgaben.

Bitte im Cloud-Device verbose temporär auf 5 setzen, dann wird jetzt ganz viel mitgeloggt. Für mich relevant ist die Antwort auf das Autocreate und die Antwort auf ein UpdateReadings der Bridge. Dort sollte ich dann erkennen können, wo die von dir gewünschten Eigentschaften der Lights stehen. Für das Ein- und Ausschalten müsstest du mir die Requests aus der Arlo-Web-Anwendung senden, die dort ausgelöst werden, wenn du das Licht ein- oder ausschaltest.

Es wird aber noch kein Light-Device (leer) angelegt, oder sollte das schon so sein?

Hier der Request für Licht an:

{"from":"114-183221_web","to":"59G1865E007ED","action":"set","resource":"lights/5FW18659014E9","transId":"web!e8233b9b.2e3a6!1544561516708","publishResponse":true,"properties":{"lampState":"on"}}

Und hier für Licht aus:

{"from":"114-183221_web","to":"59G1865E007ED","action":"set","resource":"lights/5FW18659014E9","transId":"web!976570e8.fbf94!1544561519114","publishResponse":true,"properties":{"lampState":"off"}}

Zitat von: synergymoon am 11 Dezember 2018, 21:34:58
funktioniert doch !!!!!
Muss ich immer ein set arlo Updatereading hinterherwerfen bis fhem die info erhält  ?

Es muss ein set Arlo_Cloud readModes ausgeführt werden. Dies passiert automatisch, allerdings mit 15 Sekunden Zeitverzögerung. Evtl. gab es auch Probleme nach der initialen Anlage der Devices.

Zitat von: m0urs am 11 Dezember 2018, 21:53:43
Es wird aber noch kein Light-Device (leer) angelegt, oder sollte das schon so sein?

Danke, die Befehle helfen mir sehr weiter. Ich habe in deinem Thread mit Jeffrey gesehen, dass der deviceType lights heißt, ich hatte vorher nur auf light (ohne s) abgefragt. Mit der gerade hochgeladenen Version sollte das Light-Device beim Autocreate angelegt werden und es sollte auch ein- und ausschalten möglich sein.

Wegen der fehlenden Bridge: kannst du mir mal die JSON-Ausgabe vom Autocreate zukommen lassen? Du kannst mir auch über das Forum eine private Mail schreiben, wenn das Log zu viele interne Informationen enthält.

Zitat von: maluk am 11 Dezember 2018, 22:20:59
Mit der gerade hochgeladenen Version sollte das Light-Device beim Autocreate angelegt werden und es sollte auch ein- und ausschalten möglich sein.

Ja, es wird ein Licht angelegt. Ein- und ausschalten scheint aber nicht zu gehen.

Allerdings sind der Bridge zwei Lichter zugeordnet, es wird aber nur eines angelegt. Vielleicht ein ähnliches Problem warum auch nur eine Bridge angelegt wird?

ZitatWegen der fehlenden Bridge: kannst du mir mal die JSON-Ausgabe vom Autocreate zukommen lassen? Du kannst mir auch über das Forum eine private Mail schreiben, wenn das Log zu viele interne Informationen enthält.

Das hatte ich gestern schon gemacht, hattest Du die private Mail nicht bekommen?

Die Mail ist angekommen, das hatte ich übersehen. Ich werde mir das heute Abend mal ansehen.

Hallo,

bekomme folgende Fehlermeldung und die Basisstation wird auch nicht angelegt - Readings bekomme ich auch keine- help!

Arlo call was not successful: {"data":{"error":"2001","message":"The request's content is invalid.","reason":"The request's content is invalid.","errors":["Request method 'POST' not supported"]},"success":false}

Danke!

Zitat von: dinkel75 am 12 Dezember 2018, 16:12:52
bekomme folgende Fehlermeldung und die Basisstation wird auch nicht angelegt - Readings bekomme ich auch keine- help!

Code Auswählen Erweitern

Arlo call was not successful: {"data":{"error":"2001","message":"The request's content is invalid.","reason":"The request's content is invalid.","errors":["Request method 'POST' not supported"]},"success":false}

Bitte erhöhe das Log-Level am Arlo_Cloud Device, indem du das Attribut verbose auf 4 setzt. Ich muss zuerst herausfinden, an welcher Stelle dieser Fehler passiert.

Ich hoffe, fu fängst damit etwas an.

2018.12.13 06:03:44 1: define Arlo_MuMHomesweethome Arlo CAMERA  48E35B7RA1262 1005-115-1812267: Usage: define <name> Arlo ACCOUNT username password
       define <name> Arlo BASESTATION deviceName serialNumber xCloudId
       define <name> Arlo CAMERA basestationSerialNumber deviceName serialNumber xCloudId
2018.12.13 06:03:44 3: Found device camera with name Moritz.
2018.12.13 06:04:17 1: PERL WARNING: Use of uninitialized value $xCloudId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 645.
2018.12.13 06:04:17 2: Arlo call was not successful: {"data":{"error":"2001","message":"The request's content is invalid.","reason":"The request's content is invalid.","errors":["to, may not be empty"]},"success":false}
2018.12.13 06:04:25 1: RMDIR: ./restoreDir/save/2018-12-06
2018.12.13 06:05:00 3: leistung_holen return value: 2083.463
2018.12.13 06:05:13 2: Arlo call was not successful: {"data":{"error":"2001","message":"The request's content is invalid.","reason":"The request's content is invalid.","errors":["Request method 'POST' not supported"]},"success":false}


Ich kriege ähnliche Fehler nun beim DEFINE vom Autocreate. Siehe meine Mail von eben.

Sorry, da hat sich in der letzten Version ein Fehler eingeschlichen. Ich habe den Bug gefixt, bitte die neue Version herunterladen und nochmal set autocreate aufrufen.

Zitat von: maluk am 13 Dezember 2018, 18:51:13
Sorry, da hat sich in der letzten Version ein Fehler eingeschlichen. Ich habe den Bug gefixt, bitte die neue Version herunterladen und nochmal set autocreate aufrufen.

Super! Jetzt funktioniert das, wie es sein soll.

Ich bekomme die Basisstation, beide Bridges, alle Kameras und alle Lichter erzeugt.

Das Ein- und Ausschalten der Lichter klappt auch. Ebenso das Aktivieren/Deaktivieren sowie Custom Mode setzen der Bridges!

Jetzt fehlen aus meiner Sicht nur noch folgende Dinge (ich weiss, ich kriege nicht genug :-)):

• Den Status der Lichter setzen , also sprich wenn man es einschaltet, dass der Status auf "An" geht und bei ausschalten auf "Aus".
• Die Frage: Wie bekommt man den Status "Zeitplan" bei den Bridges gesetzt, also, wie muss der Mode heissen?
• Die Kommandos für die der Lichter anpassen, da sind ja noch alle von den Kameras drin (ist aber eher Kosmetik) oops, das ist ja schon erledigt :-)
• Ach ja, und vielleicht in Zukunft mal (das nutze ich noch nicht in FHEM), dass der Bewegungssensor in den Lichtern ebenfalls einen Event in FHEM erzeugt

Aber auf alle Fälle schon mal recht herzlichen Dank für dieses Modul und für die schnelle Umsetzung/Fehlerbeseitigung!

Update: Ach ja, den Battery-Lavel der Lichter wäre noch klasse :-)

Basisstation wird jetzt auch gefunden. Nur Snapshot oder Stream aufzeichnen geht noch immer nicht. siehe

PERL WARNING: Subroutine Arlo_Initialize redefined at ./FHEM/49_Arlo.pm line 14.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Define redefined at ./FHEM/49_Arlo.pm line 23.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_InitDevice redefined at ./FHEM/49_Arlo.pm line 94.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Undef redefined at ./FHEM/49_Arlo.pm line 106.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Attr redefined at ./FHEM/49_Arlo.pm line 120.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Set redefined at ./FHEM/49_Arlo.pm line 152.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Poll redefined at ./FHEM/49_Arlo.pm line 225.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_GetBasestations redefined at ./FHEM/49_Arlo.pm line 233.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Ping redefined at ./FHEM/49_Arlo.pm line 248.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetReading redefined at ./FHEM/49_Arlo.pm line 272.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetReadingAndDownload redefined at ./FHEM/49_Arlo.pm line 289.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_WriteResponseToFile redefined at ./FHEM/49_Arlo.pm line 313.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Camera_Readings redefined at ./FHEM/49_Arlo.pm line 318.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Event redefined at ./FHEM/49_Arlo.pm line 334.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Request redefined at ./FHEM/49_Arlo.pm line 349.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_DefaultCallback redefined at ./FHEM/49_Arlo.pm line 382.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_CreateDevices redefined at ./FHEM/49_Arlo.pm line 407.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_CreateDevice redefined at ./FHEM/49_Arlo.pm line 412.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_GetNameWithoutUmlaut redefined at ./FHEM/49_Arlo.pm line 424.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_CreateDevicesCallback redefined at ./FHEM/49_Arlo.pm line 432.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_GenTransId redefined at ./FHEM/49_Arlo.pm line 458.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_PreparePostRequest redefined at ./FHEM/49_Arlo.pm line 466.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Notify redefined at ./FHEM/49_Arlo.pm line 483.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Subscribe redefined at ./FHEM/49_Arlo.pm line 490.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Unsubscribe redefined at ./FHEM/49_Arlo.pm line 501.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ReadModes redefined at ./FHEM/49_Arlo.pm line 506.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ReadModesCallback redefined at ./FHEM/49_Arlo.pm line 511.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ReadCamerasAndLights redefined at ./FHEM/49_Arlo.pm line 531.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_UpdateReadings redefined at ./FHEM/49_Arlo.pm line 541.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_UpdateReadingsCallback redefined at ./FHEM/49_Arlo.pm line 547.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetModeReading redefined at ./FHEM/49_Arlo.pm line 564.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_BasestationArm redefined at ./FHEM/49_Arlo.pm line 580.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_BasestationDisarm redefined at ./FHEM/49_Arlo.pm line 586.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetBasestationMode redefined at ./FHEM/49_Arlo.pm line 591.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_DoSetBasestationMode redefined at ./FHEM/49_Arlo.pm line 607.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetBasestationSiren redefined at ./FHEM/49_Arlo.pm line 618.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_GetBasestationForCamera redefined at ./FHEM/49_Arlo.pm line 625.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ToggleCamera redefined at ./FHEM/49_Arlo.pm line 631.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Snapshot redefined at ./FHEM/49_Arlo.pm line 641.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_StartRecording redefined at ./FHEM/49_Arlo.pm line 652.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_StartRecordingStep2 redefined at ./FHEM/49_Arlo.pm line 669.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_CameraAction redefined at ./FHEM/49_Arlo.pm line 677.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetBrightness redefined at ./FHEM/49_Arlo.pm line 688.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_SetLightState redefined at ./FHEM/49_Arlo.pm line 697.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Login redefined at ./FHEM/49_Arlo.pm line 710.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_Logout redefined at ./FHEM/49_Arlo.pm line 753.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_GetCookies redefined at ./FHEM/49_Arlo.pm line 758.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_EventQueue redefined at ./FHEM/49_Arlo.pm line 768.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_EventPolling redefined at ./FHEM/49_Arlo.pm line 788.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ProcessResponse redefined at ./FHEM/49_Arlo.pm line 831.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_ProcessEvent redefined at ./FHEM/49_Arlo.pm line 878.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_encrypt redefined at ./FHEM/49_Arlo.pm line 962.
2018.12.13 19:22:46 1: PERL WARNING: Subroutine Arlo_decrypt redefined at ./FHEM/49_Arlo.pm line 978.
2018.12.13 19:22:56 3: Found device camera with name Katzen.
2018.12.13 19:22:56 3: Found device camera with name Eingang.
2018.12.13 19:22:56 3: Found device basestation with name MuMHomesweethome.
2018.12.13 19:22:57 3: Found device camera with name Moritz.
2018.12.13 19:23:01 3: leistung_holen return value: 254.607
2018.12.13 19:23:01 3: leistung_holen return value: 255.419
2018.12.13 19:23:01 4: Notify 48E35B7RA1262, action: set subscriptions/115-3579520_web
2018.12.13 19:23:17 4: Notify 48E35B7RA1262, action: set subscriptions/115-3579520_web
2018.12.13 19:23:31 4: Take snapshot for camera 48B45A7FEAB70.
2018.12.13 19:24:00 3: leistung_holen return value: 267.361
2018.12.13 19:24:42 4: Start streaming for camera 48B45A7FEAB70.
2018.12.13 19:24:47 4: Notify 48E35B7RA1262, action: set subscriptions/115-3579520_web
2018.12.13 19:24:56 4: Action stopRecord for camera 48B45A7FEAB70.
2018.12.13 19:24:57 2: Arlo call was not successful: {"data":{"error":"5019","message":"The streaming service is reporting that no such recording in progress.","reason":"No such recording going on "},"success":false}
2018.12.13 19:25:01 3: leistung_holen return value: 256.382[/code]

Irgendwie läufts jetzt.
Readings kommen und Stream starten/stoppen geht auch.
Toll!

Ich hab so eine Babycam, wäre es möglich, dass du das Licht und die Musik integrierst?
D.h. Licht und Musik ein/aus wäre super!

Danke!

Ich habe selbst keine Babycam, daher benötige ich deine Unterstützung. Gehe auf https://arlo.netgear.com und melde dich dort an. Gehe zu deiner Kamera und aktiviere die Entwickler-Tools in deinem Browser (F12) und schneide den Netzwerkverkehr mit. Wenn du Licht und Musik ein- und ausschaltest, müssten POST-Requests erzeugt werden. Hier benötige ich die URLs die aufgerufen werden und die Parameter, die per POST an den Server übertragen werden. Dann kann ich die Funktionen in mein Modul übernehmen.

Ich habe nochmal eine neue Version hochgeladen, deren Fokus auf der Unterstützung mehrerer Basisstationen liegt (Danke mi.ke für die Bereitstellung der Basisstation).  Dadurch hat sich auch an der Struktur der Attribute / Methoden etwas geändert.

• Die Attribute interval und disable der Basisstationen sind weggefallen
• Der Befehl set updateReadings ist von der Basisstation ins Cloud-Device gewandert
• Neue/umbenannte Attribute am Cloud-Device: updateInterval (bisheriges interval der Basisstation), pingInterval (bisheriges interval des Cloud-Device)

Wer nur eine Basisstation verwendet, muss aktuell nicht updaten.

Sieht sehr gut aus!

Aktuelle Version eingespielt, alle Devices gelöscht und neu "autocreate".
Jetzt kommen alle Readings bei den Kameras und die state bei den Basestations werden ebenfalls aktuallisiert. (Die Umschaltung bei arlo.netgear.com hatte ja vorher schon funtioniert.)

Ich kann erst morgen Mittag weitertesten, aber der erste Eindruck ist sehr positiv.

Vielen Dank

Hi maluk, offensichtlich bin ich noch der Einzige, der mit der Instabilität des Readings activeState zu kämpfen hat. Das kann vermutlich daran liegen, dass ich auf dem Live System parallel den Phyton Server laufen habe...

Meine Frage: wenn ich nun auf dem Live Server auf die neue Version umsteigen will, muss ich lediglich die 49_Arlo.pm ersetzen und gut ist? Oder muss ich alles neu installieren?

Lg C

Hi choetzu,

parallel solltest du beide Versionen tatsächlich nicht betreiben. Du musst 49_Arlo.pm ersetzen (und kannst 49_Arlo.py löschen) und musst danach die Basestation- und Kamera-Devices löschen. Falls du am Cloud-Device weitere Parameter außer User/Passwort hattest, musst du diese entfernen.

reload 49_Arlo durchführen und dann am Cloud-Device einen set autocreate ausführen. Dabei werden die Devices wieder neu angelegt. Die alten Devices können nicht verwendet werden, da sich die Parameter der Devices geändert haben und daher die alten Defintionen nicht mehr funktioneren.

Falls der Autocreate nicht funktionert, das Cloud-Device auch nochmal löschen und neu anlegen.

Gruß
maluk

Hi,

sei heute kann ich mit meinem für FHEM angelegten User keine Steuerung mehr in FHEM für Arlo machen. Es kommt immer eine Meldung der Art:

2018.12.16 11:07:21 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"4RD3837TA2965 doesn't belong to the User / Is not provisioned"},"success":false}

Mit meinem Hauptuser scheint es zu funktionieren. Der FHEM-User hat Berechtigungen auf alle Devices und auch als Admin. In der Arlo-Web-Oberfläche kann dieser User auch alles machen.

Gabe den User bereits in Arlo gelöscht und neu eingeladen. leider ohne Erfolg.

Irgendeine Idee?

Update: Ein Autocreate erzeugt zwar keineneuen Device, weil ja schon alle da sind, zeigt aber m.E. dass mit dem User alle geräte gefunden werden:

2018.12.16 11:21:33 3: Found device siren with name Home.
2018.12.16 11:21:33 3: Found device camera with name Garten_2.
2018.12.16 11:21:33 3: Found device camera with name Terrasse.
2018.12.16 11:21:33 3: Found device camera with name Garten_1.
2018.12.16 11:21:33 3: Found device lights with name Licht_Garten1.
2018.12.16 11:21:33 3: Found device lights with name Licht_Garten2.
2018.12.16 11:21:33 3: Found device lights with name Licht_Terrasse.
2018.12.16 11:21:33 3: Found device lights with name Licht_TerrasseSeite.
2018.12.16 11:21:33 3: Found device arlobridge with name Bridge_AZMichael.
2018.12.16 11:21:33 3: Found device basestation with name Home.
2018.12.16 11:21:33 3: Found device arlobridge with name Bridge_AZSabine.


Update:

Ich habe jetzt alle Devices in FHEM gelöscht, die neueste 49_Arlo.pm eingespielt und alles neu erzeugen lassen. Derzeit funktioniert es wieder mit dem Arlo-FHEM-User. Strange ...

Zitat von: mi.ke am 14 Dezember 2018, 21:41:48

Aktuelle Version eingespielt, alle Devices gelöscht und neu "autocreate".
Jetzt kommen alle Readings bei den Kameras und die state bei den Basestations werden ebenfalls aktuallisiert. (Die Umschaltung bei arlo.netgear.com hatte ja vorher schon funtioniert.)

Bisher sieht es immer noch sehr gut aus.

Allerdings hat es auch bei mir die DSL Zwangstrennung nicht "überlebt und ist "hängengeblieben"
2018.12.16 03:04:11 3: Process Arlo event subscriptions/xxx-xxxxxxx_web for XXXXXXXXXXXXX
2018.12.16 09:32:43 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}

Die Trennung laut Router war um 03:04:15 Uhr. Passt also.
Mit einem "reconnect & updateReadings" an der Arlo_Cloud lief wieder alles.

Ich habe jetzt meine DOIF Überprüfung nach DSL-Zwangstrennung wieder reaktiviert, die wird den nächsten disconnect abfangen. Damit kann ich mehr als gut leben.

Zwei Bitten hätte ich für die nächste Version

- Nicht alle Meldungen auf LOG3 sondern nur wirklich relevante. Auf verbose 2 kommen gar keine Meldungen mehr an. Auf verbose 3 spammt es die SD-Card.

- Die Attribute der einzelnen Subtype ACCOUNT,BASESTATION,CAMERA nur in den relevante Devices zur Auswahl stellen. Das macht es auch den "Neueinsteigern" vielleicht noch etwas leichter.

Ist aber wirklich mehr Kür und nicht so wichtig

PS.
Eine Versionsangabe in der Datei Arlo.pm hätte auch was, gerne auch mit Anzeige in den "Internals" Subtype ACCOUNT

Hallo Zusammen,

vorab: ich bin beigeistert vom Modul! Sehr gute Arbeit.

Meine Arlo Lights und die Arlo Pro's laufen super. Ich habe noch eine ArloQ (Kabelgebunden). Beim Autocreate wird das Device sogar im Log genannt (Device Type = 'arloq'), es wird logischerweise kein Device angelegt.

Allerdings werden die Snapshots und Videodateien vom Modul empfangen und weggeschrieben.

Wie kann ich dabei unterstützen um die ArloQ einzubinden? Vieles scheint schon zu gehen.

Gruß,

Sven

Guten Morgen,

leider geht es heute morgen schon wieder nicht mehr:

2018.12.17 07:36:53 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"5631875D01239 doesn't belong to the User / Is not provisioned"},"success":false}
2018.12.17 07:36:53 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"59G1865E007ED doesn't belong to the User / Is not provisioned"},"success":false}
2018.12.17 07:36:53 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"4RD3837TA2965 doesn't belong to the User / Is not provisioned"},"success":false}


Wie auch schon zuvor:

Wenn ich mit dem User an der Weboberfläche von Arlo anmelde, kann ich alle Aktionen fehlerfrei ausführen ...
Wenn ich einen Reconnect im Arlo_Cloud-Modul mache, funktioniert es auch nicht ...
Wenn ich FHEM neu starte, geht es immer noch nicht ...
Wenn ich alle "Arlo_.*" Devices aus FHEM lösche und neu anlege, dann geht es sofort (erst mal) wieder ...

Es scheint also beim Anlegen eine neue Anmeldung zu erfolgen, die bei einem reinen Neustart nicht passiert!?

Update:

Also, ich denke ich kann das Problem reproduzieren. Die Zugriffsrechte verschwinden bei jedem Neustart von FHEM. Da ich nachts um 3 Uhr jeweils einen regelmäßigen, geplanten Neustart von FHEM mache, tritt das Problem dann spätestens danach wieder auf und wird erst wieder durch Löschen und Neuanlegen aller Arlo-Devices behoben.

Zitat von: m0urs am 16 Dezember 2018, 11:14:30

Code Auswählen Erweitern

2018.12.16 11:07:21 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"4RD3837TA2965 [color=red][b]doesn't belong to the User / Is not provisioned[/b][/color]"},"success":false}

Mit meinem Hauptuser scheint es zu funktionieren. Der FHEM-User hat Berechtigungen auf alle Devices und auch als Admin. In der Arlo-Web-Oberfläche kann dieser User auch alles machen.

Warum benutzt Du dann nicht den Hauptuser zum steuern der API über fhem?

Ein zusätzliche User-Freigabe (Zugriff gewähren über die Arlo-Web-Oberfläche) scheint wohl doch nicht alle Admin-Rechte zu beinhalten und ist ja eigentlich auch dazu gedacht, die Rechte explizit einzuschränken.
Welche Vorteil versprichst Du Dir davon?

https://kb.arlo.com/1103229/What-privileges-do-my-friends-have-when-I-grant-them-access-rights-in-my-Arlo-account (https://kb.arlo.com/1103229/What-privileges-do-my-friends-have-when-I-grant-them-access-rights-in-my-Arlo-account)

Zitat von: mi.ke am 17 Dezember 2018, 08:46:13
Warum benutzt Du dann nicht den Hauptuser zum steuern der API über fhem?

Hallo mi.ke,

ganz einfach: Zum Einen wirst Du immer von anderen Geräten abgemeldet sobald Du Dich mit dem gleichen User irgendwo anmeldest. Also, Du bist gerade auf der Webseite angemeldet und FHEM kontaktiert Arlo mit dem gleichen User auch gerade: Dann fliegst Du aus der Webanwendung raus. Zum Anderen gebe ich ungern meinen Haupt-User irgendwo raus für irgendwelche anderen Systeme. Egal ob das bei Arlo oder woanders ist ;-) Arlo selbst empfiehlt auch gerade diese Verfahren mit dem Zweit-User für solche Fälle.

Wie in meinem letzten Beitrag angemerkt: Ich denke es liegt gar nicht an dem Zweit-User sondern am Neustart von FHEM (oder vielleicht auch an einer Kombination von beidem). Die Berechtigung verschwindet grundsätzlich nach einem Neustart und kommt wieder nach einer Neuanlage aller Arlo-Devices in FHEM (ohne am User etwas schrauben zu müssen).

Zitat von: m0urs am 17 Dezember 2018, 08:52:50
ganz einfach

Naja, ganz Deiner Meinung bin ich nicht

Zitat von: m0urs am 17 Dezember 2018, 08:52:50
Zum Einen wirst Du immer von anderen Geräten abgemeldet sobald Du Dich mit dem gleichen User irgendwo anmeldest. Also, Du bist gerade auf der Webseite angemeldet und FHEM kontaktiert Arlo mit dem gleichen User auch gerade: Dann fliegst Du aus der Webanwendung raus.

Melde Dich doch einfach mit einem anderen User als dem Hauptuser an der Website an.

Zitat von: m0urs am 17 Dezember 2018, 08:52:50
Zum Anderen gebe ich ungern meinen Haupt-User irgendwo raus für irgendwelche anderen Systeme. Egal ob das bei Arlo oder woanders ist ;-)

Aber Dein fhem ist doch nicht Irgendwer  ;)

Auszug aus der Commandref:
hans.mustermann@xyz.de durch die E-Mail-Adresse ersetzen, mit der man bei Arlo registriert ist, meinPasswort durch das Passwort dort.

Das fhem-Modul speichert das Passwort ja dann auch verschüsselt ab.
Ich würde wetten, Du benutzt den Hauptuser persönlich immer und hast möglicherweise Dein Passwort (Hauptuser) auf dem Handy oder sonstwo im Browser gespeichert.

Zitat von: m0urs am 17 Dezember 2018, 08:52:50
Arlo selbst empfiehlt auch gerade diese Verfahren mit dem Zweit-User für solche Fälle.

Ich habe starke Zweifel, das Netgear so etwas empfieht.
Du verwendest hier eine selbstgestickte API, gesteuert über eine frei Software.
Netgear beschneidet ihr eigenes System, um Zusatzdienste gegen Euros freizuschalten.
Wenn die API von Netgear käme und wir dafür bezahlen müssten, hättest Du möglicherweise Recht.

Zitat von: m0urs am 17 Dezember 2018, 08:52:50
Wie in meinem letzten Beitrag angemerkt: Ich denke es liegt gar nicht an dem Zweit-User sondern am Neustart von FHEM (oder vielleicht auch an einer Kombination von beidem). Die Berechtigung verschwindet grundsätzlich nach einem Neustart und kommt wieder nach einer Neuanlage aller Arlo-Devices in FHEM (ohne am User etwas schrauben zu müssen).

Am Zweituser liegt es definitiv.
Die Frage ist wie damit umzugehen ist, und wie es umgangen werden kann, damit das Problem nicht auftritt.
Vielleicht kann es ja tatsächlich über die API programmiertechnisch abgefangen werden.

Zitat
Auszug aus der Commandref:
hans.mustermann@xyz.de durch die E-Mail-Adresse ersetzen, mit der man bei Arlo registriert ist, meinPasswort durch das Passwort dort.

Naja, mein Zweituser ist ebenfalls bei Arlo registriert ...

Zitat
Du verwendest hier eine selbstgestickte API, gesteuert über eine frei Software.
Netgear beschneidet ihr eigenes System, um Zusatzdienste gegen Euros freizuschalten.
Wenn die API von Netgear käme und wir dafür bezahlen müssten, hättest Du möglicherweise Recht.

Nicht ganz. Im Hintergrund wird schon die offizielle Arlo-API genutzt:

https://developer.arlo.co/

und dort gibt es keine Einschränkungen bzgl. ob es der Haupt- oder ein anderer User ist, sofern man dem anderen Benutzer natürlich die entsprechenden Rechte zugestanden hat. Bisher (also mit der alten 49_Arlo) hat es ja auch so einwandfrei funktioniert ;-)

Zitat aus der API-DOku:

"for production scenarios involving systems integration, we recommend a separate service user account is created for API operations that isn't shared with anyone else."

Zitat
Vielleicht kann es ja tatsächlich über die API programmiertechnisch abgefangen werden.

Das ist meine Hoffnung, dass maluk das hinbekommt ;-)

Zitat von: m0urs am 17 Dezember 2018, 10:12:42

Nicht ganz. Im Hintergrund wird schon die offizielle Arlo-API genutzt:

https://developer.arlo.co/

und dort gibt es keine Einschränkungen bzgl. ob es der Haupt- oder ein anderer User ist, sofern man dem anderen Benutzer natürlich die entsprechenden Rechte zugestanden hat. Bisher (also mit der alten 49_Arlo) hat es ja auch so einwandfrei funktioniert ;-)

Zitat aus der API-DOku:

"for production scenarios involving systems integration, we recommend a separate service user account is created for API operations that isn't shared with anyone else."

Danke, das wusste ich nicht.
Bleibt zu hoffen, das Netgear nicht irgendwann den API-Zugriff auch kostenpflichtig macht

Zitat von: m0urs am 17 Dezember 2018, 10:12:42
Nicht ganz. Im Hintergrund wird schon die offizielle Arlo-API genutzt:

https://developer.arlo.co/

Hier muss ich mit einem Missverständnis aufräumen: arlo.co ist nicht arlo.com. Hier nutzt eine clevere Firma, die offensichtilch nichts mit Netgear zu tun hat, den Namen Arlo. Es gibt keine offizielle Arlo API. Man muss die REST-API zwischen Web Browser und Server analysieren, um die API nutzen zu können.

Gehen immer alle Devices verloren oder nur ein Teil davon? Und prüfe bitte, ob die xCloudIds der Arlo-Devices nach dem Autocreate anders sind als davor.

Zitat von: mi.ke am 16 Dezember 2018, 14:36:19
Allerdings hat es auch bei mir die DSL Zwangstrennung nicht "überlebt und ist "hängengeblieben"

Code Auswählen Erweitern

2018.12.16 03:04:11 3: Process Arlo event subscriptions/xxx-xxxxxxx_web for XXXXXXXXXXXXX
2018.12.16 09:32:43 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}

Die Trennung laut Router war um 03:04:15 Uhr. Passt also.
Mit einem "reconnect & updateReadings" an der Arlo_Cloud lief wieder alles.

Ich habe jetzt meine DOIF Überprüfung nach DSL-Zwangstrennung wieder reaktiviert, die wird den nächsten disconnect abfangen. Damit kann ich mehr als gut leben.

Diese DSL-Zwangstrennungen sind wirklich nervig  >:( Ich werde mir nochmal ansehen, wann das Modul aus dem Takt kommen kann. Ich hatte am Wochenende sogar meine Fritzbox neu gestartet und ich musste keinen manuellen Reconnect machen. Daher dachte ich eigentlich, dass auch das Thema DSL Zwangstrennung erledigt ist.

Zitat von: mi.ke am 16 Dezember 2018, 14:40:27
- Nicht alle Meldungen auf LOG3 sondern nur wirklich relevante. Auf verbose 2 kommen gar keine Meldungen mehr an. Auf verbose 3 spammt es die SD-Card.

Das Logging habe ich etwas angepasst. Gehe auf verbose 2, dann bekommst du nur noch Fehler und eine Meldung beim reconnect. Das regelmäßige Logging bei verbose 3 habe ich momentan noch absichtlich, damit man mitbekommt, dass der Heartbeat-Job läuft.

Zitat
- Die Attribute der einzelnen Subtype ACCOUNT,BASESTATION,CAMERA nur in den relevante Devices zur Auswahl stellen. Das macht es auch den "Neueinsteigern" vielleicht noch etwas leichter.

Das ist leider eine kleine Schwäche von FHEM (oder ich weiß es nicht besser): man kann Attribut-Listen nur auf Modul-Ebene setzen, nicht auf Device-Typ-Ebene.

Zitat von: Schniedie am 16 Dezember 2018, 15:26:05
vorab: ich bin beigeistert vom Modul! Sehr gute Arbeit.

Danke  :)

Zitat
Meine Arlo Lights und die Arlo Pro's laufen super. Ich habe noch eine ArloQ (Kabelgebunden). Beim Autocreate wird das Device sogar im Log genannt (Device Type = 'arloq'), es wird logischerweise kein Device angelegt.

Allerdings werden die Snapshots und Videodateien vom Modul empfangen und weggeschrieben.

Wie kann ich dabei unterstützen um die ArloQ einzubinden? Vieles scheint schon zu gehen.

Ich habe eine neue Version hochgeladen, die jetzt auch für ArloQ ein Kamera-Device anlegt. Ob das funktioniert, kann ich leider nicht versprechen. Bitte versuche mal die neue Version hochzuladen und führe dann reload 49_Arlo und danach set Arlo_Cloud autocreate aus. Das Device sollte dann angelegt sein. Danach bitte set Arlo_Cloud updateReadings aufrufen und prüfen, ob die Readings an der ArloQ gesetzt sind. Dann bitte noch die set-Aktionen an der Kamera ausführen.

Wenn es Probleme gibt, bitte nochmal melden.

Zitat von: maluk am 17 Dezember 2018, 19:58:28
Hier muss ich mit einem Missverständnis aufräumen: arlo.co ist nicht arlo.com. Hier nutzt eine clevere Firma, die offensichtilch nichts mit Netgear zu tun hat, den Namen Arlo. Es gibt keine offizielle Arlo API. Man muss die REST-API zwischen Web Browser und Server analysieren, um die API nutzen zu können.

Gehen immer alle Devices verloren oder nur ein Teil davon? Und prüfe bitte, ob die xCloudIds der Arlo-Devices nach dem Autocreate anders sind als davor.

Oops! Da bin ich ja ganz schön reingefallen :-( Ok, dann ist es natürlich weitaus schwieriger, wenn hier Dinge nicht so laufen, wie sie sollen.

Ich teste morgen mal, was mir so auffällt. Was ich sagen kann ist, das Einlesen der Modes und der Readings scheint immer noch zu funktionieren. Befehle an die Devices wie Arm, Disarm etc. laufen in den angegebenen Fehler.

Hab's doch noch schnell probiert:

ZitatUnd prüfe bitte, ob die xCloudIds der Arlo-Devices nach dem Autocreate anders sind als davor.

Nein, alle IDs sind nach dem Autocreate wieder gleich.

Zitat von: mi.ke am 16 Dezember 2018, 14:36:19
Allerdings hat es auch bei mir die DSL Zwangstrennung nicht "überlebt und ist "hängengeblieben"

Code Auswählen Erweitern

2018.12.16 03:04:11 3: Process Arlo event subscriptions/xxx-xxxxxxx_web for XXXXXXXXXXXXX
2018.12.16 09:32:43 2: Arlo call was not successful: {"data":{"error":"2059","message":"Device is offline.","reason":"Device is offline."},"success":false}

Die Trennung laut Router war um 03:04:15 Uhr. Passt also.
Mit einem "reconnect & updateReadings" an der Arlo_Cloud lief wieder alles.

Ich habe jetzt meine DOIF Überprüfung nach DSL-Zwangstrennung wieder reaktiviert, die wird den nächsten disconnect abfangen. Damit kann ich mehr als gut leben.

Ich habe jetzt Anpassungen gemacht, die hoffentlich dazu führen, dass das Modul auch die DSL-Zwangstrennung überlebt. Es war ja eines der großen Ziele der Neuimplementierung, die Stabilität zu verbessern, daher gebe ich hier auch nicht auf.

Könntest du mit der neusten Version nochmal ohne deine DOIF-Überprüfung testen?

Zitat von: maluk am 18 Dezember 2018, 12:20:12
Könntest du mit der neusten Version nochmal ohne deine DOIF-Überprüfung testen?

bin dabei . . .

Heute Nacht war im übrigen keine Trennung. Das DOIF hat auch nicht angeschlagen und im Log war auch kein Eintrag.
Einzige Änderung war, dass alle 15 min  eine updateReadings  gemacht wurrde.

Ich teste jetzt mal die letzte Version vom 18.12 ohne DOIF mit verbose 4

Zitat von: maluk am 17 Dezember 2018, 20:40:51
Ich habe eine neue Version hochgeladen, die jetzt auch für ArloQ ein Kamera-Device anlegt. Ob das funktioniert, kann ich leider nicht versprechen. Bitte versuche mal die neue Version hochzuladen und führe dann reload 49_Arlo und danach set Arlo_Cloud autocreate aus. Das Device sollte dann angelegt sein. Danach bitte set Arlo_Cloud updateReadings aufrufen und prüfen, ob die Readings an der ArloQ gesetzt sind. Dann bitte noch die set-Aktionen an der Kamera ausführen.

Wenn es Probleme gibt, bitte nochmal melden.

Hallo,

ich habe das neue Modul nun geladen. Es wird auch ein Device für die ArloQ angelegt, allerdings sind die Set-Befehle nicht vollständig und die vorhandenen funktionieren leider nicht.
Beispiel für "set XXX on" hier im Log;


2018.12.18 19:29:12 5: Body: {"action":"set","publishResponse":true,"to":null,"from":"_web","transId":"web!fbab61a64f03d043!1545157752473","resource":"cameras/4SV17CSP5831D","properties":{"privacyActive":true}}
2018.12.18 19:29:12 2: Arlo call was not successful: {"data":{"error":"2001","message":"The request's content is invalid.","reason":"The request's content is invalid.","errors":["Request method 'POST' not supported"]},"success":false}

Alle Set befehle (on, off, brightness, snapshot, recording) laufen in den Fehler.

Zusätzlich fehlen die Befehle wie "arm", "disarm" und "mode" - in der Bedienung ist die ArloQ ja eher wie ein Device vom Typ CAMERA, allerdings ohne übergeordnete Bridge.

Wenn ich mir im web-Frontend von Arlo den JSON ansehe, dann wird beim Parameter "to" das Device selbst angegeben, hier wars "null". Eventuell liegt hier das Problem?

LG

Zitat von: Schniedie am 18 Dezember 2018, 19:48:29
Alle Set befehle (on, off, brightness, snapshot, recording) laufen in den Fehler.

Zusätzlich fehlen die Befehle wie "arm", "disarm" und "mode" - in der Bedienung ist die ArloQ ja eher wie ein Device vom Typ CAMERA, allerdings ohne übergeordnete Bridge.

Wenn ich mir im web-Frontend von Arlo den JSON ansehe, dann wird beim Parameter "to" das Device selbst angegeben, hier wars "null". Eventuell liegt hier das Problem?

Das ist sicherlich das Problem. Bevor ich mein Modul anpasse, noch eine Frage ist in den Requests in der Web-Version unter "resource" "cameras/SERIENNR" angegeben oder steht da ein anderer Präfix als "cameras/"?

Hallo,

der Prefix ist auch ,,cameras/,, gewesen,

Gruß

Ich habe jetzt eine ganz einfache Änderung gemacht: für ArloQ-Devices wird ein Basestation-Device und ein Kamera-Device angelegt. Die Basestation hat den Namen der Kamera mit Suffix _Base. Lade bitte die aktualisierte Version herunter und versuche es nochmal.

Heute Nacht hatte wir hier einen DSL Ausfall, von daher nicht sehr aussagekräftig. Ist wieder hängengeblieben, aber erst morgens um 6:00 Uhr. Der Router trennt zwischen 3-4 Uhr.

Was mir aber aufgefallen ist, sind die DNS-Anfrage Fehler, die tagsüber so ausgetaucht sind.

2018.12.20 10:22:51 2: (Re)starting Arlo event listener.
2018.12.20 10:46:10 3: deletereading Arlo_EingangCAM streamUrl : Deleted reading streamUrl for device Arlo_EingangCAM
2018.12.20 10:53:35 2: Error in Arlo event queue: https://arlo.netgear.com/hmsweb/client/subscribe: Can't connect(1) to https://arlo.netgear.com:443: IO::Socket::INET: Bad hostname 'arlo.netgear.com:443'
2018.12.20 10:53:35 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 10:53:35 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 10:55:15 2: Error in Arlo event queue: https://arlo.netgear.com/hmsweb/client/subscribe: Can't connect(1) to https://arlo.netgear.com:443: IO::Socket::INET: Bad hostname 'arlo.netgear.com:443'
2018.12.20 10:56:55 2: Error in Arlo event queue: https://arlo.netgear.com/hmsweb/client/subscribe: Can't connect(1) to https://arlo.netgear.com:443: IO::Socket::INET: Bad hostname 'arlo.netgear.com:443'
2018.12.20 10:57:55 2: (Re)starting Arlo event listener.
2018.12.20 11:27:57 2: (Re)starting Arlo event listener.
2018.12.20 11:37:15 1: RMDIR: ./restoreDir/save/2018-12-17
2018.12.20 11:44:28 3: Set Arlo basestation mode to mode2
2018.12.20 11:58:00 2: (Re)starting Arlo event listener.
2018.12.20 12:28:02 2: (Re)starting Arlo event listener.
2018.12.20 12:58:05 2: (Re)starting Arlo event listener.
2018.12.20 13:28:08 2: (Re)starting Arlo event listener.
2018.12.20 13:58:10 2: (Re)starting Arlo event listener.
2018.12.20 14:09:29 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 14:09:29 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 14:10:59 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 14:10:59 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 14:28:13 2: (Re)starting Arlo event listener.
2018.12.20 14:58:15 2: (Re)starting Arlo event listener.
2018.12.20 15:28:19 2: (Re)starting Arlo event listener.
2018.12.20 15:52:11 2: (Re)starting Arlo event listener.
2018.12.20 16:04:15 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 16:04:15 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 16:22:14 2: (Re)starting Arlo event listener.
2018.12.20 16:52:18 2: (Re)starting Arlo event listener.
2018.12.20 17:20:47 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 17:20:47 2: Error occured when calling Arlo daemon: DNS 172.22.1.1 timed out
2018.12.20 17:22:21 2: (Re)starting Arlo event listener.
2018.12.20 17:52:29 2: (Re)starting Arlo event listener.

172.22.1.1 ist die Fritzbox

Zitat von: maluk am 18 Dezember 2018, 21:16:01
Ich habe jetzt eine ganz einfache Änderung gemacht: für ArloQ-Devices wird ein Basestation-Device und ein Kamera-Device angelegt. Die Basestation hat den Namen der Kamera mit Suffix _Base. Lade bitte die aktualisierte Version herunter und versuche es nochmal.

Hallo,

sorry, dass ich so spät antworte - habe vorher keine Zeit für einen Test gefunden.

Das mit der Base hat weitgehend funktioniert! Ich kann nun die ArloQ ansteuern und ein/aus schalten. Leider kann ich an der "Base" keinen Modus einstellen - wird daran liegen, dass es von Namespace ja keine Base ist. Aber das ist wohl eher was für später - die Themen mit den Verbindungsabbrüchen scheinen kritischer. Zudem verhält sich das ArloLights Device im Moment ja auch genauso.

Danke auf jeden fall - ich bin sehr zufrieden!

Zitat von: mi.ke am 17 Dezember 2018, 09:55:46
Melde Dich doch einfach mit einem anderen User als dem Hauptuser an der Website an.

Ich habe das nun mal getestet. Leider ist das eher unschön, denn mit anderen Usern kann ich zwar alles steuern, aber keine Konfigurationsänderungen vornehmen. Also z.B. einen Modus anpassen etc. Das ist nicht sehr praktisch.

Es wäre schon toll, wenn ich weiterhin einen Zweit-User für die Steuerung in FHEM verwenden könnte und den Hauptuser nur für mich selbst verwende.

@maluk: Falls Du ein wenig Zeit erübrigen könntest ;-) Ich stehe gerne auch wieder als Tester zur Verfügung, falls Du das Problem nicht nachstellen kannst.

Noch mal das Problem kurz zusammengefasst:

FHEM läuft mit einem Zweit-User, der aber in der Arlo-Weboberfläche alle Rechte für alle Devices erhalten hat und über die Weboberfläche auch alles steuern kann. Das funktioniert auch in FHEM nach dem Erstellen aller Devices solange einwandfrei, bis FHEM neu gestartet wird. Danach kommt die Meldung

2018.12.16 11:07:21 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"4RD3837TA2965 [color=red][b]doesn't belong to the User / Is not provisioned[/b][/color]"},"success":false}


wenn man einen Befehl in FHEM absetzt. Nachdem man alle Arlo-Devices in FHEM löscht und neu anlegt, funktioniert wieder alles bis zum nächste Neustart.

Ich hatte mir schon eine Prozedur angelegt, die beim Start automatisch alle Arlo-Devices löscht und neu anlegt. Damit scheint es auch erst mal zu gehen. Aber das ist halt ziemlich unschön.

Für mich sieht es so aus, als würde beim Recreate irgendein Webcall gemacht, der später nach einem Neustart nicht mehr passiert? Die Devices sehen nach einem Recreate eigentlich genauso aus wie vorher.

Zitat von: mi.ke am 20 Dezember 2018, 18:34:17
Heute Nacht hatte wir hier einen DSL Ausfall, von daher nicht sehr aussagekräftig. Ist wieder hängengeblieben, aber erst morgens um 6:00 Uhr. Der Router trennt zwischen 3-4 Uhr.

Was mir aber aufgefallen ist, sind die DNS-Anfrage Fehler, die tagsüber so ausgetaucht sind.

Hat sich das Modul nach Ende des DSL-Ausfalls wieder erholt oder musstest du neu starten? Sind danach nochmal irgendwelche Probleme aufgetreten?

Zitat von: Schniedie am 20 Dezember 2018, 19:19:44
Das mit der Base hat weitgehend funktioniert! Ich kann nun die ArloQ ansteuern und ein/aus schalten. Leider kann ich an der "Base" keinen Modus einstellen - wird daran liegen, dass es von Namespace ja keine Base ist. Aber das ist wohl eher was für später - die Themen mit den Verbindungsabbrüchen scheinen kritischer. Zudem verhält sich das ArloLights Device im Moment ja auch genauso.

Wie taucht deine ArloQ in der Web-Oberfläche von Arlo auf? Falls du dort die Modes steuern kannst, bitte mal den Netzwerk-Verkehr im Browser beim aktivieren eines Modes aufzeichnen und mir die Requests zukommen lassen. Ich dachte eigentlich, dass die ArloQ alle Möglichkeiten einer Basestation und Kamera vereint.

Zitat von: m0urs am 21 Dezember 2018, 08:20:42
FHEM läuft mit einem Zweit-User, der aber in der Arlo-Weboberfläche alle Rechte für alle Devices erhalten hat und über die Weboberfläche auch alles steuern kann. Das funktioniert auch in FHEM nach dem Erstellen aller Devices solange einwandfrei, bis FHEM neu gestartet wird. Danach kommt die Meldung

Code Auswählen Erweitern

2018.12.16 11:07:21 2: Arlo call was not successful: {"data":{"error":"AUTO-5010","message":"Device doesn't belong to the User","reason":"4RD3837TA2965 [color=red][b]doesn't belong to the User / Is not provisioned[/b][/color]"},"success":false}


wenn man einen Befehl in FHEM absetzt. Nachdem man alle Arlo-Devices in FHEM löscht und neu anlegt, funktioniert wieder alles bis zum nächste Neustart.

Könntest du mal FHEM neu starten und nur "set Arlo_Cloud autocreate" aufrufen? Es ergibt für mich keinen Sinn, dass alle Devices gelöscht werden müssen, wenn danach die Cloud-ID der Devices immer noch die gleiche ist. Außerdem könntest du mal testen, ob bei nach einem "set Arlo_Cloud reconnect" auch die obige Fehlermeldung kommt.

Zitat von: m0urs am 13 Dezember 2018, 19:28:38
Jetzt fehlen aus meiner Sicht nur noch folgende Dinge (ich weiss, ich kriege nicht genug :-)):

• Den Status der Lichter setzen , also sprich wenn man es einschaltet, dass der Status auf "An" geht und bei ausschalten auf "Aus".
• Die Frage: Wie bekommt man den Status "Zeitplan" bei den Bridges gesetzt, also, wie muss der Mode heissen?
• Ach ja, und vielleicht in Zukunft mal (das nutze ich noch nicht in FHEM), dass der Bewegungssensor in den Lichtern ebenfalls einen Event in FHEM erzeugt

Aber auf alle Fälle schon mal recht herzlichen Dank für dieses Modul und für die schnelle Umsetzung/Fehlerbeseitigung!

Update: Ach ja, den Battery-Lavel der Lichter wäre noch klasse :-)

Für deine Wünsche bräuchte ich nochmal deine Unterstützung: bitte das Cloud-Device auf verbose 5 stellen, damit die JSON-Antworten geloggt werden. Bitte danach UpdateReadings aufrufen, dann sollten auch JSON-Antworten für die Lights kommen. Diese bräuchte ich für die Implementierung des Lights-Status und -Battery-Level. Danach bitte eine Bewegung an einem Light auslösen und das JSON, das hier kommt, ebenfalls mir zusenden.

Beim Zeitplan weiß ich, was zu tun ist. Das gibt es auch bei normalen Basisstationen.

Zitat von: maluk am 22 Dezember 2018, 13:37:48
Wie taucht deine ArloQ in der Web-Oberfläche von Arlo auf? Falls du dort die Modes steuern kannst, bitte mal den Netzwerk-Verkehr im Browser beim aktivieren eines Modes aufzeichnen und mir die Requests zukommen lassen. Ich dachte eigentlich, dass die ArloQ alle Möglichkeiten einer Basestation und Kamera vereint.

Hallo,
ich glaube, genau das macht es auch, gibt für die ArloQ keine Basis in der Weboberfläche, aber arm/disarm geht direkt an der Kamera. Hier die Daten des POST Request für die ArloQ und die SecLights

ArloLights
Arm: {"activeAutomations":[{"deviceId":"59G1865G0126A","timestamp":1545490124709,"activeModes":["mode1"],"activeSchedules":[]}]}
Disarm: {"activeAutomations":[{"deviceId":"59G1865G0126A","timestamp":1545490178186,"activeModes":["mode0"],"activeSchedules":[]}]}
Zeitplan: {"activeAutomations":[{"deviceId":"59G1865G0126A","timestamp":1545490214389,"activeModes":[],"activeSchedules":["schedule.1"]}]}


ArloQ

Arm: {"from":"HWUZWY65-183-31466969_web","to":"4SV17CSP5831D","action":"set","resource":"modes","transId":"web!85f17d8e.7b74d!1545490295577","publishResponse":true,"properties":{"active":"mode1"}}
Disarm: {"from":"HWUZWY65-183-31466969_web","to":"4SV17CSP5831D","action":"set","resource":"modes","transId":"web!bb23cd9c.8580b8!1545490270156","publishResponse":true,"properties":{"active":"mode0"}}
Zeitplan:{"from":"HWUZWY65-183-31466969_web","to":"4SV17CSP5831D","action":"set","resource":"schedule","transId":"web!c6ee67c8.ce5878!1545490241929","publishResponse":true,"properties":{"active":true}}

Hilft das?

Zitat von: maluk am 22 Dezember 2018, 13:34:49
Hat sich das Modul nach Ende des DSL-Ausfalls wieder erholt oder musstest du neu starten? Sind danach nochmal irgendwelche Probleme aufgetreten?

Ich bin mir ehrlich gesagt nicht sicher.

Gefühlt ist es folgendermaßen:
Das Modul verhällt sich, als hätte es sich erhohlt.
Die Basisstationen wechseln z.B. auf Anforderung durch fhem den Mode.

Allerdings werden keinerlei Readings mehr aktuallisiert. Weder bei den Kameras noch bei den Bases.
In LOG wird das Modul angeblich neu gestartet "(Re)starting Arlo event listener."

Alle Funktionen sind eigentlich erst wieder da, wenn am SUBTYPE ACCOUNT ein reconnect und updateReadinigs gemacht wird.

Jetzt hatte ich mal testweise (obwohl ja eigentlich nicht richtig) am SUBTYPE BASESTATION ein updateInterval analog zum SUBTYPE ACCOUNT eingestellt.
Seitdem keine Aussetzer mehr.

Leider hab ich im Moment nicht so viel Zeit am Stück zur Verfügung (Weihnachtsvorbereitungen), deshalb kann ich immer nur mal schnell zwischendurch was machen.

Ich würde vorschlagen wir sammeln noch ein paar Fakten.
Dazu die vermutlich wichtigste Frage . . .

@all
Bin ich der Einzige, der noch Probleme mit den reconnects hat?

Zitat von: mi.ke am 22 Dezember 2018, 16:34:59
Allerdings werden keinerlei Readings mehr aktuallisiert. Weder bei den Kameras noch bei den Bases.
In LOG wird das Modul angeblich neu gestartet "(Re)starting Arlo event listener."

Alle Funktionen sind eigentlich erst wieder da, wenn am SUBTYPE ACCOUNT ein reconnect und updateReadinigs gemacht wird.

Jetzt hatte ich mal testweise (obwohl ja eigentlich nicht richtig) am SUBTYPE BASESTATION ein updateInterval analog zum SUBTYPE ACCOUNT eingestellt.
Seitdem keine Aussetzer mehr.

Das war ein Bug, den habe ich gerade behoben habe. Das updateInterval an der Basestation kannst du löschen, das hat keine Auswirkung auf die Funktionsweise des Moduls.

Zitat von: Schniedie am 22 Dezember 2018, 15:53:51
ich glaube, genau das macht es auch, gibt für die ArloQ keine Basis in der Weboberfläche, aber arm/disarm geht direkt an der Kamera.

Ich habe gerade eine neue Version hochgeladen. Bitte lösche die Basestation- und Camera-Devices für deine ArloQ und führe danach ein set Arlo_Cloud autocreate aus. Danach sollte es ein neues ArloQ-Device geben, das neben den Kamera-Aktionen auch arm, disarm, subscribe und unsubscribe anbietet. Versuche mal, ob damit alles klappt.

Zitat von: maluk am 22 Dezember 2018, 13:45:34
Könntest du mal FHEM neu starten und nur "set Arlo_Cloud autocreate" aufrufen? Es ergibt für mich keinen Sinn, dass alle Devices gelöscht werden müssen, wenn danach die Cloud-ID der Devices immer noch die gleiche ist. Außerdem könntest du mal testen, ob bei nach einem "set Arlo_Cloud reconnect" auch die obige Fehlermeldung kommt.

Also, ein Autocreate nach dem Neustart reicht aus. Danach lassen sich wieder Arm/Disarm-Befehle korrekt absetzen und diese werden auch korrekt umgesetzt. Die xCloudId ändert sich aber nach einem Autocreate nicht. Ich schicke Dir gleich ausführlichere Logs per PN.

Zitat von: maluk am 22 Dezember 2018, 14:15:58
Für deine Wünsche bräuchte ich nochmal deine Unterstützung: bitte das Cloud-Device auf verbose 5 stellen, damit die JSON-Antworten geloggt werden. Bitte danach UpdateReadings aufrufen, dann sollten auch JSON-Antworten für die Lights kommen. Diese bräuchte ich für die Implementierung des Lights-Status und -Battery-Level. Danach bitte eine Bewegung an einem Light auslösen und das JSON, das hier kommt, ebenfalls mir zusenden.

Beim Zeitplan weiß ich, was zu tun ist. Das gibt es auch bei normalen Basisstationen.

Die Logs sind per PN an Dich versandt!

Zitat von: mi.ke am 22 Dezember 2018, 16:34:59

Allerdings werden keinerlei Readings mehr aktuallisiert. Weder bei den Kameras noch bei den Bases.
In LOG wird das Modul angeblich neu gestartet "(Re)starting Arlo event listener."

Zitat von: maluk am 23 Dezember 2018, 12:02:17
Das war ein Bug, den habe ich gerade behoben habe. Das updateInterval an der Basestation kannst du löschen, das hat keine Auswirkung auf die Funktionsweise des Moduls.

Das sieh mal richtig gut aus.

Mal schauen wie stabil es sich nach der DSL-Zwangstrennung verhält. Einen Neustart des Routers hat es schon überstanden  8)

Zitat von: m0urs am 23 Dezember 2018, 13:20:04
Also, ein Autocreate nach dem Neustart reicht aus. Danach lassen sich wieder Arm/Disarm-Befehle korrekt absetzen und diese werden auch korrekt umgesetzt. Die xCloudId ändert sich aber nach einem Autocreate nicht. Ich schicke Dir gleich ausführlichere Logs per PN.

Ich habe eine neue Version hochgeladen, die immer nach dem Einloggen alle Device liest (also das, was Autocreate auch tut). Damit solltest du jetzt keine Probleme mehr haben, wenn du dich mit deinem Neben-Account in FHEM anmeldest.

Zitat von: maluk am 23 Dezember 2018, 16:55:07
Ich habe eine neue Version hochgeladen, die immer nach dem Einloggen alle Device liest (also das, was Autocreate auch tut). Damit solltest du jetzt keine Probleme mehr haben, wenn du dich mit deinem Neben-Account in FHEM anmeldest.

Vielen Dank, ein erster schneller Test scheint das zu bestätigen! Was auch immer hier im Hintergrund anders läuft! Die Test wegen der Lichter versuche ich morgen noch hinzukriegen!

Ein Problem, von dem ich schon mal berichtet hatte, besteht aber immer noch:

Wenn in einem Modus der Base-Station ein Arlo Light enthalten ist, welches in dem Modus auch geschaltet werden soll, dann wird das Schalten in diesen Modus nicht ausgeführt. Nimmt man das Licht aus dem Mode heraus, dann geht es wieder. Im FHEM-Log kommt auch mit Verbose=5 kein Eintrag beim "Set ...mode=". Was bräuchtest Du an weiteren Informationen?

Zitat von: maluk am 14 Dezember 2018, 16:33:51
Ich habe selbst keine Babycam, daher benötige ich deine Unterstützung. Gehe auf https://arlo.netgear.com und melde dich dort an. Gehe zu deiner Kamera und aktiviere die Entwickler-Tools in deinem Browser (F12) und schneide den Netzwerkverkehr mit. Wenn du Licht und Musik ein- und ausschaltest, müssten POST-Requests erzeugt werden. Hier benötige ich die URLs die aufgerufen werden und die Parameter, die per POST an den Server übertragen werden. Dann kann ich die Funktionen in mein Modul übernehmen.

Kannst du mir das bitte nochmal erklären, mit dem HTTP Traffic mithorchen?
Verwende Chrome und das Entwicklertool hab ich offen. Weiß dann aber nicht was ich weiter machen soll und in welchem Menü.

Danke!

Im Register Network wird der Netzwerk-Traffic protokolliert. Dort kannst du den Filter auf XHR setzen, damit nur die REST-Aufrufe angezeigt werden. Relevant sind die Aufrufe, die im Headers-Tab als Request Method POST stehen haben. Ich benötige die Request URL und den Request Payload (alles im Tab Headers neben dem angeklickten Request, Beispiel-Screenshot siehe Anhang).

Modus kann ich nicht umstellen! Gibts da noch einen Bug?
LG

Bei welchem Device funktioniert das Setzen des Modus nicht? Bei Basisstationen funktioniert das eigentlich ohne Probleme.

Ich habe eine neue Version hochgeladen. Folgende neue Funktionen sind enthalten:

• Bei Kameras und Lights gibt es jetzt ein neues Reading motionDetected, das auf 1 gesetzt wird, wenn Bewegung erkannt wird.
• Für Lights werden jetzt die Readings state (Licht an/aus), batteryLevel, activityState und chargingState gesetzt.
• Bei Kameras gibt es eine neue Funktion "get readings". Als Parameter muss ein Datum im Format JJJJMMTT (also z.B. 20181227 für den 27.12.2018) übergeben werden. Die Funktion liefert alle Aufnahmen des Tages für die Kamera im JSON-Format zurück. Falls die Antwort FHEM-intern verwendet werden soll, kann sie mit decode_json wieder in ein PERL-Array umgewandelt werden.

Zitat von: maluk am 27 Dezember 2018, 10:09:59
Ich habe eine neue Version hochgeladen. Folgende neue Funktionen sind enthalten

Danke Dir, dazu auch gleich Fragen:

Zitat von: maluk am 27 Dezember 2018, 10:09:59

• Bei Kameras und Lights gibt es jetzt ein neues Reading motionDetected, das auf 1 gesetzt wird, wenn Bewegung erkannt wird.

Was ist dabei der Unterschied zu activityState ?

Zitat von: maluk am 27 Dezember 2018, 10:09:59

• Bei Kameras gibt es eine neue Funktion "get readings". Als Parameter muss ein Datum im Format JJJJMMTT (also z.B. 20181227 für den 27.12.2018) übergeben werden. Die Funktion liefert alle Aufnahmen des Tages für die Kamera im JSON-Format zurück. Falls die Antwort FHEM-intern verwendet werden soll, kann sie mit decode_json wieder in ein PERL-Array umgewandelt werden.

Gibt mit doch bitte mal nen Tipp:
Was kann man den mit der Info in JSON-Format anfangen?
Ich sehe als PopUp nur einen langen String mit hohem Lesewiderstand.

Grüße

mi.ke

Du kannst in einer eigenen Methode z.B. die Video-URLs auslesen. Hier ein Beispiel:

sub Recording() {
  my $json = fhem("get Arlo_Kamera_Name recordings 20181227");
  my @recordings = @{decode_json($json)};
  foreach my $rec(@recordings) {
    Log 3, "Video $rec->{video}";
  }
}


Zusätzlich zu video gibt es noch die Felder thumbnail und time.

Vorteil einer JSON-Antwort ist, dass man sie direkt in JavaScript verarbeiten kann. Wenn du z.B. die Arlo-Kamera in Tablet UI eingebunden hast, kannst du dir die Recordings für einen Tag holen und die Antwort in JavaScript auswerten.

Hab eine alte Basisstation, da klappt das mit der Mode Umstellung nicht.

Gelöst: hatte eine alte .pm!

Funktioniert jetzt prächtig!

Das mit dem get Record schaff ich auch nicht :-(
Hab zwar jetzt das Sub in 99_myUtils.pm drinnen, aber wie schaffe ich es jetzt die einzelnen Videos als Readings zu der Kamera hinzu zufügen. Das ist zwar wahrscheinlich eine Frage fürs Anfänger-Forum aber ich hoffe, Ihr helft trotzdem!

Zitat von: mi.ke am 27 Dezember 2018, 10:54:18
Was ist dabei der Unterschied zu activityState ?

Die Frage hatte ich noch nicht beantwortet: motionDetected reagiert etwas schneller. activityState zeigt an, ob gerade aufgenommen wird, motionDetected ist nur für die Bewegungserkennung.

Zitat von: m0urs am 23 Dezember 2018, 20:44:37
Ein Problem, von dem ich schon mal berichtet hatte, besteht aber immer noch:

Wenn in einem Modus der Base-Station ein Arlo Light enthalten ist, welches in dem Modus auch geschaltet werden soll, dann wird das Schalten in diesen Modus nicht ausgeführt. Nimmt man das Licht aus dem Mode heraus, dann geht es wieder. Im FHEM-Log kommt auch mit Verbose=5 kein Eintrag beim "Set ...mode=". Was bräuchtest Du an weiteren Informationen?

Das scheint mir der letzten Version nun auch zu funktionieren!

Hallo maluk,

Ich bin nun auch definitiv vom Python auf die neue Version umgestiegen und es gefällt mir sehr gut! Gratuliere zu diesem Wurf.

V.a. das Event motionDetected 1 gefäält. Gepaart mit sslPollingIntervall reagiert es nun super toll. Mal schauen ob dadurch die Performance leidet.

- lastVideoImageUrl: geht bei mir nicht mehr. Bei motion werden keine aktuellen Files mehr abgelegt. Das ist schade, da ich mir diese immer per Pushover bei motion geschickt habe. Warum ist das nicht mehr drin? Wenn ich set Arlo_Wohnzimmer snapshot mache, dann wird das File korrekt abgelegt.

Danke für die Antwort. Schönen Sonntag
Lg c

EDIT 30.12.: Mir ist noch grad aufgefallen, dass ich neu das Reading "Brightness"  habe, welches jedoch immer den Wert 0 ausweist... Entweder kann das meine ArloPro2 nicht oder dann ist was am Uebermitteln falsch. In der Arlo App hab ich den Wert auch nicht. Kann man evtl. dieses Reading ausschliessen?

Bei mir werden zuverlässig die Videos heruntergeladen, daher muss bei dir irgendwo ein Konfigurationsfehler das Problem verursachen. Prüfe bitte folgendes:

• Tauchen im Logfile nach der Bewegungserkennung irgendwann Einträge "Process Arlo event mediaUploadNotification" auf? Falls nicht, werden vermutlich bei arm oder in den Modes keine Videos für die Kameras aufgenommen.
• Hast du die Attribute downloadDir und downloadLink am Arlo_Cloud Device gesetzt? Ohne downloadDir werden die Videos nicht heruntergeladen.

Zitat von: maluk am 30 Dezember 2018, 19:58:32

• Tauchen im Logfile nach der Bewegungserkennung irgendwann Einträge "Process Arlo event mediaUploadNotification" auf? Falls nicht, werden vermutlich bei arm oder in den Modes keine Videos für die Kameras aufgenommen.
• Hast du die Attribute downloadDir und downloadLink am Arlo_Cloud Device gesetzt? Ohne downloadDir werden die Videos nicht heruntergeladen.

Hallo maluk

Danke für die Antwort.

Ich habe im Log die mediaUploadNotification und auch die DowloadDir resp DownloadLink gesetzt. Es klappt auch hie und da, wie soeben. Aber sehr unzuverlässig.

Geht es bei dir immer?

Lg c

Edit: Ich hab dir das Log per PN geschickt. Weiss nicht, wie heikel die CAM-Angaben sind ;)

Es geht - wie gesagt - sehr unzuverlässig. Mal hinterlegt es ein File, mal nicht...

Besteht irgendwie wie Möglichkeit , dem SUBTYPE ACCOUNT ein disable Readings mitzugeben?
Also das nicht immer Initialized angezeigt wird, sondern wenn disable= 1 dann Disabled

Ich es mit

userReadings showState {AttrVal("Arlo_Cloud","disable",0)}

versucht, aber es lässt sich irgendwie gar kein Reading erzeugen.

Habt Ihr einen Tipp?

Guten Rutsch ins neue Jahr !!!
mi.ke

Zitat von: mi.ke am 31 Dezember 2018, 14:55:10
Habt Ihr einen Tipp?

hast du es schon mit einem Notify oder DOIF versucht, welcher auf den Event..

2018-12-31 15:41:02 Global global ATTR Arlo_Cloud disable 1

..triggert. So könntest du dann ein "setstate Arlo_Cloud Disabled" als Befehl einbauen.

Habs nicht probiert, aber evtl. ein Workaround.

lg c

Zitat von: mi.ke am 31 Dezember 2018, 14:55:10
Besteht irgendwie wie Möglichkeit , dem SUBTYPE ACCOUNT ein disable Readings mitzugeben?
Also das nicht immer Initialized angezeigt wird, sondern wenn disable= 1 dann Disabled

Ich es mit

Code Auswählen Erweitern

userReadings showState {AttrVal("Arlo_Cloud","disable",0)}

versucht, aber es lässt sich irgendwie gar kein Reading erzeugen.

Ich werde das in der nächsten Version beheben.

Das mit dem state habe ich korrigiert, außerdem enthält die neue Version noch die Unterstützung für die BabyCam (Danke dinkel75 für den temporären Zugang). Die Anpassungen sollten sich auch positiv auf ArloQ auswirken, vermutlich hat dort das Aktivieren und Deaktivieren der Bewegungserkennung auch nicht funktioniert.

Es kommen noch keine Readings (Stream Url ist bei den Internen Readings, jpg und mpg kommen gar nicht) beim Aufnehmen.
Sonst supi!

Hallo!
Bei mir gleiches Problem wie bei dinkel75. Streaming URL wird im Reading angezeigt/erstellt aber Video nicht abgespeichert.
Snapshot URL Reading wird nicht erstellt und JPG nicht abgespeichert.

Ansonsten funktioniert es tadellos.

Gruß,
AnDiBaCkE

Guten Morgen!

erstmal vielen Dank für die Entwicklung von dem tollen Modul.
Eine meiner drei Kameras (Arlo Pro 2) wurde getauscht und hat demnach eine andere Seriennummer bei gleicher Bezeichnung. Leider findet das Modul nur die alte Kamera (alte Seriennummer) und aktualisiert demnach auch die Readings nicht.

Hat jemand einen Tipp in welche Richtung ich suchen muss um ihr die richtige Kamera beizubringen!?

Dank und Gruß,
Michael

Zitat von: mike.d am 10 Januar 2019, 07:45:45
Guten Morgen!

erstmal vielen Dank für die Entwicklung von dem tollen Modul.
Eine meiner drei Kameras (Arlo Pro 2) wurde getauscht und hat demnach eine andere Seriennummer bei gleicher Bezeichnung. Leider findet das Modul nur die alte Kamera (alte Seriennummer) und aktualisiert demnach auch die Readings nicht.

Hat jemand einen Tipp in welche Richtung ich suchen muss um ihr die richtige Kamera beizubringen!?

Dank und Gruß,
Michael

ich hatte das selbe Problem. Ich konnte es nur mit "Unbenennen" der neuen Cams (ArloPro2) beheben.

habe ich auch schon versucht - er legt dennoch die alte Kamera an. Die neue wird trotz anderem Namen nicht angelegt.... !?

edit: stimmt nicht, jetzt ist doch die neue Kamera mit neuem Namen aufgetaucht (Sonderzeichen gefallen ihm wohl nicht), aber der status bleibt dennoch auf initialized

hallo,
ich habe bei jedem "shutdown restart" folgendes im Log:

Error occured when calling Arlo daemon: connect to https://arlo.netgear.com:443 timed out

Und zwar 2mal...

Habt ihr das auch?

Zitat von: AnDiBaCkE am 08 Januar 2019, 20:32:50
Bei mir gleiches Problem wie bei dinkel75. Streaming URL wird im Reading angezeigt/erstellt aber Video nicht abgespeichert.
Snapshot URL Reading wird nicht erstellt und JPG nicht abgespeichert.

Das Verzeichnis, in das die Videos geschrieben werden sollen, muss am Cloud-Device (also das Device mit Subtype ACCOUNT) im Attribut downloadDir gesetzt werden. Der Linux-User fhem benötigt Schreibrechte für das Verzeichnis. Gibt es im Logfile irgendwelche Fehlermeldungen? Bei mir funktioniert das Schreiben der Video ohne Probleme.

Ich glaub, das schreiben der Videos betrifft die Arlo Q und Babycam.
Bei meinen Arlo Pro 2 funktioniert die Sache mit den Videos.

Das Problem scheint bei der Babycam immer aufzutreten, nachdem man sich über die Web-Oberfläche von Arlo oder der App anmeldet. Ich kann zwar danach noch Videos aufnehmen, aber der Arlo-Server sendet keine mediaUploadEvents dafür zurück. Leider fällt mir momentan auch nichts dazu ein, wie man das Problem sauber beheben kann.

Ein Workaround ist ein set Arlo_Cloud reconnect, nachdem man sich über Arlo-Web oder -App angemeldet hat. Schön ist das aber natürlich nicht ..

Hallo maluk,

ZitatDas Verzeichnis, in das die Videos geschrieben werden sollen, muss am Cloud-Device (also das Device mit Subtype ACCOUNT) im Attribut downloadDir gesetzt werden. Der Linux-User fhem benötigt Schreibrechte für das Verzeichnis. Gibt es im Logfile irgendwelche Fehlermeldungen? Bei mir funktioniert das Schreiben der Video ohne Probleme.

Ja downloadDir ist beim Cloud device gesetzt und fhem Rechte im Speicherordner sind 777.

Im Logfile finde ich folgendes:
2019.01.13 20:11:56 5 : data: {"resource":"cameras/48B45A74ED9B7","action":"is","error":{"code":4006,"message":"Invalid camera activity state change.: From fullFrameSnapshot to startUserStream"},"properties":{"activityState":"startUserStream","camera":"48B45A74ED9B7","streamURL":"rtsp://vzwow76-z1-prod.ar.arlo.com:443/xxx/48B45A74ED9B7_1547406715335?ingressToken=XXX

und

2019.01.13 20:11:59 2 : Arlo call was not successful: {"data":{"error":"2503","message":"The device failed to connect. Try again.","reason":"Camera is not streaming"},"success":false}

und

2019.01.13 20:38:09 2 : Error occured when calling Arlo daemon: read from https://arlo.netgear.com:443 timed out

Hast du eine Idee?
Ich habe die Einstellungen zum Phyton Modul eigentlich nicht geändert. Dort hatte alles funktioniert.
Bei mir betrifft es Arlo Pro und Arlo Pro2 Kameras. Andere Geräte habe ich nicht im Einsatz.

Vielen Dank!

Gruß,
AnDiBaCkE

@maluk

Vielleicht wäre es eine Lösung, wenn man den Videozähler als Ping nimmt und so das neue Video runterlädt. Der zählt zwar nur die Alarm-Aufnahmen und nicht die Manuellen, aber wäre zumindest schon ein Anfang.

Ciao

Zitat von: AnDiBaCkE am 08 Januar 2019, 20:32:50
Bei mir gleiches Problem wie bei dinkel75. Streaming URL wird im Reading angezeigt/erstellt aber Video nicht abgespeichert.
Snapshot URL Reading wird nicht erstellt und JPG nicht abgespeichert.

Hatte das Problem auch nach der Umstellung auf das neue Modul. Habe gerade die alten Files, die das alte Modul erzeugt hatte gelöscht (im DownloadDir) und nun läuft alles.

LG

Hallo Schniedie,

danke für den Tipp.

ZitatHatte das Problem auch nach der Umstellung auf das neue Modul. Habe gerade die alten Files, die das alte Modul erzeugt hatte gelöscht (im DownloadDir) und nun läuft alles.

Habe ich ausprobiert, jedoch ohne Erfolg.
Was mir jedoch aufgefallen ist, ist das es jetzt bei zwei der vier Kameras funktioniert. Es ist kein Muster zu erkennen. Danach habe ich mal die nicht funktionierenden Kameras gelöscht und per autocreate wieder geholt aber wieder ohne Erfolg  :'(

Woran kann das liegen?

Vielen Dank!

Gruß,
AnDiBaCkE

@maluk

Mir ist gerade folgendes aufgefallen:

Bei einer der Kameras ging der Akku zur Neige.
Also, Akkus raus und geladen.
In der arloAPP/webPortal wird die Kamera nach einiger Zeit als "Arlo Gerät ist offline" angezeigt.
So weit so wie erwartet.

Das Modul reagiert allerdings überhaupt nicht auf den "Offline"-Status. Das bedeutet, dass man noch nicht einmal mitbekommt, wenn jemand die Kamera manipuliert/stiehlt oder sonst ein Fehler vorliegt.

Besteht die Möglichkeit diesen Offline-Status (spätestens) bei dem regelmäßigen ReRead (updateInterval) abzufragen und anhand dessen ein Reading zu füttern (ggf. state) ?

Cheers
mi.ke

Hast Du vielleicht einen Umlaut im Kameranamen? Das war mal bei mir ein Problem. Hat den autocreate verhindert.

Hallo eddy242,

ZitatHast Du vielleicht einen Umlaut im Kameranamen? Das war mal bei mir ein Problem. Hat den autocreate verhindert.

Nein sind keine Umlaute drin. Das autocreate hat ja auch funktioniert, nur die Snapshot URL wurden nicht angelegt und somit auch nicht gespeichert.

Mittlerweile habe ich jedoch bei jeder Kamera mal eine URL im Reading. Es scheint also grundsätzlich zu funktionieren aber wahrscheinlich nicht zuverlässig.

Gruß,
AnDiBaCkE

@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,
Ich nutze jetzt auch das neue Modul. Soweit funktioniert alles.
Ich nutze den Modus Geofencing, der Modus wird aber in Fhem nicht Angezeigt.
Auch set readModes brachte keinen Erfolg oder habe ich das falsch interpretiert?
Wäre es auch möglich den Status der Geofencing zu erhalten, ich bekomme doch eine Pushnachricht wenn die Geräte außerhalb des Bereiches sind. Somit könnten wiederum Aktionen in Fhem ausgeführt werden.

Auch mein Dank für das tolle Modul.

Der Geofencing-Modus ist eine Funktion, die nur in der App zur Verfügung steht. Wenn ich es richtig verstanden habe, steuert die App dann den Mode.  Also z.B. beim Verlassen des Geofence wird der "arm"-Modus gesetzt, beim Eintreten in den Geofence der "disarm"-Modus. Das Modul müsste dann eigentlich mitbekommen, wenn der Modus von außen (also von der App) geändert wird. Ein aktives Setzen des Geofence-Modus über FHEM ist aber nicht möglich, da ich nur die Funktionen aufrufen kann, die man auch im Web-Modus von Arlo aufrufen kann, und dort ist Geofencing gesperrt.

Kurzer Hinweis an alle: seit heute ist das Modul Bestandteil der FHEM-Installation und wird automatisch mit update all aktualisiert. Gegenüber der letzten Download-Version habe ich das Verhalten bei Netzwerk-Problemen weiter optimiert. Ich hatte in letzter Zeit häufig das Problem, das meine FritzBox sich automatisch neu startet. Mit der neuen Version "überlebt" das Modul auch solche vollständigen Netzwerk-Ausfälle über mehrere Minuten.

Vielleicht erledigt sich dadurch auch ein Teil Eurer Probleme, manuelle reconnects sollten jetzt eigentlich nicht mehr notwendig sein. Falls weiterhin Probleme bestehen, dass nicht alle Events übertragen werden, bitte mal versuchen, das  pingInterval an Arlo_Cloud auf 60 oder 30 Sekunden zu reduzieren.

Hey maluk,
Danke, genial! Läuft auch soweit gut. Doch seit dem Update All habe ich folgende Fehlermeldung

t Mar  9 19:26:31 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 615.
[Sat Mar  9 20:26:31 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 615.
[Sat Mar  9 21:26:31 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 615.
[Sat Mar  9 22:26:31 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 615

Die Zeile 615 beinhaltet:
  if ($hash->{basestationSerialNumber} eq $hash->{serialNumber}) {

Irgendwas mit der Serialnumber?

Lg c

Hi choetzu,

sehr seltsam, an der Stelle hat sich gar nichts geändert. Hast du nach dem Update FHEM neugestartet? Mache auf jeden Fall mal einen set Arlo_Cloud reconnect und beobachte, ob der Fehler dann weiterhin auftritt.

Gruß
maluk

Hi maluk,

ich hatte die "offizielle" Version installiert und bin wieder zurück auf die Version von 2.01.

Mit der neuen Version hatte das Modul Probleme mit der Modus-Umschaltung.
Leider konnte ich im Moment nicht richtig testen, weil ich z.Z. nur noch das Also-Produktiv-SYstem am Start habe.

Mit der "alten" Version wieder alles ohne Probleme.

cheers
Mike

Hi Mike,

könntest du den Fehler etwas weiter eingrenzen?  Geht es um die benutzerdefinierten Modes und betrifft es alle deine Basisstationen oder nur eine? Hattest du FHEM nach dem Update neu gestartet? Funktioniert es, wenn du vorher updateReadings manuell aufrufst? Wenn alles nichts hilft, bitte manuell reconnect aufrufen.

Ich bin etwas verwundert wegen des Fehlers, weil ich an der Stelle eigentlich nur eine Prüfung eingebaut habe, dass in der Response von updateReadings die Modes nicht gelesen werden, wenn sie in der Response fehlen. Das hatte bei mir mal zu einem Absturz von FHEM geführt. Bei mir funktioniert das Setzen von Modes ohne Probleme.

Gruß
maluk

Zitat von: maluk am 10 März 2019, 12:53:26
Hi choetzu,

sehr seltsam, an der Stelle hat sich gar nichts geändert. Hast du nach dem Update FHEM neugestartet? Mache auf jeden Fall mal einen set Arlo_Cloud reconnect und beobachte, ob der Fehler dann weiterhin auftritt.

Gruß
maluk

Hallo maluk
jep, neu gestartet. Und heute erneut ein Update gemacht.  Hat leider nix gebracht. Immer noch die selbe Zeile. In der neuen 49_Arlo.pm Datei ist es offensichtlich nun bei Zeile 611 (selber Inhalt "if ($hash->{basestationSerialNumber} eq $hash->{serialNumber}) {")

[Mon Mar 11 21:11:18 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 611.
[Mon Mar 11 22:11:18 2019] fhem.pl: Use of uninitialized value in string eq at ./FHEM/49_Arlo.pm line 611.

woran könnte das liegen?
lg c

Versuche mal die Zeile wie folgt zu ändern:

  if (defined($hash->{basestationSerialNumber}) && $hash->{basestationSerialNumber} eq $hash->{serialNumber}) {

Danach "reload 49_Arlo" ausführen und nochmal versuchen. Falls das hilft, werde ich das Modul entsprechend anpassen.

Die Zeile ist seit dem 02.01. so im Code. Eventuell hattest du noch eine ältere Version im Einsatz.

Zitat von: maluk am 10 März 2019, 17:26:21
könntest du den Fehler etwas weiter eingrenzen?  Geht es um die benutzerdefinierten Modes und betrifft es alle deine Basisstationen oder nur eine? Hattest du FHEM nach dem Update neu gestartet? Funktioniert es, wenn du vorher updateReadings manuell aufrufst? Wenn alles nichts hilft, bitte manuell reconnect aufrufen.

Mach ich am Wochenende und werde berichten

Dank Dir

Cheers

mi.ke

Zitat von: maluk am 12 März 2019, 20:07:13
Versuche mal die Zeile wie folgt zu ändern:

Code Auswählen Erweitern

  if (defined($hash->{basestationSerialNumber}) && $hash->{basestationSerialNumber} eq $hash->{serialNumber}) {

Danach "reload 49_Arlo" ausführen und nochmal versuchen. Falls das hilft, werde ich das Modul entsprechend anpassen.

Die Zeile ist seit dem 02.01. so im Code. Eventuell hattest du noch eine ältere Version im Einsatz.

genau das wars. Nach dem Ändern der Zeile kam die Meldung nicht mehr. Wenn ich jedoch nun update all mache, dann wird das Modul wieder überspielt. Ich möchte eigentlich das Modul nicht beim Update ausschliessen. Was spricht dagegen, die Zeile standartmässig reinzunehmen?

lg c

Ich habe die Änderung gerade eingecheckt, ab morgen kommt sie bei update all mit. Es ist immer wieder erstaunlich, dass derselbe Code auf einem Rechner läuft und auf dem anderen nicht. Nur interessehalber: welche Perl-Version ist bei die installiert (perl -v aufrufen)?

@mi.ke: evtl. hattest du dasselbe Problem. Der Fehler kann unter Umständen das lesen der benutzerdefinierten Modes verhindert haben.

Zitat von: maluk am 13 März 2019, 19:16:00
Ich habe die Änderung gerade eingecheckt, ab morgen kommt sie bei update all mit. Es ist immer wieder erstaunlich, dass derselbe Code auf einem Rechner läuft und auf dem anderen nicht. Nur interessehalber: welche Perl-Version ist bei die installiert (perl -v aufrufen)?

Super, danke.

Ich habe This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 85 registered patches, see perl -V for more detail)

Offensichtlich nicht die neuste... 5.28 wäre die neuste. Liegt es daran?

Ich habe die gleiche Perl-Version, also kein Grund, etwas zu ändern. Manchmal gibt es einfach so seltsame Unterschiede. Hauptsache es läuft jetzt  :)

Zitat von: maluk am 13 März 2019, 19:16:00
Ich habe die Änderung gerade eingecheckt, ab morgen kommt sie bei update all mit. Es ist immer wieder erstaunlich, dass derselbe Code auf einem Rechner läuft und auf dem anderen nicht. Nur interessehalber: welche Perl-Version ist bei die installiert (perl -v aufrufen)?

@mi.ke: evtl. hattest du dasselbe Problem. Der Fehler kann unter Umständen das lesen der benutzerdefinierten Modes verhindert haben.

Arlo läuft bei mir produktiv seit Beginn auf einem RPi0W mit Perl v5.20.2.
Bei der v5.24.1 (läuft auf dem Hauptrechner) hab ich das Problem, dass mit der Zeit der Speicher voll läuft. Das ist bei dem Cubie mit 2GB nicht so tragisch, aber ein Killer für den schmalbrüstigen RPi0W.

Ich will ja am Wochenende eh mal nach dem Problem sehen, da teste ich auch mal Richtung Perl-Version.
Danke für den Tip.

Cheers
mi.ke

Zitat von: mi.ke am 10 März 2019, 14:39:06
ich hatte die "offizielle" Version installiert und bin wieder zurück auf die Version von 2.01.

So, ich hab jetzt mal die letzte Version eingespielt.
Bis jetzt läufts, morgen ist Sonntag, da mach ich mal nen Stresstest.


Das Modul generiert allerdings auch jetzt schon Meldungen:
2019.03.30 17:03:43 2: (Re)starting Arlo event listener.
2019.03.30 17:03:43 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains
2019.03.30 17:03:43 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains
2019.03.30 17:33:45 2: (Re)starting Arlo event listener.
2019.03.30 17:33:47 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains
2019.03.30 17:33:47 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains
2019.03.30 18:03:51 2: (Re)starting Arlo event listener.
2019.03.30 18:03:51 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains
2019.03.30 18:03:51 2: Invalid Arlo event response: Strict-Transport-Security: max-age=63072000; includeSubDomains

Kann auch sein, das Netgear was an der Security geändert hat.
Ich meine mich erinnern zu können, so etwas gelesen zu haben, sicher bin ich mir aber nicht.

Cheers

mi.ke

Wenn sonst alles funktioniert, kannst du die Fehlermeldung ignorieren. Das ist nur der HSTS-Header, der aussagt, dass mit der Arlo Website nur über HTTPS kommuniziert werden darf. Das macht das Modul sowieso. Daher werde ich in das Modul einbauen, dass die HSTS-Header keine Fehlermeldungen mehr erzeugen.

Guten Morgen maluk und co,
gehen eigentlich die neuen Ultra HD Cams von Arlo auch mit deinem Modul? Ich möchte mir die neuen Cams gerne anschaffen.
Lg c

Hallo choetzu,

ich gehe davon aus, dass auch die neuen Kameras funktionieren, da das Prinzip das Gleiche ist wie bei den bisherigen Pro-Kameras - also Basisstation + Kameras. Die Ultra-Kameras werden auch von der bisherigen App unterstützt, daher wird vermutlich die selbe API verwendet.

Gruß
maluk

Hi maluk,

kurze Rückmeldung.

Bis auf die SSL Meldungen scheint alles stabil zu laufen.
In den letzten Tagen, also seit dem letzten Update, gab es nur einmal einen Hänger. Da waren die beiden Basisstationen anscheinend vertauscht. Die Modi über Base2 wurde in Base1 angezeigt und da kam die Steuerung natürlich durcheinander.
Nach Neustart der Basisstationen war wieder alles normal.
Ich vermute, dass der Fehler nicht von Modul kam, sondern von einem, zur gleichen Zeit stattgefundenen, wLAN-Update.

Dank und viele Grüße

Cheers
mi.ke

Zitat von: maluk am 06 April 2019, 12:04:41
Hallo choetzu,

ich gehe davon aus, dass auch die neuen Kameras funktionieren, da das Prinzip das Gleiche ist wie bei den bisherigen Pro-Kameras - also Basisstation + Kameras. Die Ultra-Kameras werden auch von der bisherigen App unterstützt, daher wird vermutlich die selbe API verwendet.

Gruß
maluk

Hallo maluk.

es geht "fast" alles ;) Leider aber das wichtigste nicht. Und zwar kann ich den Mode "Aussen" nicht mehr mit "set Arlo_BasisSystem mode Aussen" aktivieren. Arm und disarm geht. Aber der Mode nicht. Wenn ich auf dem App dann den Mode auswähle, kommt dann auf Fhem "mode2". Und wenn ich wiederum "set Arlo_BasisSystem mode mode2" eingebe, gehts auch nicht...

"set Arlo_BasisSystem mode mode2"
[Wed Apr 10 14:20:21 2019] fhem.pl: Use of uninitialized value $nameOfId in string eq at ./FHEM/49_Arlo.pm line 691.
2019.04.10 14:20:21 5: Checking for Arlo server response.
2019.04.10 14:20:22 5: Checking for Arlo server response.
2019.04.10 14:20:22 5: Checking for Arlo server response.
2019.04.10 14:20:23 5: Checking for Arlo server response.
2019.04.10 14:20:23 5: Checking for Arlo server response.

set Arlo_BasisSystem mode Aussen
2019.04.10 14:21:19 5: Checking for Arlo server response.
[Wed Apr 10 14:21:19 2019] fhem.pl: Use of uninitialized value $nameOfId in string eq at ./FHEM/49_Arlo.pm line 691.
2019.04.10 14:21:19 5: Checking for Arlo server response.
2019.04.10 14:21:20 5: Checking for Arlo server response.
2019.04.10 14:21:21 5: Checking for Arlo server response.

woran könnte das liegen?

lg c

EDIT: Sorry, ich habe den Fehler gefunden. Wer lesen kann ist eindeutig im Vorteil. Und zwar muss man zuerst "set Arlo_Cloud readModes" machen, bevor es funktioniert... Alles Gut also! Schnurrt wie ein Kätzchen... ;)

Das Auslesen der Modes scheint sich bei der neuen Basisstation geändert zu haben. Setze verbose im Arlo_Cloud-Cloud Device auf 5 und rufe danach set Arlo_Cloud readModes auf. Danach wieder verbose auf 3 setzen.

Schicke mir bitte die Antwort von Arlo auf readModes aus dem Logfile per persönlicher Mitteilung. Dann schaue ich mir an, was da falsch läuft.

Hallo maluk,
ersteinmal schönen dank für deine viele und gute Arbeit. Ich hab mich sehr gefreut die Steuerung von Arlo mit Fhem zu übernehmen.
Super  :D :D :D

Was mir noch nicht klar ist wie ich die Video und Bild Dateien auf meinen Server download kann.
Ich habe das Verzeichnis angelegt und die Berechtigungen stehen auf 777.
Die Attribute Download Verzeichnis und Download Link habe ich auch eingerichtet.

Kannst du mir da weiterhelfen?
Vielen Dank im Voraus
Gruß AyshaHM

Post doch mal deine attr der DownloadDir und DownloadLink. Das ging bei mir auch nicht auf anhieb.

Lg c

Hallo choetzu,
hier meine Daten.
/opt/fhem/www/arlo/
https://xxxxxx.selfhost.eu:8083/fhem/www/arlo/

Danke für deine Hilfe

Gruß
AyshaHM

Hallo AyshaHM,

bei der URL musst du www/ entfernen, korrekt ist also

https://xxxxxx.selfhost.eu:8083/fhem/arlo/

Oder befindet sich im Verzeichnis /opt/fhem/www/arlo/ kein Video?

Gruß
maluk

Hallo maluk,
ich habe das Problem gelöst.
Mir war nicht klar das die Daten in Arlo_Cloud eingetragen werden.
Ich hatte sie für jede Kamera eingetragen.
Bei mir ging der Download aber auch mit dem www. Jetzt habe ich es entfernt und das geht auch.

Also wenn die Daten so in die Arlo_Cloud eingetragen werden geht alles wunderbar.

Vielen Dank für eure Hilfe und für dieses super Modul.
lG AyshaHM

:D :D :D

Hi,

bei mir werden keine neuen Stream-Links mehr angelegt!
Funktioniert bei euch noch die Verbindung?

Danke

Ciao
Michael

Hi Michael,

bei mir funktioniert noch alles ganz normal. Wenn eine neue Aufnahme erzeugt wurde, sendet Arlo normalerweise eine mediaUploadNotification.

Hast du folgenden Log-Eintrag im Logfile?

Process Arlo event mediaUploadNotification

Gruß
maluk

Das kommt leider nicht.
Echt komisch - alles geht, Status, Akku, usw. nur die Files werden nicht angelegt.
Vielleicht liegts an meinem Raspberry.

Jetzt geht's wieder!
Hab in der Arlo App die Benutzerrechte neu gespeichert.

@maluk

wollte nur nochmal "Danke" sagen.
Die Steuerung läuft sensationell stabil seit über sechs Wochen ohne Eingriff.

Perfekt

Vielen Dank und Grüße

Cheers
mi.ke

Da schliess ich mich mi.ke an!! Super stabil!!

Einziger Wehrmutstropfen. Wenn ich ein Snapshot mache, dann aktualisiert es mir den Download nicht immer zuverlässig.
Manchmal gehts, manchmal nicht. Hab noch kein Muster erkannt. rechte auf 777y

Lg c

Hat dies sonst noch jemand beobachtet? (Push)

Zitat von: choetzu am 26 Mai 2019, 11:13:13
Einziger Wehrmutstropfen. Wenn ich ein Snapshot mache, dann aktualisiert es mir den Download nicht immer zuverlässig.
Manchmal gehts, manchmal nicht. Hab noch kein Muster erkannt. rechte auf 777y

Zitat von: choetzu am 30 Mai 2019, 08:12:08
Hat dies sonst noch jemand beobachtet? (Push)

<OT>
Wermut ist ein mit Gewürzen und Kräutern aromatisierter und aufgespriteter Wein mit einem vorgeschriebenen Alkoholgehalt zwischen 14,5 und 21,9 Volumenprozent Alkohol und unterschiedlich hohem Zuckergehalt.
;D
</OT>

wenn niemand darauf antwortet, vermutlich nicht.

@maluk

Moin,
ich bin mal wieder am ausprobieren und habe versucht, den "Netgear M1 Nighthawk Router" als Basisstation zu betreiben. Das funktioniert auch, er wird auf arlo.netgear.com als Basisstation erkannt.

In Deinem Modul wird er per autocreate auch "gesehen", denn im LOG taucht er auf:
2019.06.20 13:01:58 3: Found device routerM1 with name Nighthawk.

Allerdings wird kein device erzeugt.

Kann ich das auch händisch machen?
Ich möchte über das Modul später den Modus ändern können.

Vielen Dank und Grüße

Cheers
mi.ke

Hallo mi.ke,

stelle mal am Arlo_Cloud-Device verbose auf 5 und führe nochmal autocreate durch. Schicke mir den Teil des Logfiles, der die Daten zum M1 Router enthält, per privater Nachricht zu. Ich ergänze dann das Modul entsprechend.

Gruß
maluk

Hallo Jungs,

leider hab ich hier am Land immer wieder DSL Abbrüche bis zu 8 Std.
Immer wenn das Internet weg ist, blockiert das Arlo Modul das komplette Fhem.
Fhem läuft zwar irgendwie, ist aber nicht erreichbar und arbeitet auch nicht oder nur extrem verzögert.

Hat dieses Problem noch jemand?
Wenn ich Arlo disable oder das Internet wieder steht funktioniert fhem wieder einwandfrei ohne restart.

Danke
Gruß
Flo

Zitat von: maluk am 20 Juni 2019, 18:00:30
stelle mal am Arlo_Cloud-Device verbose auf 5 und führe nochmal autocreate durch. Schicke mir den Teil des Logfiles, der die Daten zum M1 Router enthält, per privater Nachricht zu. Ich ergänze dann das Modul entsprechend.

Hi maluk,

vielen Dank, das Du das Modul erweiterst.
Hab Dir eine PM geschickt.

Cheers
mi.ke

Zitat von: Niko1987 am 21 Juni 2019, 11:52:45
leider hab ich hier am Land immer wieder DSL Abbrüche bis zu 8 Std.

Wie krass, dass es sowas in 2019 noch gibt, unfassbar

Zitat von: Niko1987 am 21 Juni 2019, 11:52:45
Immer wenn das Internet weg ist, blockiert das Arlo Modul das komplette Fhem.
Fhem läuft zwar irgendwie, ist aber nicht erreichbar und arbeitet auch nicht oder nur extrem verzögert.

Hat dieses Problem noch jemand?
Wenn ich Arlo disable oder das Internet wieder steht funktioniert fhem wieder einwandfrei ohne restart.

Man könnte ein notify/DOIF bauen, das, wenn keine Internetverbindung besteht, das ArloCloud-Device disabled. Wenn die Verbindung wieder steht, disable wieder auf 0.

Cheers
mi.ke

Zitat von: Niko1987 am 21 Juni 2019, 11:52:45
Hallo Jungs,

leider hab ich hier am Land immer wieder DSL Abbrüche bis zu 8 Std.
Immer wenn das Internet weg ist, blockiert das Arlo Modul das komplette Fhem.
Fhem läuft zwar irgendwie, ist aber nicht erreichbar und arbeitet auch nicht oder nur extrem verzögert.

Hat dieses Problem noch jemand?
Wenn ich Arlo disable oder das Internet wieder steht funktioniert fhem wieder einwandfrei ohne restart.

Danke
Gruß
Flo

Hallo Flo,

du kannst mir (gerne auch als persönliche Nachricht) eine Logfile-Auszug aus einem solchen Zeitraum schicken, an dem FHEM wegen dem Modul hängt. Vielleicht kann ich das Verhalten so anpassen, dass FHEM nicht lahmgelegt wird.

Trotzdem würde ich mich mal bei meinem DSL-Anbieter beschweren. Klagen über schlechte Bandbreiten (nicht nur auf dem Land) sind ja bekannt, aber bei deinem DSL scheint ja irgendetwas anderes nicht in Ordnung zu sein.

Gruß
Manfred

Zitat von: maluk am 22 Juni 2019, 12:37:27
Hallo Flo,

du kannst mir (gerne auch als persönliche Nachricht) eine Logfile-Auszug aus einem solchen Zeitraum schicken, an dem FHEM wegen dem Modul hängt. Vielleicht kann ich das Verhalten so anpassen, dass FHEM nicht lahmgelegt wird.

Trotzdem würde ich mich mal bei meinem DSL-Anbieter beschweren. Klagen über schlechte Bandbreiten (nicht nur auf dem Land) sind ja bekannt, aber bei deinem DSL scheint ja irgendetwas anderes nicht in Ordnung zu sein.

Gruß
Manfred

Hallo Manfred,

ja leider musste ich hier einen Regionalen Anbieter wählen. Das Große pinke T bietet nur light DSL.

Die Störungen bei meinem Anbieter scheinen immer weitläufiger zu sein.
Wenn ich eine Störung habe, funktioniert das Internet auch bei Freunden und Nachbarn nicht die den gleichen Anbieter haben.
Wenn es mal läuft dann hab ich auch super Bandbreiten :)

Danke für deine Hilfe

Gruß
Florian

Zitat von: mi.ke am 21 Juni 2019, 12:05:38
Hi maluk,

vielen Dank, das Du das Modul erweiterst.
Hab Dir eine PM geschickt.

Cheers
mi.ke

Ich habe mal eine Version gebaut (siehe Anhang), mir der der Router funktionieren sollte (inkl. Mode setzen). Bitte ersetze mal 49_Arlo.pm in deiner Installation. Vor dem Test bitte das Nighthawk-Device löschen und erneut autocreate durchführen.

Zitat von: Niko1987 am 22 Juni 2019, 12:50:59
Hallo Manfred,

ja leider musste ich hier einen Regionalen Anbieter wählen. Das Große pinke T bietet nur light DSL.

Die Störungen bei meinem Anbieter scheinen immer weitläufiger zu sein.
Wenn ich eine Störung habe, funktioniert das Internet auch bei Freunden und Nachbarn nicht die den gleichen Anbieter haben.
Wenn es mal läuft dann hab ich auch super Bandbreiten :)

Danke für deine Hilfe

Gruß
Florian

Hallo Florian,

im ersten Moment sieht das Log für mich halbwegs normal für den Fall aus, dass gerade das Netzwerk weggebrochen ist und das Modul versucht, alle Verbindungen neu herzustellen. Du kann mal mit folgenden 2 Attribute am Cloud-Device spielen:

* pingInterval: standardmäßig wird alle 90 Sekunden ein Ping gesendet. Wenn der schiefgeht, versucht das Modul sich neu zu verbinden. Du kannst mal den Wert auf 180 (Sekunden) oder eventuell noch höher setzen. Zu hoch sollte er nicht sein, da sonst die Session auf der Arlo-Seite abläuft. Wo genau der kritische Wert liegt, kann ich dir aber nicht sagen. Das müsstest du ausprobieren. Ein höherer Wert bedeutet aber auch, dass es bei eventuellen Verbindungsproblemen länger dauert, bis die Verbindung wieder steht (wie immer gibt es Vor- und Nachteile für niedrige und hohe Werte  ;))
* ssePollingInterval: dieser Wert ist standardmäßig bei 2 (Sekunden). Auch diesen Wert kannst du mal hochsetzen (z.B. auf 4 Sekunden oder noch höher). Das dürfte die Last verringern, führt ab zu trägeren Reaktionszeiten im Normalbetrieb.

Es ist immer ärgerlich, wenn der Internet Provider nicht zuverlässig funktioniert. Ich habe auch immer mal wieder Probleme und muss ab und zu meine FritzBox neu starten - da nutzt die beste Bandbreite nichts, das ist einfach ärgerlich.

Gruß
maluk

Zitat von: Niko1987 am 22 Juni 2019, 19:47:07
Danke für deine Mühe aber was ist ein Nighthawk-Device?  :P

Die Antwort war für mi.ke  ;)

Zitat von: maluk am 22 Juni 2019, 19:49:56
Die Antwort war für mi.ke  ;)

Sorry  8)

Zitat von: maluk am 22 Juni 2019, 19:22:01
Ich habe mal eine Version gebaut (siehe Anhang), mir der der Router funktionieren sollte (inkl. Mode setzen). Bitte ersetze mal 49_Arlo.pm in deiner Installation. Vor dem Test bitte das Nighthawk-Device löschen und erneut autocreate durchführen.

Hallo maluk,

mit der neuen Version wird der Nighthawk erkannt und die Modi lassen sich perfekt schalten, klasse.

Ein kleines Problem gibt es leider noch.
Da der Nighthawk ein Mobiles-Gerät ist, lässt sich die Arlo-Funktion im Router Menü deaktivieren um Akku zu sparen. Im Arlo-Browser und in der APP wird der Router dann als Offline markiert.

Das Modul erkennt die Änderung nach Offline dann nicht automatisch. Ausschliesslich mit einem manuellen updateReadings im Arlo_Cloud Device ändert sich das Reading im Modul.

Wird die Arlo-Funktion im Router wieder aktiviert, nutzt auch ein updateReadings im Arlo_Cloud Device nichts. Das Reading im Modul bleibt auf disarmed . Im Browser und der APP wird der korrekte Zustand angezeigt.
Man kann das Readings im Modul dann nur noch mit wildem "Modus umschalten" in der APP wieder zum aktualisieren bewegen.

Siehst Du eine Möglichkeit das abzufangen?

Cheers
mi.ke

Mal ne kurze Zwischenfrage: kann mir einer die verschiedenen Intervall Atribute so erklären, dass ich es als Laie auch kapiere. Resp. Was sie bezwecken.. Ich möchte diese Werte gerne u.U. Optimieren.

- sspollingInterval: was bezwecken Ss Events?
- pingintervall. Wieso ist der Heartbeat wichtig?

Danke.
Lg c

Zitat von: choetzu am 29 Juni 2019, 00:47:57
Mal ne kurze Zwischenfrage: kann mir einer die verschiedenen Intervall Atribute so erklären, dass ich es als Laie auch kapiere. Resp. Was sie bezwecken.. Ich möchte diese Werte gerne u.U. Optimieren.

- sspollingInterval: was bezwecken Ss Events?
- pingintervall. Wieso ist der Heartbeat wichtig?

Danke.
Lg c

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.

Zitat von: mi.ke am 23 Juni 2019, 10:16:33
Ein kleines Problem gibt es leider noch.
Da der Nighthawk ein Mobiles-Gerät ist, lässt sich die Arlo-Funktion im Router Menü deaktivieren um Akku zu sparen. Im Arlo-Browser und in der APP wird der Router dann als Offline markiert.

Das Modul erkennt die Änderung nach Offline dann nicht automatisch. Ausschliesslich mit einem manuellen updateReadings im Arlo_Cloud Device ändert sich das Reading im Modul.

Wird die Arlo-Funktion im Router wieder aktiviert, nutzt auch ein updateReadings im Arlo_Cloud Device nichts. Das Reading im Modul bleibt auf disarmed . Im Browser und der APP wird der korrekte Zustand angezeigt.
Man kann das Readings im Modul dann nur noch mit wildem "Modus umschalten" in der APP wieder zum aktualisieren bewegen.

Siehst Du eine Möglichkeit das abzufangen?

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.

Zitat von: maluk am 30 Juni 2019, 10:54:39
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.

Zitat von: maluk am 30 Juni 2019, 12:45:44
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:
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

@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

Zitat von: m0urs am 30 Januar 2019, 10:39:19
@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 ...

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

Zitat von: choetzu am 24 Juli 2019, 19:26:59
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

Zitat von: mi.ke am 24 Juli 2019, 20:34:12
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?

Zitat von: choetzu am 24 Juli 2019, 21:15:14
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.

Zitat von: choetzu am 24 Juli 2019, 21:15:14
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.

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

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

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!

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

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

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

Ich habe mir die neue Website von Arlo mal genauer angesehen und dabei festgestellt, dass sich neben der URL auch die Methode der Anmeldung geändert hat. Dies habe ich jetzt im Modul nachgezogen - ab morgen Vormittag wird die Änderung über den FHEM-Update mitkommen. Damit sollte jetzt wieder zukunftssicher alles funktionieren.

Darüber hinaus hatte ich schon einige Zeit das Problem von choetzu, dass die Videos nicht zuverlässig heruntergeladen werden. Aus irgendwelchen Gründen werden nicht immer mediaUplaod-Events vom Server gesendet. Darum habe ich für alle, die das Problem haben, ein neues Attribute "videoDownloadFix" am Arlo Cloud Device eingeführt. Wenn dieses Attribut auf 1 gesetzt wird, ruft das Modul 2 Sekunden, nachdem die Kamera vom Aufnahme-Modus in den Idle-Modus zurück wechselt, die vorhandenen Aufnahmen für die Kamera vom Server ab und lädt das neueste Video und Thumbnail herunter. Auf mediaUpload-Events wird in diesem Modus nicht mehr reagiert. Verfügbar ist auch diese Funktion mit dem Update morgen.

@mi.ke: dein Router Nighthawk funktioniert mit der neuen Version auch. Du kannst also auch updaten  ;)

@durchstarter: die Zweifaktor-Authentifizierung kann man im Web Portal und der App im Profil aktivieren. Sobald man das tut, wird jedoch mein Modul nicht mehr funktionieren. Technisch wäre es zwar grundsätzlich möglich, die Zweifaktor-Authentifizierung zu implementieren, allerdings muss sich das Modul häufig alleine neu einloggen, und das würde natürlich nicht mehr funktionieren.

Zitat von: maluk am 16 September 2019, 21:42:28
Ich habe mir die neue Website von Arlo mal genauer angesehen und dabei festgestellt, dass sich neben der URL auch die Methode der Anmeldung geändert hat. Dies habe ich jetzt im Modul nachgezogen - ab morgen Vormittag wird die Änderung über den FHEM-Update mitkommen. Damit sollte jetzt wieder zukunftssicher alles funktionieren.

. . .

@mi.ke: dein Router Nighthawk funktioniert mit der neuen Version auch. Du kannst also auch updaten  ;)

. . .

Jawoll !

Update gemacht, kurz getestet, dann gleich in die Live-Umgebung.

Sieht gut aus, keine Probleme.

Vielen Dank!

Cheers
mi.ke

Hallo maluk
Super, herzlichen Dank. Update gemacht.
Ich hatte heute das Phänomen dass ich weder Snapshot machen konnte noch arm/disarm. Nach einem Restart gehts wieder.
Lg c

Ist bei mir gestern auch passiert, dass plötzlich das Access Token ungültig war. Ich werde was einbauen, dass dies erkannt wird und in diesem Fall automatisch ein Reconnect stattfindet.

Super, danke. Weisst du in der Zwischenzeit wie oft/regelmässig man einen reconnect machen muss? Ich werden dann einen at machen..

Ich habe das Problem gestern mal grob gefixt. Wenn du heute einen Update in FHEM machst, bekommst du diese Version. Ich werden das noch besser beheben, da der automatische Reconnect erst erfolgt, wenn man einen Aufruf bei Arlo macht und dieser fehlschlägt. Aber das dauert etwas länger und mit der jetzigen Lösung gibt es zumindest keine Komplett-Abbrüche mehr.

Hallo maluk, danke. V.a. Für deine Mühe!

Bei mir klappt es aber noch nicht so wie früher. Update gemacht. Ich triggere auf snapshotURL und dieser Event kommt nach wie vor erst, wenn ich ein reconnect der Arlo_Cloud mache.

Ich mache nun via at stündlich ein reconnect bis das Problem gelöst ist.

Lg und schönen Sonntag

@maluk

ich kann seit dem letzten Update die Kameras nicht mehr mit on | off schalten, kann das zusammenhängen?

Chhers
mi.ke

Hallo mi.ke,

ich habe damit keine Probleme. Gibt es Einträge im Logfile? Falls nicht, mal verbose auf dem Coud-Device auf 4 oder 5 stellen und Logfile nochmal prüfen.

Gruß
maluk

Okay, LogLevel auf 5 und Problem erkannt.

Wenn eine Kamera offline ist (Akku komplett leer, Verbindung gestört oder gestolen) merkt das Modul es nicht.

Die Readings dieses Gerätes state, signalStrength, batteryLevel und brightness werden trotzdem aktuallisiert, bleiben aber auf dem letzten Wert und bekommen einen neuen timstamp.
Es sieht also auf den ersten Blick so aus, als wäre das Gerät noch online.

Wenn man versucht ein solches "Offline-Gerät" zu schalten, passiert nichts. Im LOG gibt es dann eine Meldung mit LogLevel 4:
"action":"set","error":{"code":4000,"message":"Resource not found."}

Es wäre klasse, wenn es einen Status (Reading) gäbe, der z.B connected oder disconnected ausgibt.

Wäre sowas machbar?

cheers
mi.ke

Zitat von: mi.ke am 27 September 2019, 21:44:59
@maluk

ich kann seit dem letzten Update die Kameras nicht mehr mit on | off schalten, kann das zusammenhängen?

Chhers
mi.ke

Hey mi.ke
Ich habe selbes Problem. Wenn ich unmittelbar ein reconnect der Arlo_Base mache, klappt es wieder.

Auch das at mit dem stündlichen Reconnect konnte mein Problem nicht lösen.

Lg c

Zitat von: choetzu am 29 September 2019, 15:34:27
Hey mi.ke
Ich habe selbes Problem. Wenn ich unmittelbar ein reconnect der Arlo_Base mache, klappt es wieder.

Auch das at mit dem stündlichen Reconnect konnte mein Problem nicht lösen.

Lg c

Hallo maluk und mi.ke
Gibts für dieses Problem mittlerweile eine Lösung?
Lg c

Zitat von: choetzu am 29 September 2019, 15:34:27
Ich habe selbes Problem.

Nein, ich bin anderer Mweinung.
Ich glaube nicht, dass das die gleiche Ursache hat. Die Symtome sind doch unterschiedlich.

Deine Devices verlieren den Connect, meine "tun so" als ob sie connected wären, obwohl sie zur Zeit bei einem Freund in Marokko sind.
Soweit reicht dann doch kein wLAN  8)

cheers
mi.ke

Danke mi.ke

Komisch. Ich kann zwar schalten, aber es werden keine Events ausgelöst, die ich triggern könnte. Ausser ich mache kurzfristig einen Reconnect.

Shit ich brauche die Events motion (für Alarmanlage) und snapshotURL (für Türklingel Bild) zum auswerten. Vor dem Update ging sas relativ zuverlässig.

Lg Tom

Lg

Zitat von: choetzu am 15 Oktober 2019, 09:10:29
Vor dem Update ging sas relativ zuverlässig.

Hast Du die alte Version (mit Datum vom 30.06.2019) noch?
Dann würde ich, wenn ich an Deiner Stelle wäre, die alte VErsion wieder aufspielen (die neue vorher sichern) um das zu testen.
Das hätte zwei klare Vorteile.
Dein System würde wieder laufen wie von Dir erwartet und Du könntest maluk Deine Erkenntnis mitteilen.
Oder es liegt gar nicht an der neuen Version, aber auch dann hättest Du zumindest den Beweis.

Hast Du eine Sicherung? Wenn nicht könnte ich Dir die letzte Version auch zukommen lassen.

Cheers
mi.ke

Ich habe gerade eine neue Version hochgeladen, die dann ab morgen vormittag beim FHEM update mitkommen wird. Dort habe ich jetzt hoffentlich die Verbindungsabbrüche eliminiert, die auch bei mir sporadisch aufgetreten sind. Ich habe das jetzt bei mir einige Tage laufen lassen, um Erfahrungen damit zu sammeln.

Eine wichtige Neuerung habe ich auch eingebaut: wenn alle Basisstationen disarmed sind, wird die Verbindung zur Cloud abgebaut. Wenn man neue Befehle absendet oder wieder in einer Basisstation die Überwachung wieder aktiviert bzw. einen Mode setzt, wird die Verbindung wieder aufgebaut. Wie lange eine Verbindung noch nach aktiv bleibt, wenn bei allen Basisstationen die Überwachung deaktiviert wurde, kann über das Attribut expiryTime gesetzt werden. Standardmäßig wird die Verbindung nach 10 Minuten abgebaut, die Angabe erfolgt in Sekunden (also 600 = 10 Minuten).  Wenn der Wert auf 0 gesetzt wird, wird wie bisher die Verbindung nie abgebaut. Diesen Wert würde ich aber nur setzen, falls es unerwartete Probleme gibt. Ansonsten gibt es keinen Grund für eine dauerhafte Verbindung.

Zitat von: mi.ke am 29 September 2019, 15:26:00

Wenn eine Kamera offline ist (Akku komplett leer, Verbindung gestört oder gestolen) merkt das Modul es nicht.

Die Readings dieses Gerätes state, signalStrength, batteryLevel und brightness werden trotzdem aktuallisiert, bleiben aber auf dem letzten Wert und bekommen einen neuen timstamp.
Es sieht also auf den ersten Blick so aus, als wäre das Gerät noch online.

Wenn man versucht ein solches "Offline-Gerät" zu schalten, passiert nichts. Im LOG gibt es dann eine Meldung mit LogLevel 4:

Code Auswählen Erweitern

"action":"set","error":{"code":4000,"message":"Resource not found."}

@maluk
Kannst Du den Code 4000 irgendwie verwerten?
Ich finde, daß das noch eine elementare Sicherheitsfunktion wäre, wenn state auch "offline" könnte,
also Kamera (Akku komplett leer, Verbindung gestört oder gestolen)
und nicht sugestieren würde "es ist alles in Ordnung".

cheers
mi.ke

Hallo Maluk, Hallo Forum,
ich habe das Modul Arlo aktiviert und kann die Kamera nun, ausgelöst mit einem Bewegungsmelder mit dem Befehl startRecording starten.

Mein DOIF sieht folgendermaßen aus:
([10:45-22:00] and [Bewegungsmelder:state] eq "motion")(set Arlo startRecording)

Frage: Wie kann ich die Aufnahme zeitlich begrenzen? Damit sie zum Beispiel nach 15 Sekunden stoppt?
Ein on-for-timer gibt es ja hier nicht.

Hallo tom
Wieso verbaust du nicht in dein DOIF am Schluss ein (set Arlo stopRecording) ein? Und dann das wait Attribut auf 0,15 setzen. Dann hats den selben Effekt wie on-for-timer.
Lg c

Ps und ich würde auf den Event triggern und nicht auf den Status.

Hi C,

ZitatWieso verbaust du nicht in dein DOIF am Schluss ein (set Arlo stopRecording) ein? Und dann das wait Attribut auf 0,15 setzen. Dann hats den selben Effekt wie on-for-timer.

Weil ich leider nicht so viel Erfahrung habe .... ;-) Vielen Dank, ich habe das nun so erweitert:
([10:45-22:00] and [Bewegungsmelder:state] eq "motion")(set Arlo startRecording) (set Arlo stopRecording)
mit
attr arlo wait 0,15

ZitatPs und ich würde auf den Event triggern und nicht auf den Status.

Aus dem Event Monitor?
Das wäre dann wahrscheinlich?    
([Arlo:"^motionDetected:.1$"]) ()

Ich bekomm immer folgende Fehlermeldung:

Arlo call was not successful: {"data":{"error":"1021","message":"Access token is empty.","reason":"Access token is empty"},"success":false}

Hat jemand eine Idee?
Zugangsdaten sind richtig.
LG Nicolas

Ich wollte bei Black Friday zuschlagen aber schwanke noch zwischen Arlo und Blink XT. Eine Funktion die ich aber wirklich haben möchte scheint keines der Systeme zu bieten: einen Live Stream über TabletUI. Möchte damit Tier im Klein-Tierstall zuschauen können. Kann mir einer sagen ob das möglich ist? Oder muss da wieder auf eine ,,normale" IPCam ausweichen?

Zitat von: Nico_98 am 12 November 2019, 19:48:35
Ich bekomm immer folgende Fehlermeldung:

Arlo call was not successful: {"data":{"error":"1021","message":"Access token is empty.","reason":"Access token is empty"},"success":false}

Hat jemand eine Idee?
Zugangsdaten sind richtig.
LG Nicolas

Hallo Nicolas,

sorry, ich habe keine E-Mail-Benachrichtigungen mehr von FHEM bekommen und daher nicht mitbekommen, dass es hier Fragen gab. Der Fehler dürfte nur auftreten, wenn die Anmeldedaten falsch sind. Die spitzen Klammern (<>) aus dem Beispiel musst du weglassen, also nur
define Arlo_Cloud Arlo ACCOUNT hans.mustermann@xyz.de meinPasswort

angeben. Falls der Fehler trotzdem auftritt, bitte mal temporär das Attribut verbose am Cloud-Device auf 5 setzen und im Logfile schauen, welche Antwort von Arlo zurückkommt (danach wieder auf 3 setzen).

Zitat von: StephanFHEM am 18 November 2019, 20:56:51
Ich wollte bei Black Friday zuschlagen aber schwanke noch zwischen Arlo und Blink XT. Eine Funktion die ich aber wirklich haben möchte scheint keines der Systeme zu bieten: einen Live Stream über TabletUI. Möchte damit Tier im Klein-Tierstall zuschauen können. Kann mir einer sagen ob das möglich ist? Oder muss da wieder auf eine ,,normale" IPCam ausweichen?

Leider bin ich etwas spät für Black Friday. Live Streams bekommt man mit Arlo nur über das RTSP(S)-Protokoll. Das ist nicht ganz so einfach in TabletUI zu integrieren, aber mit etwas Aufwand könnte es funktionieren (ohne Garantie). Zu Blink kann ich nichts sagen, aber wenn due eine Stromversorgung in deinem Kleintierstall hast, kannst du eine normale Webcam verwenden. Der Vorteil von Arlo ist, dass die Kameras mit Akku funktionieren und dadurch unabhängig von einer Stromversorgung betrieben werden können.

Gibt es eine Möglichkeit das aktuelle Bild der Arlokamera anzuzeigen?

Habe fhem auf Raspberry 4 installiert, läuft bestens, die Videos werden auch automatisch aus der Arlo-Cloud auf den raspberry kopiert. Ich möchte jedoch wenn es klingelt nicht warten, bis das Video kopiert ist, sondern auf die Kamera schauen, ähnlich wie es mit der ARLO-App am Tablett geht.

LG
Herbert

Hallo Herbert,

wenn dir ein Bild reicht, kannst du set <Kamera> snapshot aufrufen. Dann wir ein einzelnes Bild aufgenommen, das relativ schnell (innerhalb ca. 3 - 4 Sekunden) lokal aufgerufen werden kann. Sobald das Bild von Arlo kopiert wurde, wird das Attribut snapshotUrl aktualisiert. 

Danke für die Antwort, das Snapshotbild wird jetzt auf dem raspi erzeugt.
Ich zeige es mit iframe https://192.168.26.180:8083/fhem/www/arlo/52M17C7NA8566_snapshot.jpg   an.

Leider habe ich noch nichts gefunden, damit das Bild im Firefox sofort aktualisiert wird.
Das Attribut snapshotUrl wird sofort aktualisiert.
Habe mal mit define Arlo_x  at +*00:00:20 get Arlo_vorne snapshot festgelegt, dass
alle 20 Sekunden ein Snaphshot gemacht wird. Dieser wird auch auf dem raspi abgelegt,
aber leider nicht sofort angezeigt bzw. aktualisiert.

Wie kann ich z.B. abhängig vom Attribut snapshotUrl sofort das aktuelle Bild anzeigen?

Du kannst eine kleine HTML-Datei in deinem Arlo-Web-Verzeichnis ablegen, die du dann in den iframe einbindest. In dieser HTML-Datei wird dann das Bild angezeigt und regelmäßig neu geladen. Durch Anhängen eines Parameters an die URL wird das Bild auch nie aus dem Cache geladen, sondern immer neu vom Server geladen. Hier der Beispiel-Code:

<html>
<head>
<script>
   function loadImage() {
     var d = new Date();
     document.getElementById("img").src = "52M17C7NA8566_snapshot.jpg?t=" + d.getTime();
     window.setTimeout(loadImage, 2000);
   }
</script>
</head>
<body onload="loadImage()">
  <img id="img">
</body>
</html>

Hier wird alle 2 Sekunden (Parameter 2000 in setTimeout bedeutet 2000 Millisekunden) das Bild neu geladen. Wenn du seltener oder häufiger aktualisieren möchtest, musst du diesen Parameter entsprechend anpassen.

wie funktioniert das Einbinden der HTML-Datei in den iframe?
mit attr ?
Habe die html-Datei unter /opt/fhem/www/arlo/snapshot.html abgelegt.
Wo wird die Funktion "loadImage" angestossen?

Mein iframe sieht so auf:
Internals:
   CFGFN     
   DEF        iframe 192.168.26.180:8083/fhem/www/arlo/snapshot.html
   FUUID      5e09ddbb-f33f-7e75-2ea6-73b773f50a245abf
   LINK       192.168.26.180:8083/fhem/www/arlo/snapshot.html
   NAME       ss
   NR         395
   STATE      initialized
   TYPE       weblink
   WLTYPE     iframe
Attributes:
   htmlattr   width="480" height="560"
   room       Snapshot

Du darfst www nicht in den Pfad-Namen aufnehmen, da alles unter dem Verzeichnis www über host:8083/fhem aufgerufen werden kann. Außerdem kannst auch die IP-Adresse weglassen. Die Einbindung müsste wie folgt funktionieren:

define xyz weblink iframe /fhem/arlo/snapshot.html

loadImage wird automatisch beim Laden aufgerufen - siehe <body onload="loadImage()">

Vielen Dank für die Antwort, die snapshots und thumb-files kann ich jetzt anzeigen.
Hast du noch einen Tipp wie man die Bilder verkleinern kann, da ich immer nur
einen Ausschnitt sehe, und erst wenn ich mit der Maus draufklicke und etwas ziehe,
wird das gesamte Bild in Verkleinerung dargestellt.
Die snapshots haben die Auflösung 1900x1088 Punkte, die Thumbs: 640x360.

Teilweise dauert es relativ lange bis die Bilder ins fhem kopiert werden, vermute es liegt
am Netz und nicht im FHEM da bei Löschen eines Bildes in fhem/arlo die
Anzeige innerhalb 2 Sekunden weg ist.

Du kannst in dem img-Tag des HTML die Breite und Höhe angeben, in der das Bild dargestellt werden soll:

  <img id="img" style="width:900px; height: 500px">

Das eigentliche Kopieren der Bilder sollte nicht sehr lange dauern. Allerdings dauert es ein paar Sekunden, bis der gesamte Prozess abgeschlossen ist. Bei mir dauert es ca. 4 Sekunden vom Auslösen des Snapshot bis ich das Bild im Browser sehe.

Bilder verkleinert anzeigen funktioniert damit bestens, wenn die Bilder unter www/arlo liegen, werden sie auch innerhalb von Sekunden angezeigt.Danke.

Habe jetzt festgestellt, dass die Arlokamera beim Erkennen einer Bewegung keine Aufnahme macht, wenn gerade ein Snapshot erstellt ist (Verdacht).
Habe mit "define Arlo_x  at +*00:00:20 set Arlo_vorne snapshot" festgelegt, dass alle 20 Sekunden ein Snapshot gemacht wird.
Wenn da gerade eine Aufnahme läuft, wird der Snapshot nicht erstellt und umgekehrt, also auch in der Arlo-Cloud fehlen Aufnahmen.

Ich bräuchte nur einen Snapshot, wenn es klingelt:
1) z.B. auf das alte Snapshotbild klicken und ein neuer Snapshot sollte angestossen werden
2) abhängig vom Erstellen eines Thumb oder mp4 (lastVideoThumbnailUrl, lastVideoUrl, motionDetected 1 oder 0)

Wie könnte man 1) oder/und 2) realisieren um den Zugriff auf Arlo nur zu machen, wenn er wirklich benötigt wird?

zu 1) habe ich einen dummy-Knopf eingebracht, der beim Schalten die Snapshots meiner 3 Kameras erstellt:
   knopfss für Skript:
   define knopfss dummy
   attr knopfss setList on off
   attr knopfss room Test_ss
   set knopfss on set Arlo_haustuer snapshot;set Arlo_vorne snapshot;set Arlo_hinten snapshot
zu 2) geht mit
   define Arlo_haustuer_notify_1 notify Arlo_haustuer:lastVideoUrl:.https://192.168.26.180:8083/fhem/www/arlo/52M17C7NA8566.mp4 {fhem("set
   Arlo_haustuer snapshot");;return 0}

Ein grundsätzliches Problem lässt sich wohl nicht lösen: Die Arlo-Kamera kann nur einen Befehl gleichzeitig entgegennehme und wenn sie gerade was macht,
gehen die weiteren Befehle verloren.
Beispiel: Bewegungsmelder macht eine Aufnahme von 30 sec Dauer. Innerhalb dieser 30 sec kann kein Snapshot erstellt werden.
Meine Idee ist wenn es an der Tür klingelt einen Snapshot zu machen, wenn jedoch kurz zuvor der Bewegungsmelder ausgelöst hat, kann ich nur
die *thumb-Datei der Arlo-Kamera anzeigen und das leider erst wenn die 30 sec für die Aufnahme der mp4-Datei vorbei sind, da erst dann
die *thumb und die *mp4-Datei ins FHEM-System kopiert werden. Snapshot wird in diesem Fall nicht erstellt.

Wenn man auf der Arlo-App das Live-Bild anschaut, macht die Kamera sonst auch nichts (Bewegungsmelder geht nicht, solange das Live-Bild angezeigt wird).
Ist das bei anderen Arlo-Kameras auch so?
LG Herbert

hab das Modul auch am laufen. es klappt soweit super aber ich bekomme noch jeden Menge Nachrichten ins Log
Process Arlo event subscriptions/****_web for ****

ist das normal? ich habe am Verbose nichts geändert, daher sollten doch nicht so viele gleiche Log-Einträge geschrieben werden? brauche ich eine neuere Version oder soll ich Verbose auf etwas bestimmtes setzen?

Setze verbose auf 0 für alle Geräte: Arlo_Cloud, Arlo_Arlo, WEB   und deine Kameras,
bei mir kommt keine Meldung ins logfile.

Es reicht aus, im Arlo_Cloud Device verbose auf 2 zu stellen. Wenn du überall verbose auf 0 setzt, bekommst du gar keine Meldungen mehr mit, also auch keine Fehler. Dass regelmäßig "Process Arlo event"-Meldungen kommen, hängt noch mit der Anfangszeit des Moduls zusammen, als es häufig Verbindungsabbrüche gab. So lange die Event-Meldungen kommen sieht man, dass die Arlo-Verbindung noch funktionsfähig ist.

Danke! Klappt anscheinend 8)

Zitat von: maluk am 21 Januar 2020, 22:20:56
Es reicht aus, im Arlo_Cloud Device verbose auf 2 zu stellen. Wenn du überall verbose auf 0 setzt, bekommst du gar keine Meldungen mehr mit, also auch keine Fehler. Dass regelmäßig "Process Arlo event"-Meldungen kommen, hängt noch mit der Anfangszeit des Moduls zusammen, als es häufig Verbindungsabbrüche gab. So lange die Event-Meldungen kommen sieht man, dass die Arlo-Verbindung noch funktionsfähig ist.

ich habe mal von 0 auf 2 geschaltet... jetzt kommen folgende Meldungen an

2020.01.22 17:11:41 2:  Arlo call was not successful: {"data":{"error":"2217","message":"The device does not exist.","reason":"No such device."},"success":false}

Hmm, aber irgendwie geht es trotzdem... Was bedeutet dieser nicht erfolgreiche call?

Seit heute Probleme mit dem Modul:

2020.02.11 18:05:55 2: Arlo Login not successful, status $status_line

Auch das Neu-anlegen des Arlo_Cloud accounts hat nix gebracht.

Zitat von: Hobbel am 11 Februar 2020, 18:09:48
Seit heute Probleme mit dem Modul:

Code Auswählen Erweitern

2020.02.11 18:05:55 2: Arlo Login not successful, status $status_line

Auch das Neu-anlegen des Arlo_Cloud accounts hat nix gebracht.

Ich habe seit gestern Abend ebenfalls genau das selbe Problem:

Arlo call was not successful: {"data":{"error":"1021","message":"Access token is empty.","reason":"Access token is empty"},"success":false}

same here... Auch wenn dies nicht zur Lösung beiträgt.. ;)

Bei mir funktioniert es nun seit eben wieder (ohne etwas zu tun)

Zitat von: marcopolo1312 am 11 Februar 2020, 21:01:37
Bei mir funktioniert es nun seit eben wieder (ohne etwas zu tun)

dito  :)

Ich hab das Problem auch: Access token is empty.

Bei mir lief es auch gestern tagsüber nicht. Dann gestern abend plötzlich wieder und nun schon wieder nicht mehr.

Bei mir ist ebenfalls down.

Gestern war es aber eine andere Fehlermeldung und es gab gestern auf heute auch eine größere Störung der Internetinfrastuktur
Gestern wurde nur der Server nicht gefunden.
Logeinträge Gestern:
2020.02.07 18:35:57 2: Error in Arlo event queue: https://my.arlo.com/hmsweb/client/subscribe: Can't connect(1) to https://my.arlo.com:443: IO::Socket::INET: Bad hostname 'my.arlo.com:443'


Die heutige Meldung hat etwas mit der Anmeldung zu tun.

Logeinträge Heute:2020.02.12 12:32:07 2: Arlo call was not successful: {"data":{"error":"1021","message":"Access token is empty.","reason":"Access token is empty"},"success":false}

Über das WEB-Portal sind die Kameras erreichbar.
Hoffentlich hat arlo nicht wieder was geändert.

cheers
mi.ke

Any News? Bei mir läuft es immer noch nicht. Merke grad meine Abhängigkeit ;)

ich hänge mich ebenfalls an, da auch mein fhem modul auf einen Fehler bei dem login läuft (an email und password liegt's nicht).

lg

Gernot

Bei mir funktionierts auch nichtmehr. =(

Hi ihr Leidensgenossen,
also bei mir läuft es auch die ganze Zeit nicht mehr.
Ich habe für mich aber einen Workaround gefunden, der wenigstens das An- und Abschalten der Kameras wieder funktionieren lässt. Der ist aber etwas langsamer.
Ich nutze jetzt IFTTT. Was spannend ist, dass das noch geht. d.h. entweder die API hat sich nicht geändert und das Modul hat ein Problem oder die haben die Änderung der API schon implementiert.
Ich habe dort (in IFTTT) den eMail-Trigger genutzt und der löst dann das Event bei Arlo aus.

Bei IFTTT sieht es dann so aus:
"If Send trigger@applet.ifttt.com an email tagged #Kameras_An from xx.xx@yy.de, then Arm Arlo"

In FHEM beim Event Kameras anschalten so:
{ DebianMail('trigger@applet.ifttt.com','#Kameras_An','') }

Natürlich müsst ihr Euch dafür einen Account bei IFTTT holen und aus FHEM Mail verschicken können z.b. über DebianMail.

Vielleicht hilft das ja jemandem.

bb Tobias

Ich bin schon vor einem dreiviertel Jahr umgestiegen und nutze ein externes Python-Script zum Aktivieren / Deaktivieren meiner Kameras. Ich hab das Repo mal publig geschaltet: https://github.com/m0urs/arlo-cl

Ist nicht wirklich komfortabel. Schaltet aber meine Kameras genau so wie ich es brauche und das sehr zuverlässig.

Leider hab ich bisher keine Doku, aber vielleicht kann ja jemand trotzdem damit was anfangen. Fragt gerne nach, wenn ihr was wissen möchtet.

Hier noch ein paar Script-Schnipsel, wie ich die Prozedur aus FHEM heraus nutze:

   sub setArloCamMode($)
   {
    my ($mode) = @_;
Log3 undef,1, "setArloCamMode: $mode";
    system("/usr/bin/python3 /opt/fhem/arlo-cl/arlo-cl.py -c /opt/fhem/arlo-cl/arlo-cl.cfg set-mode -m $mode &");

if ($mode eq "aktiviert") {
fhem("setreading Arlo_Cam.dum currentMode Aktiviert");
fhem("setreading Arlo_Cam.dum status-Home armed; setreading Arlo_Cam.dum status-Bridge_AZMichael armed; setreading Arlo_Cam.dum status-Bridge_AZSabine armed");
}
elsif ($mode eq "deaktiviert") {
fhem("setreading Arlo_Cam.dum currentMode Deaktiviert");
fhem("setreading Arlo_Cam.dum status-Home disarmed; setreading Arlo_Cam.dum status-Bridge_AZMichael disarmed; setreading Arlo_Cam.dum status-Bridge_AZSabine disarmed");
}
elsif ($mode eq "aktiviert_tag") {
fhem("setreading Arlo_Cam.dum currentMode Aktiviert");
fhem("setreading Arlo_Cam.dum status-Home Aktiviert_Tag; setreading Arlo_Cam.dum status-Bridge_AZMichael Aktiviert_Tag; setreading Arlo_Cam.dum status-Bridge_AZSabine Aktiviert_Tag");
}
elsif ($mode eq "garten") {
fhem("setreading Arlo_Cam.dum currentMode Garten");
fhem("setreading Arlo_Cam.dum status-Home Garten_Alle; setreading Arlo_Cam.dum status-Bridge_AZMichael Garten; setreading Arlo_Cam.dum status-Bridge_AZSabine armed");
}
elsif ($mode eq "garten_hinten") {
fhem("setreading Arlo_Cam.dum currentMode Garten_hinten");
fhem("setreading Arlo_Cam.dum status-Home Garten_2; setreading Arlo_Cam.dum status-Bridge_AZMichael disarmed; setreading Arlo_Cam.dum status-Bridge_AZSabine armed");
}
   }

sub getArloCamMode()
   {
   my $currentMode = "";
   my $mode = "";
   my $output_string = qx(/usr/bin/python3 /opt/fhem/arlo-cl/arlo-cl.py -c /opt/fhem/arlo-cl/arlo-cl.cfg list-current-modes);
   my @lines = split /^/, $output_string;
   foreach my $line (@lines) {
my @tokens = split / /, $line;
chomp $tokens[3];
fhem("setreading Arlo_Cam.dum status-$tokens[0] $tokens[3]");
}
if ( (ReadingsVal("Arlo_Cam.dum", "status-Home", "") eq "disarmed") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZMichael", "") eq "disarmed") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZSabine","") eq "disarmed") ) {
$currentMode = "Deaktiviert";
}
elsif ( (ReadingsVal("Arlo_Cam.dum", "status-Home", "") eq "armed") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZMichael", "") eq "armed") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZSabine", "") eq "armed") ) {
$currentMode = "Aktiviert";
}
elsif ( (ReadingsVal("Arlo_Cam.dum", "status-Home", "") eq "Aktiviert_Tag") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZMichael", "") eq "Aktiviert_Tag") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZSabine", "" ) eq "Aktiviert_Tag") ) {
$currentMode = "Aktiviert";
}
elsif ( (ReadingsVal("Arlo_Cam.dum", "status-Home", "") eq "Garten_Alle") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZMichael", "") eq "Garten") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZSabine", "") eq "armed") ) {
$currentMode = "Garten";
}
elsif ( (ReadingsVal("Arlo_Cam.dum", "status-Home", "") eq "Garten_2") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZMichael", "") eq "disarmed") && (ReadingsVal("Arlo_Cam.dum", "status-Bridge_AZSabine", "") eq "armed") ) {
$currentMode = "Garten_hinten";
}
else {
$currentMode = "Undefiniert";
}
fhem("setreading Arlo_Cam.dum currentMode $currentMode");
return
   }

   sub setArloCamState($$)
{
  # Aktiviert / Deaktiviert die Arlo-Außenkameras abhängig von Tageszeit
  # Tagsüber, wenn es noch hell ist, wird die Terrassenkamera nicht aktiviert, sondern nur die Gartenkameras, wegen Fehlalarm durch Blumenkübel
  # Abends, wenn es dunkel ist, wird beim Öffnen der Tür nur die Terrassenkamera und Garten_1 abgeschaltet
  # Parameter 1: Status der geschaltet werden soll.
  # Paremeter 2: "auto" (= Automatik) : Es soll keine Schaltung erfolgen, wenn die Automatik für die Arlo-Cams abgeschaltet ist.
 
  my ($state,$automatic) = @_;

if (($automatic eq "auto") && (ReadingsVal("Arlo_Cam_Automatic.dum","state","on") eq "off")) {
# Der Schaltvorgang wird von einer automatischen Prozedur aufgerufen und die Automatik ist abgeschaltet
# Daher nichts tun!
Log3 undef,1, "setArloCamState: $state ignored - Automatik abgeschaltet";
return;
}

  if ($state eq "arm") {

if ( (ReadingsVal("xx.HUE.lichtsensor_aussen","lightlevel",0) > 15000) ) {
setArloCamMode("aktiviert_tag");
}
else {
setArloCamMode("aktiviert");
}
  }
  elsif ($state eq "disarm")  {
if ( (ReadingsVal("xx.HUE.lichtsensor_aussen","lightlevel",0) < 10000) && (ReadingsVal("Arlo_Cam_Automatic.dum","state","off") eq "on") ) {
fhem("set Arlo_Home disarm; set Arlo_Bridge_AZMichael disarm; set Arlo_Bridge_AZSabine disarm");
setArloCamMode("garten_hinten");
}
    else {
        fhem("set Arlo_Home disarm; set Arlo_Bridge_AZMichael disarm; set Arlo_Bridge_AZSabine disarm");
setArloCamMode("deaktiviert");
    }
  }
  elsif ($state eq "garten")  {
setArloCamMode("garten");
}
  elsif ($state eq "garten_hinten")  {
setArloCamMode("garten_hinten");
}
  else
  {
  Log3 undef,1, "Error: setArloCamState: Undefined state $state";
  }
}


Hey Mours
Danke. Als Altenative bei Ausfällen wie jetzt wäre deine Variante gut. Kannst du auch Modi schalten und auf Motion reagieren?
Lg C

Ich benutze es nur zum scharf-/unscharf-Schalten sowie zum Setzen verschiedener Custom Modes, die vorher in der Arlo App definiert wurden. Ich habe mal eine Basic Doku in Github hinzugefügt. So Dinge wie Motion Detection etc. nutze ich nicht und die kann das Script auch nicht. Ist, wie gesagt, nur ein ganz "dummes" Skript um meine Cams zu steuern. Ich mache damit so Dinge wie die Außenkameras abschalten, wenn die Terrassentür offen ist, tagsüber Modi einschalten, die weniger empfindlich sind um nicht bei jedem Vogel auszulösen usw.

Aus irgendeinem Grund habe ich keine E-Mail-Benachrichtigung über die Aktivitäten hier im Forum erhalten, daher erst jetzt meine Reaktion. Ich habe das Problem gefunden und gefixt. Ab morgen wird die neue Version beim FHEM Update automatisch verteilt.

Für diejenigen, die es dringender benötigen, anbei die Datei.

@maluk,

erstmal vielen Dank für die Anpasssung.

Erst schien es zu laufen, nach einem Neustart war das Device wieder "active".

Leider, zumindest bei mir, geht das Device "SUBTYPE ACCOUNT" nach einiger Zeit (ca.10 min) wieder auf "inactive".
Ein manuelles "set device reconnect" verbindet zwar wieder, aber nur temporär.

Ich hab jetzt mal  auf "verbose 4" gestellt um Dir vielleicht mehr Infos geben zu können.

cheers
mi.ke

Maluk, vielen Dank für den Fix - Modul läuft bei mir wieder :-)

mi.ke, dass die connection von Arlo_Cloud auf inactive geht, ist seit der Version von Oct 2019 so gewollt.
Sobald, ein event getriggered wird, geht die connection automatisch wieder auf active - das funktioniert bei mir auch ohne Probleme.

LG

Zitat von: Hobbel am 17 Februar 2020, 14:49:34
mi.ke, dass die connection von Arlo_Cloud auf inactive geht, ist seit der Version von Oct 2019 so gewollt.

Zitat von: maluk am 15 Oktober 2019, 20:15:25
wenn alle Basisstationen disarmed sind, wird die Verbindung zur Cloud abgebaut.

Das hatte ich anders verstanden, da die Basisstationen nicht alle disconnected waren.
Dann schau ich mal, ob es tut was es soll.
Danke für dir Info

cheers
mi.ke

Hallo maluk,

bei mir geht es auch wieder. Vielen Dank dafür.

Ich hätte mal noch eine andere Frage:
Ich würde gerne selektiv die Cams schärfen. Ich hab es bei mir so eingestellt wenn ich oder meine Freundin daheim sind (Handy eingebucht im WLAM) wird Arlo disarmed.
Ich hätte aber gerne dass z.B. die Aussencam überwacht auch wenn wir da sind.
Wie könnte ich das lösen?

Liebe Grüße
Oli

Zitat von: ojb am 18 Februar 2020, 18:39:56
Ich würde gerne selektiv die Cams schärfen. Ich hab es bei mir so eingestellt wenn ich oder meine Freundin daheim sind (Handy eingebucht im WLAM) wird Arlo disarmed.
Ich hätte aber gerne dass z.B. die Aussencam überwacht auch wenn wir da sind.
Wie könnte ich das lösen?

Hi Oli,

das geht über Modus.
In der Web-Oberfläche legst Du Dir verschiedene Modi an (Standard ist Aktiviert+Deaktiviert).
Wenn Du nun einen "zuHause" Modus anlegst, kannst Du festlegen, welche Kameras was machen sollen.

FHEM sagtst Du es dann so (über ein notify das auf die Anwesenheit triggert):
set Basisstation mode zuHause

Hoffe das hilft Dir

cheers
mi.ke

Hi mi.ke,

super. Das haut hin. Danke.

Liebe Grüße
Oli

Hallo mi.ke,

danke ...,

Gernot

@maluk

Ich habe ein Verständnisproblem mit der im Oktober eingeführten Änderung des connect-Verhaltens des Subtype ACCOUNT "aktiv|inaktiv", die seit Oktober2019 zusätzlich eingebaut wurde.

Quelle:"Device specific help"
expiryTime
Subtype ACCOUNT: Wenn alle Basisstation auf "disarmed" stehen, wird die Verbindung zur Cloud nach der hier angegebenen Zeit beendet. Bei einer Aktion mit einem Arlo-Gerät wird eine neue Verbindung aufgebaut. Angabe in Sekunden, Standard ist 600 (10 Minuten). Durch Angabe von 0 kann die Verbindung dauerhaft bestehen bleiben."

a.)
Ich habe mehrere Basisstationen am laufen, von denen 99% der Zeit mind. eine auf "armed" steht. Die Dritte meist auf "offline"
Trotzdem schaltet der "Subtype ACCOUNT" nach 10 Minuten auf "inaktiv".  Dies dürfte ja nach der Beschreibung nicht der Fall sein.

b.)
Das funktioniert meist.
Aber nicht belastbar. Der Status bleibt dann, trotz trigger, auf "inaktiv".

c.)
auch wenn "expiryTime" auf 0 steht, wechselt das device auf "inaktiv"

Kann es sein, dass das Verhalten an den mehrfach vorhandenen Basisstationen liegt?
Ich muss getehen, dass ich die in der Oktober-Version eingebauten Änderungen bis dato nicht getestet hatte, da die für mich stabilste Version die Rev.20219 vom 21.09.2019 war.

Oder lieg ich völlig falsch?

Danke und Grüße
cheers
mi.ke

PS.

Zitat von: mi.ke am 20 Februar 2020, 11:48:26
Ich muss getehen, dass ich die in der Oktober-Version eingebauten Änderungen bis dato nicht getestet hatte, da die für mich stabilste Version die Rev.20219 vom 21.09.2019 war.

@maluk
Ich habe jetzt erstmal zur Überbrückung die letzte Änderung zur Anmeldung in die Version Rev.20219 vom 21.09.2019 eingebaut, da leider das Device mit der neusten Version immer wiedermal auf inaktiv geblieben ist und so Bewegungen, die die APP gemeldet hat, nicht von FHEM erkannt wurden.
Seit dem wieder einwandfreier und störungsloser Betrieb.

Vielleicht könntest Du ja noch mal schauen?
Wenn Du LOGs oder irgendwas brauchst, sag einfach Bescheid.

cheers
mi.ke

Gibt es schon eine Idee, wie man mit der ab Anfang kommenden Jahres wohl verpflichtenden 2FA umgehen kann? Ich denke, wir sollten Arlo wissen lassen, dass man das entweder weiterhin optional machen muss oder wenigstens eine Art Application Password einführt...

https://community.arlo.com/t5/Arlo/Mandatory-Two-Step-Authentication-Verification-a-Bad-Idea/m-p/1760890#M4454

Ich habe mir über die verpflichtende 2FA mal Gedanken gemacht: vermutlich kann man protestieren, so viel man möchte. Arlo wird es trotzdem einführen.

Was mir momentan als mögliche Lösung einfällt: es gibt unter Linux den Gammu SMSD, mit dem man SMS empfangen kann. Dazu benötigt man einen Surf-Stick und eine SIM-Karte. Mit einem Prepaid-Tarif sollten da auch keine großen Kosten anfallen, da ja nichts versendet, sondern nur empfangen wird. Ich werde das bei Gelegenheit mal ausprobieren. Wenn man SMS empfangen kann, kann ich das Arlo-Modul so umstellen, dass es mit 2FA zurechtkommt.

Theoretisch gibt es auch virtuelle SMS-Dienste, aber ich habe auf die Schnelle keinen günstigen gefunden, der für den Zweck verwendbar wäre. Falls irgendjemand eine Idee hat, wie man zuverlässig kostenlos SMS auf dem Raspberry empfangen kann, gerne hier Vorschläge machen  :)

Ich experimentiere gerade damit ein wenig rum. Allerdings nutze ich ja nicht mehr das FHEM Modul sondern ein eigenes Python-Script basierend auf https://github.com/jeffreydwalter/arlo. M.E. bringt das ganze aber nur sinnvoll etwas, wenn wir es schaffen, dass man nicht andaurnd eine SMS benötigt sondern ein Device als TRUSTED kennzeichnen kann und damit nach einmaliger Authentifizierung keine weitere 2FA Abfrage mehr bekommt. Angeblich soll das so ja mit der iPhone-App z.B. funktionieren (hab ich aber noch nicht getestet).

Meine Experimente sind aber auch noch seh am Anfang. Erschwerend kommt hinzu, dass ich kein Programmierer bin, sondern das mit Try & Error machen muss ;-)

Das FHEM-Modul nutze ich übrigens deswegen nicht mehr, weil es ja bei mir mit einer Basis-Station und 2 Bridges mit mehreren Arlo Lights nie zufriedenstellend funktioniert hatte.

Vielleicht rudert Arlo doch wieder zurück. Aus diesem Chat-Ausschnitt mit dem Arlo-Support kann man ablesen, dass es doch eine Wahlfreiheit bleibt. Man kann nur hoffen.

https://community.arlo.com/t5/Arlo/Mandatory-Two-Step-Authentication-Verification-a-Bad-Idea/m-p/1762753#M74989

Bad news, Arlo scheint genauso beratungsresistent zu sein, wie sonst auch. Der Kundenservice ist echt unterirdisch bei denen :-(

Zitat

As part of our efforts to continually evolve and further strengthen our privacy and security practices, Arlo announced it will now require all users to use two-factor authentication when logging into their Arlo account. The new security mandate will go into effect for new users in Q2 of 2020, and will require existing Arlo users to enable the feature on their current Arlo accounts by end of year. While Arlo has strongly encouraged its users to enable two-factor authentication since its introduction, Arlo believes requiring this added layer of security is yet another measure we can take to help our users safeguard their accounts and their data.



Arlo Team

Zitat von: maluk am 22 Dezember 2018, 14:15:58
Für deine Wünsche bräuchte ich nochmal deine Unterstützung: bitte das Cloud-Device auf verbose 5 stellen, damit die JSON-Antworten geloggt werden. Bitte danach UpdateReadings aufrufen, dann sollten auch JSON-Antworten für die Lights kommen. Diese bräuchte ich für die Implementierung des Lights-Status und -Battery-Level. Danach bitte eine Bewegung an einem Light auslösen und das JSON, das hier kommt, ebenfalls mir zusenden.

Beim Zeitplan weiß ich, was zu tun ist. Das gibt es auch bei normalen Basisstationen.

Guten Tag liebe FHEM Gemeinde,

weiss zufällig jemand wie ich über FHEM mit "set Arlo_Basis mode ..." den Zeitplanmodus eingestellt bekomme?

Keiner der wüsste wie dies möglich wäre?  :(

Aktuell geht das mit dem Modul nicht, da es beim Schedule um keinen Mode handelt. Ich kann das erweitern, dauert aber ein bisschen.

Zitat von: marcopolo1312 am 17 April 2020, 10:57:15
wie ich über FHEM mit "set Arlo_Basis mode ..." den Zeitplanmodus eingestellt bekomme?

Jetzt bin ich mal neugierig....

Du hast FHEM mit all seinen Einstellmöglichkeiten (Stichwort: "Schweizer Taschenmesser")
und Du kannst über das arlo-Modul via FHEM Deine Kameras "schalten und walten" wie Du willst....

...und Du hast vor, den starren, unflexiblen "Zeitplanmodus" zu nutzen?!?

Versteh ich nicht! Hast Du eine bestimmte Anforderung, die dies notwendig macht?

cheers
mi.ke

Zitat von: mi.ke am 24 April 2020, 01:12:25
Jetzt bin ich mal neugierig....

Du hast FHEM mit all seinen Einstellmöglichkeiten (Stichwort: "Schweizer Taschenmesser")
und Du kannst über das arlo-Modul via FHEM Deine Kameras "schalten und walten" wie Du willst....

...und Du hast vor, den starren, unflexiblen "Zeitplanmodus" zu nutzen?!?

Versteh ich nicht! Hast Du eine bestimmte Anforderung, die dies notwendig macht?

cheers
mi.ke

Das ist korrekt. Klar gibt es auch die Möglichkeit das Ganze über FHEM zu steuern und nicht mit dem eingeschränkten Zeitplan von Arlo zu arbeiten. Leider ist es jedoch so, dass ich die Automation bei Freunden auf einem kleinen Raspy eingerichtet habe. Die Freunde kennen sich leider überhaupt nicht mit FHEM oder sonstigen technischen Dingen aus. Um hier also nicht die Flexibilität zu nehmen, auch selbst Änderungen am Zeitplan vorzunehmen, hatte ich geplant den Zeitplan von Arlo zu nutzen, welcher eingeschaltet wird sobald eine Aktion ausgeführt wird.

Zitat von: marcopolo1312 am 24 April 2020, 10:38:53
Die Freunde kennen sich leider überhaupt nicht mit FHEM oder sonstigen technischen Dingen aus. Um hier also nicht die Flexibilität zu nehmen, auch selbst Änderungen am Zeitplan vorzunehmen, hatte ich geplant den Zeitplan von Arlo zu nutzen, welcher eingeschaltet wird sobald eine Aktion ausgeführt wird.

Danke für die Erklärung!
Wie gesagt, ich war nur neugierig

cheers
mi.ke

Ich bekomme seit heute keine Update von den Kameras!
Hat das noch wer? Bzw. kann mir wer helfen?

Zitat von: dinkel75 am 04 Juni 2020, 10:18:51
Ich bekomme seit heute keine Update von den Kameras!
Hat das noch wer? Bzw. kann mir wer helfen?

Hier läufts noch.

Hast Du mal das Device SUBTYPE ACCOUNT reconnected?

Hilft leider nicht.
Hab von einer uralt Basisstation auf eine 4030 (arlo pro 2) gewechselt.
Naja kann man nix machen.

Zitat von: dinkel75 am 04 Juni 2020, 10:18:51
Ich bekomme seit heute keine Update von den Kameras!
Hat das noch wer? Bzw. kann mir wer helfen?

Zitat von: dinkel75 am 04 Juni 2020, 21:32:25
Hab von einer uralt Basisstation auf eine 4030 (arlo pro 2) gewechselt.

Na, wenn das dann mal nicht eine total detailierte Problembeschreibung war...

Ich wollte halt mal wissen, ob es generell gerade ein Problem gibt.

Die neue Basestation ist eine VMB4500. Laut der github Seite ist dieses Modell leider nicht unterstützt. Vielleicht kann man hier etwas anpasse. Werd mal ein bisschen probieren.
Vielleicht gibts ja Unterstützung von @maluk

Hallo,

bei mir funktioniert das Arlo-Modul ganz gut. Allerdings wird mein Log ziemlich zugemüllt mit den folgenden Einträgen:

2020.07.03 22:26:35 2: (Re)starting Arlo event listener.
2020.07.03 22:26:35 2: Invalid Arlo event response: requestId: xxx
2020.07.03 22:26:35 2: Invalid Arlo event response: x-transaction-id: xxxx
2020.07.03 22:26:35 2: Invalid Arlo event response: cf-request-id: xxx

die kommen genau alle 30 Minuten. Kann man das irgendwie abstellen?

hat keiner sonst das Problem mit den Log-Einträgen?

hab gerade noch etwas rumprobiert und die Einträge kommen auch, wenn man in der Arlo Cloud auf Reconnect geht. Obwohl die Einträge auf einen Fehler hindeuten funktioniert aber alles. Die Cloud wird als Active angezeigt und die Readings werden auch alle aktualisiert.

Kann ich bestätigen, gleiches Phänomen

wenn es Euch stört, könnt Ihr bei dem Subtype ACCOUNT "verbose 1" einstellen.
Dann sind die Meldungen weg.

Hallo zusammen,

bin nicht sicher ob die Frage vielleicht schon behandelt wurde, habe aber nichts gefunden. Die Basestation VMB5000 (für Ultra's) scheint sich hartnäckig dem Zugriff über API's zu entziehen. Auch wenn ich direkt die python Beispiellskripte, die mit mehreren Basisstationen laufe (von https://github.com/jeffreydwalter/arlo (https://github.com/jeffreydwalter/arlo)) verwende, wird immer nur meine VMB4000 gefunden, nicht aber die VMB5000. Ist das so, weil die API vielleicht "nur" neu und/oder anders ist, dann gäbe es ja Hoffnungsschimmer, oder weil es da gar keine (offene) API mehr gibt?

Grüße
eddy

Hallo zusammen,
hat jemand von Euch mittlerweile mit der Zwei-Faktor-Authentifizierung herumexperimentiert? Nachdem ich jetzt immer häufiger Benachrichtigungen von Arlo bekommen habe, dass das demnächst verpflichtend wird, hab ich mal auf deren Hilfe-Seite geschaut - dort liest sich es so, als könne man die App auf dem Handy nutzen und damit andere Gerätenach einer Push-Nachricht freigeben, wenn die sich versuchen einzuloggen.
Hab's dann mal direkt probiert. Für ein zweites Handy hat das auch prima geklappt, aber bei FHEM eben nicht, da dann die Push-Nachricht auf dem Handy ausbleibt. Da ich die Arlo-Steuerung über FHEM richtig liebe, habe ich die Zwei-Faktor-Authentifizierung sofort wieder deaktiviert. Ich befürchte aber, das wird nicht dauerhaft so aufrecht zu erhalten sein - wie regelt Ihr das?
Danke Euch!

Ich habe das Thema 2FA längere Zeit verdrängt, aber Arlo macht jetzt zum 31.10. wohl doch ernst. Wie die 2FA API funktioniert, weiß ich grundsätzlich - daran wird es nicht scheitern. Das Problem ist die Weiterleitung des SMS-Text an FHEM. Eine vernünftige App, die das "out of the box" erledigt, habe ich leider nicht gefunden. Auf GitHub habe ich für Android eine ganz einfache App gefunden, auf deren Basis ich das evtl. implementieren könnte (https://github.com/laudrup/MessagingForwarder). Daran werde ich mich die nächsten Wochen mal versuchen - ich bin zwar Java-Entwickler, aber Android Apps programmiere ich normalerweise nicht.

Generell wird gelten: es wird nur funktionieren, wenn man ein Android Handy hat und sich dieses im lokalen Netzwerk befindet oder man die URL in FHEM, die für die 2FA-Authentifizierung entgegenimmt, über für das Internet freigeschaltet hat.

Ich bin gerade dabei, mit einer Python-Prozedur basierend auf https://github.com/twrecked/pyaarlo zu experimentieren.

Derzeitiger Stand ist, dass ich einen Service basierend auf einer Python-Prozedur habe, der auf einem TCP-Socket hört und ich dann von FHEM aus Kommandos an den Service schicke, die dieser dann ausführt. Allerdings benötige ich auch nur so Dinge wie Aktivieren und Deaktivieren bzw. Umschalten zu bestimmten Modes für meine Kameras und Lichter.

"pyaarlo" unterstützt 2FA via Mail. Das klapt soweit auch schon ganz gut.

Bin noch in der frühen Experimentierphase. Sobald ich hier was einigermassen stabiles habe, werde ich hier berichten.

Danke für den Hinweis. In der API scheint es tatsächlich eine Möglichkeit zu geben, die 2FA-PIN per Mail anzufordern. Ich dachte eigentlich, das geht nur per SMS, weil nur eine Handy-Nr. als 2FA in den Einstellungen von Arlo angeben kann.

Das macht die Sache natürlich viel einfacher (keine Smartphone App), da ich Mails auch direkt auf FHEM heraus abrufen kann.

Zitat von: maluk am 05 Oktober 2020, 10:40:40
Danke für den Hinweis. In der API scheint es tatsächlich eine Möglichkeit zu geben, die 2FA-PIN per Mail anzufordern. Ich dachte eigentlich, das geht nur per SMS, weil nur eine Handy-Nr. als 2FA in den Einstellungen von Arlo angeben kann.

Das macht die Sache natürlich viel einfacher (keine Smartphone App), da ich Mails auch direkt auf FHEM heraus abrufen kann.

Die mit dem "Arlo Konto verknüpfte E-Mail-Adresse" scheint sogar Standard zu sein, wenn nicht SMS oder Pushnachricht gewählt wird.
https://kb.arlo.com/de/000062288/Was-ist-zweistufige-Verifizierung-und-wie-richte-ich-sie-ein

cheers
mi.ke

So, ich habe mal meine Prozedur public gemacht, die ich für die Steuerung von Arlo aus FHEM heraus mittlerweile einsetze. Ich brauche aber auch nur aktiv/inaktiv schalten meiner Kameras, d.h. mehr ist bisher dort auch nicht implementiert. Es funktioniert aber auch mit der aktivierten Zwei-Faktor-Authentifizierung einwandfrei. Man benötigt dazu aber ein IMAP-Konto an dem man sich die 2FA-Mail schicken lassen kann. Wenn jemand Fragen hat, gerne melden.

https://github.com/m0urs/arlo-fhem

Eine kurze Zwischen-Info: ich bin an der Integration der 2FA mit E-Mail dran und im Prinzip funktioniert das auch. Das große Problem ist, dass das HttpUtils-Modul von FHEM gerade noch viele Timeouts verursacht, da der Arlo-Server bei seinen Antwort das Header-Attribut "Content-Length" nicht mitsendet. Hier werde ich wohl selbst Support benötigen, daher dauert es noch ein bisschen mit der Lösung. Außerdem wird die Authentifizierung natürlcih viel komplizierter und dauert dadurch auch viel länger. Das bisherige Vorgehen, dass bei abgebrochener Verbindung ein Login synchron durchgeführt wird, wird daher auch nicht mehr funktionieren. Aber auch hierfür wird es eine Lösung geben ...

Für die Beta-Tester gibt es jetzt eine erste Version, die 2-Faktor-Authentifizierung per E-Mail unterstützt (siehe Anhang). Damit das umgeschriebene Modul funktioniert, sind folgende Vorarbeiten notwendig:

Zuerst muss der IMAP-Client für Perl installiert werden:

sudo apt-get install -y libmail-imapclient-perl

Danach muss in FHEM das Arlo_Cloud Device erweitert werden: zunächst das Attribut mailServer setzen. Hier muss der IMAP-Server des Mail-Providers (z.B. imap.gmx.net) eingetragen werden. Bitte beachten, dass die Verbindung zum IMAP-Server verschlüsselt erfolgt und Port 993 verwendet wird. Falls irgendjemand hier etwas anderes benötigt, bitte melden. Außerdem muss die Definition für das Arlo_Cloud Device um das E-Mail-Passwort erweitert werden. Hierzu im Device auf DEF klicken und dort hinter den letzten Crypt-Parameter mit Leerzeichen getrennt das Passwort für den Mail-Server eingeben. Nach Klicken auf "modify Arlo_Cloud" wird auch dieses Passwort verschlüsselt.

Danach einen reconnect durchführen und beten, dass es funktioniert  :)  Zunächst erfolgt die normale Anmeldung bis zur Anforderung des 2FA-Codes. Dann wird 5 Sekunden gewartet und die E-Mails werden geprüft. Anhand der Absender-Adresse und einem enthaltenen 6-stelligen Code wird die E-Mail erkannt. Der Code der neuesten E-Mail wird verwendet, um sich anzumelden. Wenn das schief geht, wird nach 5 Sekunden ein erneuter Versuch unternommen.

Falls das mit den Mails noch nicht ganz funktioniert, kann man mit "set Arlo_Cloud loginSecondFactor 123456" den per Mail erhaltenen Code auch selbst angeben (das wir normal automatisch aufgerufen).

Ganz fertig bin ich mit der Implementierung noch nicht, da aufgrund des asynchronen Anmelde-Vorgangs einige Anpassungen notwendig sind:

- Retry bei temporären Anmeldeproblemen ist noch nicht implementiert (war in der bisherigen Version enthalten)
- Abfragen von Recordings funktioniert nur, wenn die Verbindung aktiv ist
- Starten von Recordings funktiniert vermutlich nur sauber, wenn die Verbindung aktiv ist

Bin auf Eure Rückmeldungen gespannt. Bitte das Modul nur auf Test-Systemen einsetzen oder dann, wenn Ihr es in Ordnung ist, dass in den nächsten Tagen nicht alles reibungslos funktioniert.

Wenn der Login des Emails ebenfalls mit 2FA ist, dann kann das nix werden, oder?

Nein, das kann nicht klappen. Du müsstest dir dann selbst was bauen, wie du den 2FA-Code abrufst und dann den Aufruf "set Arlo_Cloud loginSecondFactor 123456" auslösen.

Aber noch ein Hinweis: ich habe für Arlo eine neue E-Mail-Adresse angelegt, damit das getrennt von meiner normalen E-Mails abläuft. Wenn du das gleiche machst, ist dein Problem gelöst  :) Bei GMX geht das ohne 2FA. Du musst danch nur deinen Arlo-Account auf die neue E-Mail-Adresse umstellen.

So hab ichs auch gemacht. Neue GMX Adresse und fertig!

2FA - funktioniert tadellos!

Ich habe das Modul jetzt bei FHEM eingecheckt. Ab morgen Vormittag wird es beim nächsten FHEM-Update mitgeliefert. Hier nochmal die Zusammenfassung, wie die 2-Faktor-Authentifizierung aktiviert wird:

Zuerst muss der IMAP-Client für Perl installiert werden:

sudo apt-get install -y libmail-imapclient-perl

Danach in FHEM das Arlo_Cloud Device erweitern: zunächst das Attribut mailServer auf den IMAP-Server des Mail-Providers (z.B. imap.gmx.net) setzen. Bitte beachten, dass die Verbindung zum IMAP-Server verschlüsselt erfolgt und Port 993 verwendet wird. Außerdem muss die Definition für das Arlo_Cloud Device um das E-Mail-Passwort erweitert werden. Hierzu im Device auf DEF klicken und dort hinter den letzten Crypt-Parameter mit Leerzeichen getrennt das Passwort für den Mail-Server eingeben. Nach Klicken auf "modify Arlo_Cloud" wird auch dieses Passwort verschlüsselt.

Ich habe heute auf 2FA umgestellt, klappt soweit gut - vielen Dank für die Anpassung des Moduls!

Hier ein paar Tipps, die mir bei der Umstellung aufgefallen sind:

• Wenn nach dem FHEM-Update und nachfolgendem FHEM restart der IMAP-Client für Perl noch nicht installiert ist, dann werden keine Arlo devices mehr in FHEM geladen und angezeigt.
• Wenn man eine neue GMX E-mail für 2FA einrichtet, dann nicht vergessen in den E-Mail Einstellungen bei GMX Pop3/Imap zu aktivieren.
• Wenn man den neuen ACCOUNT zum 2FA login bei FHEM verwenden möchte, dann das bestehende Arlo_Cloud device löschen und entsprechend neu anlegen. Im FHEM Arlo wiki ist der entsprechende define zu finden, allerdings muss zwischen meinArloPasswort und meinEmailPasswort ein Leerzeichen sein.

Hallo liebe mitleidende,
Erst einmal vielen Dank an maluk für die viele Arbeit!!!

Ich habe die 2FA bei mir eingerichtet.
Der Login funktioniert mal und mal nicht. Irgendwann geht die Verbindung auf inaktive.
Wenn ich dann auf reconnect  klicke habe ich immer login failed einen neue Verbindung geht nicht mehr.
Mach ich da was falsch oder ist das Modul noch nicht stabil und wird da noch dran gearbeitet?

Überings:
Ich kann bei Arlo immer noch die 2FA abschalten. Bei einem gute Passwort in der Arlo Cloud währe es für mich völlig i.o. gewesen. Leider kann man das neue Modul nicht mehr für die 1FA benutzen.
Schade.

einen schönen Sonntag noch für alle
Gruß AyshaHM  :D

Ich hatte ähnliche Probleme. Die konnte ich lösen in dem ich Arlo.com auf die Whitelist gesetzt habe. Vorher hat er die eMails mal als Spam oder unbekannt wegsortiert.

Soweit ich weiss dreht Arlo am 30.11. die 1FA ab.
Ich habe gute Erfahrungen damit gemacht das Arlo_Cloud device mit dem attr expiryTime 0 zu versehen.
Damit geht die Verbindung nicht mehr auf inactive und das Modul funktioniert gut.

Hallo,

ich habe auch gerade umgestellt und es schein zu funktionieren. Vielen vielen Dank für das Modul.

Liebe Grüße
Oli

Ok, ich hatte auch das Problem, dass die Cloud nach einiger Zeit auf 'inactive' geht.
Mit 'expireTime 0' scheint es zu gehen.

Ich wollte übrigens den Zustand, also z.B. wann geht die Cloud auf 'inactive' in einem FileLog tracken. Das schaffe ich aber nicht, es werden zwar die Zustände wie 'reconnect', 'checkMail' geloggt aber nicht der 'inactive' und 'active'.
Habe dann mein Glück versucht mit 'addStateEvent = 1' im FileLog, aber das bringt auch nichts.

Any help appreciated.

Liebe Grüße
Oli

Die expiryTime dient dazu, die Verbindung zur Cloud nach der definierten Zeit abzubauen, wenn keine Basisstation mehr aktiv ist (also alle Basisstationen im Status disarmed oder offline sind). Wer das nicht möchte, muss wie beschrieben die expiryTime auf 0 setzen. Wenn man die expiryTime gesetzt hat, wird das Inaktiv-Setzen im Logfile mit Verbose-Level 3 geloggt ('Arlo set to inactive.'). Falls das Attribut verbose auf 2 oder 1 gesetzt ist, findet man im Logfile keine Einträge.

Ansonsten kann es noch Timeout- oder Fehler-Situationen geben, in denen der Status auf inactive wechselt, aber auch in diesen Fällen müsste es im Logfile den oben beschriebenen Eintrag geben.

Ich selbst arbeite ausschließlich mit expiryTime, da beim Setzen des arm-Status einer Basisstation automatisch wieder die Verbindung aufgebaut wird. Solange die Kamera nichts überwachen, brauche ich auch keine Cloud-Verbindung. Der einzige Nachteil daran ist, dass das Abrufen von Recordings aus dem inactive-Status heraus länger dauert.

Hallo zusammen,
nach setzen des Attributes expireTime 0 scheint die Verbindung zur Cloud ok zu sein.
Mit autocreate wurden meine Station und die Kameras ohne Probleme angelegt.

Das war es aber auch schon weder die Station noch die Kameras reagieren auf Befehle.
Was mache ich falsch? :'(

Danke für eure Hilfe im Voraus!!

Gruß AyshaHM

Gibt es im Logfile auffällige Einträge? Falls nicht, kannst du mal das Attribut verbose auf 4 setzen und prüfen, ob dann im Logfile Hinweise zu finden sind, warum es nicht funktioniert. Falls das auch nicht hilft, kann mit verbose 5 die gesamte Kommunikation zwischen FHEM und Arlo Cloud geloggt werden.

Hallo maluk,

Danke für das Update.
Hast du einen Tipp, wie ich den Account einrichte, wenn der Benutzername vom Mail Server nicht die E-Mail Adresse ist?
Viele Grüße
Frank

Hallo Frank,
um einen von der E-Mail-Adresse abweichenden Benutzernamen nutzen zu können, muss ich das Modul anpassen. Ich werde das in den nächsten Tagen machen und hier melden.
Viele Grüße
maluk

Guten Abend

wenn ich FHEM neu starte kommt neuerdings folgende Meldung im Log:

[Sat Dec 26 10:36:10 2020] fhem.pl: %defptr{...} in scalar context better written as $defptr{...} at ./FHEM/49_Arlo.pm line 860, <$fh> line 1329.

Linie 860
      my $state = %defptr{$key}->{STATE};

Der gesamte Block mit Linie 860
sub Arlo_CheckBasestationsInactive() {
  my %defptr = %{$modules{$MODULE}{defptr}};
  foreach my $key (keys %defptr) {
    if (substr($key, 0, 1) eq 'B') {
      my $state = %defptr{$key}->{STATE};
      if ($state ne 'disarmed' && $state ne 'offline') {
        return \0;
      }
    }
  }
  return \1;
}

Linie 1329:
my $name = $hash->{NAME};

Und der gesamte Block mit Linie 1329:
sub Arlo_EventPolling($) { 
  my ($hash) = @_;
  my $con = $hash->{helper}{con};
  my $name = $hash->{NAME};

  if (!defined($con->{conn})) {
    Log3 $name, 3, "Arlo connection not defined, stop event polling.";
    return;
  }

Mir sagt das grad gar nix. Jemand eine Idee? Danke.

Lg C

@choetzu: Danke für den Hinweis, ich habe das korrigiert.

@FrankieSOC: ich habe den E-Mail-Benutzername als optionalen Parameter in die Definition des Cloud-Device aufgenommen:
define Arlo_Cloud Arlo ACCOUNT <hans.mustermann@xyz.de> <meinArloPasswort> <meinEmailPasswort> <meinEmailBenutzername>

Wenn man "meinEmailBenutzername" weg lässt, wird die E-Mail-Adresse als Benutzername für den Mailserver verwendet (bisheriges Verhalten). Bitte probiere das mal aus.

Wichtig: ich habe das Modul gerade eingecheckt, über den Update-Mechanismus von FHEM wird es immer erst am Folgetag verteilt. Also bitte frühestens morgen den Update durchführen.

Zitat von: maluk am 27 Dezember 2020, 10:15:45
@choetzu: Danke für den Hinweis, ich habe das korrigiert.

Danke. Aber jetzt kommt beim Reboot von FHEM folgender Log-Eintrag. Sorry..

[Mon Dec 28 19:56:03 2020] fhem.pl: Use of uninitialized value in concatenation (.) or string at ./FHEM/49_Arlo.pm line 56, <$fh> line 4451.

Zeile 56
    $hash->{DEF} = "ACCOUNT $cryptUser $cryptPasswd $cryptMailPasswd $a[6]";

Zeile 4451 gibts im Alro.pm gar nicht. Hmm..

lg c

Die Anpassung für den abweichenden Mail-Benutzernamen war etwas quick&dirty. Ich habe dsa korrigiert, ab morgen sollte die Warnung nicht mehr kommen.

Guten Morgen Zusammen,

kann es sein, dass das Arlo-Modul entfernt wurde? Habe Gestern ein "Update All" auf meinem Raspberry gemacht und nun sind die Devices weg. In der Fhem CFG sind die Defines noch vorhanden, jedoch wenn ich diese speicher, sagt er mir das er das Modul Arlo nicht findet?  :-\  :'(

Hat noch jemand das Problem bzw. ggf. eine Lösung? =)

Vielen Dank & Grüße

Hallo Chuellma,

das Modul ist noch da. Es kann aber sein, dass beim Start ein Fehler aufgetreten ist und daher die Devices nicht mehr da sind. Bitte prüfe dein Logfile, ob sich dort irgendwelche Fehlermeldungen bzgl. Arlo befinden.

Hallo Maluk,

danke für den Tipp, es ist tatsächlich ein Start Problem des PMs.

reload: Error:Modul 49_Arlo deactivated:
Can't locate Mail/IMAPClient.pm in @INC (you may need to install the Mail::IMAPClient module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/49_Arlo.pm line 13, <$fh> line 212.
BEGIN failed--compilation aborted at ./FHEM/49_Arlo.pm line 13, <$fh> line 212.


Liegt wohl daran, da ich nie die 2 FA aktiviert habe. Lief bisher trotzdem weiter.

Hast du ne Idee wie ich das Problem lösen kann?

Danke & Grüße

Du musst folgendes Perl-Modul installieren - unabhängig davon, ob 2FA verwendet wird oder nicht:

sudo apt-get install -y libmail-imapclient-perl

Super, vielen Dank. Dachte das brauche ich nur bei 2 FA. Installiere ich später gleich ma. =)

Hallo Maluk,

herzlichen Dank für Dein Modul, dass ich seit einiger Zeit nach einer problemlosen Installation wie gewünscht nutzen kann. Nach dem Auslösen eines Türschalters erstelle ich mit der Kamera ein snapshot, dass dann auf dem Tablett angezeigt wird. Das klappte bisher problemlos. Leider kann ich mich seit gestern nicht mehr in die Arlo-Cloud einwählen. Im Log erscheint folgender Fehler:


2021.03.09 20:35:03 3: Request second factor.
2021.03.09 20:35:04 3: Arlo Login is waiting for second factor.
2021.03.09 20:35:15 3: Trying to complete 2FA Login with code 583190
2021.03.09 20:35:17 2: (Re)starting Arlo event listener.
2021.03.09 20:35:20 2: Arlo event queue error: wrong http status 401.
2021.03.09 20:35:20 2: Invalid Arlo event response: {"data":{"error":"1022","message":"Access token is invalid.","reason":"Access token is invalid"},"success":false}
2021.03.09 20:35:48 3: Updated Arlo readings. Next automatic update in 3600 seconds


Der Login in die Arlo-Cloud über den Browser klappt. Was kann ich jetzt versuchen?

Herzlichen Dank und Grüße

Ich habe seit einigen Tagen ebenfalls das Problem, dass keine Snapshots mehr erstellt werden.
Im Gegensatz zu dir funktioniert die Anmeldung in der Cloud etc. fehlerfrei.

Über 'autocreate' werden auch keine Geräte mehr angelegt - ich hatte testweise eine Kamera gelöscht. Irgendetwas scheint also nicht mehr zu passen...

Das gleiche bei mir:

2021.03.10 08:34:27 3: Request second factor.
2021.03.10 08:34:28 3: Arlo Login is waiting for second factor.
2021.03.10 08:34:44 3: Trying to complete 2FA Login with code 412002
2021.03.10 08:34:46 2: (Re)starting Arlo event listener.
2021.03.10 08:34:47 2: Arlo event queue error: wrong http status 401.
2021.03.10 08:34:47 2: Invalid Arlo event response: {"data":{"error":"1022","message":"Access token is invalid.","reason":"Access token is invalid"},"success":false}

Vermutlich hat Arlo mal wieder etwas an den Services geändert. Ich muss mir das mal ansehen, komme aber momentan leider nicht dazu.

Hab auch noch nicht auf 2FS umgeschaltet und auch sonst alles gleich gelassen. Cloud zeigt er als Connected an aber die Kameras liefern anscheinen keine Readings mehr und Snapshots gehen nicht mehr. Neustart hat auch nicht geholfen

Zitat von: StephanFHEM am 17 März 2021, 12:38:20
Hab auch noch nicht auf 2FS umgeschaltet und auch sonst alles gleich gelassen. Cloud zeigt er als Connected an aber die Kameras liefern anscheinen keine Readings mehr und Snapshots gehen nicht mehr. Neustart hat auch nicht geholfen

exakt das Gleiche bei mir.

errorLog:
2021.03.17 18:14:34 2: (Re)starting Arlo event listener.
2021.03.17 18:14:34 2: Arlo event queue error: wrong http status 401.
2021.03.17 18:14:34 2: Invalid Arlo event response: {"data":{"error":"1022","message":"Access token is invalid.","reason":"Access token is invalid"},"success":false}

LG
mi.ke

Hmm, an meiner Kamera hängen einige Routinen.. Any News? Workaround?

@maluk
wenn Du Unterstützung brauchst sag Bescheid was Du an LOGs etc benötigst.

Oder vielleicht hast Du einen Tipp für eine Interimslösung?

@all
Interessant das man erst merkt wie sehr etwas feht wenn es nicht mehr funktioniert.

ohne nerven zu wollen:-) gibt es schon etwas neues? ich bekomme bisher immer ein Bild wenn es klingelt - was manchmal echt hilft... jetzt ist auf dem Bild immer nur der selbe Schnee von vor ein paar Wochen zu sehen..

Vielleicht als möglicher workaround für Einige:
Wenn ich auf das Arlo_Cloud device ein reconnect mache, dann kann man nach ca. 15 sec (sobald das cloud device wieder auf Status active geht) für den Zeitraum von 5-7 Minuten den Mode ändern (also arm/disarm/etc.).  Allerdings werden die readings der devices nicht updated, und auch die snapshot und recording Funktionen der Kamera's aus FHEM heraus funktionieren nicht.
Ist sicherlich nicht super toll, aber immerhin könnte man sich so behelfen, das System bei Abwesenheit/Ankunft scharf/unscharf zu stellen.

Bislang konnte ich die Cams zwar nicht mehr direkt ansprechen, aber der Modus konnte gelesen werde. Seit einigen Tagen geht auch das nciht mehr. Die Arlo_Cloud hängt bei "login" Status... Und nix geht mehr. Bei Euch auch?

Maluk: Wenn du Hilfe brauchst, tell me...

Seit gerade selbes Problem:

Arlo call was not successful: {"data":{"error":"2401","message":"Access token is empty or unauthorized request","reason":"Empty token"},"success":false}

Hallo,

habe auch das Problem mit dem State = login und die selbe Fehlermeldung wie marcopolo1312.

Jemand eine Idee?

Die App wird auch wieder sehr penetrant bzgl. der 2FA. :D

LG Chuellma

Gibt es schon etwas neues zu dem Thema? Scheint ja mehrere zu geben, bei denen die Anbindung Arlo->FHEM nicht mehr richtig läuft...

Zitat von: maluk am 11 März 2021, 17:33:44
Vermutlich hat Arlo mal wieder etwas an den Services geändert. Ich muss mir das mal ansehen, komme aber momentan leider nicht dazu.

Nein, nichts neues.

Es dürfte bei keinem, der das arlo-Modul verwendet, funktionieren, da Arlo irgendwas am Anmeldeprozess geändert hat.

Leider hat maluk keine Zeit das Modul anzupassen, von dem her bleibt nur die Kameras manuell zu steuern
cheers
mi.ke

Edit: Typo

Ich habe jetzt versucht, die Arlo-Anbindung wieder zum Laufen zu bringen, scheitere aber inzwischen schon beim Auth-Request. Hier scheinen neue Sicherheitskomponenten im Einsatz zu sein, ich bekomme immer 403-Meldungen mit einer Captcha-Aufforderung vom Server zurück. Aktuell sieht es nicht danach aus, dass ich das Modul wieder zum Laufen bringen werde.

Ich werde mich parallel mal nach einer Cloud-freien Alternative zu Arlo umsehen. Hardwareseitig sind die Arlo-Kameras ja gut, aber die fehlende offizielle API macht sie für meinen Einsatzzweck quasi nutzlos.

Ich hatte schon mal geschrieben, was ich seit einiger zeit zusammen mit FHEM benutze. Funktioniert auch mit der neuen Cloudflare-Authentication von Arlo und auch mit 2FA. Die Python-Library unterstützt alle möglichen Features der Arlo-Cams. Ich nutze allerdings nur sehr rudimentäre Funktionen, wie Aktivieren/Deaktivieren bzw. Modus umschalten der Kameras und einstellen der Helligkeit. Mehr brauche ich für mich nicht, da ich nur sicherstellen will, dass die Cams aus sind, wenn ich in den Garten gehe bzw. sicher bin, dass die Cams aktiv sind, wenn ich abends ins Bett gehe oder das Haus verlasse etc.

Aber vielleicht hilft es ja jemandem weiter. Bei Fragen, gerne bei mir melden.

https://github.com/m0urs/arlo-fhem

Zitat von: maluk am 25 April 2021, 22:29:56
Ich werde mich parallel mal nach einer Cloud-freien Alternative zu Arlo umsehen. Hardwareseitig sind die Arlo-Kameras ja gut, aber die fehlende offizielle API macht sie für meinen Einsatzzweck quasi nutzlos.

hey maluk, verstehe ich dich richtig, dass du hier dem Arlo Modul die rote Karte gibst und auf ein anderes System setzen willst?

Zitat von: maluk am 25 April 2021, 22:29:56
Ich werde mich parallel mal nach einer Cloud-freien Alternative zu Arlo umsehen. Hardwareseitig sind die Arlo-Kameras ja gut, aber die fehlende offizielle API macht sie für meinen Einsatzzweck quasi nutzlos.

args.... hab gerade weil die Hardware gut ist und genau das mitbringt was ich gesucht habe auf dieses System gesetzt (was ja auch nicht gerade günstig war). Ein Kernbaustein war für mich die Möglichkeit zur FHEM-Anbindung und sich bei Bedarf ein Foto senden zu lassen. es wäre schon ganz schön übel, wenn das plötzlich wegfällt...

Noch habe ich nicht ganz aufgegeben. Momentan werden aber alle meine Anmeldeversuche von Arlo geblockt, daher kann ich noch nicht sagen, wann und ob ich das Modul wieder zum Laufen bekommen.

Zitat von: m0urs am 26 April 2021, 13:07:47
Ich hatte schon mal geschrieben, was ich seit einiger zeit zusammen mit FHEM benutze. Funktioniert auch mit der neuen Cloudflare-Authentication von Arlo und auch mit 2FA. Die Python-Library unterstützt alle möglichen Features der Arlo-Cams. Ich nutze allerdings nur sehr rudimentäre Funktionen, wie Aktivieren/Deaktivieren bzw. Modus umschalten der Kameras und einstellen der Helligkeit. Mehr brauche ich für mich nicht, da ich nur sicherstellen will, dass die Cams aus sind, wenn ich in den Garten gehe bzw. sicher bin, dass die Cams aktiv sind, wenn ich abends ins Bett gehe oder das Haus verlasse etc.

Aber vielleicht hilft es ja jemandem weiter. Bei Fragen, gerne bei mir melden.

https://github.com/m0urs/arlo-fhem

Das Problem liegt auf jeden Fall am Anti-Bot-Schutz von Cloudflare. Beim Python-Modul pyaarlo ist die Komponente cloudscraper eingebunden, die das umgehen soll. Der Zugriff über pyaarlo klappt bei mir aber auch nicht immer.

@m0urs: Hast du hier auch manchmal Probleme? Vielleicht habe ich es mit meinen Tests auch übertrieben und Cloudflare hat meine IP kurzfristig gesperrt  :)

Sicher kann ich auf jeden Fall sagen, dass das Problem nicht ohne Python lösbar sein wird. Die cloudscraper-Komponente führt JavaScript aus, das der Anti-Bot-Schutz normalerweise an den Browser zurückliefert und erhält über den Weg Cookies, die für die weitere Verarbeitung zwingend notwendig sind. Es gibt keine vergleichbare Komponente für Perl und so etwas nachzuimplementieren wäre sehr aufwendig. Mein Plan ist jetzt, die cloudscraper-Komponente so in das FHEM-Modul zu integrieren, dass sie zum Login verwendet wird und danach die Cookies an an mein bisheriges Modul zurückgibt. Aber das wird eine größere Anpassung, die auf jeden Fall Zeit in Anspruch nehmen wird. Zumindest gibt es damit aber eine Chance, das Modul am Leben zu erhalten.

Trotzdem werde ich zukünftig endgültig einen Bogen um Hardware machen, die ausschließlich über die Cloud steuerbar ist und keine offizielle API anbietet.

Hi maluk,

klasse das Du es trotzdem versuchst, vielen Dank dafür.

@all
Achtung, nur meine Meinung:
,,Ich ärgere mich auch maßlos über a.) die hohen Preise für eine gute Hardware, die erstens eine schlechte Software und zweitens schlicht keinen (er ist so schlecht, dass es keiner ist) Support bietet. Ich würde arlo auch nicht mehr kaufen, aber die mehreren hundert Euro sind halt nicht so einfach auf doof wegzuwerfen.
Ist aber bei Netgear (Mutti von arlo) leider Standard, Switche und die Router sind hardwareseitig klasse, aber keine oder nur rudimentäre Firmwareupdates und mieser Support."
meine Meinung ENDE-

Nun aber zurück zum SAML von Cloudflare...
Bei einem Webserver ist es doch so, dass python, php, perl und co serverseitig laufen und javascript auf der Anwenderseite (Browser), also auf dem PC des Users.

Jetzt ohne große Programmierkenntnisse; würde es nicht funktionieren den Login über Perl zu generieren, den Token über ein externes Javascript abzufangen, einen http-Header anzuhängen, den Cookie erzeugen, und im Erfolgsfall wieder zurück auf Perl zu wechseln?
Wenn ein ,,dummer Browser" das ,,out oft he box" kann...ich meine auch gelesen zu haben, dass HTTPMOD (Modul in FHEM) mit Cloudflare umgehen kann (Ich glaube es war die Heizölpreisabfrage)...
Vielleicht könnte man das adaptieren?

...eine 2stufen Authentifizierung über E-Mail stelle ich mir irgendwie viel komplizierter vor

Aber leider hab ich keine Programmierkenntnisse und bin nur Anwender, deshalb den Post bitte nicht überbewerten. 
Vielleicht hilft er ja trotzdem. Wenn nicht, bitte ignorieren
cheers
mi.ke

Zitat von: maluk am 26 April 2021, 22:49:44
@m0urs: Hast du hier auch manchmal Probleme? Vielleicht habe ich es mit meinen Tests auch übertrieben und Cloudflare hat meine IP kurzfristig gesperrt  :)

Ja, beim Testen kam das hin und wieder auch schon mal bei mir vor ... ;-)

In der Praxis funktioniert das bei mir aber seit Wochen absolut stabil. Ich melde mich allerdings auch meistens nur einmal an, wenn nachts mein FHEM einmal durchstartet. Ansonsten bleibt die Anmeldung bestehen und Cloudflare verhält sich damit auch ruhig.

Guten Tag zusammen,

vorab ein großes Dankeschön an Maluk für seine Arbeit und das tolle Arlo Modul.
Ich bin eigentlich nur zu FHEM gekommen, da ich sonst Iobroker und seine Visualisierung nutze und es dort keine Unterstützung für Arlo gibt. Die Verbindung vom IoB zu Fhem funktioniert sehr gut und so konnte ich alles steuern und auch Snapshots abgreifen.

Im Zuge der Suche nach einem Ausweg habe ich mir jetzt in einer VM den Home Assistant installiert, als 4. SchlauHausServer. Unter Hass.io habe ich Arlo mittels HACS und AArlo in voller Funktion.
Schalten, gespeicherte Videos abrufen und !LiveStream! funktionieren.
Ich habe keine Programmierkenntnisse und kenne nicht wirklich die Unterschiede zwischen den Systemen bzw. Modulen.
Meine ganzen Systeme und Module habe ich mithilfe von so hilfreichen Foren wie diesem hier und viel Lesen und lernen, ohne Vorkenntnisse zum Laufen gebracht.

Die Visualisierung im IoB habe ich vorerst über ein Iframe gelöst, in dem das Dashboard des HA mit den Kameransichten und Alarmpanel, sowie den Button für die Bedienung dargestellt wird.
Vielleicht hilft diese Methode dem ein oder anderen zur Überbrückung. Den HA direkt steuern von IoB aus habe ich noch nicht geschafft. Mit Fhem habe ich es noch nicht versucht zu verbinden.

Gruß, Rumpel

@maluk
vielleicht ist hier eine Teillösung versteckt?
https://forum.fhem.de/index.php/topic,119014.msg1134523.html#msg1134523 (https://forum.fhem.de/index.php/topic,119014.msg1134523.html#msg1134523)

cheers
mi.ke

mi.ke, die Lösung wird nur mit Python funktionieren. Wenn der Anti-Bot-Schutz von Cloudflare zuschlägt, wird es richtig komplex. Daher werde ich wie bereits beschrieben den Login mit Python und der cloudscraper-Komponente durchführen und den Rest wieder mit dem bestehenden FHEM-Modul machen. Für Euch ändert sich dadurch nichts, Ihr müsst nur Python3 und cloudscraper auf Eurem Raspberry installieren. Prototypisch habe ich das auch schon mal ausprobiert und es scheint zu funktionieren. Beim Notification-Listener gibt es aber auch noch ein Problem, das ich beheben muss.

Die von m0urs entwickelte Python-Anbindung funktioniert natürlich auch. Mein ursprüngliches Modul war ebenfalls Python-basiert. Ich habe allerdings irgendwann bewusst auf Perl umgestellt, da die Notificatons dann FHEM-intern abgearbeitet werden. Für den reinen Login sehe ich aber kein Problem, Python aufzurufen.

Es bleibt daher schon noch einige Arbeit für mich zu tun, aber der Lösungsweg ist soweit klar. Also einfach gedulden, es wird demnächst eine Lösung geben.

Hallo maluk,

DANKE. Ich liebe das Modul auch. Schick mir mal eine PM damit ich Dir einen Kasten Bier oder ne gute Flasche Wein ausgeben kann.

Liebe Grüße
Oli

Nachdem ich etliche Stunden mit dem Versuch verbracht habe, nur den ersten Login-Schritt nach Python auszulagern und den Rest in FHEM zu machen und damit gescheitert bin, habe ich jetzt den kompletten Login-Prozess inkl. 2-Faktor-Authentifizierung nach Python verlagert. Alles was danach passiert, bleibt wie bisher im FHEM-Modul.

Anbei der aktuelle Stand meiner Entwicklung - alle Beta-Tester unter euch dürfen jetzt loslegen :)

Die angehängte Datei 49_Arlo.pm im Verzeichnis /opt/fhem/FHEM abelgen, vorher die vorhandene 49_Arlo.pm sichern. Die Datei 49_Arlo.py muss im Verzeichnis /opt/fhem/contrib abgelegt werden, nicht im Verzeichnis FHEM! Den genauen Speicherort muss ich noch mit Rudolf König klären, aber zu 90% bleibt es bei contrib.

Damit der Python-Login funktioniert, muss vorher Python3, PIP und Cloudscraper installiert werden:

sudo apt install python3 python3-pip
sudo pip3 install cloudscraper


Nach dem Kopieren der Datei und der Installation von Python/Cloudscraper muss in FHEM "reload 49_Arlo" durchgeführt werden, damit die neue Version aktiviert wird.

Bei mir tritt beim Login immer wieder folgender Fehler auf: "Detected a Cloudflare version 2 Captcha challenge, This feature is not available in the opensource (free) version." Falls das Arlo-Cloud-Device im Status "login failed" stehen bleibt und im Logfile der obige Fehler auftritt, einfach so lange "set Arlo_Cloud reconnect" versuchen, bis die Anmeldung klappt. Hier muss ich mir noch überlegen, wie ich den Fehler besser umgehe.

Auftretende Fehler bitte hier zurückmelden, das Fehlerhandling im Modul muss noch etwas verbessert werden.

Änderung 02.05.2021 13:35 Uhr
Ich habe nochmal eine neue 49_Arlo.pm hochgeladen. Teilweise gab es Probleme, dass keine Events angekommen sind. Hier habe ich noch etwas korrigiert.

Super Danke! Schaut gut aus!

SUPER, gleich installiert.. Herzlichen Dank.. Ich teste nun das Ganze noch etwas durch und melde mich ggf..

Vielen, vielen Dank!
Leider laufe ich warum auch immer in einen Python 3 f-string syntax error - bin auf Python 3.5.3-1 - System sagt neueste Version.
Arlo_Cloud device steht auf python-login und im log steht:

Traceback (most recent call last):
  File "contrib/49_Arlo.py", line 4, in <module>
    import cloudscraper
  File "/usr/local/lib/python3.5/dist-packages/cloudscraper/__init__.py", line 202
    print(f"Debug Error: {getattr(e, 'message', e)}")
                                                   ^
SyntaxError: invalid syntax

Aus deiner Python3-Version schließe ich, dass du noch Debian 9 (Stretch) installiert hast.  Ich habe bei mir Debian 10 (Buster) installiert, das bringt Python 3.7 mit und damit funktioniert die Cloudscraper-Komponente.

Debian 9 ist eigentlich seit Juli 2020 out of support, ich würde dir einen Update empfehlen. Alternativ gibt es auch Anleitungen im Netz, wie man Python 3.7 in Debian 9 installieren kann. Übrigens gibt es inzwischen schon Debian 11 mit Python 3.9 (allerdings noch nicht als stabiles Release).

ich muss auch erst eine Neuinstallation machen. Mein ArloPi hat auch noch kein Buster drauf.
Wird eh mal Zeit.

@maluk
Vielen, vielen Dank, dass Du so viel Zeit und Arbeit für uns investiert hast!

cheers
mi.ke

kurzes Feedback ohne getestet zu haben:

Damit sudo pip3 install cloudscraper funktioniert musste ich bei mir vorher sudo apt-get update und dann sudo apt-get install python3-pip durchführen.

Falls noch jemand einen Fehler bekommt:-)

zwei Einträge im Log aber kein Connect:
2021.05.02 22:20:01 1: PERL WARNING: Use of uninitialized value $userId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 687.
2021.05.02 22:20:49 1: Bei 2-Faktor-Authentifizierung muss das Attribut mailServer gesetzt sein, damit die Mail mit dem Authentifizerungs-Code abgerufen werden kann.

Hab 2FA nicht aktiviert. Muss ich da jetzt etwas gesondert einstellen?

Hatte die 2-Faktor-Authentifzierung bei dir bereits am Laufen? Falls ja, müsste der Mail-Server eigentlich bereits eingetragen sein.

Ansonsten hier nochmal die Anleitung: am Cloud-Device muss der Mailserver deines Mail-Providers als Attribut hinterlegt. Hier das Beispiel für GMX:
attr Arlo_Cloud mailServer imap.gmx.net

Wichtig ist auch, dass du das Passwort für deine E-Mail-Adresse beim Define angegeben hast, also in dieser Form:
define Arlo_Cloud Arlo ACCOUNT <hans.mustermann@xyz.de> <meinArloPasswort> <meinEmailPasswort>

Erfolgreich auf Debian 10 (Buster) updated.
Leider kommt jetzt bei der 2FA immer diese Fehlermeldung und das Arlo Cloud device geht auf login failed:
2021.05.02 22:32:44 3: Arlo: Try to login with code 155898
2021.05.02 22:32:44 2: Arlo: finishAuth not successful, response code 200
2021.05.02 22:33:36 3: Arlo: Try to login with code 526858
2021.05.02 22:33:36 2: Arlo: finishAuth not successful, response code 200
2021.05.02 22:33:57 3: Arlo: Try to login with code 532748
2021.05.02 22:33:58 2: Arlo: finishAuth not successful, response code 200

Zitat von: maluk am 02 Mai 2021, 22:30:37
Hatte die 2-Faktor-Authentifzierung bei dir bereits am Laufen?

Nö:-) hab auch gerade ein paar Seiten vorher gesehen, dass 1FA nicht mehr unterstützt wird... Hatte Arlo bisher noch nicht umgestellt. Werde mir dann auch wohl eine GMX-Adresse zulegen und umstellen

edit: Perfekt! Hab jetzt auf eine andere Mail gewechselt, auf 2FA umgestellt und Reconnect gemacht. Und was soll ich sagen? War gleich Active und beim Test-Klingeln an der Haustür wurde ein aktuelles Foto gemacht und mir per Telegram gesendet. Super vielen Dank @Maluk für deine Arbeit an dem Modul und das du es nicht aufgegeben hast!!!

Zitat von: Hobbel am 02 Mai 2021, 22:37:33
Erfolgreich auf Debian 10 (Buster) updated.
Leider kommt jetzt bei der 2FA immer diese Fehlermeldung und das Arlo Cloud device geht auf login failed:

Code Auswählen Erweitern

2021.05.02 22:32:44 3: Arlo: Try to login with code 155898
2021.05.02 22:32:44 2: Arlo: finishAuth not successful, response code 200
2021.05.02 22:33:36 3: Arlo: Try to login with code 526858
2021.05.02 22:33:36 2: Arlo: finishAuth not successful, response code 200
2021.05.02 22:33:57 3: Arlo: Try to login with code 532748
2021.05.02 22:33:58 2: Arlo: finishAuth not successful, response code 200

Bitte tausche 49_Arlo.py durch die angehängte Version aus. Im Logfile müssten danach mehr Informationen stehen. Falls persönliche Daten von dir enthalten sind, schicke mir das Ergebnis bitte per privater Mitteilung.

Zitat von: maluk am 02 Mai 2021, 22:45:49
Bitte tausche 49_Arlo.py durch die angehängte Version aus. Im Logfile müssten danach mehr Informationen stehen. Falls persönliche Daten von dir enthalten sind, schicke mir das Ergebnis bitte per privater Mitteilung.

Danke maluk - jetzt steht das im log:

2021.05.02 22:51:29 3: Arlo: Try to login with code 196705
2021.05.02 22:51:29 3: Arlo: can only concatenate str (not "dict") to str
2021.05.02 22:51:38 3: Arlo: Try to login with code 354601
2021.05.02 22:51:38 3: Arlo: can only concatenate str (not "dict") to str
2021.05.02 22:51:47 3: Arlo: Try to login with code 418675
2021.05.02 22:51:47 3: Arlo: can only concatenate str (not "dict") to str

Das war nicht das, was ich sehen wollte - habe im Logging einen Fehler eingebaut. Bitte versuche es nochmal mit der angehängten 49_Arlo.py.

Es ändert sich mit der neuen 49_Arlo.py nichts an der Fehlermeldung:

2021.05.02 23:09:01 3: Arlo: Try to login with code 684394
2021.05.02 23:09:01 3: Arlo: can only concatenate str (not "dict") to str
2021.05.02 23:09:10 3: Arlo: Try to login with code 247734
2021.05.02 23:09:10 3: Arlo: can only concatenate str (not "dict") to str
2021.05.02 23:09:19 3: Arlo: Try to login with code 577950
2021.05.02 23:09:19 3: Arlo: can only concatenate str (not "dict") to str

Nächster Versuch  :)

Danke für deine Hilfe  :)

2021.05.02 23:19:52 3: Arlo: Try to login with code 391224
2021.05.02 23:19:52 3: Arlo: {'meta': {'code': 400, 'error': 9236, 'message': 'Invalid OTP'}}
2021.05.02 23:19:52 2: Arlo: finishAuth not successful, response code 200


In der mail von Arlo ist das OTP 153271

Sind vielleicht noch alte E-Mails vom Absender do_not_reply@arlo.com vorhanden? Falls ja, diese bitte löschen. Es sieht für mich danach aus, als ob aus einer falschen E-Mail der Einmal-Code gelesen wird. Oder kommen mehrere E-Mails pro Anmeldeversuch? Ich hatte ein solches Problem bisher noch nicht.

Bingo - es war immer noch die vorherige Email im Postfach, so dass die 2FA nicht den aktuellen OTP code ausgelesen hat, sondern den davor.
Email gelöscht - jetzt läuft alles wunderbar.
Vielen Lieben Dank maluk für deine Hilfe - super!
LG, Patrick

Guten Morgen maluk,

erstmal vielen Dank für deine Mühe!

Ich habe wie beschrieben installiert, Arlo Cloud meldet auch State "active".
Wenn ich aber nun z.B. an eine Kamera 'set <cam> snapshot' sende passiert nichts.

Bei 'set <cam> startRecording' erhalte ich nach kurzer Zeit als Reading 'activityState' einen timeout.
Allerdings wird ein Reading 'lastVideoImageUrl' erzeugt und das JPG ist auch vorhanden, mehr allerdings nicht.

Im FHEM-LOG wiederholen sich die Meldungen:

2021.05.03 07:59:42 2: (Re)starting Arlo event listener.
2021.05.03 07:59:45 2: Invalid Arlo event response: Vary: Origin
2021.05.03 07:59:45 2: Invalid Arlo event response: Vary: Access-Control-Request-Method
2021.05.03 07:59:45 2: Invalid Arlo event response: Vary: Access-Control-Request-Headers

Auch alle anderen Readings, wie z.B. batteryLevel,brightness, usw. werden nicht aktualisiert.

Buster ist installiert und aktuell.

Hallo suchard,

hast du 49_Arlo.pm gestern nach 13:35 Uhr heruntergeladen? Ich hatte da eine Korrektur hochgeladen, die diesen Fall eigentlich verhindern soll. Falls es die aktuelle Version ist, hilft leider nur, manuell einen reconnect durchzuführen. Diese Vary-Meldungen bedeuten, dass der Notification-Subscription-Request von Arlo abgelehnt wurde. Daher setze ich inzwischen die Header Origin, Access-Control-Request-Method und Access-Control-Request-Headers bei diesem Request ...

Falls es beim ersten reconnect nicht gleich funktioniert, bitte mehrfach versuchen.

Das neueste pm-File hatte ich eingespielt.
Ich habe jetzt mehrfach den reconnect ausgeführt bis die Meldungen im LOG verschwunden waren, und siehe da, es funktioniert.
Ich dachte der STATE 'active' bei der Arlo Cloud bedeutet, dass der Connect erfolgreich war. Mein Fehler.
Super Arbeit, ich danke Dir vielmals!!!

Ich werde noch etwas einbauen, dass bei Auftreten der Vary-Meldung automatisch so lange verbunden wird, bis die Meldung nicht mehr kommt. Die tollen Sicherheits-Features, die Arlo / Cloudflare hier ständig erweitern, sind wirklich anstregend. Offensichtlich möchte Arlo nicht, dass die Kameras außerhalb der eigenen App genutzt werden  >:(

Hauptsache die Produkte sind nicht günstig, dann kann man die Einschränkungen als Kunde auch akzeptieren.  >:(

Nochmals vielen Dank!!!

Also, ich hab
- den PI mit Buster neu installiert
- Python/Cloudscraper installiert
- arlo.pm und py hochgeladen
- alte Mails aus den 2FA Accout gelöscht
- neue IP Adresse geholt
- PI neugestartet
expiryTime = 0pingInterval = 90ssePollingInterval = 2
leider sagt der arlo-ACCOUNT nach jeden reconnect: "login timeout"

im LOG steht
2021.05.03 13:37:02 2: Arlo call was not successful: {"data":{"error":"2015","message":"Your session has expired. Please log in.","reason":"Access token is required."},"success":false}
Woran könnte das liegen?

cheers
mi.ke

Gibt es im Logfile keine Einträge davor? Falls nicht, wird Python nicht korrekt aufgerufen. In diesem Fall bitte auf Shell-Ebene in das Verzeichnis /opt/fhem wechseln und
sudo -u fhem python3 contrib/49_Arlo.py
aufrufen. Hier sollte dann gemeldet werden, dass 5 Argumente benötigt werden. Falls etwas anderes passiert, muss gemäß der Fehlermeldung vorgegangen werden.

Außerdem bitte prüfen, ob es eine Datei /tmp/arlo gibt und ob der FHEM-User Schreib-Zugriff auf /tmp hat.

Hi maluk,

Der Pythonteil scheint zu funktionieren.

error: 5 arguments expected: arlo user, arlo password, imap server, email user, email passwordTraceback (most recent call last):
  File "contrib/49_Arlo.py", line 202, in <module>
    tfa_mail_check = TfaMailCheck(sys.argv[3], sys.argv[4], sys.argv[5])
IndexError: list index out of range

die Date /tmp/arlo wird erstellt

Inhalt:
status: login
status: getFactors
status: startAuth
status: waitFor2FA
log: Try to login with code xxxxxx
status: finishAuth
cookies: wird erzeugt
userId: xxx-xxxxxxx
end

verbose =5
Im LOG steht, je öfter ich einen reconnect versuche, immer weniger zum arlo-Modul.
Am meisten beim Neustart des PI
nach 3-4 versuchen gar nichts mehr zum Login.

Ich starte jetzt mal durch und schick Dir den LoG per PM, okay?

Super, jetzt passiert mehr.
Ich habe vor dem Neustart nochmal die IP-Adresse gewechselt.
Jetzt lief es durch und steht auf active
Wahrscheinlich zu viele Fehlversuche und ich war geblockt oder sonst was.Klasse, ich warte mal was jetzt an Readings kommt

Ich muss nochwas fragen...
Ich vermisse das reading motionDetected true|false.
Das ist jetzt schon so lange her, aber das wurde doch erzeugt, nachden das erstemal eine Bewegung erkannt wurde, oder?

motionDetected gibt es immer noch, es wird 0 oder 1 geliefert. Die Readings werden aber nur aktualisiert, wenn in der Event-Subscription keine Vary-Header gesendet werden. An der Lösung dieses Problems bin ich noch dran, bis dahin so lange reconnecten, bis die Verbindung steht.

Anbei nochmal die aktuellste Version. Wenn eine Vary-Header in der Event-Subscription geliefert wird, erfolgt jetzt automatisch so oft ein Neustart der Event-Subscription, bis es klappt.

Diese Version habe ich jetzt auch ins FHEM-SVN eingecheckt. Ab morgen wird sie also auch bei normalen FHEM-Updates mit verteilt.

ich habe python und cloudscraper installiert und beide Dateien wie beschrieben in die entsprechenden Pfade kopiert. Nach einem reconnect wurden umgehend state, batteryLevel, u.a. aktualisiert.
Das tolle Arlo-Modul läuft wieder. Schade, dass der Kamera-Hersteller permanent und undokumentiert das Login ändert.

@maluk : Herzlichen Dank für Dein Engagement und Deine tolle Arbeit.

@maluk Vielen lieben Dank. Nach Anleitung installiert funktioniert auf anhieb.

Hallöchen,

habe alles gemacht wie hier im Thread beschrieben (cloudflare, arlo.py etc) und bekomme:
2021.05.06 21:27:30 3: Arlo: b'authentication failed'

Trotz verbose 5 ist das alles was im Log auftaucht (allerdings 3 mal). Es kommt keine Mail ins GMX Postfach. Ich habe mit einem bisher nicht benutzten Device mal manuell im Browser den Login geprüft, 2FA ist korrekt auf mail konfiguriert und bei dem manuellen Anmeldeversuch kam auch die Mail mit dem sechsstelligen Code. Was kann es sein?

Grüße
eddy

kurzer Zwischenbericht: ALLES SUPPER!!

PS Wenn du dein PayPal in deine Signatur machst, gibt es bestimmt der eine oder andere der dir einen Zustupf als Dankbarkeit leistet ;)

Zitat von: eddy242 am 06 Mai 2021, 21:32:59
habe alles gemacht wie hier im Thread beschrieben (cloudflare, arlo.py etc) und bekomme:

Code Auswählen Erweitern

2021.05.06 21:27:30 3: Arlo: b'authentication failed'

Trotz verbose 5 ist das alles was im Log auftaucht (allerdings 3 mal). Es kommt keine Mail ins GMX Postfach. Ich habe mit einem bisher nicht benutzten Device mal manuell im Browser den Login geprüft, 2FA ist korrekt auf mail konfiguriert und bei dem manuellen Anmeldeversuch kam auch die Mail mit dem sechsstelligen Code. Was kann es sein?

Hallo Eddy,

das Logging im Python-Modul ist leider nur sehr rudimentär und es reagiert auch nicht auf die Verbose-Einstellung. Hier muss ich bei Gelegenheit mal nacharbeiten.

Den Fehler konnte ich aber reproduzieren, indem ich falsche Zugangsdaten für das GMX-Postfach angegeben habe. Wichtig ist hier die Syntax bei der Definition des Cloud-Device (den E-Mail-Benutzername benötigst du bei GMX nicht):
define Arlo_Cloud Arlo ACCOUNT <hans.mustermann@xyz.de> <meinArloPasswort> <meinEmailPasswort>

Bitte prüfe nochmal dein E-Mail-Passwort.

Zitat von: choetzu am 07 Mai 2021, 22:58:40
kurzer Zwischenbericht: ALLES SUPPER!!

PS Wenn du dein PayPal in deine Signatur machst, gibt es bestimmt der eine oder andere der dir einen Zustupf als Dankbarkeit leistet ;)

Danke für die Rückmeldung. Ich freue mich immer über positives Feedback. Es geht mir hier aber gar nicht darum, mit dem Modul  Geld zu verdienen, sondern einen Beitrag zum FHEM-Projekt zu leisten. Es gibt viele Entwickler, die hier viel Zeit opfern (insbesondere natürlich Rudolf König), und davon profitiere auch ich.

Prima, vielen Dank. Funktioniert wieder alles bestens. Nun brauche ich nicht mehr die App nutzen.
Hoffentlich bleibt das erstmal ein wenig erhalten...

LG,
M

Hallo Zusammen,

ich laufe leider noch mit dem PI auf Jessie somit kein Python fürs Arlo Modul, möchte aber diesen nicht platt machen und neu aufsetzen, sondern neue Hardware holen (wollte ich eh nach 5 Jahren), welche Empfehlung habt ihr zum Pi 4? 4GB oder 8GB? B Modell?

Danke & Liebe Grüße

Chuellma

Zitat von: Chuellma am 11 Mai 2021, 20:05:08
...welche Empfehlung habt ihr zum Pi...

mein Arlo läuft auf einem schmalen RPi Zero mit 512Mb aus 2016 stabil und ohne Zeitdelta. Und das über FHEM2FHEM.

Wenn Du mehr installiert hast oder nur einen Rechner nutzt, wovon ich ausgehe, kauf Dir einen 4er mit 4 oder 8 Gb und gut...
Kostet doch eh nix.
Aber die Frage|Diskussion hat dann m.M.n. auch nix in diesem Thread verloren, nix für ungut!

cheers
mi.ke

Zitat von: Chuellma am 11 Mai 2021, 20:05:08
ich laufe leider noch mit dem PI auf Jessie somit kein Python fürs Arlo Modul, möchte aber diesen nicht platt machen und neu aufsetzen, sondern neue Hardware holen (wollte ich eh nach 5 Jahren) ...

Normalerweise musst du den PI nicht plattmachen, sondern kannst von Jessie auf Stretch und dann von Stretch auf Buster updaten (direkt von Jessie auf Buster solltest du nicht versuchen). Anleitungen dazu gibt es im Internet. Ich habe sogar noch einen alten Raspberry 2B mit Debian 10 am Laufen.

Hallo maluk,

alles getestet. Ich fasse es nicht .... es geht ... vielen vielen Dank.

Liebe Grüße
Oli

PS: Der Wein geht umgehend raus ....

Mist, nach Reboot geht es nicht mehr ... jetzt kommt immer
2021.05.15 10:27:28 1: PERL WARNING: readline() on closed filehandle $fh at ./FHEM/49_Arlo.pm line 1148.

Kommt sonst keine Fehlermeldung? Prüfe mal, ob es eine Datei /tmp/arlo gibt. Wichtig ist, dass der FHEM-User im /tmp-Verzeichnis Schreibrechte hat und die Datei arlo (über-)schreiben darf. Falls die Datei da ist, diese bitte löschen. Und auf jeden Fall nochmal set Arlo_Cloud reconnect durchführen.

Das war scheinbar ein Problem mit meinem e-mail Postfach. Hab jetzt auf mein GMX-Postfach gewechselt, jetzt geht alles ...  :D

Danke Dir, maluk! Läuft perfekt! :-)

Ich hatte in meinem Arlo-Passwort noch das Zeichen "&", was das Python-Skript nicht so mag - da schlägt die "5 arguments expected.."-Meldung zu. Hab jetzt das PW abgeändert, und damit ist alles super und unkompliziert.

Kurze Frage in die Runde: Ich kann mich neuerdings nicht mehr mit der Arlo-App verbinden. Ich werde nach ein paar Sekunden immer wieder "rausgeschmissen" mit der Meldung "you have logged in with another device". Ich nehme mal an, das ist dieses Modul.. Habt ihr das auch?

zudem stehen nun auch  - nach einem reconnect - alle Cams auf initialized... komisch.

Das Problem kann immer mal wieder auftreten. Die Session des Moduls mit dem Arlo Cloud-Dienst geht auf jeden Fall verloren, wenn man sich über die App einloggt. Danach versucht das Modul aber automatisch wieder, eine neue Verbindung herzustellen. Dies sollte spätestens klappen, nachdem man die App wieder verlassen hat. Auch wieder so ein Thema, auf das ich leider keinen Einfluss habe.

Habe das Problem (eher per Zufall) bei mir gelöst. Ich habe mich mit einem zweiten Account bei Arlo registriert und im Erstprofil (in der App) alle Kameras für dieses Zweitprofil freigegeben. Auf den Handys nutzen wir das Zweitprofil, in FHEM und auf einem Tablet das Erstprofil. Meine Intention war eigentlich, dass ich die Video-Doorbell fürs Zweitprofil nicht freigebe, um zu vermeiden, dass alle Geräte, auf denen die App ist, gleichzeitig bimmeln, wenn jemand klingelt - das hat leider nicht funktioniert, aber als Nebeneffekt beissen sich die Accounts beim Login nicht mehr.

Habt Ihr auch Probleme beim Login?

Letzte Aktion war 2021-05-25 07:36:43.
Seitdem kein Login möglich
Mit verbose 4 steht im LOG

2021.05.25 12:41:49 1: Logfile gelöscht
connect error: Connection refused (111)
connect error: Connection refused (111)
connect error: Connection refused (111)
2021.05.25 12:45:15 2: Arlo: unknown command status: getFactors
2021.05.25 12:45:17 3: Arlo: b'[AUTHENTICATIONFAILED] Authentication failed.'
2021.05.25 12:48:24 3: Arlo: Try to login with code 000000
2021.05.25 12:48:24 3: Arlo: {'meta': {'code': 400, 'error': 9236, 'message': 'Invalid OTP'}}
2021.05.25 12:48:24 2: Arlo: finishAuth not successful, response code 200
2021.05.25 13:30:51 2: Arlo call was not successful: {"data":{"error":"2401","message":"Access token is empty or unauthorized request","reason":"Empty token"},"success":false}
2021.05.25 13:30:53 1: PERL WARNING: Use of uninitialized value $userId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 686.
2021.05.25 13:30:53 2: Arlo call was not successful: {"data":{"error":"2015","message":"Your session has expired. Please log in.","reason":"Access token is required."},"success":false}
2021.05.25 13:30:55 2: Arlo call was not successful: {"data":{"error":"2015","message":"Your session has expired. Please log in.","reason":"Access token is required."},"success":false}
2021.05.25 13:30:57 2: Arlo call was not successful: {"data":{"error":"2015","message":"Your session has expired. Please log in.","reason":"Access token is required."},"success":false}




Die Mail mit dem Code für die 2-Faktor-Authentifizierung wurde von Arlo angepasst. Jetzt findet das Modul den Code nicht mehr. Ich werde das korrigieren.

Das Problem ist behoben und kann morgen früh über den FHEM-Update aktualisiert werden. Für diejenigen, die es eilig haben, habe ich die neuen Versionen von 49_Arlo.pm und 49_Arloy.py angehängt.

Noch ein wichtiger Hinweis: bevor Ihr Euch über FHEM neu verbindet, bitte alle Mails mit alten Anmelde-Codes löschen, falls welche vorhanden sind.

Wie immer klasse Job von dir.
Dankeschön

Zitat von: maluk am 25 Mai 2021, 19:23:10
Das Problem ist behoben ...

Vielen Dank, maluk.

Hoffentlich ist sich arlo endlich mal einig und hört auf, dauernd was zu ändern.

cheers
mi.ke

@all
Also gefühlt hab ich den Eindruck, dass seit umstellen auf die Python-Auth der gesamte Schaltvorgang wesendlich weniger Delay verursacht. Das mag eine subjektive Wahrnehmung sein, aber die Modus-Wechsel und Cam-Readings erreichen bei mir nahezu in Echtzeit FHEM, das war vor her nicht so.

Egal, @maluk, tolle Arbeit, nochmals vielen lieben Dank !

cheers
mi.ke

Vielen Dank @maluk !!!

Noch ein Hinweis, nach FHEM <update all> heute wurde zwar die neue 49_Arlo.pm installiert, allerdings wurde die 49_Arlo.py (in /home/fhem/contrib) nicht updated. Diese musste ich manuell nachziehen.

LG, Patrick

Die Probleme mit Arlo scheinen nicht aufzuhören  :'(
Ich bekomme beim login inzwischen diesen Fehler (verbose 5):
2021.06.04 08:39:37 3: Arlo: Detected a Cloudflare version 2 Captcha challenge, This feature is not available in the opensource (free) version.

Dieses Problem kann ich leider nicht lösen, es tritt aber normalerweise nicht dauerhaft auf. Bitte versuche so lange "set Arlo_Cloud reconnect", bis die Verbindung hergestellt werden konnte.

Leider besteht das Problem bei mir dauerhaft. Keine Chance ... die Fehlermeldung kommt auch nach zigmaligen reconnect Versuchen :-(

EDIT: Heute morgen steht das Arlo_Cloud device wieder auf active und alles ist gut :-)

Hallo,

ich hatte zuletzt auch wieder Login-Probleme. Habe aber den Fehler gefunden.

@maluk: Vielleicht könntest Du das ins Wiki mitaufnehmen.

Normalerweise wird ja der Authentifizierungscode in der e-mail sofort wieder gelöscht. Ich hatte aber Fälle, wie zuletzt heute, dass eine Mail nicht gelöscht war und noch in der Inbox war. Der Login haut dann nicht hin. Scheinbar kommt das Modul / Skript durcheinander, wenn noch eine Mail in der Inbox ist.

Lösung war einfach, nämlich die alte Mail löschen, reconnect und alles ging wieder.

Liebe Grüße
Oli

Habe leider seit Wochen wieder nicht lösbare login Probleme:

2021.08.24 07:45:50 3: Arlo: Detected a Cloudflare version 2 Captcha challenge, This feature is not available in the opensource (free) version.

mehrfaches reconnect hilft leider nicht, hab auch schon anderen Arlo bzw. Email account probiert, aber leider kommt er gar nicht bis zur 2FA.
Hat sonst noch jemand das Problem? Mögliche Lösungsansätze?

Vielen Dank vorab,
Patrick

ich habe leider massiv Probleme wenn ich selbst in Arlo über die mobile App schauen möchte. Er wirft mich dann jede Minute raus (wahrscheinlich weil FHEM sich einloggt bzw. etwas abfragt).
Ab und zu passiert es auch, dass der Status noch auf active steht aber gar nicht mehr active ist. Ich merke das nur weil sie die Screenshots nicht mehr aktualisieren. Das lässt sich zwar mit einem Reconnect lösen bedeutet aber auch einen manuellen Eingriff.

Hat jemand evnt. auch diese zwei Themen und ggf. schon Lösungen?

edit: man kann die Arlo-Kameras ja auch bei Homekit einbinden (gerade probiert und scheint gut zu funktionieren). Kann man über diesen Weg FHEM<->Homekit vielleicht Bewegung und einen Screenshot der Cams in FHEM auslesen?

Arlo lässt nur eine Anmeldung zu. Wenn du dich in der App anmeldest, wird FHEM abgemeldet. Wenn sich FHEM wieder anmeldet, wird die App abgemeldet. Da kann ich leider gar nichts dagegen machen, das wird vom Server so gesteuert.

Zitat von: StephanFHEM am 22 September 2021, 20:43:27
ich habe leider massiv Probleme wenn ich selbst in Arlo über die mobile App schauen möchte. Er wirft mich dann jede Minute raus (wahrscheinlich weil FHEM sich einloggt bzw. etwas abfragt).

Ich hab mir einen zweiten User angelegt den ich im Browser oder in der APP nutze.
Das funktioniert soweit ganz gut

Danke für den Hinweis. Mache ich dann wohl auch mal. Mittlerweile kann ich in der App nichts mehr nachschauen ....

Bei mir ist seit letzter Woche kein Login mehr möglich.
Geändert hatte ich nichts, aber einen Neustart des RPi durchgeführt.

Scheint das gleiche oder ein ähnliches Problem wie das vom 25.05.2021 zu sein.

Zitat von: maluk am 25 Mai 2021, 18:12:13
Die Mail mit dem Code für die 2-Faktor-Authentifizierung wurde von Arlo angepasst.

Kann jemand das Problem bestätigen oder bin ich der einzige, bei dem es nicht mehr geht?

Bei mir funktioniert noch alles. Bitte prüfe, ob noch eine alte Arlo-Mail in deiner Mailbox liegt. Falls ja, bitte erst alle Arlo-Mails löschen und dann nochmal versuchen.

Zitat von: maluk am 25 Oktober 2021, 19:45:08
Bei mir funktioniert noch alles. Bitte prüfe, ob noch eine alte Arlo-Mail in deiner Mailbox liegt. Falls ja, bitte erst alle Arlo-Mails löschen und dann nochmal versuchen.

Hatte schon geschaut und alle Mails gelöscht vor dem letzten Loginversuch.

Und jetzt live unter Beobachtung der Mailbox (Webmail) nochmal getetstet.
Es scheint so zu sein, dass die Mail zu lange braucht.
Der login timeout erscheint, bevor die Mail in der Mailbox auftaucht. Der Zeitstempel der E-Mail stimmt dann allerdings.
Möglicherweise hat mein Provider etwas geändert und arlo ist unschuldig.

Kann ich den Timeout im Python Modul temporär anpassen?

Zitat von: mi.ke am 26 Oktober 2021, 09:41:22
Möglicherweise hat mein Provider etwas geändert und arlo ist unschuldig.

Hab jetzt stundenlang nach dem Fehler gesucht.
45 Minuten mit dem "Support" meines Provider (seit 20 Jahren dort Kunde) telefoniert ("Wir haben nichts verändert"),
kein Erfolg.

Eine GMX E-Mail-Adresse erstellt und auf diese umgestellt...
... läuft

Manchmal fragt man sich wirklich, warum man Geld für sinnlose Sachen ausgibt, unglaublich

Hallo zusammen,

vielleicht erinnert Ihr Euch, ich hatte vor ein paar Monaten mal um Hilfe gerufen. Mit den Hinweisen hier im Forum hat es nicht geklappt und ich habe dann erstmal aufgegeben. Bis heute abend, als mich der Ehrgeiz dann doch nochmal gepackt hat.

Es lag daran, dass mein GMX Passwort ein $-Zeichen enthielt. Das hat das Python-Script zu dem b-Auth-Fehler gebracht. Neues GMX Passwort generiert (diesmal mit einem %), Modul neu definiert, läuft.

Vielleicht hilft das jemand anderem.

Grüße
eddy

hab seit einiger Zeit permanente Log-Einträge (siehe unten). Weiß jemand woran das liegen kann und wie ich das weg bekomme? Es funktioniert ansonsten alles...


2021.11.19 13:21:41 2: (Re)starting Arlo event listener.
2021.11.19 13:21:43 2: Invalid Arlo event response: server-timing: intid;desc=4c20de8f63a8xxxx
2021.11.19 13:53:13 2: (Re)starting Arlo event listener.
2021.11.19 13:53:13 2: Invalid Arlo event response: server-timing: intid;desc=58fea142173dxxxx
2021.11.19 14:24:44 2: (Re)starting Arlo event listener.
2021.11.19 14:24:46 2: Invalid Arlo event response: server-timing: intid;desc=594f3006cb6fxxxx
2021.11.19 14:56:15 2: (Re)starting Arlo event listener.
2021.11.19 14:56:16 2: Invalid Arlo event response: server-timing: intid;desc=abea16088c18xxxx
2021.11.19 15:27:47 2: (Re)starting Arlo event listener.
2021.11.19 15:27:49 2: Invalid Arlo event response: server-timing: intid;desc=789e90e298c1xxxx
2021.11.19 15:59:20 2: (Re)starting Arlo event listener.
2021.11.19 15:59:23 2: Invalid Arlo event response: server-timing: intid;desc=033db85b7fa4xxxx
2021.11.19 16:30:50 2: (Re)starting Arlo event listener.
2021.11.19 16:30:53 2: Invalid Arlo event response: server-timing: intid;desc=e667aca43848xxxx
2021.11.19 17:02:25 2: (Re)starting Arlo event listener.
2021.11.19 17:02:27 2: Invalid Arlo event response: server-timing: intid;desc=062a94d75db7xxxx
2021.11.19 17:33:55 2: (Re)starting Arlo event listener.
2021.11.19 17:33:55 2: Invalid Arlo event response: server-timing: intid;desc=ba36b925db3axxxx
2021.11.19 17:42:16 2: (Re)starting Arlo event listener.
2021.11.19 17:42:19 2: Invalid Arlo event response: server-timing: intid;desc=c412ba7ca6ddxxxx
2021.11.19 17:58:19 2: (Re)starting Arlo event listener.
2021.11.19 17:58:22 2: Invalid Arlo event response: server-timing: intid;desc=eaffea6c509bxxxx

Ich muss die ignorierten HTTP Request Header erweitern, damit die Meldung nicht mehr kommt. Ich mache das mit dem nächsten Release. Ist aber ein reiner Schönheitsfehler, hat keine Auswirkung auf die Funktionalität.

wäre super, wenn du das updaten könntest. Es ist zwar ein Schönheitsfehler aber macht mein Log doch sehr unübersichtlich...

Ich habe die Änderung eingecheckt. Wenn du morgen einen FHEM-Update machst, sollte das Problem behoben sein.

Top Danke!

Hallo,

geht bei euch noch das Login?
Bei mir schon seit 2 Wochen nicht :-)

Ciao
Michael

Hi,

Ich hab seit kurzem auch Login Probleme, scheinbar kommt keine Mail mehr seitens Arlo für die 2FA. Hab schon probiert einen neuen Account bei Arlo anzulegen, trotzdem keine Mail bekommen ..

MfG
Kev

Bei mir funktioniert noch alles. Wenn Ihr Probleme habt mit der 2FA-Mail dann prüft bitte, ob noch alte 2FA-Mails in Eurer Mailbox liegen. Bitte alle Arlo-Mails löschen und nochmal versuchen. Falls das auch nicht klappt, müssten im Logfile Fehlermeldungen auftauchen. Diese bitte hier posten, sonst habe ich keinen Anhaltspunkt, woran es liegen könnte.

Aufräumen vom GMX Postfach hat geholfen - Danke!

Hallo in die Runde,
ich habe vor, mir das Modul lokal so zu modifizieren, dass auch die Arlo Doorbell unterstützt wird. Die Doorbell braucht keine Basisstation, sollte sich also so wie eine ArloQ verhalten. Reicht es da, die gleichen Checks auf den Devicetype einzufügen, oder gibt es da Probleme? Außerdem hat die Doorbell sozusagen zwei Spezialfunktionen, also eine Benachrichtigung beim Drücken der Klingeltaste sowie den "Lautlosmodus". Hat da jemand eine Idee, wie man da rankommt?
Danke Euch schon mal für jeglichen Tipp! :-)

Kurze Info bzgl. der Arlo-Doorbell: Es klappt tatsächlich, wenn man den Devicetype "doorbell" in entsprechender Art wie "arloq" behandelt. Damit funktionieren Snapshot, Bewegungsmelder (arm/disarm), Start/Stop Recording und Brightness direkt. Eine Notification für den Klingeltaster habe ich über Umwege (Arlo-Skill für Alexa kombiniert mit dem FHEM-Connector) hinbekommen.

ist es möglich das sich bei Arlo wieder etwas geändert hat ?
Bekomme die Fehlermeldung User id missing in subscribe request bei der Anmeldung.
Keine Anmeldung möglich.

Bei mir kommt auch loginFailed ...

ja, leider kann ich das bestätigen,

PERL WARNING: Use of uninitialized value $userId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 686.

Same here, Login failed.
Aufruf von URL https://ocapi-app.arlo.com/api/auth aus contrib/49_Arlo.py resultiert in HTTP error 403...
Zugriff scheint Server-seitig unterbunden worden zu sein.
Anfrage bei Arlo noch pendent...

Gerade gesehen: Bei Jeffrey Walter's Python-Modul gibt es dasselbe Issue (https://github.com/jeffreydwalter/arlo/issues/188 (https://github.com/jeffreydwalter/arlo/issues/188)). Es sieht so aus, dass der Login dort mit einer Änderung im Header hinzubekommen ist, aber trotzdem klappen dann nicht alle Funktionen.

Zitat von: GSK19 am 22 Februar 2022, 15:44:38
Gerade gesehen: Bei Jeffrey Walter's Python-Modul gibt es dasselbe Issue (https://github.com/jeffreydwalter/arlo/issues/188 (https://github.com/jeffreydwalter/arlo/issues/188)). Es sieht so aus, dass der Login dort mit einer Änderung im Header hinzubekommen ist, aber trotzdem klappen dann nicht alle Funktionen.

Besten Dank für den Tipp! Habe contrib/49_Arlo.py entsprechend angepasst, login funktioniert nun wieder und auch die paar Funktionen, welche ich für Arlo nutze (arm, disarm, snapshots) :-)

was genau hast du denn geändert? Werde nicht so richtig schlau draus, würde aber mein Arlo System gerne weiter nutzen:-)

ZitatBesten Dank für den Tipp! Habe contrib/49_Arlo.py entsprechend angepasst, login funktioniert nun wieder und auch die paar Funktionen, welche ich für Arlo nutze (arm, disarm, snapshots) :-)

Sehr cool! :-) Da bist Du wiederum weitergekommen als ich - bei mir klappt das alles noch nicht, aber das liegt wohl an meinen eher an meinen fehlenden Kenntnissen. Was genau hast Du eingefügt, kannst Du die Zeilen mal posten?

Ich hab es auch noch nicht gerafft, was dort wo einfügt werden muss.
Meine 49_Arlo.py sieht komplett anders aus als die unter https://github.com/jeffreydwalter/arlo

Zitat von: rzumsteg am 22 Februar 2022, 20:26:13
Besten Dank für den Tipp! Habe contrib/49_Arlo.py entsprechend angepasst, login funktioniert nun wieder und auch die paar Funktionen, welche ich für Arlo nutze (arm, disarm, snapshots) :-)

wäre super, wenn du uns hier weiterhelfen könntest, auch bei mir gehts nicht. Danke...

Ich habe die Änderungen von rzumsteg in das Modul eingebaut, vielen Dank für die Anpassung.

Wenn Ihr morgen einen Update von FHEM macht, sollten zumindest der Login und die Grundfunktionen wieder funktionieren.

Was Arlo sonst noch alles angepasst hat, muss ich mir in nächster Zeit mal ansehen.

Zitat von: maluk am 27 Februar 2022, 12:21:20
Ich habe die Änderungen von rzumsteg in das Modul eingebaut, vielen Dank für die Anpassung.

Wenn Ihr morgen einen Update von FHEM macht, sollten zumindest der Login und die Grundfunktionen wieder funktionieren.

Was Arlo sonst noch alles angepasst hat, muss ich mir in nächster Zeit mal ansehen.

Vielen Dank Euch Beiden!

Rückmeldung:
Für mich funktioniert die Automatik wieder wie gewohnt (Kamera Readings kommen und der Modus kann geschaltet werden)

Nochmals, Dankeschön
cheers
mi.ke

Super, herzlcihen Dank..

da ich morgen geschäftlich unterwegs bin, wollte ich das heute Abend noch testen. Kann ich evtl. bereits auf die neue 49_Arlo.pm zugreifen resp. downloaden?
Oder wie hast du das getestet mi.ke?

Zitat von: choetzu am 27 Februar 2022, 20:02:37
... downloaden?...

Hier kann man vor dem Upload schon downloaden (sortiert nach neuste oben).
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM?order=date&desc=True (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM?order=date&desc=True)

die heutige Version von 49_Arlo.pm
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/49_Arlo.pm (https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/49_Arlo.pm)

Aber die neue 49_Arlo.py aus dem contrib nicht vergessen.
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/49_Arlo.py (https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/49_Arlo.py)

super, perfekt. Danke mi.ke. Die Links kannte ich noch nicht.. ;)

Es klappt auch auf Anhieb.. sehr gut.. So kann die Woche gerne starten ;)

lg c

Hallo Zusammen,

hab alles aktualisiert auch die 49_Arlo.py, aber leider funktioniert es nicht. Es kommt "login timeout".

Was kann ich versuchen?

Herzlichen Dank insbesondere an mi.ke. Habe das Update durchgeführt, login und snapshot klappen wieder.

Zitat von: ojb am 28 Februar 2022, 09:24:50
Hallo Zusammen,

hab alles aktualisiert auch die 49_Arlo.py, aber leider funktioniert es nicht. Es kommt "login timeout".

Was kann ich versuchen?

Was heisst aktualisiert?
Bevor Du fragst, was Du versuchen kannst, solltest Du erstmal sagen, was Du schon alles selbst versucht hast, sonst kann Dir vermutlich keiner die Frage beantworten bzw. einschätzen, wo der Fehler liegen könnte.

Update gemacht oder manuell runtergeladen und drüberkopiert?
Danach neustart gemacht?
Was sagt das LogFile?

Hi mi.ke,

update gemacht und die py manuell ins contrib kopiert ...

ABER: Jetzt geht es. Ich war heute mit meinem Sohn in den Bergen und als ich heimgekommen bin wurde die Videoüberwachung ausgeschaltet so wie es sein soll.

Komisch. Danke auf jeden Fall für das Einbauen und Reparieren.

Könntest Du kurz sagen was Du wo geändert hast, weil ich würde gerne dazu lernen.

Vielen lieben Dank im Voraus.
Liebe Grüße Oli

Klasse, vielen Dank. Es klappt nun wieder.

Also beim "update" wird nur die "49_Arlo.pm" neu geschrieben, die "49_Arlo.py" wird nicht mit erneuert. Die muss man noch händisch kopieren. Dabei aber auf die Rechte achten  :)

Zitat von: ojb am 28 Februar 2022, 19:05:14

Könntest Du kurz sagen was Du wo geändert hast....

ich hab gar nichts geändert.

maluk und rzumsteg haben das Modul wiederbelebt.

Ich bin auch nur dankebar das es wieder funktioniert.

Seit gestern scheitert die Verbindung leider wieder:

PERL WARNING: Use of uninitialized value $userId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 686.

waitFor2FA -> login timeout

Zitat von: suchard am 27 Mai 2022, 13:36:03
Seit gestern scheitert die Verbindung leider wieder:

PERL WARNING: Use of uninitialized value $userId in concatenation (.) or string at ./FHEM/49_Arlo.pm line 686.

waitFor2FA -> login timeout

Hast Du mal alle Auth-Mails gelöscht?
Ich hab eben den RPi neugestartet und der Login hat funktioniert...

Bei mir läuft es auch noch ohne Probleme.

Ideen:
- FHEM_Arlo aktuell?
- Landen die Aut-Mails eventuell im Spam?
- Hast Du eventuell Dein Email-Passwort geändert?
- Nutzt Du für FHEM den Arlo-Haupt-Account oder einen Freigegeben?

Zitat von: mi.ke am 27 Mai 2022, 14:48:23
Hast Du mal alle Auth-Mails gelöscht?
Ich hab eben den RPi neugestartet und der Login hat funktioniert...

jetzt muss ich einmal dumm fragen: wo finde ich die Mails, du meinst in meinem "normalen" Posteingang oder werden die irgendwo auf Dem Rasp Pi abgelegt?  :-[
btw: mir fällt auf dass ich keine Mails mehr erhalte...

Zitat von: tobias.vorberg am 27 Mai 2022, 14:58:14
Bei mir läuft es auch noch ohne Probleme.

Ideen:
- FHEM_Arlo aktuell?
- Landen die Aut-Mails eventuell im Spam?
- Hast Du eventuell Dein Email-Passwort geändert?
- Nutzt Du für FHEM den Arlo-Haupt-Account oder einen Freigegeben?

ja, alles aktuell, nein, landen nicht im Spam, nur kommen seit einigen Stunden offensichtlich überhaupt keine mehr, geändert habe ich nichts, zumindest nicht wissentlich, es sein denn, der Vatertag hat zugeschlagen.  ;) Echt komisch.

Ich schaue mir das später noch einmal in Ruhe an, habe jetzt einen Termin. Vielen Dank aber schon einmal für die Hinweise.  :)

Was bedeutet "nur kommen seit einigen Stunden offensichtlich überhaupt keine mehr"? Kommen gar keine keine Mails von Arlo bei Dir an?

Die Mails von Arlo zur 2FA kommen in Deinem Posteingang an, werden da von FHEM gelesen, und der Code für die 2FA benutzt und danach aus dem Posteingang gelöscht.

Zitat von: tobias.vorberg am 27 Mai 2022, 15:32:52
Was bedeutet "nur kommen seit einigen Stunden offensichtlich überhaupt keine mehr"? Kommen gar keine keine Mails von Arlo bei Dir an?

Die Mails von Arlo zur 2FA kommen in Deinem Posteingang an, werden da von FHEM gelesen, und der Code für die 2FA benutzt und danach aus dem Posteingang gelöscht.

Ich kann nicht genau sagen seit wann die Mails nicht mehr ankamen, da ich sie automatisch nach einer Weile löschen lasse.
Mir ist das nur aufgefallen als ich es einmal genau beobachtet hatte.
Nachdem ich nun alles noch einmal überprüft habe und nichts finden konnte, habe ich ein Backup von meinem Pi vom letzten Sonntag eingespielt. Siehe da: Es funktioniert wieder wunderbar.
Ich habe keine Ahnung was sich verändert hat. Sicher saß / sitzt das Problem aber vor der Tastatur.  ;D
Egal, nun tut es wieder. Danke aber an Alle! :)

Hallo, ich hatte schon ein neues Thema unter Anfägerfragen aufgemacht. https://forum.fhem.de/index.php/topic,129893.0.html (https://forum.fhem.de/index.php/topic,129893.0.html).
Mein ArloLogin funktioniert schon länger nicht mehr, habe aber jetzt wieder Zeit mich darum zu kümmern.
Die 49_Arlo.py habe ich runtergeladen und installiert.
Aber ich erhalte in im Logfile folgenden Fehler:
Traceback (most recent call last):
  File "contrib/49_Arlo.py", line 4, in <module>
    import cloudscraper
  File "/usr/local/lib/python3.5/dist-packages/cloudscraper/__init__.py", line 210
    print(f"Debug Error: {getattr(e, 'message', e)}")
                                                   ^
SyntaxError: invalid syntax
Hierzu fehlt mir aber die Kenntnis .
Wer kann hier helfen oder was ist zu tun?

Gruß Josef

Hallo Joseph,

da steht sinngemäß, daß im Quellcode etwas falsch geschrieben wurde. Der Fehler ist in der letzten Zeile:
das "f" muß vor die Klammer, der Befehl heißt "printf"
Diese Zeile in der Datei "49_Arlo.py" mußt Du suchen und wie folgt ändern:


printf("Debug Error: {getattr(e, 'message', e)}")


Gruß Thomas

Hallo Thomas,
danke erstmal, aber der Erfolg war noch nicht da.
Die Fehlermeldung kommt ja aus der __init__.py.
Dort habe ich die Zeile geändert, aber jetzt habe ich den nächsten Fehler.
Traceback (most recent call last):
  File "contrib/49_Arlo.py", line 4, in <module>
    import cloudscraper
  File "/usr/local/lib/python3.5/dist-packages/cloudscraper/__init__.py", line 222
    f'You\'re running urllib3 {requests.packages.urllib3.__version__}, Brotli content detected, '
                                                                                                ^
SyntaxError: invalid syntax

Verwendest du auch Arlo kannst du mir mal deine __init__.py senden.

Gruß Josef

Hallo Joseph,

verwende das Modul selbst nicht, ist mir zu viel "gefrickel", geht mal ein paar Wochen, dann ändert Arlo wieder was, geht nicht mehr usw.
Das ist mir zu unzuverlässig  ;) Aber dafür kann ja das Modul hier nichts !
Du hast natürlich Recht, der Fehler ist in der __init__.py zu suchen.
Da scheint aber einiges falsch zu sein, sieht die Zeile 222 wirklich so aus in der Datei ?
f'You\'re running urllib3 {requests.packages.urllib3.__version__}, Brotli content detected, '
müßte mal die Zeile davor und danach sehen, dann könnte man das vielleicht rekonstruieren.

Gruß Thomas

Hallo Thomas,
hier die Funktion mit dem Fehler.

 
def decodeBrotli(self, resp):
     if requests.packages.urllib3.__version__ < '1.25.1' and resp.headers.get('Content-Encoding') == 'br':
         if self.allow_brotli and resp._content:
             resp._content = brotli.decompress(resp.content)
         else:
             logging.warning(
                 f'You\'re running urllib3 {requests.packages.urllib3.__version__}, Brotli content detected, '
                 'Which requires manual decompression, '
                 'But option allow_brotli is set to False, '
                 'We will not continue to decompress.'
             )

     return resp


Gruß Josef

Hallo Josef,

könnte tatsächlich sein, dass das "f" zuviel ist, muß aber nicht. Kannst ja mal ohne dem "f" am Anfang der Zeile probieren.
Wenn Du aber in der Verzweigung landest, heißt das wohl, daß ein Fehler aufgetreten ist und evtl. in irgendeiner config Datei
"allow_brotli" auf "true" gesetzt werden muß, weiß aber nicht genau, welche.
Wenn das "f" zuviel ist, müßte anschließend der Fehlertext ausgegeben werden.

Gruß Thomas

Hallo Thomas,

der Fehler wandert weiter.

        try:
            resp = scraper.get(url, **kwargs)
            resp.raise_for_status()
        except Exception:
            logging.error(f'"{url}" returned an error. Could not collect tokens.')
            raise


Gruss Josef

Hallo Josef,

also das mit dem "f" vorher war wohl richtig so. Irgendwie scheint die Abfrage der "urllib3" Version nicht zu funktionieren.
Vielleicht musst Du noch zusätzlich etwas installieren, damit das arlo-Modul wieder funktioniert ?

Hab da leider nicht den Überblick bei dem arlo-Modul.

Gruß Thomas

Der Pfad-Angabe nach verwendest du Python 3.5 und damit vermutlich noch Debian 9 (stretch). Als Mindestvoraussetzung für das Arlo-Modul habe ich Python 3.7 (Debian 10) angegeben. Falls du noch Debian 9 installiert hast, solltest du einen Update machen, da diese Version seit 2020 auch nicht mehr gewartet wird.

Hallo Maluk,
Vielen Dank für deine Antwort. Ich habe zu wenig gedacht und war der Meinung mit "sudo apt install python3 python3-pip sudo pip3 install cloudscraper" wird schon das richtige installiert.
Mit Debian 9 hattest du Recht, hatte vor einiger Zeit eine 2. Installation upgedatet und diese mit meiner Hauptinstallation verwechselt.
Werde also mein System in den nächsten Tagen auf Bullseye updaten und dann sehen wir weiter.
Noch ein schönes Wochenende.

Gruß Josef

Hallo Maluk,
System ist jetzt aktuell (Buster).
Allerdings bekomme ich folgenden Fehler "2022.11.15 19:45:46 3: Arlo: b'[AUTHENTICATIONFAILED] Authentication Failed'"

Ich habe meine Einstellungen Login und PW im Browser verfiziert und dort funktioniert das PW und die Mail wird auch an meinen Account gesendet.
define Arlo_Cloud Arlo ACCOUNT crypt:530c4455551f4b5f545f5340785c525d09445617075f0c crypt:78535d4355435444035d crypt:012f06480b080a0763 josef.riemer@icloud.com
attr Arlo_Cloud mailServer imap.mail.me.com
attr Arlo_Cloud room Arlo
#   CFGFN     
#   DEF        ACCOUNT crypt:530c4455551f4b5f545f5340785c525d09445617075f0c crypt:78535d4355435444035d crypt:012f06480b080a0763 josef.riemer@icloud.com
#   FUUID      6373d26d-f33f-07c9-278f-60fb5302743b2d53
#   NAME       Arlo_Cloud
#   NR         8901
#   STATE      loginFailed
#   SUBTYPE    ACCOUNT
#   TYPE       Arlo
#   eventCount 3
#   helper:
#     mailPassword **
#     mailUser   josef.*****@icloud.com
#     password  **
#     pythonTimeout 1668538058.03514
#     username   josef.*****@icloud.com
#
setstate Arlo_Cloud loginFailed



Gruß Josef

Habe einen neuen Accont bei Arlo und GMX erstellt.
Beim Versuch über Fhem erhalte ich folgenden Eintrag im Logfile.
Mail wird auch keine gesandt.

2022.11.17 15:44:03 3: Arlo: Try to login with code 250958
2022.11.17 15:44:03 3: Arlo: {'meta': {'code': 400, 'error': 9236, 'message': 'Invalid OTP'}}
2022.11.17 15:44:03 2: Arlo: finishAuth not successful, response code 200

Gruß Josef

Jetzt funktioniert der Login auf einmal, keine Ahnung warum.

Gruß Josef

Hat noch jemand Probleme mit dem Login?
Seit heute geht plötzlich der Login nicht mehr.
Ich konnte bis jetzt nichts finden.
Auffällig ist nur, dass auch keine E-Mails für die 2FA im Postfach landen.

Bevor ich nun eine große Fehleranalyse starte wollte ich hier nur mal kurz nachfragen.
Danke für Infos.

Gleiches Problem hier.
Login funktioniert nicht mehr, auch mit verbose 5 sehe ich nichts im log.
Gruss, Patrick

Nach dem ich python und pip upgedatet habe und dann nochmal
sudo apt install python3 python3-pip
sudo pip3 install cloudscraper

drüber laufen gelassen habe, läuft es wieder.
Zwischendurch habe ich einen alten Pi komlett neu aufgesetzt mit neuem FHEM und da lief es auch auf anhieb. also war klar das es irgedwie mit updaten gehen musste.

Nach dem ich python und pip upgedatet habe und dann nochmal
sudo apt install python3 python3-pip
sudo pip3 install cloudscraper

drüber laufen gelassen habe, läuft es wieder.
Zwischendurch habe ich einen alten Pi komlett neu aufgesetzt mit neuem FHEM und da lief es auch auf anhieb. also war klar das es irgedwie mit updaten gehen musste.

Zitat von: tobias.vorberg am 11 Mai 2023, 17:25:48sudo pip3 install cloudscraper

super, danke. Das wars bei mir... nun gehts wieder

Hallo,

vielleicht stelle ich mich dumm an aber ich bin direkt nach der anleitung Wiki (https://wiki.fhem.de/wiki/Arlo) vorgeangen. Jetzt habe ich noch rausgefunden das man eine Perldatei noch braucht /opt/fhem/contrib/49_Arlo.py um genau zu sein. diese habe ich dann gleich mit fhem:dialout versehen. Was braucht man noch alles da es nicht bei mir geht :(
Auch habe ich rausgefunden das man eine ZweiFaktorAuthorisierung über Email braucht und es nicht über die APP geht :( den das hatte ich so eigentlich eingestellt. Habe dann einen eigenen Account über gmx erstellt und wollte ihm halt meine Kameras freigeben. Aber auch da klappt es nicht. Ich habe damit dieser nicht den Fehler fabriziert beim define die Passwörter im Klartext angegeben :( und auch den Emailserver im Attr versehen. Klar habe ich davor bei gmx auch den IMAP Zugang freigeschaltet.
Die 49_Arlo.pm existierte schon bei mir und kann es also nicht sein.

Zu Hilfe. Ich möchte doch nur die letzten Bilder meiner Arlos im Webfrontend sehen und das Deaktivieren/Aktivieren über PRESENCE nutzen

Hm, also bei mir klapp es nach der Anleitung https://wiki.fhem.de/wiki/Arlo sehr gut.

Bitte check doch mal die Python-Version. Das war neulich bei mir das Problem. Nach einem Update von Python lief dann alles wieder.
Wichtig ist auch noch, dass in dem benutzten E-Mail-Account keine "alten" 2FA-Mails liegen. Die sollten alle gelöscht sein.

also ich habe jetzt einen apt udate | apt upgradegemacht und er hat tatsächlich ein paar dinge noch angemekert. also brav geupdatet und dann gehoft das er jetzt tut aber er bleibt wie auf dem Screenshot zu sehen bei python-login stehen.
2023-06-08_19h28_15.png
2023-06-08_19h28_24.png 
Nach ner Zeit sagt er "login timeout"

Muss die 49_arlo.pm angepasst werden da ich das per update von Fhem genutzt habe.

und im übrigen im fhemwiki steht ja nicht drinnen das man die py datei nach /opt/fhem/contrib einfügen muss und welche musste ich mir auch hier aus dem Forum zurecht suchen habe jetzt diese hier

import base64
import sys
import time
import cloudscraper
import email
import imaplib
import re

class Arlo:
    def __init__(self, tfa_mail_check) -> None:
        self._tfa_mail_check = tfa_mail_check
        browser = {
            'browser': 'chrome',
            'platform': 'linux',
            'mobile': False
        }
        self._session = cloudscraper.create_scraper(browser=browser)
        self._headers = {
            "Accept": "application/json, text/plain, */*",
            "Referer": "https://my.arlo.com",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36",
            "Source": "arloCamWeb"
        }
        self._baseUrl = "https://ocapi-app.arlo.com/api/"
        self._token = None

    def login(self, username, password):
        status("login")
        json = {"email": username, "password": encode(password), "language": "en", "EnvSource": "prod"}
        attempt = 0
        while attempt < 3:
            attempt += 1
            try:
                r = self._session.post(self._baseUrl + "auth", json=json, headers=self._headers)
                if r.status_code == 200:
                    data = _get_data(r)
                    if data is not None:
                        self._request_factors(data)
                    return
                if r.status_code == 400:
                    error("Bad auth request - probably the credentials are wrong.")
                    return
            except Exception as e:
                log(e)
            time.sleep(3)
        status("loginFailed")

    def _request_factors(self, data):
        status("getFactors")
        self._token = data["token"]
        self._headers["Authorization"] = encode(self._token)
        r = self._session.get(self._baseUrl + "getFactors?data=" + str(data["authenticated"]), headers=self._headers)
        data = _get_data(r)
        if data is None:
            error("getFactors not successful, response code " + str(r.status_code))
            return

        factor_id = None
        for factor in data["items"]:
            if factor["factorType"] == "EMAIL":
                self._auth_tfa(factor["factorId"])
                return
        error("email factor not found.")

    def _auth_tfa(self, factor_id):
        status("startAuth")
        json = {"factorId": factor_id}
        r = self._session.post(self._baseUrl + "startAuth", json=json, headers=self._headers)
        data = _get_data(r)
        if data is None:
            error("startAuth not successful, response code " + str(r.status_code))
            return
        factor_auth_code = data["factorAuthCode"]

        status("waitFor2FA")
        self._tfa_mail_check.open()
        code = self._tfa_mail_check.get()
        self._tfa_mail_check.close()
        log("Try to login with code " + code)

        status("finishAuth")
        json = {"factorAuthCode": factor_auth_code, "otp": code}
        r = self._session.post(self._baseUrl + "finishAuth", json=json, headers=self._headers)
        data = _get_data(r)
        if data is None:
            error("finishAuth not successful, response code " + str(r.status_code))
            return

        self._token = data["token"]
        self._headers["Authorization"] = encode(self._token)
        r = self._session.get(self._baseUrl + "validateAccessToken?data=" + str(data["authenticated"]),
                              headers=self._headers)
        if r.status_code != 200:
            error("validateAccessToken not successful, response code " + str(r.status_code))
            return

        print("cookies:", self._get_cookie_header())
        print("token:", self._token)
        print("userId:", data["userId"])
        print("end")

    def _get_cookie_header(self):
        cookie_header = ""
        for cookie in self._session.cookies:
            if cookie_header != "":
                cookie_header += "; "
            cookie_header += cookie.name + "=" + cookie.value
        return cookie_header
def _get_data(r):
    if r.status_code != 200:
        return None
    try:
        body = r.json()
    except Exception as e:
        return None

    if "meta" in body:
        if body["meta"]["code"] == 200:
            return body["data"]
    elif "success" in body:
        if body["success"]:
            if "data" in body:
                return body["data"]
    return None


class TfaMailCheck:
    def __init__(self, mail_server, username, password) -> None:
        self._imap = None
        self._mail_server = mail_server
        self._username = username
        self._password = password

    def open(self):
        self._imap = imaplib.IMAP4_SSL(self._mail_server)
        res, status = self._imap.login(self._username, self._password)
        if res.lower() != "ok":
            return False
        res, status = self._imap.select()
        if res.lower() != "ok":
            return False
        res, ids = self._imap.search(None, "FROM", "do_not_reply@arlo.com")
        for msg_id in ids[0].split():
            self._determine_code_and_delete_mail(msg_id)
        if res.lower() != "ok":
            return False
    def get(self):
        timeout = time.time() + 100
        while True:
            time.sleep(5)
            if time.time() > timeout:
                return None

            try:
                self._imap.check()
                res, ids = self._imap.search(None, "FROM", "do_not_reply@arlo.com")
                for msg_id in ids[0].split():
                    code = self._determine_code_and_delete_mail(msg_id)
                    if code is not None:
                        return code

            except Exception as e:
                return None

    def _determine_code_and_delete_mail(self, msg_id):
        res, msg = self._imap.fetch(msg_id, "(RFC822)")
        for part in email.message_from_bytes(msg[0][1]).walk():
            if part.get_content_type() == "text/html":
                for line in part.get_payload().splitlines():
                    code = re.match(r"^\W*(\d{6})\W*$", line)
                    if code is not None:
                        self._imap.store(msg_id, "+FLAGS", "\\Deleted")
                        return code.group(1)

    def close(self):
        self._imap.close()
        self._imap.logout()


def status(status):
    print("status:", status, flush=True)

def log(msg):
    print("log:", msg, flush=True)

def error(msg):
    print("error:", msg, flush=True)

def encode(s):
    return base64.b64encode(s.encode()).decode()


if __name__ == '__main__':
    if len(sys.argv) < 6:
        error("5 arguments expected: arlo user, arlo password, imap server, email user, email password")
    tfa_mail_check = TfaMailCheck(sys.argv[3], sys.argv[4], sys.argv[5])
    arlo = Arlo(tfa_mail_check)
    arlo.login(sys.argv[1], sys.argv[2])

EDIT:
habe auch keine Email von Arlo an das GMX konto erhalten. Also scheint er sich nicht mal korrekt anzumelden und soweit zu kommen das er die 2fa braucht

Zitat von: tobias.vorberg am 10 Mai 2023, 21:35:09Hat noch jemand Probleme mit dem Login?
Seit heute geht plötzlich der Login nicht mehr.
Ich konnte bis jetzt nichts finden.
Auffällig ist nur, dass auch keine E-Mails für die 2FA im Postfach landen.

Bevor ich nun eine große Fehleranalyse starte wollte ich hier nur mal kurz nachfragen.
Danke für Infos.

Hier hast du das ja auch geschrieben das genaue verhalten. Login geht nicht und keine emails zur 2fa

Edit: Manuel kann ich mich mit den angegebenen Daten 1a anmeldung und bekomme auch die 2FA-Email

Also irgendetwas ist da bei dir nicht richtig.
Wie oben schon geschrieben habe ich gerade einen frischen PI mit "Debian version: 11 (bullseye)" aufgesetzt; FHEM neu installiert und ARLO installiert nach Wiki https://wiki.fhem.de/wiki/Arlo

Es lief dann sofort.
Ich wollte aber meine alte Installation nicht wegwerfen und habe mit den Befehlen
sudo apt install python3 python3-pip
sudo pip3 install cloudscraper
bei meiner alten Installation alles wieder zum Laufen gebracht.
Man muss nichts an der 49_arlo.pm anpassen.

okay. ich habe halt nen ne vm installiert, aber darf das nen unterschied machen? Gibts irgend ein Debuglog?

edit:
Was mir noch kommt könnte es an den Sonderzeichen vom Passwort liegen?

Edit2:
habe jetzt mal die passwörter trivialisiert und es geht immer noch nicht. also ein debuglog was er genau macht wäre sehr sehr hilfreich

Hallo,

obwohl ich nichts geändert habe, bekomme seit kurzem immer 'loginFailed'. Trotz 'verbose 5' sehe ich nichts im Log.
Hat das Problem sonst noch jemand?
Was kann ich tun?

Liebe Grüße
Oli