49_SSCam: Fragen, Hinweise, Neuigkeiten und mehr rund um dieses Modul

[Martin Fischer]

Hallo Heiko,

danke für Deine Mühen!

Nein, es macht leider keinen Unterschied welche Sessionmethode ich nutze. Ich habe mit SVS getestet, habe aber ansonsten auf DSM gesetzt.

Anbei das Log von verbose 5.

Hier noch ein paar Anmerkungen / Fragen:
Umlaute in Kameranamen werden nicht unterstützt. Benenne ich die Kamera nach "Haustür", so erhalte ich:

Code Auswählen Erweitern

2016.08.17 12:12:15 1: GR.tr.CAM.SSS.01 - ERROR - Cameraname Haustür wasn't found in Surveillance Station. Check Userrights, Cameraname and Spelling

Wenn Du magst, kannst Du Dir mal das Modul 98_JsonList.pm oder 98_JsonList2.pm anschauen. Stammen von Rudi und mir. Dort ist ein utf8 Handling bzg. Umlaute eingebaut (JsonList_Escape). Vielleicht ist das ja hilfreich.

Im Moment habe ich nach der Umstellung auf SSCam noch einige false-positives, sprich die Aufnahme wird ausgelöst aber auf dem Video sehe ich keinen Auslöser. Auch enden alle Aufnahmen nach ~30 sec, auch wenn dort noch Bewegung ist. Hier greift wohl bei mir das Attribut recextend nicht. Vermutlich liegt das jedoch am HM Bewegungsmelder wo das Delay für die erneute Bewegungsmeldung zu hoch ist. Was für Werte nimmst Du hier? 20 Sekunden im Bewegungsmelder oder kleiner? Sollte ja dann unter der rectime liegen.

Etwas SSCam - Offtopic aber im direkten Zusammenhang:
Für erkannte Aufnahmen lasse ich mir (u.a.) auch eMails mit einen Snapshot sowie dem Link zur Aufnahme senden. Letzteres stelle ich via FHEM als HTTPSRV zur Verfügung. Rufe ich nun die Aufnahmen mittels Browser ab, dann blockt das herunterladen FHEM:

Code Auswählen Erweitern

2016.08.17 12:06:04 1: Perfmon: possible freeze starting at 12:05:57, delay is 7.018

Welchen Weg gehst Du, bzw. siehst Du hier einen anderen Weg die Aufnahmen ohne HTPSERV zur Verfügung zu stellen. Vermutlich hilft da nur ein zusätzlicher Apache / nginx als Proxy.

Da vermutlich viele so wie ich die eMails auf einem Smartphone lesen, wäre es optimal, wenn man in die eMail einen Link der Aufnahme steckt, den man dann mit der App DS cam verknüpfen könnte. Kennst Du hier evtl. einen Weg?

Und last but not least:
Einbinden der Livestreams in FHEM habe ich bisher mittels weblink vorgenommen. Hierzu lieferte die Kamera das Bild direkt, nicht die SVS. Hat natürlich zu einen den Vorteil, das es unabhängig von der SVS ist ist aber zum anderen belastet der zusätzliche Stream die Kamera, bzw. das Netzwerk. In der SVS gibt es ja den "Stream-Pfad" je Kamera, den man mittels "Rechtsklick" auf die Kamera einsehen kann. Wenn ich diesen in einen weblink bei FHEM einbinde, bekomme ich nur ein "broken Image" obwohl es gestern scheinbar (zeitweise) ging.

Code Auswählen Erweitern

http://192.168.1.9:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=7&StmKey="296b0e3b145db3a0dc59837eaa94f562"
Das zeitweise funktionieren scheint mit dem StmKey zusammen zu hängen. Dieser hat sich im Laufe des Tages gestern (so wie ich das heute sehe), min. dreimal verändert. Das macht jedoch aus meiner Sicht keinen Sinn, da Synology ja in dem Contextmenü auch die Möglichkeit zur Anlage einer Desktopverknüpfung anbietet. Hier sehe ich noch nicht den Zusammenhang aber vielleicht wäre diese URL ja auch in den Readings als Quelle für den eMailversand (Alarmierung und durch den Link direkt auf den Livestream gehen) oder die Einbindung von Livestream mittels weblink interessant.

Stimmt der StmKey nicht, dann erhält man im Browser:

Code Auswählen Erweitern

{"error":{"code":105},"success":false}

Viele Grüße
Martin

