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

Baerli34 · 14 September 2016, 09:34:08

Hiho,

ist exakt der gleiche Aufruf - natürlich mit dem Pass. Und ja - ein DSM Update wurde durchgeführt sowie leider einige Änderungen
mehr die aber eigentlich nichts mit dem Surveillance Modul zu tun hatten (hab das nas relativ neu). Habe leider auch
wohl zu vorschnell in FHEM die Kams rausgeworfen und versucht neu zu initialisieren

Wobei mir einfällt dass das Passwort auch geändert wurde -
aber wie du ja auch schon sagtest - würde eine andere Fehlermeldung provozieren! Und ich habe es mehrfach neu gesetzt und fhem auch neu gestartet
sowie sogar den pi

Kurzes Update: ein curl 'http://192.168.0.36:5000/webapi/auth.cgi' -d api=SYNO.API.Auth -d version=6 -d method=Login -d account=cam -d passwd=xxxx -d format=sid bringt mir auch den 407er auf dem Pi

Ergo werde ich jetzt erst mal da weiterforschen - wie gesagt ein Browseraufruf mit den Get-Params hatte funktioniert...

grüsse, Jörg

DS_Starter · 14 September 2016, 10:27:18

Das Hauptproblem wird vermutlich das DSM Update sein. Synology ändert gern einmal die internen Versionen seiner API und dokumentiert leider die dazu gehörigen Syntaxänderungen nicht konsequent.
Komisch ist allerdings wieso der manuelle Login mit exakt dem gleichen Aufruf funktioniert.
Das verstehe ich momentan noch nicht.
Bitte ein bisschen Geduld .... Bin noch unterwegs und melde mich wieder.

Grüße
Heiko

DS_Starter · 14 September 2016, 10:53:00

Ich glaube ein anderer User hatte ein ähnliches Problem einige Seiten zuvor. Wir haben dann herausbekommen dass der FHEM-Host im DSM gesperrt war. In der Security Einstellung des DSM .. blockiere IP-Adresse wenn Login ein paar Mal falsch o.ä. Ich hab die genaue Stelle nicht im Kopf.
Firewall auf DSM ist auch eine heisse Spur.

Baerli34 · 14 September 2016, 11:28:14

Sehr ärgerlich und tut mir gerade ein wenig leid deine Zeit verschwendet zu haben

Dachte mir auch gerade sowas nachdem es überall funktionierte nur nicht auf dem PI

Und siehe da - in der Automatischen Blockierung hatte ich die Liste übersehen und da stand der Pi - jetzt in
die Whiteliste aufgenommen und alles schön - danke für deine Geduld. Werde mich demnächst hoffentlich hier mal
revanchieren können (komme aus der Entwicklung)...

lg, Jörg

DS_Starter · 14 September 2016, 11:39:59

Hi Jörg,
Kein Problem. Dadurch lernen wir alle.
Werde den unbekannten 407er mit einem Text versehen und so vielleicht zukünftig die Fehlersuche erleichtern.
Hoffe das er dann nicht in die Irre führt

Würde mich freuen wenn du mithilfst das Modul oder Lösungen damit und drumherum zu verbesern.
Wenn du Berechtigung hast kannst du auch einen Hinweis im Wiki hinterlassen. Es gibt dort eine Seite für SScam.

Grüsse,
Heiko

DS_Starter · 15 September 2016, 17:45:05

Hallo zusammen,

können bitte mal ein oder gern auch mehrere Nutzer (vor allem mit SVS Version 7.2) die angehängte Version testen !?

Ich habe neben einem Fehlertext für den error 407 ( @Jörg, vllt. kannst du das nochmal bei dir simulieren ) die Funktion Start/Stop einer Aufnahme auf die neue Syntax für SVS 7.2 erweitert.
Neu ist ebenfalls die Möglichkeit mit dem Attribut simu_SVSVersion die Version 7.1 zu simulieren (wenn man eine SVS 7.2 hat). Der Funktionsumfang ändert sich dadurch nicht. Sowohl mit als auch ohne dieses Attrbut sollte alles normal funktionieren. Gedacht ist diese Möglichkeit vor allem zur Fehlersuche bzw. werden in Zukunft vllt. auch Unterschiede im Funktionsumfang spürbar.

