Modul für Netgear Arlo-Kameras

Begonnen von maluk, 02 Dezember 2018, 22:20:58

Vorheriges Thema - Nächstes Thema

maluk

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

mi.ke

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

Vielen Dank und Grüße

mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

mi.ke

#2
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".
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

maluk

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?


choetzu

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
Raspi3, EnOcean, Zwave, Homematic

maluk

@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.

m0urs

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 ;-)

maluk

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

choetzu

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.
Raspi3, EnOcean, Zwave, Homematic

m0urs

#9
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?

m0urs

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"

choetzu

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

m0urs

#12
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.

maluk

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.

maluk

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:

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.