P.S.:
Das File webapi/Camera/conf/SYNO.SurveillanceStation.Camera.lib auf der SVS gibt einen Hinweis, das der StmKey auslesbar ist:
{"GetStmKey":{"grantable":true}},{"GetStmUrlPath":{"grantable":true}}

[Martin Fischer]

Habe mal bzgl. StmKey weiter recherhiert:

Ausgabe (PHP Code) von:

Code Auswählen Erweitern

$json = file_get_contents('http://'.$ip.':'.$port.'/webapi/entry.cgi?version="8"&cameraIds="7"&blIncludeDeletedCam=true&deviceOutCap=true&streamInfo=true&method="GetStmKey"&api="SYNO.SurveillanceStation.Camera"&ptz=true&basic=true&privCamType=3&camAppInfo=true&optimize=true&fisheye=true&eventDetection=true&_sid='.$sid);

Code Auswählen Erweitern

{
   "data":{
      "stmKeys":[
         {
            "dsId":0,
            "stmKey":"51b4f3374a09d21a061f007a0ac4d569"
         }
      ]
   },
   "success":true
}

Und wenn man diesen je Kamera hat, kann man sich die URL für den Livestream zusammenbauen:

Code Auswählen Erweitern

http://192.168.1.9:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=7&StmKey="51b4f3374a09d21a061f007a0ac4d569"

[DS_Starter]

Hallo Martin,

erstmal vielen Dank für die vielen Infos und Anmerkungen.  Zu deinen Fragen/Anmerkungen...

Umlaute in Kameranamen werden nicht unterstützt.

Ja stimmt. Die Unterstützung für Umlaute habe ich auf meiner ToDo-Liste. Dein/euer JsonList-Modul schaue ich mir gerne an. Dann gehts sicher schneller mit der Umsetzung im SSCam-Modul. Danke für der Tipp ! 
Mal schauen wann ich mich wieder verstärkt mit SSCam beschäftige .... will erstmal 93_DbRep noch ein wenig ergänzen. Aber dann habe ich mir wieder Erweiterungen/Verbesserungen für SSCam vorgenommen.

Was für Werte nimmst Du hier? 20 Sekunden im Bewegungsmelder oder kleiner?

Meine Kameras (4) habe ich auf eine rectime von 30 Sekunden eingesetllt. Mit der prerectime von 10s  (kommt aus der SVS eigenen Einstellung) sind es dann effektiv 40 s bei mir.
Ich habe FS20 PIRI Melder und auch einen HM-Sen-MDIR-O-2. Den Sendeabstand habe ich auf 24s beim FS20 eingestellt. Beim HM habe ich das Register minInterval auf 15 (20 geht bei dem nicht) gesetzt. Standard ist 30. In dem Fall würde ich die rectime auf z.B. 35 oder 40s setzen.
Bei allen Cams habe ich inzwischen auch das Attr "recextend" gesetzt. Es hat sich einfach als praktisch erwiesen. Dadurch kann der IR immer vor Ablauf der Aufzeichnung mit einem neuen Impuls die Aufzeichnung fortsetzen. Das wird auch im Log mit verbose 3 vermerkt:

Code Auswählen Erweitern

2016.08.17 20:40:12.924 3: CamTER - Camera Terrasse Recording with Recordtime 30 s started
2016.08.17 20:40:36.003 3: CamTER - running recording renewed to 30 s

Was ich auch bemerkt habe ist, dass die in der SVS eingestellte prerectime nur dann zieht wenn ein neuer Aufnahmestart länger als <prerectime> nach dem Ende der vorigen Aufnahme erfolgt. Das hat sicher SVS-interne techn. Gründe. Aber es kann dazu führen dass ein IR den Start triggert, aber durch eine kleine Verögerung nicht alles erfasst wird da in dem speziellen Fall die prerectime fehlt welche sonst dafür sorgt dass man immer die z.B. 10s vor dem auslösenden Ereignis mit aufnimmt.
So zumindest meine Beobachtung und ist auch ein Grund weshalb ich gern recextend benutze.

Vermutlich hilft da nur ein zusätzlicher Apache / nginx als Proxy

