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

[forum-merlin]

Hallo Heiko.

Kann man die schwellwerte für die Empfindlichkeit der bewegungserkennung auch irgendwie über fhem mitgeben?

Hintergrund ist dass ich an sehr windigen Tagen wo ich permanent über Bewegung informiert werde diese nicht abschalten will sondern auf eine andere Empfindlichkeit per set Kommando über einen Dummy den ich dann auch per WhatsApp oder telegram triggere.
Geht sowas?

Gruß Holger

Gesendet von meinem SM-G920F mit Tapatalk

[DS_Starter]

Hallo Holger,

ja die API gibt das her. Ich habe es aber noch nicht im Modul implementiert und getestet. Wäre mal wieder etwas für ein verregneten WE 

Gruß
Heiko

[math78]

Hallo Heiko,

Danke für Deine Änderungen, probiere sie aus.

LG

Matthias

[dt2510]

Gerade bei dem aktuellen Wetter schlägt die Kamera bzw. die SVS dann doch zu oft an (Sonne da / Sonne weg). Ich werd' wohl auf den Bewegungsmelder ausweichen müssen.
Welche Bewegungsmelder nutzt  ihr ? Ich bräuchte einen für ZWave oder EnOcean und außen (aber überdacht, vor Wind und Wetter geschützt).

[DS_Starter]

Denke auch dass es besser ist. Gerade aus diesem Anlass war dieses Modul ja entstanden 
Einen Rat bzgl. des IR-Melders kann ich dir nicht geben. Ich persönlich habe FS20 bzw. Homematic-Melder im Einsatz.
Vielleicht hast du bezüglich der Produktauswahl in den Spezialforen zu EnOcean bzw. ZWave etwas schnelleren Erfolg.

viele Grüße
Heiko

[forum-merlin]

Hallo Holger,

ja die API gibt das her. Ich habe es aber noch nicht im Modul implementiert und getestet. Wäre mal wieder etwas für ein verregneten WE 

Gruß
Heiko

Ich weiss ja nicht wie es bei dir dieses Wochenende aussieht aber bei mir in München ist das Wetter für diese Aufgabe nahezu perfekt.
Wetter Prognose quasi "caps lock"
Schifft permanent

Gruß Holger

Gesendet von meinem SM-G920F mit Tapatalk

[DS_Starter]

Hi Holger,
schon verstanden ... schauen wir mal 
Ich will aber vorher den gegenwärtige Entwicklungsstand einchecken mit der Änderung aus #299.
Hast du den auch mal ausgetestet ?

Gruß
Heiko

[forum-merlin]

Hi Holger,
schon verstanden ... schauen wir mal 
Ich will aber vorher den gegenwärtige Entwicklungsstand einchecken mit der Änderung aus #299.
Hast du den auch mal ausgetestet ?

Gruß
Heiko

Hallo Heiko,

Nein leider nicht, denn ich kann gerade nicht mal ein update check erfolgreich ausführen, und ich will das erstmal vorher richten.
Habe einen Thread offen und hoffe auf Hilfe.
siehe hier
OFF TOPIC AN
https://forum.fhem.de/index.php/topic,52187.0.html
OFF TOPIC OFF

Gruß

Holger

[forum-merlin]

Hallo Heiko,

ich glaube ich habe mein Problem mit der setstate Message aus dem anderen Thread gefunden.
Es hängt aber mit Deinem modul am Rande zusammen.

Ich habe zwei NAS und damit zwei SVS und ich hatte zu Testzwecken in beide NAS, bzw. SVS, die Cams eingebunden und in FHEM definiert.

Also NAS 1 hiessen die Kameras dann Cam1 bis Cam4 und das Pendant in FHEM dann GA.Cam1 bis GA.Cam3 und die vierte WZ.Cam4

Jetzt habe ich in dem zweiten NAS/SVS die gleichen Cam1 bis Cam4 eingetragen, und in FHEM hiessen die Cams dann Test.Cam1 bis Test.Cam4

Jetzt hatte ich das zweite NAS ausgeschaltet, und die Cams waren da quasi per polling requests nicht erreichbar zur Abfrage.
Dadurch hatten die Cams keinen Default STATE nachdem ich FHEM mal durchgestartet hatte.

