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

[ArminK]

Hallo, ich habe in den letzten Tagen immer wieder das Problem, dass sich fhem nach einem Neustart (z.B. nach Änderungen an der Konfiguration) von selbst wieder beendet (/etc/init.d/fhem status sagt: fhem is not running). Dies passiert nachvollziehbar wenn eine meiner zwei in der SVS definierten Kameras nicht erreichbar ist (Netzwerkprobleme oder "Hänger", Netzteil raus und wieder rein und sie ist wieder ereeichbar). Die letzten Meldungen im Log ist folgende:

Code Auswählen Erweitern

2017.06.11 14:33:30 2: CamH2 - error while requesting http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid" - http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid": empty answer received
2017.06.11 14:33:30 4: CamH2 - --- Begin Function sscam_login ---
2017.06.11 14:33:30 4: CamH2 - Credentials read from RAM: sscam ********
2017.06.11 14:33:30 5: CamH2 - HTTP-Call login will be done with httptimeout-Value: 20 s
2017.06.11 14:33:30 4: CamH2 - Call-Out now: http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=*****&format="sid"
2017.06.11 14:33:31 2: CamH1 - error while requesting http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid" - http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid": empty answer received
2017.06.11 14:33:31 3: CUL_HM set to_ht statusRequest
2017.06.11 14:33:32 3: CUL_HM set wz_tvLiftDown statusRequest
2017.06.11 14:33:35 3: CUL_HM set wz_tvLiftUp statusRequest
2017.06.11 14:33:37 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/49_SSCam.pm line 3635.
Can't use string ("") as a subroutine ref while "strict refs" in use at ./FHEM/49_SSCam.pm line 3635.

Aktuell ist es die CamH2, die nicht erreichbar ist.
Deren Definition sieht so aus:

Code Auswählen Erweitern

define CamH2 SSCam HUSC2 192.168.1.41
attr CamH2 alias Kamera Eingang
attr CamH2 devStateIcon .*isable:set_off .*nable:FS20.off .*nap:li_wht_on
attr CamH2 event-on-change-reading LastSnapFilename, Record
attr CamH2 eventMap on:Start off:Stop snap:Snap enable:Enable disable:Disable
attr CamH2 group Haus
attr CamH2 httptimeout 20
attr CamH2 icon it_camera
attr CamH2 pollcaminfoall 200
attr CamH2 pollnologging 1
attr CamH2 rectime 30
attr CamH2 room Cams
attr CamH2 showStmInfoFull 1
attr CamH2 verbose 5
attr CamH2 webCmd Start:Stop:Snap:Enable:Disable

Verwendet wird die aktuelle Version 49_SSCam_V2.2.1.pm
Bin ich der einzige der dieses Problem hat?
Grüße aus Heidelberg
Armin

[DS_Starter]

Hallo Armin,

den Fehler hatte ich noch nicht und es wurde bisher auch noch nicht gemeldet.
Ich habe den Code etwas abgeändert um das Problem abzufangen (V2.2.2 anbei).
Bitte teste ob die Stabilität nun bei dir gegeben ist.

ABER... es mildert nur das Symptom, nicht die Ursache.
Es sieht mir so aus als ob deine Syno bzw. die API nicht sauber antwortet.