Dazu ist mir eingefallen, dass wir in der Synology bereits einen Webserver haben mit dem man eien virtuellen Host über einen Unterordner im web-Verzeichnis anlegen kann. Wenn es nun gelingen würde z.B. über einen Link das Stammverzeichnis der SVS-Aufnahmen (z.B.  "/volume1/surveillance/Terrasse") dort einzubinden sollte es möglich sein ohne Belastung von FHEM direkt über die Syno die Aufnahmen abzurufen.
Diesen virtuellen Server kann man im Modul über das Attr "videofolderMap" entsprechend bekannt machen. Dadurch wird das Reading VideoFolder überschrieben. Inhalt von "VideoFolder" und "CamLastRec" bilden zusammen den Aufruflink für die Aufnahme.
Diese Idee habe ich noch nicht probiert, aber das werde ich sicherlich mal machen. Sollte doch möglich sein.
Leider ist meine Internet-Uploadgeschwindigkeit zu gering als das ich selbst daraus einen praktischen Nutzen ziehen könnte. Aber es ist sicherlich für andere Nutzer interessant.

Da vermutlich viele so wie ich die eMails auf einem Smartphone lesen, wäre es optimal, wenn man in die eMail einen Link der Aufnahme steckt, den man dann mit der App DS cam verknüpfen könnte. Kennst Du hier evtl. einen Weg?

Den kenne ich momentan auch nicht. Aber ich nehme es in meine ToDo-Liste auf. Ggf. frage ich bei Synology nach ob die helfen und einen Weg zeigen können.

Einbinden der Livestreams in FHEM habe ich bisher mittels weblink vorgenommen.

Also die Methode über den StmKey klingt interessant. Ich verwende dazu im Modul ( "set <cam> runView Image|Link|Link_open") einen ähnlichen Aufruf der ebenfalls die SYNO.SurveillanceStation.VideoStreaming API nutzt. Er sieht so aus:

Code Auswählen Erweitern

http://192.168.2.10:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&cameraId=5&format=mjpeg&_sid="PeDFznZITzP4Q14A0MIN235902"

Wenn du im Modul den Livestream startest, wird ebenfalls auch das Reading "LiveStreamUrl" mit dem Livestreamlink gefüllt.
Das könntest du jetzt auch schon verwenden um dir in einer Mail diesen Link zusenden zu lassen.

Auch hier kannst du über das Attr "livestreamprefix" die URL für den Link beeinflussen um ihn von extern zugreifbar zu machen. Das sieht dann z.B. so aus:

Code Auswählen Erweitern


attr livestreamprefix = https://sds1.myds.me:9901
Reading LiveStreamUrl = https://sds1.myds.me:9901/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&cameraId=5&format=mjpeg&_sid="PeDFznZITzP4Q14A0MIN235902"


Ich probiere auf jeden Fall mal die Variante mit stmKey aus. Mal schauen ob es irgendwelche Unterschiede/Vorzüge zur jetzigen Variante gibt. Vielleicht einfach als weitere Möglichkeit.

Jetzt schaue ich mir mal dein Log an. Das ist ein sehr mysteriöses Verhalten.
Sind deine anderen 5 Kameras ebenfalls vom selben Typ oder sind das andere ?
Wenn ich den Sachverhalt Synology schildern muß, wäre das sicherlich ein wichtiger Fakt.

viele Grüße
Heiko

[DS_Starter]

Hallo Martin,

die Info welche Kameras du noch hast, waren ja im Log ersichtlich ... brauche ich also nicht mehr.
Ein Lösungsansatz ist mir nach Durchsicht des Logs noch nicht gekommen, es sieht alles unglaublich normal aus.
Allerdings habe ich die Logausgabe von relevanten Informationen im Code an eine ungünstige Stelle positioniert.
In der angehängten Version habe ich das geändert und besser platziert.

Mache doch bitte mit dieser neuen Version einen neuen verbose 5 Log.  Die Version checke ich heute Abend auch noch ein. Würde also auch morgen nach einem Update genügen.
Vielleicht fällt uns/mir dann noch etwas sinnvolles zu dem Problem ein.

viele Grüße
Heiko

[Martin Fischer]

Hallo Heiko,

Mache doch bitte mit dieser neuen Version einen neuen verbose 5 Log.  Die Version checke ich heute Abend auch noch ein. Würde also auch morgen nach einem Update genügen.

anbei das neue Log.

Viele Grüße
Martin

[Martin Fischer]

Hallo Heiko,

vielen Dank für Deine Ausführungen!

