Modul für Netgear Arlo-Kameras

[mi.ke]

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

[m0urs]

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

[mi.ke]

ganz einfach

Naja, ganz Deiner Meinung bin ich nicht

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.

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.

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.

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.

[m0urs]

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

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

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

Das ist meine Hoffnung, dass maluk das hinbekommt

[mi.ke]

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

[maluk]

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.

[maluk]

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.

[maluk]

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

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

[maluk]

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

Danke 

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.

[m0urs]

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.

[m0urs]

Hab's doch noch schnell probiert:

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

[maluk]

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?

[mi.ke]

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

[Schniedie]

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;

Code Auswählen Erweitern

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

[maluk]

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/"?