Blink Security Home Kamera - Modul - 48_BlinkCamera.pm

elektrikpe2 · 23 September 2020, 10:03:24

Hallo,

ja, Panik liegt grundsätzlich richtig. Nur zur Aufhellung

1. Alle settings mach das was sie sollen (jedenfalls soweit ich das bei meinen 5 Kameras - inkl. eine blink-mini) testen konnte. Dabei war es egal, ob ich das mit set gemacht habe oder über die Blink-App. Alle settings kamen auch in der Blink-App an und alle Blink-App Änderungen kamen in FHEM an
2. Ja, es ist richtig. ein set auf enabled führt zu den Inhalten "armed" bei den readings "networkCameraxxx", "networkCameraxxxActive". Allerdings geht dann aber "networkCameraxxxxEnabled" auf 1. Dabei ist es egal, ob ich das über die Blink-App mache oder hier mit set.
3. Bei mir gehen aber alle readings wieder auf den Inhalt "disabled" wenn ich den entsprechenden set / die Funktion über Blink-App mache
4. arm/disarm führt zur Deaktivierung/Reaktivierung des Sync-Moduls und verändert keine readings der Kamera, daher hier auch keine Änderungen. Gem. Blink-App wird der set mit arm/disarm richtig ausgeführt
5. Mit $VAR.... ist die Übersicht von CameraConfigxxxxx gemeint, die bei get getinfocamera erzeugt wird
6. Fazit: Bei mir funktioniert alles wie es soll. Ich kann mit der Darstellung armed anstatt enabled leben

viegener · 23 September 2020, 18:18:50

Zitat von: Panik am 23 September 2020, 05:58:09
Ok, dann anders:

Hast du mal den Set-Befehl arm bzw. disarm gesendet?
Was zeigt dann das Reading "networkCamera******Active" ?
Oder in welchem Reading erwartest du eine entsprechende Rückmeldung auf den Set-Befehl? Was sagt diese?
Reagiert sie auf den Set-Befehl?

Bei mir steht - egal welchen Set-Befehl ich sende das Reading "networkCamera******Active" auf "armed"
Auch bei Set-Befehl "enabled" und "disabled" ...