Dazu ist mir eingefallen, dass wir in der Synology bereits einen Webserver haben mit dem man eien virtuellen Host über einen Unterordner im web-Verzeichnis anlegen kann. Wenn es nun gelingen würde z.B. über einen Link das Stammverzeichnis der SVS-Aufnahmen (z.B.  "/volume1/surveillance/Terrasse") dort einzubinden sollte es möglich sein ohne Belastung von FHEM direkt über die Syno die Aufnahmen abzurufen.
Diesen virtuellen Server kann man im Modul über das Attr "videofolderMap" entsprechend bekannt machen. Dadurch wird das Reading VideoFolder überschrieben. Inhalt von "VideoFolder" und "CamLastRec" bilden zusammen den Aufruflink für die Aufnahme.
Diese Idee habe ich noch nicht probiert, aber das werde ich sicherlich mal machen. Sollte doch möglich sein.
Leider ist meine Internet-Uploadgeschwindigkeit zu gering als das ich selbst daraus einen praktischen Nutzen ziehen könnte. Aber es ist sicherlich für andere Nutzer interessant.

Nun, ich war nicht ganz untätig. Die Idee mit dem Webserver auf der Synology war ein super Hinweis. Das Naheliegendste liegt meist so fern

Was habe ich getan (für die, die es nachstellen möchten):
Vorab.. ich habe mehrere Synology NAS (RS812+,RS815+,DS2irgendwas). Meine Surveillance Station läuft auf einer RS812+ mit INTEL Atom Chipsatz. Alle NAS laufen mit DSM 6+. Es sollte jedoch auf allen gleich funktionieren.

Als erstes die Web Station installieren und starten (sofern noch nicht geschehen). In der Web Station läuft der HTTP-Backend-Server bei mir auf Apache 2.2 (Optional: nginx (ungetestet)). PHP ist (aktuell) ausgeschaltet, so wie die persönlichen Websites.

Ich habe einen virtuellen Host portbasiert zugefügt. HTTP lauscht auf 8081, HTTPS auf 8443. Das Dokument-Root ist bei mir der Ordner "/volume1/share/surveillance", kann aber ein beliebiger sein der unter Durchsuchen angezeigt wird. Der virtuelle Host läuft ebenfalls auf Apache 2.2.

Leider (und das ist auch gut so) ist das SVS Verzeichnis hier nicht als Dokument-Root auswählbar. Um dieses nun über den Apachen verfügbar zu machen gibt es zwei Wege. Bei beiden muss man sich via SSH an dem NAS anmelden (ggf. muss das noch in den Einstellungen eingeschaltet werden!). Nach dem Login als admin wechselt man mittels

Code Auswählen Erweitern

sudo -i
und dem Passwort vom admin zu root.

1. Der schnelle Weg:

Code Auswählen Erweitern

ln -s /volume1/surveillance/ /volume1/share/surveillance/svs
Das war es auch schon...

2. Der etwas andere Weg (dazu hole ich etwas aus):
Da ich auf meinem Haupt-NAS (RS815+) einige nfs-Exports habe, liegen meine Daten dort ebenfalls unter "/volume1/share/". Hier gibt es auch mp3s, Videos und Fotos. Da ich aber nur ausgewählte Ordner von der Synology indizieren und mittels DLNA, nfs oder SMB freigeben will, binde ich diese Verzeichnisse in die jeweiligen (vorgegeben) gemeinsamen Ordner music, photo und video ein. Dadurch ergibt sich bei mir folgender Verzeichnisbaum (Auszug):

• music (beinhaltet den Inhalt aus dem Verzeichnis /share/music/share und wird indiziert)


• a...
• [...]
• z...
• photo (beinhaltet den Inhalt aus dem Verzeichnis /share/photo/share und wird indiziert)


• a...
• [...]
• z...
• share


• a...
• [...]
• music


• a...
• [...]
• share (wird zusätzlich unter /music eingebunden und indiziert)
• z...
• [...]
• photo


• a...
• [...]
• share (wird zusätzlich unter /photo eingebunden und indiziert)
• z...
• [...]
• video


• a...
• [...]
• share (wird zusätzlich unter /video eingebunden und indiziert)
• z...
• [...]
• z...
• video (beinhaltet den Inhalt aus dem Verzeichnis /share/video/share und wird indiziert)


• a...
• [...]
• z...