Jetzt wollte ich die Test.Cam1 bis 4 per "attr Test.Cam1 disable 1" deaktivieren, aber das ist im Modul nicht berücksichtigt wie es scheint, und ein disable der CAM über den Befehl setzt das ja nicht in FHEM, sondern in der SVS auf disabled.

Ich könnte die Cams einfach auch löschen, aber ich nehme mal stark an, dass Dir die Implementierung eines disable attributes, oder in Zusammenhang eines setstate <camname> defined besser gefällt oder?

Gruß

Holger

[forum-merlin]

Hallo Heiko,

habe #299 nun gelesen und das Modul dafür eingespielt.
Es hat diese Infos im Code:
# $Id: 49_SSCam.pm 11202 2016-04-07 20:10:18Z nasseeder1 $

Erstmal habe ich ohne irgendwelche Attribute ein einfaches
set GA.Cam1 on
ausgeführt.
Dann die Aufnahme auf dem NAS angeschaut, und diese hat 25 Sekunden und nicht 15.
Das kann aber an den Settings liegen die ich grundsätzlich im SVS eingestellt habe oder?
Ich habe nämlich irgendwo gesagt, dass ich immer 5 Sekunden VOR und NACH der Bewegungserkennung aufgezeichnet haben will.
Ob das auch Auswirkungen auf ein getriggertes Record hat?!

Dann mal ein
attr GA.Cam1 rectime 20
gesetzt, dann save


Erwartung = Aufnahmedauer in meinem Fall dann 30 Sekunden
Ergebnis = Aufnahmedauer NICHT 30 Sekunden, aber auch nicht 20 Sekunden, sondern 26 Sekunden > komisch, aber nicht schlimm denke ich.


Dann mal ein
attr GA.Cam1 recextend 1
gesetzt, dann save und dann ein
set GA.Cam1 on
abgesetzt, dann nach ca 10 Sekunden wieder ein
set GA.Cam1 on
und dann nichts mehr.

Erwartung = 10 Sekunden + 26 Sekunden = 36 Sekunden
Ergebnis = PASST! 38 Sekunden



Im Übrigen...
@math78

Ich hatte aufgrund von notify´s und DOIF´s etc auch immer mal Probleme dass bestimmte Kommandos nicht am SVS ankamen, und deshalb hatte ich das Attribut "httptimeout" eingetragen.
Es war so, also würden zu schnell hintereinander gesendete http calls von FHEM zu SVS irgendwo verschluckt werden.
Wenn Du also deinen Bewegungsmelder zum Triggern einer Aufnahme nimmst, kann da natürlich viel geschickt werden.
Wenn Du einen HomeMatic Bewegungsmelder hast, dann kann man da z.B. auch sagen wie lange ein "Stillstand" sein mus, bis er von MOTION auf NOMOTION umstellt, und umgekehrt, was dann wieder Auswirkung auf die PUT Calls gegen das SVS haben dürfte.

Aber Heiko hat das im Modul nun berücksichtigt, und damit is es einfacher

Danke Heiko


Gruß

Holger

[DS_Starter]

Hallo Holger,

erstmal Danke für deine umfangreichen Tests und Erläuterungen.

Also zunächst zum Modul-disable. Hatte ich auch schon daran gedacht es einzubauen und habe es auch noch vor. Nur habe ich noch keinen Plan wie ich es am Besten umsetzen kann. Denn ein Setzen von "state" auf disabled würde ja sogleich suggerieren dass die Kamera disabled wäre was aber nicht stimmten würde. Ich habe da noch das Richtige gefunden ...bin für Ideen offen ...

Um das setstate-Problem, welches du in der speziellen Konstellation erlebt hast zu eliminieren, könnte ich in der Init-Phase zunächst alle Cams auf state = off setzen. Wenn sich beim initialen Polling (sofern die Cams erreichbar sind) ein anderer Status ergibt, wird er ja entsprechend gesetzt. Damit sollte das Prob nicht mehr vorkommen. Teste ich mal...

Zu deinen Aufnahmetests...

Die sehen gut aus. Ja, die in der SVS eingestellte Dauer der Vor-Aufzeichnung geht in die Gesamtlaufzeit der Aufnahme ein. Das stelle ich aber nicht im Modul irgendwo ein, sondern wird von der SVS von sich aus berücksichtigt. Die in der SVS eingestellte Zeit für die Nach-Aufzeichnung geht aber nicht mit ein.

