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

[forum-merlin]

Überall im Netz findet man Like Buttons!

Und wenn man mal einen braucht um ein cooles Modull und neue Funktionen zu liken is weit und breit keiner da 

Cool dass du dran bleibst Heiko!

Schönes Wochenende!

Gruß

Holger

[dt2510]

Ich weiß, daß das Modul nicht dafür gedacht war um auf die Bewegungserkennung der Kamera oder der SVS zu reagieren, da diese zu viele "Fehlalarme" produziert.
Nachdem ich meine Verbindungsprobleme - PowerLAN eignet sich nicht wirklich, ein Netzwerkkabel ist immer noch die Beste Lösung - in den Griff bekommen habe, hab' ich die Kamera eine Weile in der SVS laufen lassen.
Klar produziert sie Fehlalarme, aber bei mir hauptsächlich, wenn sie von Tag auf Nachtmodus oder umgekehrt schaltet, bzw. wenn ich das Licht ein-/ausschalte. Damit könnte ich durchaus leben...

Jetzt aber zum eigentlichen Punkt:
Meine Kamera hab' ich anstelle des alten Bewegungsmelders für die Eingangsbeleuchtung montiert (war der Beste Blickwinkel) und demnach wird die Beleuchtung nicht mehr automatisch an-/ausgeschaltet.

Ich hätte jetzt 2 Möglichkeiten

a) mit den Fehlalarmen leben - also den Start der Aufzeichnung zum (möglicherweise unnötigen) Einschalten des Lichts verwenden und den Stop zum Ausschalten

Problem: beim Ausschalten würde gleich eine neue Aufnahme gestartet, also wieder Licht an usw. ... ein ewiger Kreislauf
Mögliche Lösung: vor dem Ausschalten des Lichts die Bewegungssteuerung der SVS deaktivieren und danach wieder aktivieren

b) einen Bewegungsmelder (in meinem Fall Z-Wave oder EnOcean) montieren und damit Kamera und Licht steuern

Könnte mir jemand bei einem Script für Lösung a) behilflich sein (ich hab' außer einem notify für einen Funkschalter noch nichts in FHEM "programmiert") oder einen Bewegungsmelder für Lösung b) empfehlen ?

[DS_Starter]

Hallo dt2510,

für deine Aufgabenstellung die Funktionen des Moduls verwenden zu wollen ist m.M. nach nicht zielführend. Vor allem müssten Bewegungserkennungen per Polling zum Modul übertragen werden was viel zu träge reagieren würde.

Ich würde, auch aus den von dir selbst genannten Gründen, immer einen IR-Bewegungsmelder vorziehen.

Aber es gibt noch einen Ansatz mit der Kamera und der SVS den ich kurz andiskutieren möchte.

Man kann in der SVS den Aktionsregeleditor benutzen um eine externe Webseite aufzurufen wenn eine Kamera eine Bewegung erkannt hat.
Die aufzurufende Webseite kann man mit verbose 4 für das globale Gerät nach der Aktivität (z.B. Regal anschalten) im Logfile mit etwas Mühe herausfinden.

Ich habe als Beispiel mal das Einschalten des Lichtes in einer Vitrine hier eingefügt.

Dazu im Aktionsregeleditor -> Aktionsgerät -> externes Gerät -> Url: 

Code Auswählen Erweitern

http://<FHEM-Server>:8083/fhem&dev.seteg_wz_vitrine=eg_wz_vitrine&cmd.seteg_wz_vitrine=set&arg.seteg_wz_vitrine=on

und Benutzer / Passwort hinterlegen.

Als Ereignis gibt man die entsprechende Kamera und "Bewegung entdeckt" an.

Wenn die Cam jetzt eine Bewegung registriert, wird über die Aktionregel die FHEM-Webseite aufgerufen und der Befehl ausgeführt.
Man könnte ein "on-for-timer" benutzen um das Licht für eine gewisse Zeit einzuschalten wenn der Aktor das hergibt.

Jetzt müßte man nur noch dafür sorgen tragen, dass der nächste Schaltimpuls erst wieder akzeptiert wird wenn die Leuchtdauer des Hoflichts (zzgl. Sicherheitszuschlag) vorüber ist um ein ständiges Schalten des Lichtes zu verhindern.

Das kann man sich sicherlich noch ausdenken wenn du weißt welchen Weg du gehen möchtest. Du kannst die Sache mit der Aktionsregel ja mal testen ob das für dich in Frage käme ... dann lohnt es sich weitere Überlegungen in der beschriebenen Richtung anzustellen.

Das ist was mir so adhoc dazu einfällt. Erste Wahl bleibt für mich der IR-Melder.
Vielleicht gibt es noch weitere Ideen dazu ....

viele Grüße
Heiko

[dt2510]

Wenn die Cam jetzt eine Bewegung registriert, wird über die Aktionregel die FHEM-Webseite aufgerufen und der Befehl ausgeführt.
Man könnte ein "on-for-timer" benutzen um das Licht für eine gewisse Zeit einzuschalten wenn der Aktor das hergibt.

Jetzt müßte man nur noch dafür sorgen tragen, dass der nächste Schaltimpuls erst wieder akzeptiert wird wenn die Leuchtdauer des Hoflichts (zzgl. Sicherheitszuschlag) vorüber ist um ein ständiges Schalten des Lichtes zu verhindern.

Ich hab' vergessen zu erwähnen, daß es sich um die Kamera vor der Haustür handelt (also Outdoor) ! Ein Bewegungsmelder könnte allerdings in einem Windfang regengeschützt montiert werden.

Für die Beleuchtung verwende ich ein Fibaro Relais, welches auch on-for-timer unterstützt. Meiner Meinung nach reicht das alleine aber nicht aus.
Wie bei einem handelsüblichen Bewegungsmelder sollte on-for-timer erst aktiv werden, wenn KEINE Bewegung mehr erkannt wird, also folgendermaßen:

1) Bewegung erkannt -> Licht an
2) keine Bewegung mehr -> Timer starten für z.B. 30 Sekunden (gibt es so was ?), bei Bewegung wieder zu 1) und Timer stoppen
3) Timer abgelaufen -> Bewegungserkennung für z.B. 5 Sekunden ignorieren und Licht ausschalten