Sieht vielleicht kompliziert aus, ist es aber nicht   Diese Struktur hat den Vorteil, das ich mir die Freigabe "/share" per nfs mounte und somit alle Daten zur Verfügung habe. Auf meinen Multimediageräten oder für die Familie werden nur die gemeinsame Ordner music, photo und video freigegeben. So kann ich in Ruhe z.B. einen Film unterhalb von "/share/video/" in einen speziellen Ordner ablegen und schneiden bevor ich ihn dann final nach "/share/video/share/" für alle freigebe. Dadurch ist er automatisch unter "/video" sichtbar, da "/video" nur ein "Spiegel" von "/share/video/share" ist. Nach dem gleichen Schema verfahre ich für "/music" wenn ich z.B. Playlisten o.a. nicht global freigeben und indizieren lassen will oder bei "/photo" wo z.B. noch unsortierte Bilder o.a. liegt, was nicht indiziert und freigeben wird.

Damit das ganze funktioniert, werden die entsprechenden Verzeichnisse beim Starten des NAS automatisch in die jeweiligen Verzeichnisse gemountet. Dieses Script nutze ich nun auch für die Surveillance Station zur Freigabe der Snapshots und Aufnahmen über die Web Station.

Also zurück zur Surveillance Station:
In dem oben angelegten Dokument-Root ("/volume1/share/surveillance") habe ich ein Verzeichnis "svs" angelegt. In dieses Verzeichnis wird nun die Surveillance Station Verzeichnisstruktur "gespiegelt". Das übernimmt das folgende Script, das als Root im Verzeichnis "/usr/local/etc/rc.d/" des NAS angelegt und ausführbar gemacht werden muss. Der Speicherort "überlebt" auch ein Update des NAS und steht danach wieder zur Verfügung.

Die Datei habe ich "S99mountbind.sh" genannt:

Code Auswählen Erweitern

#!/bin/sh
# S99mountbind.sh
# Copyright 2011 M.Fischer

mountbind() {
        # arg1: source
        # arg2: destination
        if [ ! -e $2 ]; then
                /bin/mkdir -p $2
        fi
        /bin/mount -o bind $1 $2
        /usr/syno/bin/synologset1 sys info 0x11800000 "$0: Mounted $1 to $2"
        return
}

umountbind() {
        # arg1: destination
        /bin/umount $1 && \
        /usr/syno/bin/synologset1 sys info 0x11800000 "$0: Unmounted $1"
        return
}

case $1 in
start)
        mountbind /volume1/surveillance/ /volume1/share/surveillance/svs/
        ;;
stop)
        umountbind /volume1/share/surveillance/svs
        ;;
*)
        echo "Usage: $0 [start|stop]"
        ;;
esac

Das Script wird beim Booten bzw. Herunterfahren des NAS automatisch ausgeführt. Den Reboot sparen wir uns und führen das Script mittels "./S99mountbin.sh start" aus und et voila - wie von "Zauberhand" ist die Verzeichnisstruktur der Surveillance Station im gemeinamen Ordner "/share/surveillance/svs/" sichtbar (ja, ich weiss... ein softlink (ln -s) ginge schneller, hat aber den Nachteil, das man Symlinks nicht ohne weiteres exportieren (nfs) kann.).

Optional (gilt für Weg 1 und 2):
Da der Inhalt der Surveillance Station Verzeichnisstruktur nun mittels Web Station zugänglich ist, will man den Inhalt vielleicht etwas schützen. Auch hatte ich das Problem, das Firefox als auch Chrome die Aufnahmen (.mp4) als HTML5 direkt im Browser abspielen wollte, dieses aber mit einer Fehlermeldung, dass das File defekt ist, unterbunden hat. Für letzteres habe ich noch keine Lösung gefunden (vermutlich kein sauberer Header im Videofile), so dass die Aufnahmen derzeit nur zum Download und Abspielen mittels VLC (o.a.) angeboten werden.

Dies alles landet nun in einer ".htaccess" Datei in dem Dokument-Root "/share/surveillance":
.htaccess:

Code Auswählen Erweitern

Options +Indexes -ExecCGI -MultiViews -Includes
IndexOptions +FancyIndexing +FoldersFirst +SuppressDescription NameWidth=* +SuppressColumnSorting

# DirectoryIndex: sets the file that Apache will serve if a directory is requested.
DirectoryIndex index.html index.php /index.php

IndexIgnore .htaccess @CmsSyncData @SSDBBackup @SSRECMETA @Thumbnail

# Commonly used filename extensions to character sets.
AddDefaultCharset UTF-8

# AddType allows you to add to or override the MIME configuration
# Force "File Save As" Prompt
AddType application/octet-stream .avi .mpg .mov .mp4
AddAlt "VIDEO" .mp4

