Modul für Netgear Arlo-Kameras

[Schniedie]

Hallo,

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

Gruß

[maluk]

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.

[mi.ke]

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.

Code Auswählen Erweitern

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

[Schniedie]

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!

[m0urs]

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

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.

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.

[maluk]

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?

[maluk]

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.

[maluk]

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.

[maluk]

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.

[Schniedie]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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?

[mi.ke]

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?

[maluk]

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.

[maluk]

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.

[m0urs]

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.

[m0urs]

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!