Sollte das nicht möglich sein, bräuchte ich eine Tip für einen Bewegungsmelder (Z-Wave oder EnOcean, wenn möglich Outdoor und Netz-/Netzteilbetrieb)

[Merlin2000]

Hallo DS_Starter,
Ich bin gestern auf Dein Modul SSCam gestoßen, es löst der Beschreibung nach einige Probleme, die ich mit der SVS habe. Besonders hilfreich ist die Funktion, die Bewegungserkennung abschalten zu können. So lässt sich die Kameraüberwachung prima mit dem Hausstaus koppeln.
Ich habe es also gleich installiert, allerdings stecke ich jetzt fest.
Ich bekomme keinen Zugriff, die Fehlermeldung lautet "connection refused".

Was ich gemacht habe:
- Einen DSM-User angelegt, der hat Adminrechte und Zugriff auf SVS, sonst nichts.
- Den Kameras mittels credentials Namen und Passwort des DSM-Users zugewiesen.
- Den Kameras mittels session mitgeteilt, dass der DSM-User verwendet werden soll.

Wenn ich es richtig verstanden habe, steuert SSCam nur die SVS. Die Kameras haben wiederum eigene User und Passwörter, die in SVS eingetragen sind.
Müssen die User (DSM und Kamera) identisch sein, greift also SSCam direkt auf die Kameras zu?

Beste Grüße,
Dirk

[math78]

Hallo Heiko,

ich wollte endlich mal Rückmeldung geben bezüglich der Aufnahmezeiten. Es ist nach Deinen Änderungen deutlich stabiler geworden, jedoch tritt manchmal der Fehler immer nochmals auf. Nach einem Neustart ist alles wieder in Ordnung. Ausgelöst wird der Fehler vor allem dann, wenn relativ viele Anfragen an die Kamera innerhalb eines kurzen Zeitraums gestellt werden (bei uns reagiert aktuell immer der Bewegungsmelder, wenn der Mähroboter vorbei fährt - das kann dann relativ oft hintereinander vorkommen). Ich denke, dass irgendwann eine Meldung (vor allem Stop-Meldung) an die Kamera nicht weitergeleitet wird. Entweder habe ich dann wieder meine Daueraufnahme oder die Zeit der Aufnahme wird von etwa 40sec auf etwa 10sec reduziert. Ich werde mal versuchen, meine Befehle etwas anzupassen.

LG

Matthias

[DS_Starter]

Hallo zusammen,

@Merlin2000 .... das sieht so aus als ob der HTTP Call nicht zur SVS durchgelassen wird. Port richtig ? Firewall auf der DS offen ?
Mach mal bitte ein "list <Kamera>" und wenn wir damit nicht weiterkommen einen Logauszug mit verbose=4. Dann sehen wir mehr.
Das Modul greift ausschließlich auf die SVS zu. Die Kameras selbst werden nicht angesprochen, das passiert dann ausschließlich von der SVS aus.
EDIT: ...d.h. Nutzer/PW von SVS und Kamera müssen NICHT identisch sein.

@math78 .... das liest sich schon mal sehr gut und freut mich    Ich habe bei mir jetzt testweise x-mal über das Eingabefeld "set <cam> on" im Abstand von 2 Sekunden (so schnell ich eben war) abgesetzt um das Modul zu "provozieren".
Es ist nichts passiert. Die Aufnahmedauer lag konstant bei den eingestellten 22 Sekunden.