# or add HTML-5 Support
#AddType video/ogg .ogv
#AddType video/mp4 .mp4
#AddType video/webm .webm

# AddEncoding allows you to have certain browsers uncompress information on the fly. Note: Not all browsers support this.
AddEncoding x-compress .Z
AddEncoding x-gzip .gz .tgz

## PROTECT FILES
<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh|db|conf|[0-9])$">
  Order Allow,Deny
  Deny from all
</FilesMatch>

<FilesMatch "\.(jpg|mp4)$">
  Order Allow,Deny
  Allow from all
</FilesMatch>


# Force the MIME-type, but don't actually perform a rewrite
RewriteEngine On
RewriteRule ^svs/[^/]+$ - [L,T=application/octet-stream]

SetEnvIf Request_URI ^/svs/([^/]+)/?(.*)(AM|PM|laRec)/[^/]+$ force-download
Header set Content-Disposition attachment env=force-download

Wer will kann auch das "Verzeichnisbrowsing" abschalten oder/und den Zugriff auf die neue Website mittel .htpasswd absichern. Im Dokument-Root kann man noch sein index.html als Einstiegsseite anlegen oder irgendwas mit PHP machen (einschalten!). Dann noch eine Portfreigabe auf dem Router und man kann diese Website nach aussen öffnen

Wer diesen Weg bis hier nachgestellt hat (egal ob Weg 1 oder 2), sollte nun im Browser seiner Wahl direkten Zugriff auf die Snapshots und Aufnahmen im Verzeichnis "svs" bekommen: http://<ip_des_synology_nas>:8081

In FHEM wird bei den Kameras das Attribut "videofolderMap" auf  z.B. "http://192.168.1.9:8081/svs/ipcam02/" gesetzt und schon die Bilder und Aufnahmen aus den eMails oder sonstigen Benachrichtigungen direkt vom NAS "serviert".

Im Wiki wird der Weg über HTTPSERV beschrieben. Dieser Weg belastet aber FHEM beim Zugriff auf die Videos zum Teil erheblich (>7 sek. blocking). Besonders bei zeitkritischen Modulen wie z.B. 1Wire oder HM kann das zu ungewollten Effekten führen. Das wird mittels dieser Lösung verhindert. Der geübte User erledigt das in 10 bis 20 Minuten (je nach gewähltem Weg).

Viel Spaß damit...

Edit: .htaccess angepasst..

[Martin Fischer]

Hallo Heiko,

Also die Methode über den StmKey klingt interessant. Ich verwende dazu im Modul ( "set <cam> runView Image|Link|Link_open") einen ähnlichen Aufruf der ebenfalls die SYNO.SurveillanceStation.VideoStreaming API nutzt. Er sieht so aus:

[...]
Ich probiere auf jeden Fall mal die Variante mit stmKey aus. Mal schauen ob es irgendwelche Unterschiede/Vorzüge zur jetzigen Variante gibt. Vielleicht einfach als weitere Möglichkeit.

Der Vorteil (aus meiner Sicht) ist, das wenn Du den Stmkey als Reading bereit stellst, dieser für weitere Streams genutzt werden kann ohne die sonst notwendige Erzeugung einer Sessionid. Ich fände das gut und es ist nur ein Reading mehr

Ein "GetStmKey" zeigt die Verwendung des Stmkey und den möglichen Streams:

Code Auswählen Erweitern

{
   "data":{
      "pathInfos":[
         {
            "cameraId":7,
            "forceEnableMulticast":false,
            "mjpegHttpPath":"http://192.168.1.9:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=7&StmKey=\"0e2d36491d01a1372085eea0f7bf6b42\"",
            "multicstPath":"rtsp://admin:0e2d36491d01a1372085eea0f7bf6b42@192.168.1.9:554/Sms=7.multicast",
            "mxpegHttpPath":"http://192.168.1.9:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mxpeg&cameraId=7&StmKey=\"0e2d36491d01a1372085eea0f7bf6b42\"",
            "unicastOverHttpPath":"rtsp://192.168.1.9:5000/webman/3rdparty/SurveillanceStation/cgi/rtsp.cgi?Sms=7.unicast&DsId=0&StmKey=0e2d36491d01a1372085eea0f7bf6b42",
            "unicastPath":"rtsp://admin:0e2d36491d01a1372085eea0f7bf6b42@192.168.1.9:554/Sms=7.unicast"
         }
      ]
   },
   "success":true
}