Das heißt die Erwartung darf immer sein:

Gesamtzeit = Vorlaufzeit in SVS + rectime im Modul + Prozess/Verarbeitungszeit

Dein Bespiel 2 mit "attr GA.Cam1 rectime 20" trifft die Erwartungshaltung sehr gut.

Laufzeit = 5 Sek Vorlaufzeit + rectime 20 + Verarbeitungszeit 1 Sek. = 26 Sekunden

Bezüglich der Verarbeitungzeit muß man wissen, dass zur Ablaufsteuerung Prozesstoken eingesetzt werden, die ein gegenseitiges Überholen von konkurrierenden Http-Calls verhindern (asynchrone Abarbeitung duch nonblocking Calls). Der Zustand dieser Token wird zur Zeit alle 1 Sek. ausgewertet (falls ein Befehl ausgelöst ist).  Eine Verzögerung von 1 Sek. ist durchaus normal falls die Befehlsausführung auf ein freies Token warten muß. 5 Sekunden, wie in deinem ersten Beispiel ist zwar etwas lang, kann aber auch durch andere Faktoren wie der Abarbeitungsgeschwindigkeit der SVS  beeinflusst sein.
Um den Verarbeitungsablauf der Token zu loggen und sich anzusehen kann durch das Attribut "debugactivetoken = 1" realisiert werden. Probiers ruhig mal aus  ...

Wichtig ist dass die Aufnahmezeit nicht GERINGER als die eingestellte rectime ausfällt, wie von Mathias beschrieben. Ich selbst habe dieses Phänomen nicht und bin auf das Feedback von der Gemeinde angewiesen. Aber bin zuversichtlich das wir das nun im Griff haben.

Grüße
Heiko

[forum-merlin]

Hallo Holger,

erstmal Danke für deine umfangreichen Tests und Erläuterungen.

Also zunächst zum Modul-disable. Hatte ich auch schon daran gedacht es einzubauen und habe es auch noch vor. Nur habe ich noch keinen Plan wie ich es am Besten umsetzen kann. Denn ein Setzen von "state" auf disabled würde ja sogleich suggerieren dass die Kamera disabled wäre was aber nicht stimmten würde. Ich habe da noch das Richtige gefunden ...bin für Ideen offen ...

Um das setstate-Problem, welches du in der speziellen Konstellation erlebt hast zu eliminieren, könnte ich in der Init-Phase zunächst alle Cams auf state = off setzen. Wenn sich beim initialen Polling (sofern die Cams erreichbar sind) ein anderer Status ergibt, wird er ja entsprechend gesetzt. Damit sollte das Prob nicht mehr vorkommen. Teste ich mal...

Hi Heiko,
Zum Disable kann ich nichts sagen, da ich nicht weiss wie man sowas im Code umsetzt.
Einzige Idee ist für STATE zwischen disabledSVS und disabled zu unterscheiden. disabled zählt aber dann zu FHEM und beeinträchtigt den INIT oder so???

Zu deinen Aufnahmetests...

Die sehen gut aus. Ja, die in der SVS eingestellte Dauer der Vor-Aufzeichnung geht in die Gesamtlaufzeit der Aufnahme ein. Das stelle ich aber nicht im Modul irgendwo ein, sondern wird von der SVS von sich aus berücksichtigt. Die in der SVS eingestellte Zeit für die Nach-Aufzeichnung geht aber nicht mit ein.

Das heißt die Erwartung darf immer sein:

Gesamtzeit = Vorlaufzeit in SVS + rectime im Modul + Prozess/Verarbeitungszeit

Dein Bespiel 2 mit "attr GA.Cam1 rectime 20" trifft die Erwartungshaltung sehr gut.

Laufzeit = 5 Sek Vorlaufzeit + rectime 20 + Verarbeitungszeit 1 Sek. = 26 Sekunden