Freue mich auf eure Rückmeldungen !

viele Grüße
Heiko

Motivierte linke Hände · 15 September 2016, 22:48:19

Hi Heiko,

ich habe hier SVS 7.2. Habe die Testversion eingespielt. Bisher keine Auffälligkeiten. Wenn ich was Spezielles machen soll, sag gerne bescheid.

Grüße
Christian

DS_Starter · 16 September 2016, 07:56:32

Hi Christian,

danke für die Rückmeldung. Aufnahmetest hast du sicher schon gemacht.
Auch mit und ohne dem Attribut simu_SVSVersion = 7.1-xxxx ?

Wenn du es versuchen möchtest dann setzte die IP deines FHEM-Servers im DSM -> Sicherheit -> automatische Blockierung auf die Blockierungsliste.
Dann sollte in der Cam ein sinnvoller Fehlertext erscheinen sobald eine Aktion ausgeführt werden soll.

Grüße
Heiko

Motivierte linke Hände · 16 September 2016, 12:29:51

So, hab mal mit simu_SVSVersion herumgespielt.

Ohne gesetztes Attribut funktioniert alles (Aufnahme starten/stoppen), wie es soll.
Mit Attribut auf 7.1 funktioniert alles, wie es soll.
Mit Attribut 7.2 ist irgendwas im Argen:

Aufnahme startet.
Aufnahme stoppt nicht nach der angegebenen Zeit (in der SS zu beobachten). fhem geht aber davon aus, dass die Aufnahme gestoppt ist
Aufnahme manuell stoppen geht nicht, fhem sagt: Cam_Terrasse - recording is already stopped - new stop-command will be ignored
Neustart von fhem führt zu Cam_Terrasse - Recording of Terrasse seems to be still active after FHEM restart - try to stop it now, gefolgt von einem Cam_Terrasse - Camera Terrasse Recording stopped, was allerdings eine blanke Lüge ist, die Aufnahme läuft weiter.
Ändere ich dann das Attribut wieder auf 7.1, erkennt er den Status der Kamera (an/aus) wieder richtig und kann die Aufnahme dann auch stoppen.

Man könnte meinen, ich hätte SVS 7.1 statt 7.2. Allerdings sagen die Kamera-Readings:

Code Auswählen

SVSversion 7.2-4664

Und auch auf der Syno auf der Weboberfläche der SS steht 7.2.

DS_Starter · 16 September 2016, 13:03:29

Die 7.2 glaube ich dir

Kannst du mir bitte einen Log 4 Auszug machen wo auch das (fehlgeschlagene) Stopkommando mit drin ist ?

Dann finde ich den Fehler sicherlich schneller ...

Grüße
Heiko

Motivierte linke Hände · 16 September 2016, 13:34:45

Das ist länger...

(edit: Nachdem das Format auch beim Nacheditieren immer zerschossen wurde, habe ich den Text nun gelöscht, er hat seinen Zweck ja wohl erfüllt.

)

DS_Starter · 16 September 2016, 14:21:15

Jo danke ... das war ein typischer Copy & Paste - Fehler.

Kannst du das alles bitte wieder mit der angehängten Version testen !?

Danke und Grüße
Heiko

Motivierte linke Hände · 16 September 2016, 18:16:43

Meinem groben Wahrnehmungsraster zufolge: Löppt!

(Kameras gehen an und gehen aus, bewegungsmeldergesteuert. Mit und ohne Attribut, egal, wie es gesetzt ist.)

Eins ist mir aber doch aufgefallen:

Wenn die Kamera gerade gepollt wird, funktioniert die Aufnahme nicht oder nur sehr verzögert:

Code Auswählen