Sieht so aus im Log:

Code Auswählen Erweitern

2016.04.12 20:20:11.221 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:20:34.708 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:20:36.258 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:20:59.573 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:21:01.828 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:21:25.127 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:23:28.272 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:23:56.773 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:23:58.683 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:24:21.781 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:25:05.949 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:25:29.213 3: CamCP1 - Camera Carport Recording stopped
2016.04.12 20:25:30.824 3: CamCP1 - Camera Carport Recording with Recordtime 22s started
2016.04.12 20:25:53.997 3: CamCP1 - Camera Carport Recording stopped

Vielleicht würde es sich lohnen mal über eine längere Zeit ein verbose 4 Log mitlaufen zu lassen. Da kommen zwar viele Meldungen zusammen, aber vielleicht hilft das der Sache auf die Spur zu kommen.

viele Grüße
Heiko

[Merlin2000]

Hallo DS_Starter,
das war schon mal ein guter Hinweis. Ich hatte den Port nicht angegeben, damit wurde 5000 benutzt. Mit Port 80 komme ich weiter, allerdings nur bis zur nächsten Fehlermeldung "malformed JSON string received".
JSON ist installiert, zumindest ergibt JSONLIST ein Ergebnis. Falsche Version vielleicht? Kann ich die Version irgendwie abfragen? FHEMINFO hilft hier nicht weiter.
PHP ist über das Synology-Paket mit der Version 5.6 installiert, da kommt JSON gleich mit.

Das Listing der Kamera:

Code Auswählen Erweitern

CAMNAME    GHxxKM01
   CREDENTIALS Set
   DEF        GHxxKM01 192.168.0.55 80
   NAME       GHxxKM01
   NR         339
   OPMODE     Getptzlistpatrol
   SERVERADDR 192.168.0.55
   SERVERPORT 80
   STATE      ???
   TYPE       SSCam
   Helper:
     ACTIVE     off
     APIAUTH    SYNO.API.Auth
     APICAM     SYNO.SurveillanceStation.Camera
     APICAMEVENT SYNO.SurveillanceStation.Camera.Event
     APIEVENT   SYNO.SurveillanceStation.Event
     APIEXTEVT  SYNO.SurveillanceStation.ExternalEvent
     APIEXTREC  SYNO.SurveillanceStation.ExternalRecording
     APIINFO    SYNO.API.Info
     APIPTZ     SYNO.SurveillanceStation.PTZ
     APISNAPSHOT SYNO.SurveillanceStation.SnapShot
     APISTM     SYNO.SurveillanceStation.Streaming
     APISVSINFO SYNO.SurveillanceStation.Info
     APIVIDEOSTM SYNO.SurveillanceStation.VideoStreaming
     CREDENTIALS V6Kz]ZKqPn56iqDpnUH}OW@?
     OLDVALPOLLNOLOGGING 0
     RECTIME_DEF 15
   Readings:
     2016-04-12 20:44:54   Availability
     2016-04-12 20:45:13   Error           malformed JSON string received
     2016-04-12 20:45:13   Errorcode       none
     2016-04-12 20:44:54   LiveStreamUrl
     2016-04-12 20:44:54   PollState       Inactive
Attributes:
   group      Melder
   icon       it_camera
   room       Aussenbereich_hinten
   session    DSM
   webCmd     on:off:snap:enable:disable

Beste Grüße,
Dirk

[DS_Starter]

Hallo Dirk,

PHP ??  -> Perl  .... aber wirst du sicher meinen

Die Meldung gebe ich im Modul aus wenn die empfangenen Daten nicht JSON-konform sind. Das sehen wir wenn du ein Log mit verbose 4 machst und das zur Verfügung stellst (Auszug).

Aber Port 80 ? Hast du den wirklich auf der Syno für die SVS eingestellt ? Das kollidiert doch mit der Web Station / Photo Station. Ich prophezeie mal kühn dass hier das Problem liegen könnte ...

Grüße
Heiko

[DS_Starter]

Hallo Mathias,

mir ist noch eine Möglichkeit, außer verbose 4 LOg, eingefallen.
Setze für die Cam das Attribut "debugactivetoken = 1". Vielleicht reicht das schon für den Zweck und es fallen nicht so viele Daten im Log an.

Grüße
Heiko

[Merlin2000]

Hallo Heiko,
Da war wohl einiges durcheinander bei mir...
Ich habe die SVS jetzt auf Port 554 angesprochen, im Moment bekomme ich noch ein time-out, aber das war hier schon mal Thema, danach suche ich jetzt.
Eine Frage noch: TCP-Port ist richtig? Es wird für die SVS noch ein UDP-Port genannt.