Bezüglich der Verarbeitungzeit muß man wissen, dass zur Ablaufsteuerung Prozesstoken eingesetzt werden, die ein gegenseitiges Überholen von konkurrierenden Http-Calls verhindern (asynchrone Abarbeitung duch nonblocking Calls). Der Zustand dieser Token wird zur Zeit alle 1 Sek. ausgewertet (falls ein Befehl ausgelöst ist).  Eine Verzögerung von 1 Sek. ist durchaus normal falls die Befehlsausführung auf ein freies Token warten muß. 5 Sekunden, wie in deinem ersten Beispiel ist zwar etwas lang, kann aber auch durch andere Faktoren wie der Abarbeitungsgeschwindigkeit der SVS  beeinflusst sein.
Um den Verarbeitungsablauf der Token zu loggen und sich anzusehen kann durch das Attribut "debugactivetoken = 1" realisiert werden. Probiers ruhig mal aus  ...

Um ehrlich zu sein, sind mir die Zeiten nicht sowichtig, und daher muss das bei mir nicht auf die Sekunde (oder 10 Sekunden) genau sein.

Wichtig ist dass die Aufnahmezeit nicht GERINGER als die eingestellte rectime ausfällt, wie von Mathias beschrieben. Ich selbst habe dieses Phänomen nicht und bin auf das Feedback von der Gemeinde angewiesen. Aber bin zuversichtlich das wir das nun im Griff haben.

Grüße
Heiko

Also ich habe das nicht so 100%ig verfolgt, aber ich dachte er hatte berichtet, dass sein Rasenmäher Robo den Bewegungsmelder auslöst (und das sehr häufig) und dann dadurch Aufnahmen getriggert werden. Dann aber irgendwann aufgrund der vielzahl der PUT Calls mit dem "set CAM on" hängt sich die SVS irgendwie auf, und reagiert nicht mehr auf z.B. "set CAM off" und es wird eine DAUERAUFNAHME draus, und nur ein Restart biegt das wieder gerade?

Deswegen dachte ich nämlich zwischenzeitlich auch an den httptimeout den Du als ATTR eingebaut hast.

Ich kann im Übrigen auch _manchmal_ beobachten (nur gefühlt, nicht im Log), dass wenn ich zuviele PUT Calls gegen die SVS schicke, sich das aufstaut, und ggf. nicht mehr abarbeitet und dann beispielsweise die Bewegungserkennung für CAM 1 und 3 auf SVS steht, aber 2 und 4 auf disabled, obwohl ich immer nur ALLE auf den GLEICHEN Status stellen lasse.

Gruß

Holger

[DS_Starter]

Hi Holger,

Code Auswählen Erweitern

Zum Disable kann ich nichts sagen, da ich nicht weiss wie man sowas im Code umsetzt.

Naja, es geht weniger um die Umsetzung im Code, das ist nicht das Problem. Es ist eher der logische Konflikt der sich aus der verschiedenen disable-Bedeutungen ergibt.

Bei der Bewertung von Problemen können natürlich ganz unterschiedliche Ursachen eine Rolle spielen. Der beschriebene Sachverhalt der Daueraufnahme könnte sich aus einem Stopp-Befehl ergeben, der wegen Timeout die SVS nicht erreicht. Das würde man im Log sehen. Es könnte aber z.B. auch sein, dass wegen Timerfehlers dieser Stopp-Befehl nicht ausgelöst wird. Das Ergebnis wäre das gleiche aber eine ganz andere Ursache.
Was ich damit sagen will .... jeder Sachverhalt kann, muß aber nicht, die gleiche Ursache haben.

Deswegen ist es wichtig für mich zu erfahren ob es timeouts im Log gibt usw.

Auch die SVS wirft einige spezifische Fehler die im Logfile eingetragen werden.

Ich habe mir einen dummy gebaut, mit dem ich alle Cams gleichzeitig auf disabled stelle .... kein Problem. Das ist im Prinzip das gleiche wie deine Umstellung auf die Bewegungserkennung durch SVS bzw. disable.

Um die Ursache zu ergründen hilft eigentlich nur ein verbose 4 Log wenn man diese Massenänderung ausführt und sich das dann mal anzuschauen.

viele Grüße
Heiko

[math78]

Hallo,

schon mal kurze Rückmeldung von mir.
Bis jetzt funktioniert alles, keine Zeitveränderungen im Verlauf!!!

LG

Matthias

[DS_Starter]

Hallo Matthias,

super ... danke für deine Rückmeldung 

Ich checke die Version ein und arbeite weiter am Modul ...

schönes WE,
Heiko