Durch polling hätte man in FHEM immer den aktuell gültigen Stmkey und kann ihn ohne Anmeldung bei der SVS weiterverwenden. Bisher habe ich nicht heraus gefunden, wann der geändert wird. Meine Vermutung: bei Änderungen der Einstellung der Kamera, bzw. (wohl auch) beim en- und disablen. Bin mir da aber nicht sicher und da Du (scheinbar) einen Draht zu den Synology Developern hast, kannst Du das ja vielleicht mal erfragen

Viele Grüße
Martin

[Martin Fischer]

Ich probiere auf jeden Fall mal die Variante mit stmKey aus. Mal schauen ob es irgendwelche Unterschiede/Vorzüge zur jetzigen Variante gibt. Vielleicht einfach als weitere Möglichkeit.

Vielleicht gibt es ja analog zu Stmkey für den Livestream ein Pendant für die Aufnahmen. Habe jetzt nicht die API dazu durchforstet. Wäre aber genial, wenn man an Stelle die URL zum .mp4 Files auch (oder / und) direkt die URL für einen Stream der Aufnahme bekommt. Mal so als Denkansatz

[DS_Starter]

Morgen Martin,

super dass die Möglichkeit  mit dem Webserver auf der DS so gut umzusetzen ist ! 
Die Lösung würde ich gern auch ins Wiki übertragen, vielleicht ein wenig gestrafft. Willst du es selbst tun ? Sonst würde ich es mit meinen Worten erledigen sobald ich diese Variante mal nachgebaut habe oder einen Link zu deinem Beitrag setzen. 

Der Vorteil (aus meiner Sicht) ist, das wenn Du den Stmkey als Reading bereit stellst, dieser für weitere Streams genutzt werden kann ohne die sonst notwendige Erzeugung einer Sessionid. Ich fände das gut und es ist nur ein Reading mehr

Keine Frage, das kriege ich hin. 

Vielleicht gibt es ja analog zu Stmkey für den Livestream ein Pendant für die Aufnahmen. Habe jetzt nicht die API dazu durchforstet.

Mit der API-Doku bin ich momentan nicht zufrieden. Hier gibt es auch mit der Version 2.4 wieder fehlerhafte bzw. nicht vorhandene Beschreibungen zu den Änderungen an den API's (z.B. SYNO.SurveillanceStation.ExternalRecording: 2 -> 3 ; SYNO.SurveillanceStation.PTZ:  4    ->  5  ) bzw. einer geänderten Aufrufsyntax. Die Methode getstmkey steht in der 2.4 Doku übrigends auch nicht drin. Das sind so Sachen ....

Mittlerweile hat sich ein guter Kontakt zum Product Manager Video Surveillance Station (in D) entwickelt. Er unterstützt mich sehr engagiert in Richtung "seiner" Entwickler in Taiwan. Die letzte Anfrage bzgl. der API Doku hängt aber nun auch schon 14 Tage in der Luft. Ist also auch nicht ganz so einfach 

Schaue mir dein Log heute Abend wieder an.

Schönen Tag und bis später.
Heiko

[Martin Fischer]

Hallo Heiko,

super dass die Möglichkeit  mit dem Webserver auf der DS so gut umzusetzen ist ! 
Die Lösung würde ich gern auch ins Wiki übertragen, vielleicht ein wenig gestrafft. Willst du es selbst tun ? Sonst würde ich es mit meinen Worten erledigen sobald ich diese Variante mal nachgebaut habe oder einen Link zu deinem Beitrag setzen. 

Du kannst die Lösung gerne im Wiki beschreiben, ich habe derzeit kein Account.

Viele Grüße
Martin

[Martin Fischer]

Hallo Heiko,

Mittlerweile hat sich ein guter Kontakt zum Product Manager Video Surveillance Station (in D) entwickelt. Er unterstützt mich sehr engagiert in Richtung "seiner" Entwickler in Taiwan. Die letzte Anfrage bzgl. der API Doku hängt aber nun auch schon 14 Tage in der Luft. Ist also auch nicht ganz so einfach 

Schaue mir dein Log heute Abend wieder an.

ich habe weiter getestet:
Die besagte Kamera aus FHEM geschmissen und wieder aufgenommen, Werksreset auf der Kamera und Konfiguration, Kamera in SVS gelöscht und wieder eingebunden, equivalentes Model (FOSCAM) in SVS eingetragen und zurück auf INSTAR IN-2905...

Nichts davon führte zum Erfolg. Es bleibt bei dem Errorcode 400.