Beste Grüße,
Dirk


Gesendet von iPad mit Tapatalk

[DS_Starter]

Hallo Matthias,

ich habe über deine Schilderung noch einmal nachgedacht und habe nochmal eine Änderung am Modul vorgenommen. Wenn bisher, während eine Aufnahme lief ein weiterer Startimpuls eintraf, wurde nach Beendigung der ersten Aufnahme eine weitere gestartet.  Möglicherweise ist das unter Umständen eine Ursache für die plötzliche Minderung der Aufnahmedauer.
Mit der anghängten Version wird erst ein weiterer Startimpuls akzeptiert wenn die erste Aufnahme beendet ist. Alternativ denke ich noch darüber nach die erste Aufnahme zu verlängern wenn während des Prozesse ein weiterer Startimpuls eintreffen sollte.

Bitte verwende die angehängte Version und gib mir Bitte eine schnelle Rückmeldung !

(Kann natürlich auch jeder Interssierte ebenfalls tun  )

schönen Tag ,
Heiko

[DS_Starter]

Morgen Dirk,

ja TCP ist richtig. Der Port 554 kommt mir aber irgendwie bekannt vor dass  er von einem anderen Dienst auf der Syno schon genutzt wird, bin mir aber nicht sicher.
Kannst du mir mal ein paar Screenshots von deiner Portkonfiguration auf der SVS machen ?
Also wo du den Port einstellst den die SVS benutzen soll usw.

EDIT: jetzt weiß ich .... 554 ist der RTSP Port den die SVS verwendet. Das ist ein Streamingport. Nimm mal einen anderen wenn du den Standard 5000 nicht verwenden willst. Zum Beispiel 9900 im Anwendungsportal.

viele Grüße
Heiko

[Merlin2000]

Ok, Port 5000 war doch richtig. 5000 ist der HTTP-Port der Synology, 554 ist der interne Port der SVS.
Jetzt gibt es keine Fehlermeldung mehr.
Vielen Dank für Deine Unterstützung!

Dirk


Gesendet von iPad mit Tapatalk

[DS_Starter]

Hallo zusammen,

ich habe das Verhalten der Funktion "set ... on" zum Start einer Aufnahme etwas angepasst und mit dem neuen  Attribut "recextend" flexibilisiert.

Hier ein Auszug der Doku zu diesem Befehl. Sobald ich die neue Version eingecheckt habe, aktualisiere ich auch das WIki.


Der Befehl "set <name> on" startet eine Aufnahme. Die Standardaufnahmedauer beträgt 15 Sekunden. Sie kann mit dem Attribut "rectime" individuell festgelegt werden. Die im Attribut (bzw. im Standard) hinterlegte Aufnahmedauer kann einmalig mit "set <name> on [rectime]" überschrieben werden. Die Aufnahme stoppt automatisch nach Ablauf der Zeit "rectime".

Ein Sonderfall ist der Start einer Daueraufnahme mit "set <name> on 0" bzw. dem Attributwert "rectime = 0". In diesem Fall wird eine Daueraufnahme gestartet die explizit wieder mit dem Befehl ""set <name> off" gestoppt werden muß.

Das Aufnahmeverhalten kann weiterhin mit dem Attribut "recextend" wie folgt beeinflusst werden.

Attribut "recextend = 0" bzw. nicht gesetzt (Standard):

* wird eine Aufnahme mit z.B. rectime=22 gestartet, wird kein weiterer Startbefehl für eine Aufnahme akzeptiert bis diese gestartete Aufnahme nach 22 Sekunden beendet ist. Ein Hinweis wird bei verbose=3 im Logfile protokolliert.

Attribut "recextend = 1" gesetzt:

* eine zuvor gestartete Aufnahme wird bei einem erneuten "set <name> on"-Befehl mit der Aufnahmezeit "rectime" neu parametrisiert. Das bedeutet, dass der Timer für den automatischen Stop auf den Wert "rectime" neu gesetzt wird. Dieser Vorgang wiederholt sich mit jedem Start-Befehl. Dadurch verlängert sich eine laufende Aufnahme bis kein Start-Inpuls mehr registriert wird.

* eine zuvor gestartete Endlos-Aufnahme wird mit einem erneuten "set <name> on"-Befehl nach der Aufnahmezeit "rectime" gestoppt (Timerneustart). Ist dies nicht gewünscht, ist darauf zu achten dass bei der Verwendung einer Endlos-Aufnahme das Attribut "recextend" nicht verwendet wird.

Durch diese Änderung sollen unter anderem die in #290 geschilderten Effekte beseitigt werden.

Hier angehängt die neue Version wieder vorab für alle Interessierten zum Einsatz.