2016.09.16 18:08:19 3: Cam_Terrasseneingang - Polling now: 18:08:19 , next Polling: 18:11:19
2016.09.16 18:08:20 3: Cam_Terrasseneingang - Query event list of Terrasseneingang successfully done
2016.09.16 18:08:23 3: Cam_Terrasseneingang - Camera-Informations of Terrasseneingang retrieved
2016.09.16 18:08:24 3: Cam_Terrasseneingang - Enumerate motion detection parameters of Terrasseneingang successfully done
2016.09.16 18:08:26 1: n_Motion: triggered, Device >Motion_Terrasseneingang<, Event >motion<
2016.09.16 18:08:27 3: Cam_Terrasseneingang - Capabilities of Camera Terrasseneingang retrieved
2016.09.16 18:08:28 1: Cam_Terrasseneingang - ERROR - Operation Getptzlistpreset of Camera Terrasseneingang was not successful. Errorcode: 400 - Execution failed
2016.09.16 18:08:30 1: Cam_Terrasseneingang - ERROR - Operation Getptzlistpatrol of Camera Terrasseneingang was not successful. Errorcode: 400 - Execution failed
2016.09.16 18:08:31 1: n_Motion: triggered, Device >Motion_Terrasse<, Event >motion<
2016.09.16 18:08:33 3: Cam_Terrasse - Camera Terrasse Recording with Recordtime 35 s started
2016.09.16 18:08:37 3: Cam_Terrasseneingang - Camera Terrasseneingang Recording with Recordtime 35 s started
2016.09.16 18:08:52 3: Cam_Terrasse - Polling now: 18:08:52 , next Polling: 18:11:52
2016.09.16 18:08:54 3: Cam_Terrasse - Query event list of Terrasse successfully done
2016.09.16 18:08:56 3: Cam_Terrasse - Camera-Informations of Terrasse retrieved
2016.09.16 18:08:59 3: Cam_Terrasse - Enumerate motion detection parameters of Terrasse successfully done

Wie zu sehen: Bewegungsmelder Terrasseneingang (ich kam raus) sprach an, Aufnahme startete in diesem Fall, aber erst 7s später. Bei einem anderen Test startete sie nicht.

Normal ist, was Bewegungsmelder Terrasse (dahin wanderte ich weiter) macht: Er meldet, und 2s später startet die Aufnahme.

Nun kann man sagen, 180s Pollzeit ist zu wenig, ich sollte das hochsetzen. Das verringert aber nur das statistische Risiko, dass das Problem auftritt. Ich würde es gerne lösen...

Auf "pollcaminfo" ganz verzichten und manuell ein "get <cam> caminfoall", wenn der Readingstimestamp zu alt ist und der StmKey oder etwas Ähnliches benötigt wird?

Grübelnd,
Christian

DS_Starter · 16 September 2016, 19:02:14

Hi Christian,

Fehler ist beseitigt ... sieht gut aus.

Zu deinem Problem.
Das Polling erzeugt natürlich eine gehörige "Abfragelast". Synology stellt leider die Informationen nicht in einer einzelnen Abfrage zur Verfügung. Vielmehr muss ich eine ganze Reihe von Calls absetzen um alle Infos zu bekommen.
Ein Ziel meiner Weiterentwicklung am Modul ist es die Anzahl der Calls gegen die SVS zu verringern um das Zeitverhalten zu verbessern.
Ich habe mir zwar vorgenommen im Herbst weiterzumachen, aber ich werde dir nachher eine Version zur Verfügung stellen, in der ich das interne Zeitregime weiter gestrafft habe.
Vielleicht hilft dir das schon weiter (es kommt auch etwas darauf an wie performant dein FHEM-Host mit der SVS zusammenspielt).

Kannst du bitte noch die Sache mit der Blockingliste testen ? Bis dahin bin ich auch mit deiner Testversion fertig.

EDIT: Das aber die Aufnahme garnicht startet darf nicht passieren ! Dann stimmt etwas nicht. Die Befehle gehen nicht verloren. Es sei denn dein FHEM blockiert hervorgerufen durch andere/äußere Umstände.

Gruß,
Heiko

DS_Starter · 16 September 2016, 19:42:33

Hallo Christian,

schau mal ob du in deinem Zeitverhalten mit der angehängten Version eine Verbesserung erzielst.
Falls du in deiner Umgebung auf das komplette Polling verzichten musst/willst kannst du dir auch ein AT bauen mit dem du nur "get <cam> StmUrlPath" aufrufst. Damit wird lediglich der StmKey neu geholt und dadurch die Anzahl der Calls zur SVS minimiert.

Grüße
Heiko