Dann habe ich mal in der Synology App DS cam bei der Kamera auf Screenshot gedrückt.. und siehe da: Es kommt die Meldung "Aktion nicht ausgeführt". Also hat die App das gleiche Problem mit der Kamera. Also eine weitere IN-2905 ausgegraben und an den Start gebracht.. Selbes Ergebnis! Bei alle anderen Kameras (IN-3001, Axis M1031-W, Vivotek IB8369) funktioniert es.

Obwohl die Meldung "Aktion nicht ausgeführt" in der App angezeigt wird und FHEM bei "snap" ein Error 400 schmeisst, werden die Snapschüsse angelegt! Hier scheint etwas nicht mit der Rückmeldung Kamara <-> API zu funktionieren. Ich glaube Du suchst Dir hier einen Wolf. Der Fehler liegt wohl klar bei Synology oder INSTAR.

Mumpls.. Vorher hatte ich ja mein eigenes FHEM Modul 49_IPCAM.pm für die Schnappschüsse genutzt. Das ging auf jeden Fall, da ich die direkte URL der Kamera genutzt hatte.

[DS_Starter]

Hallo Martin,

dein Log hatte ich vor ein paar Minuten runtergeladen und suche seitdem in der Syno rum. Auch in /var/log/ war nichts brauchbares zu finden.
Ich hatte im Log auch gesehen dass FHEM/Modul die Fehlerinfo definitiv von der Syno zurückbekommt.
Und nach deinen Testergebnis sehe ich es genauso wie du. Da können wir aufhören mit rumsuchen

Ich schlage vor ich mache eine Meldung an meinen Kontakt bei Synology mit der Bitte sich das mal genauer anzuschauen. Die relevanten Logauszüge mit dem Request und der fehlerhaften API-Antwort schicke ich mit. Ich hoffe damit kommen wir weiter.

Ich würde mich dann eher darauf konzentrieren die strmkey-Funtion ins Modul einzubauen. Die Mitteilung an Synology mache ich heute oder morgen fertig.

Etwas würde ich an deiner Stelle noch probieren ... schau doch mal ob es eine neue Firmware für diese Kamera gibt. Vielleicht ist da was geändert worden.

Gruß,
Heiko

[DS_Starter]

Hallo Martin,

bin gerade dabei die Meldung zu formulieren... es betrifft NUR die Schnappschußfunktion ? Ein Aufnahme triggern geht, oder ?

Grüße
Heiko

[Martin Fischer]

Hallo Heiko,

bin gerade dabei die Meldung zu formulieren... es betrifft NUR die Schnappschußfunktion ? Ein Aufnahme triggern geht, oder ?

ja, es betrifft nur die Schnappschüsse. Und wie bereits erwähnt auch in der DS cam App. Solltest Du unbedingt erwähnen, da es dann vielleicht etwas schneller geht

Gruß Martin

[Martin Fischer]

Hallo Heiko,

[...]
Und nach deinen Testergebnis sehe ich es genauso wie du. Da können wir aufhören mit rumsuchen
[...]
Ich würde mich dann eher darauf konzentrieren die strmkey-Funtion ins Modul einzubauen. Die Mitteilung an Synology mache ich heute oder morgen fertig.

Ich denke, das macht Sinn.

Etwas würde ich an deiner Stelle noch probieren ... schau doch mal ob es eine neue Firmware für diese Kamera gibt. Vielleicht ist da was geändert worden.

Ja, Firmware hatte ich auch geprüft. Ist auf dem aktuellen Stand.

Noch etwas was mir - unabhängig von diesem Fall - aufgefallen ist:
Wird ein Schnappschuss ausgelöst, dann treten bei mir immer zwei Events auf:

Code Auswählen Erweitern

2016-08-18 21:00:49 SSCam GR.ho.CAM.SSS.01 LastSnapId:
2016-08-18 21:00:49 SSCam GR.ho.CAM.SSS.01 LastSnapId: 135
2016-08-18 21:02:01 SSCam GR.ho.CAM.SSS.01 LastSnapId:
2016-08-18 21:02:02 SSCam GR.ho.CAM.SSS.01 LastSnapId: 136


Der "leere" Counter ist hier überflüssig und löst ein notify aus, wenn man nur auf "LastSnapId" filtert ohne zu prüfen ob dahinter noch ein Counter kommt. Ist das nur bei mir so? Tritt bei allen Kameras auf.

Viele Grüße
Martin