[url="http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid""]http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid"[/url]: empty answer received

Es betrifft ja auch beide Cams CamH1, CamH2, wenn ich das richtig sehe:

2017.06.11 14:33:30 2: CamH2 - error while requesting http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid": empty answer received
2017.06.11 14:33:31 2: CamH1 - error while requesting http://192.168.1.41:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=sscam&passwd=XXXXXXXXX&format="sid": empty answer received

Der Call geht ja auch an die DS bzw. die API und nicht an die Cams an sich.

Also da solltest du m.M. nach mal forschen warum die sich nicht meldet.
Aber dessen ungeachtet sollte mit dieser Codeänderung dein FHEM nicht abstürzen wenn dieser Fehler beim Start auftritt.

Grüße
Heiko

[ArminK]

Hallo Heiko,
vielen Dank für die fixe Antwort und Hilfe. Habe gerade nachdem ich nach Hause gekommen bin die Kamera wieder online gebracht und das Phänomen bleibt das gleiche
Wenn ich fhem per Kommandozeile starte und gleich danach den Status prüfe so ist dieser "running", allerdings nicht lange, geschätz gegen Ende des Startvorgangs schmiert fhem wieder mit dem gleichen Fehler ab. Ich habe jetzt erstmal die beiden Cams (=alles was mit SSCam zu tun hat) auskommentiert und fhem läuft erfreulich normal.
Ich werde dann mal wieder einen Schritt zurück gehen und Deine angehängte Version ausprobieren, gebe dann gleich Bescheid.
Grüße Armin

[ArminK]

Hallo nochmals,
deine Änderung scheint zu greifen, auch wenn Du ganz richtig bemerkst, dass die Änderung nur die Symptome und nicht die Ursache beseitigt, trotzdem natürlich vielen Dank dafür!
An welcher Stelle sollte ich den genau mal schauen? Eher Netzwerk-Topologie oder Disk- bzw. Surveilancestation? Fhem-Cubie, Fritzbox und Diskstation sind nicht (wie vieles andere) über das ganze Haus/Grundstück verteilt sondern räumlich beisammen und an einem gemeinsamen Switch angeschlossen...ich denke ich muss trotzdem mal mein ganzes Netzwerk aufdröseln und frisch organisieren...

Ein schönes Wochenende noch!

Grüße
Armin

[DS_Starter]

Hi Armin,

keine Ursache. Hauptsache ist dass trotz Fehlern FHEM stabil läuft. Das hat oberste Prio.

Hmmm ... kann mir ehrlich gesagt noch keine Erklärung dafür liefern wieso die DS auf die Anforderung der Session ID eine leere Antwort zurückgibt, keinen Fehler. 
Zur Eräuterung, SSCam holt sich beim Start für jedes SSCam-Device eine Session-ID und arbeitet mit der solange sie gültig ist. Falls die Session beendet wird, z.B. die Session im DSM gelöscht wird, holt sich SSCam eine neue ID.

Ob es am Netzwerk liegt bezweifle ich momentan etwas, auch weil ja alles recht übersichtlich aufgebaut ist, wie du geschrieben hast.

Du könntest mit dem Attribut "session" experimentieren. Hierüber kannst du auswählen ob die Session mit DSM bzw. der Surveillance Station aufgebaut wird. Du müßtest dir dann einen User in der SS anlegen und diesen in den Credentials verwenden.

Schreib auch mal welchen DS-Typ du hast bzw. welche SS-Version. Vielelicht kann dann auch noch ein anderer User etwas dazu sagen der die gleiche Umgebung hat.

Die neue Version teste ich noch ein bisschen und checke sie dann ein.

Dir auch noch einen schönen Restsonntag.

Heiko

[ArminK]

Hallo Heiko,
nochmals vielen Dank für die ausführliche Antwort! Ich werde mir das mal anschauen und hier mitteilen.
Grüße Armin

[oli82]

Guten Morgen Heiko.

Hatte gestern Handwerker im Haus und deshalb eine der Kameras über Fhem deaktiviert.
Leider hat das aktivieren über Shem nicht mehr geklappt, sondern ich musste erst in die SS und dort die Kamera aktivieren.
Erst dann konnte ich die Kamera wieder über Fhem bedienen.
Kannst du das reproduzieren?
SS-Version 8.0.3-5159
SSCam: 2.2.2

[DS_Starter]

Morgen Oli,

klappt bei mir einwandfrei. Sowohl disable als auch enable. Habe es gerade mit meinen Cams probiert.
Hast du vlt. irgendwelche Timeouts  im Log ?

Grüße
Heiko

[oli82]

Schau ich nachher mal nach. grade etwas schlecht

[kermitthefrog]

Moin,

bei mir evtl. ähnliches Problem. Mein FHEM hängt sich 1-2 mal am Tag auf, mit einem Fehler im LOG welcher auf SSCAM als Ursache hindeutet (oder die dahinterliegende Ursache).

Code Auswählen Erweitern


2017.06.20 07:42:44 3: KameraGarten - PTZ Patrols of Garten retrieved
2017.06.20 07:42:46 3: KameraGarten - Capabilities of Camera Garten retrieved
2017.06.20 07:43:10 3: KameraGarten - Polling now: 07:43:10 , next Polling: 07:43:40
2017.06.20 07:43:10 3: KameraGarten - Query event list of Garten successfully done
2017.06.20 07:43:11 3: KameraGarten - Camera-Informations of Garten retrieved
2017.06.20 07:43:12 3: KameraGarten - Capabilities of Camera Garten retrieved
2017.06.20 07:43:13 3: KameraGarten - Enumerate motion detection parameters of Garten successfully done
2017.06.20 07:43:14 3: KameraGarten - PTZ Presets of Garten retrieved
2017.06.20 07:43:16 3: KameraGarten - PTZ Patrols of Garten retrieved
2017.06.20 07:43:22 3: KameraGarten - Camera Garten motion detection source set to "SVS"
2017.06.20 07:43:43 3: KameraGarten - Polling now: 07:43:43 , next Polling: 07:44:13
2017.06.20 07:43:44 3: KameraGarten - Query event list of Garten successfully done
2017.06.20 07:43:45 2: KameraAuffahrt - ERROR - 105 - Insufficient user privilege in operation MotDetSc -> try new login
2017.06.20 07:43:45 3: KameraGarten - Capabilities of Camera Garten retrieved
2017.06.20 07:43:47 3: KameraGarten - Enumerate motion detection parameters of Garten successfully done
2017.06.20 07:43:49 2: KameraAuffahrt - error while requesting http://192.168.178.2:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login&account=admin&passwd=ftcdbtx&format="sid" - read from http://192.168.178.2:5000 timed out
2017.06.20 07:43:51 2: KameraGarten - error while requesting http://192.168.178.2:5000/webapi/entry.cgi?api="SYNO.SurveillanceStation.Camera"&version="8"&method="GetStmUrlPath"&cameraIds="3"&_sid="78D20v6OjXeYsD1KDN00066" - read from http://192.168.178.2:5000 timed out
Can't use an undefined value as a subroutine reference at ./FHEM/49_SSCam.pm line 3635.


Hatte deswegen FHEM schon mal komplett neu aufgesetzt, dass hat aber nicht geholfen, außer bei der Eingrenzung des Fehlers. Wenn ich die Devices (SSCAM) lösche, läuft wieder alles rund...

Wenn meine DS nicht erreichbar ist (zB Neustart), dann meldet FHEM/SSCAM - error while requesting / Connection refused. FHEM läuft aber sauber weiter.

Mir fehlt etwas der Ansatz, wo ich den Fehler suchen soll

Gruß,
Kermit

[DS_Starter]

Hallo Kermit,

Welche Version hast du im Einsatz ? Mach mal bitte ein List eines Devices.
Der letzte Fehler in Zeile 3635 sollte seit dem letzten Update nicht mehr auftreten.

Die timeouts kannst du versuchen mit dem Attr "Timeout" zu fixen. Die eine Meldung bzgl. Privileged ist auch nicht ok.
Schau mal ob der verwendete User ausreichende Rechte für die Funktion hat. Das ist abhängig von dem Session-Attribut.  Im einfachsten Fall zur Fehlereingrenzung einen Admin-user mit DSM-session verwenden.

Grüße
Heiko

[kermitthefrog]

Hey,

korrekt, durch das letzte Update ist der Fehler weg (oder wird unterdrückt). Hatte ich parallel zu meinem Beitrag gestern aufgespielt...
Bzgl. der timeouts habe ich das Pooling-Intervall erstmal reduziert, hatte das testweise auf 30 Sekunden, vielleicht mochte das die DS nicht. User ist der Hauptadmin, von daher dürfte es hinsichtlich Rechte eigentlich kein Problem geben.

Die Frage ist für mich ja jetzt noch, woher kam/kommt der Fehler. Es lief alles einwandfrei, bis.... ? Ich kann es leider nicht sagen. FHEM hat sich auf einmal immer wieder "erhängt", ich hatte es den Spielereien mit nem anderen Service auf dem Raspberry zugeordnet und deshalb den raspberry stumpf neu aufgesetzt.

Danke trotzdem für die "Lösung"...

Ich bin jetzt auf
SSCAM Version 2.2.2
SVSversion 8.0.3-5159

Gruß,
Kermit

[DS_Starter]

Hallo Kermit,

Der Fehler in Zeile 3636 war ein richtig böser Fehler der fhem abstürzen ließ. Er kam aber nur dann zum Tragen wenn wie bei dir Login Fehler auftraten. Das Modul ist an dieser Stelle nun gefixt.

Der 105 Error kann natürlich weiterhin auftreten. Der wird von der Syno bzw. API gemeldet. Der 105er kann sogar auftreten wenn die Credentials stimmen. Das gab es ab und zu in  älteren DSM bzw. SS-versionen. Bei mir ist es schon sehr lange nicht mehr vorgekommen. Für diesen Zweck hatte ich Mal das Attr NoQuotesForSid eingeführt. In manchen Fällen hat es geholfen den sporadischen 105er zu vermeiden. Kannst des Mal probieren.

Grüße,
Heiko

[Rumbel]

Hallo zusammen,

laut Synology gibt es ein schönes neues Update (beta) für deren Software mit HTML5 um endlich auch wieder per Chrome die Kamera nutzen zu können.

Gibt es schon Informationen, ob sich dabei die Schnittstelle auch ändert oder sollte es direkt mit SSCam laufen?
Hat das schon jemand getestet?

[DS_Starter]

Ich selbst konnte mich auch noch nicht durchringen weil ich Grad noch eine Baustelle in DbRep und DbLog hatte.
Aber falls etwas nicht mehr gehen sollte kann man sich mit dem Attr simu_SVSversion behelfen bis ich dazu gekommen bin das Modul anzupassen. So ist zumindest der Plan 

Vllt. Versuche ich das Update am WE.

Grüße
Heiko