Zu dem $VAR1 (ist nur ein mögliches Indiz für das obere primäre Problem):
Hast du ein Reading "cameraConfig******" mit etlichen kommagetrennten Werten? Pro Kamera bestimmt 100 Stück.
Der Wert des Readings geht los mit $VAR1 = [ ...
Lies dir mal die Inhalte durch. Da gibt es so merkwürdige Werte, wie ich schon schrieb.
Ich dachte, du nimmst dieses Reading als Grundlage um andere Readings zu generieren...

Also ja ich habe die Befehle abgesetzt - ich tue das gelegentlich sogar um mein Modul zu testen

Es gibt momentan 2 Readings die den Stand der einzelnen Kameras bezüglich active/enabled anzeigen

...Enabled --> Wert 0 oder 1
...Active --> Wert armed / disabled

ja und das reding reagiert auf camenable und camDisable (nicht auf arm und disarm)

Die Werte werden nicht direkt nach dem Kommando gesetzt sondern erst wenn das Kommando bestätigt wurde und ein Update von Blink kommt

Ich verwende getInfoCamera nur zu debug-Zwecken, es macht die Readingliste ziemlich unleserlich - der Inhalt ist ein JSON-Dump aus perl - das erzeugt recht komische Ausgaben hat aber nichts mit dem Quellformat zu tun und ist eigentlich nur zu Debugzwecken geeignet. Ich würde mich auf den Inhalt nicht verlassen - es wird nicht automatsich upgedatet

Die Beschreibung von elektrikpe2 zum Verhalten von arm/disarm ist richtig - Die Werte armed/disabled wurden ursprünglich von blink so benannt, ich wollte (und will) diese Texte nicht ändern obwohl sie offensichtlich missverstanden werden können.

Hatte ich oben schonmal beschrieben:

cam*abled wirkt nur auf die einzelne kamera (active/enabled)
arm/disarm wirkt nur auf das Netzwerk

Nur wenn beides "an" ist läuft die Motion detection --> als Netzwerk UND Kamera

Panik · 23 September 2020, 19:43:05

Hallo,

das reine Absetzen ist ja nicht das Problem. Ich verstehe auch die Zusammenhänge.

Ich würde mich nur nicht melden, wenn ich mir nicht bis vor Kurzem die Readings von "networkCamera******Active"
auf farbige LEDs in einem LED-Panel ausgegeben habe und die haben in schöner Regelmäßigkeit
alle möglichen Zustände rückgemeldet : rot , blau , grün
Jetzt ist's nur noch grün. Indiz für mich dass das Reading nicht mehr stimmt.

Vielleicht hängt es auch mit der API zusammen bzw. homeScreeenV3 = 1

viegener · 23 September 2020, 21:37:24

Zitat von: Panik am 23 September 2020, 19:43:05
Hallo,

das reine Absetzen ist ja nicht das Problem. Ich verstehe auch die Zusammenhänge.

Ich würde mich nur nicht melden, wenn ich mir nicht bis vor Kurzem die Readings von "networkCamera******Active"
auf farbige LEDs in einem LED-Panel ausgegeben habe und die haben in schöner Regelmäßigkeit
alle möglichen Zustände rückgemeldet : rot , blau , grün
Jetzt ist's nur noch grün. Indiz für mich dass das Reading nicht mehr stimmt.

Vielleicht hängt es auch mit der API zusammen bzw. homeScreeenV3 = 1

Die Spekulation hilft jetzt nicht weiter: Nein wie oben schon beschrieben in homescreenV3 inzwischen obsolet

Vielleicht beschreibst Du einfach mal genau das Probem: Was Du machst, wie Du auswertest und was genau nicht geht. Inzwischen spekulieren wir hier bereits seit 10 Beiträgen und ich habe immer noch keinen Ansatz für das eigentliche Problem.

Panik · 24 September 2020, 18:17:42

Stimmt!
3 bis 4 Beiträge wären vielleicht einzusparen gewesen.

Ich bin nur auf eine falsche Fährte gekommen und hab hier vielleicht falsche Aufregung verursacht. Sorry.
Grund: Da eine selbstgeschriebene Funktion immer auf dem Reading networkCamera******Active beruhte und dieses
hat definitiv einmal die Zustände armed, disarmed, enabled und disabled angenommen.
Aktuell wird dieses Reading offenbar nicht mehr mit all den genannte Zuständen bedient.
Sonst hätte ich das Reading ja nie benutzt und meine Funktion hätte nie funktioniert...

Egal, schreib ich es mir halt wieder um und benutze eine Kombination aus den Readings networkArmed und
networkCamera*****Enabled. Die funktionieren korrekt.

Somit kann die Beitragsetappe als abgehakt betrachtet werden.

viegener · 24 September 2020, 21:05:20

@Panik: Dadurch dass Blink die Apis regelmässig verändert und sich damit auch Bezeichnungen und Stati immer wieder ändern lässt sich nicht ausschliessen, dass das auch in Zukunft wieder vorkommt. Ich habe am Anfang auch etwas unvorsichtigerweise die Bezeichnungen gewählt (auch durch Übernahme aus dem Blinkjsonformat).

Inzwischen versuche ich vieles stabil zu halten, so habe ich auch die neuen Blink Mini Kameras versucht so ähnlich wie möglich zu den anderen Kameras darzustellen, obwohl Sie in der Schnittstelle von Blink ganz andere Geräte sind.

DoubleD · 16 Oktober 2020, 17:18:57

Ein tolles Modul! Vielen Dank dafür!

Eine vermutlich dumme Frage, kann man die Kameras auch ohne die Cloud nutzen?

Gruß
Daniel

viegener · 16 Oktober 2020, 17:38:12

Zitat von: DoubleD am 16 Oktober 2020, 17:18:57
Ein tolles Modul! Vielen Dank dafür!

Eine vermutlich dumme Frage, kann man die Kameras auch ohne die Cloud nutzen?

Gruß
Daniel

Hallo Daniel,
Nein dazu kenne ich momentan keine Möglichkeit
Gruss,
Johannes

Hiob314 · 16 Oktober 2020, 18:22:52

Liebe Fheministinnen und Fheministen,

ich bin neu hier (also seht mir bitte einige Anfängerfehler nach) und probiere mich gerade an der Nutzung einer Blink XT2 zusammen mit einem Sonoff als Türklingel, die mir per Telegram eine Nachricht inkl. Thumbnail schickt. Der Klingeltaster hängt entkoppelt an einem Sonoff Eingang. Das Sonoff meldet per MQTT das Klingeln an Fhem und per Blink Plugin hole ich ein Thumbnail, was ich per Telegram versende.

Mein Problem ist: wird die Klingel eine gewisse Weile nicht betätigt, hatte ich beim erneuten Klingeln bisher ein veraltetes Bild erhalten. Die Kamera geht offensichtlich in einen Sleep-Modus und es dauert dann eine ganze Weile, bis sie bei einem Event wieder aufwacht.

Mein Notify sieht wie folgt aus:

Code Auswählen


MQTT2_Tuerklingel_613405:RESULT_POWER:.*ON 
set myTelegramBot message Es klingelt an der Haustür!; 
get blink getThumbnail 6743; 
get blink getInfoCamera 6743;
sleep 10;
set myTelegramBot sendMedia [blink:networkCamera6743File];

Das Sleep hatte ich eingebaut um die mögl Latenzen zu berücksichtigen.
Das "getInfoCamera" ist drin, weil ich irgendwo hier im Thread gelesen habe, dass dies nach dem "getThumbnail" benötigt wird.
Bei recht hohen Werten für das Sleep (>10 Sekunden) scheint es recht passabel zu funktionieren.
Um mir das Timing mal anzuschaun, habe ich den Event Monitor geöffnet, manuell ein "getThumbnail" abgefeuert und mal den Zeitstempel der Aktion mit dem Zeitstempel der Datei im Filesystem verglichen.
Da habe ich teilweise 13 Sekunden Verzögerung. Wenn ich die Zeit vermesse, zwischen Bild capturen in der iOS App und dem Erscheinen dort, komme ich auf ca. 3 Sekunden.

Daher folgende Fragen:
- habt Ihr ähnliche Beobachtungen beim Timing?
- wie erklärt sich der große Unterschied zur iOS App?
- Ideen für Optimierungen?
- wird das getInfoCamera im obigen Notify überhaupt benötigt?

Eine Erklärung für den großen Unterschied zwischen iOS App und FHEM Plugin, könnte auch im Verbindungsaufbau liegen. Ist die Komm. TLS verschlüsselt? Ist das IPhone hier ggf. schneller, bzw. nutzt evtl. ein Session Resume? Hat mal jemand die Verbindung mitgetraced?

Viele Grüße
Hiob

Hiob314 · 17 Oktober 2020, 11:04:07

Zitat von: Hiob314 am 16 Oktober 2020, 18:22:52
Eine Erklärung für den großen Unterschied zwischen iOS App und FHEM Plugin, könnte auch im Verbindungsaufbau liegen. Ist die Komm. TLS verschlüsselt? Ist das IPhone hier ggf. schneller, bzw. nutzt evtl. ein Session Resume? Hat mal jemand die Verbindung mitgetraced?

Das kann ich nach genauerer Überlegung eigentlich selbst ausschließen, da man ja an der blauen LED an der Cam erkennt, wenn sie captured und das geht recht schnell.
Am eigentlichen Verbindungsaufbau sollte es daher nicht liegen.
Fraglich warum es danach so lange dauert, bis das File im Dateisystem landet.

viegener · 17 Oktober 2020, 12:57:54

Zitat von: Hiob314 am 16 Oktober 2020, 18:22:52
Eine Erklärung für den großen Unterschied zwischen iOS App und FHEM Plugin, könnte auch im Verbindungsaufbau liegen. Ist die Komm. TLS verschlüsselt? Ist das IPhone hier ggf. schneller, bzw. nutzt evtl. ein Session Resume? Hat mal jemand die Verbindung mitgetraced?

Viele Grüße
Hiob

Zu den technischen Fragen: Ja die Kommunikation ist TLS verschlüsselt und auch Ja ich habe mitgetraced (in verschiedenen Versionen). Die Verbindungsgeschwindigkeit dürfte hier keinen Unterschied machen (weder Aufbau noch Schlüsselaustausch - das liegt alles weit unterhalb einer Sekunde).

Erste Frage wäre, auf welchen Wert ist Dein pollingTimeout eingestellt in FHEM eingestellt?

Hiob314 · 18 Oktober 2020, 09:16:33

Wenn ich das Attrribut PollingTimeout im Blink Device auswähle ersheint kein Wert im Input-Feld daneben.
D.h. doch, dass PollingTimeout nicht gesetzt ist, oder?
Was genau beeinflusst "PollingTimeout"? Ist das eine Intervallangabe, wann nach einem Request wieder gepollt wird?

Grüße

viegener · 18 Oktober 2020, 14:18:03

Zitat von: Hiob314 am 18 Oktober 2020, 09:16:33
Wenn ich das Attrribut PollingTimeout im Blink Device auswähle ersheint kein Wert im Input-Feld daneben.
D.h. doch, dass PollingTimeout nicht gesetzt ist, oder?
Was genau beeinflusst "PollingTimeout"? Ist das eine Intervallangabe, wann nach einem Request wieder gepollt wird?

Grüße

Wenn im List kein Attribut pollingTimeout auftaucht ist dieses nicht gesetzt und es findet keine (regelmässige) Abfrage der Daten statt.
(Auswahl des Attributes ist kein guter Weg um den aktuellen Wert herauszufinden)
Ohne Polling werden die Werte des Devices nur auf Anforderung aktualisiert

Ich bin mir aber nicht sicher, ob das hier Einfluss hat

viegener · 18 Oktober 2020, 23:49:18

@Hiob314: Ich habe mir das jetzt nochmal genauer angeschaut. Das Verhalten ist so zu erklären: das Kommand getThumbnail wird an die Blink server gesendet. Die Kommandos werden von den Blinkservern aber nicht synchron bearbeitet sondern es gibt dann eine id zurück unter der man feststellen kann, wann das Kommando fertig ist. Nach 3 Sekunden wird das erste Mal geprüft, dann nach 9 Sekunden, danach würde nach 27 Sekunden nochmal geschaut. Bei mir ist das Kommando bei der 2. Überprüfung ferti also nach etwa 12 Sekunden (3+9). Das erklärt vermutlich die Verzögerung.

Generell ist das Verhalten des Moduls völlig korrekt, ich habe aber in github mal eine neue Version eingeführt, bei der die Wartezeiten verkürzt sind also nach 2 4 8 Sekunden das verkürzt den ABlauf deutlich (nach etwa 6 Sekunden ist bei mir das Ergebnis da).

Hiob314 · 19 Oktober 2020, 10:29:59

Ich habe jetzt mal das ein wget auf https://raw.githubusercontent.com/viegener/Telegram-fhem/master/Blink/48_BlinkCamera.pm auf meinem Raspbian gemacht und das Modul in meiner FHEM Installation überschrieben. Jetzt scheint es bei mir mit 8 Sekunden Sleep zu funktionieren:

Code Auswählen


MQTT2_Tuerklingel_613405:RESULT_POWER:.*ON 
set myTelegramBot message Es klingelt an der Haustür!; 
{ unlink("/tmp/BlinkCamera_blink_thumbnail_camera_6743.jpg")};
get blink getThumbnail 6743; 
sleep 8;
set myTelegramBot sendMedia [blink:networkCamera6743File];

Schöner wäre noch etwas weniger. Nach 2 Sekunden ist es offensichtlich noch nicht da. Dann wird aber erst wieder nach 6 Sekunden gepollt.
Evtl. sind die Timings auch abhängig vom jeweiligen Setup - Wifi Verbindung, etc.
Könnte man die Intervalle über FHEM Attribute zugänglich machen? Zickt der Blink Server eigentlich bei zu agressiven Timings rum?
Ich bekomme ab und zu mal E-Mails von Blink, dass die Anzahl maximal möglicher Requests überschritten wurde.

Vielen Dank für Deine Bemühungen und beste Grüße