Modul IPCAM überarbeitet

Begonnen von Martin Fischer, 01 Februar 2013, 20:30:37

Vorheriges Thema - Nächstes Thema

delMar

Blocking gehst du immer auf channel=0, non-blocking immer auf channel=1.
Hat das einen bestimmten Grund?

Zitat von: eldrik am 09 September 2021, 09:43:43
Und mit Blocking 1 sehe ich gerade, scheint die meiste Zeit beim löschen des alten readings draufzugehen (kommt mit meinen genannten 3 - n Sekunden hin)
Das ist ja eine spannende Erkenntnis, dankeschön.

Dieses Housekeeping im Code ist mir bisher absolut nicht als potentielles Problem bewusst gewesen. Aber du hast recht, dadurch entsteht eine irrsinnige Verzögerung zwischen Aufrufen von get image und dem tatsächlichen Request zur Kamera.

Der Grund ist wohl

    my $readings = $hash->{READINGS};
    foreach my $r (sort keys %{$readings}) {

Ich werde mir das beizeiten genau anschauen müssen.

Danke
schöne Grüße
Martin
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

eldrik

nein der Channel hat hier keine Bewandtnis 0 und 1 liefern den gleichen Snapshot und haben die gleiche Reaktionszeit, da war ich an der einen oder anderen Stelle einfach nicht konsequent bei meinen FHEM Definitionen :)

Ich verfolge den Thread und die FHEM Codeänderungen, wenn es was neues zu IPCAM gibt, probiere ich es erneut ist ja ein glück schnell ein und auskommentiert in meinen Subs.

Greetz
Eldrik 

MadMax-FHEM

#392
Zitat von: eldrik am 09 September 2021, 08:31:48
avconv ist ja ein Stück software ffmpeg ginge auch müsste als Eingangsvoraussetzung auf dem System installiert sein.

In FHEM kann man es dann nutzen in dem man sich ein Shell Skript erstellt, über das der entsprechende avconv oder ffmpeg Befehl aufgerufen wird. Dieses Skript kann über FHEM mit dem system Befehl aufgerufen werden.

Ich bin tatsächlich gestern wieder auf mein vorheriges Konstrukt via Shell Skript und system Befehl gewechselt, da ich mit der Variante über IPCAM einen Versatz von 3-4 Sekunden hatte und die nonblocking Variante bei mir nicht zuverlässig zu funktionieren scheint.

Ich greife jedoch nicht den Stream ab (das kann je nach verwendeten Codec der Kamera und Einstellung bei avconv und ffmpeg auch schon einmal zu unvollständigen Bildern führen) sondern rufe das normale Snapshot Kommando der Kamera via curl auf.

Aufruf in FHEM aus einer 99_myUtils Sub
system("/opt/fhem/FHEM/99_ipcam_briefkasten.sh");

Befehl im Shell Skript
#!/bin/sh
curl -o /opt/fhem/Haustuer_Aufnahmen/cam_briefkasten_snapshot.jpg 'http://IPADRESSE/webcapture.jpg?command=snap&channel=0'


So werden die Aufnahmen bei mir jetzt wieder nahezu zeitgleich zum Auslöseevent erzeugt.

Greetz
Eldrik

Hallo Eldrik,

system blockiert fhem allerdigs (außer mit & am Ende -> Background)

Siehe: https://heinz-otto.blogspot.com/2018/02/in-fhem-externe-programme-aufrufen.html

Und wenn im Script dann curl genommen wird bzw. eben HTTP-Abfragen (die schon mal dauern können), dann kann das schon "schlecht" sein...

Ich habe jetzt nicht verfolgt, ob es blockierend sein muss (z.B. wegen Rückgabewerten), wenn ja, dann entweder aus dem Script Daten zurück an fhem (z.B. per telnet / https://forum.fhem.de/index.php/topic,122801.msg1173393.html#msg1173393 ) oder gleich nonBlocking "auslagern".
Sieht schlimmer aus als es ist, habe ich auch schon mal eingesetzt, habe so z.B. SMARTMON nonblocking "umgebaut" (und bin beileibe kein Perl-Programmierer)...
https://wiki.fhem.de/wiki/Blocking_Call

EDIT:
Zitat
So werden die Aufnahmen bei mir jetzt wieder nahezu zeitgleich zum Auslöseevent erzeugt.
Vermutlich weil eben fhem in der Zwischenzeit nichts tut... ;)
Evtl. wäre es ein Ansatz im Script (oder auch im Modul) nachdem die Bilder (definitiv) da sind ein Reading zu setzen/Event zu erzeugen. D.h. dann bei Reaktion auf DIESES Event müsste ja dann alles klappen?
(oder stehe ich jetzt "im Wald"? / habe meine Kamera ja immer noch nicht im "tatsächlichen" Einsatz)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Hallo Martin,

dürfte ich das noch mal "ins Rennen schicken":

Zitat
Nun dachte ich, dass ich das doch auch bei pathCmd user/pw angeben kann und damit dann auch nur "einfache Kommandos" bei cmd1, cmd2, usw. eingeben brauche.
Das geht leider nicht, weil dann zweimal das "Fragezeichen" kommt, statt dem "Und" für weitere Parameter.

Hier mal was ich meine:

Mein cmd1 meiner "gebastelten" Kamera (2tes list):

    http://192.168.10.184:88/cgi-bin/CGIProxy.fcgi?usr=admin&pwd=madmax123?cmd=ptzStopRun


Hier ein pan/tilt Kommando:

    http://192.168.10.184:88/cgi-bin/CGIProxy.fcgi?usr=admin&pwd=madmax123&cmd=ptzMoveRight


Wäre schön, wenn hier das Verhalten gleich wäre, dann könnte man alle Kommandos "einfach" gestalten...

Ausführlicher hier: https://forum.fhem.de/index.php/topic,10772.msg1147375.html#msg1147375

Eine "Vereinheitlichung" von Kommandos bzw. deren Nutzung (Angabe per Attrinut) wäre schon gut? 8)

Aber wie geschrieben, wenn ich der Einzige damit bin...
...dann vielleicht auch nicht.

Evtl. finde ich auch mal Zeit und schaue mir das "im Modul" an und versuche mich an einem Patch...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

delMar

Zitat von: MadMax-FHEM am 09 September 2021, 10:50:02
dürfte ich das noch mal "ins Rennen schicken":
Ja, ich hab das nicht vergessen.

Die Änderung ist relativ rasch umzusetzen, denke ich.
Ich scheue allerdings den Testaufwand
Und befürchte auch, dass viele Konfigurationen so gestaltet sind, dass sie mit der aktuellen Implementierung funktionieren, aber mit einer "sauberen" nicht mehr, und somit die selbe Situation wie mit blocking non-blocking entsteht.

Aber vielleicht täusche ich mich auch.
Das ist auf jeden Fall ein Thema, für die länger werdenden Abende ;-)

Danke, dass du nach wie vor dein Interesse daran bekundest.
Das ist ein maßgeblicher Faktor, ob man sich die Zeit für etwas nimmt.

schöne Grüße
Martin
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

MadMax-FHEM

Hallo Martin,

klar verstehe ich, ist ja auch ein "gewaltiger" Umbau für alle, die bereits viele Kommandos umgesetzt haben...
...allerdings wundert mich, dass da noch niemand sonst was "angemerkt" hat ;)

(-> evtl. nutzen das noch gar nicht viele/keine ;)  )

Aber längere Abende klingt gut, dann habe ich auch Zeit zu testen :)

Danke für's Nicht-vergessen, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

misux

Hallo...

Ich teste weiter und mit meinen neuen Cams ist mir im Log aufgefallen das ich bei EINEN "get image" das im log bekomme... Ist das normal so? Muss das so oft passieren?

2021.09.15 18:43:10 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:12 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:12 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:19 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:19 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:31 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:31 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:31 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:31 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:33 3: IPCAM (CAMEingang) - getSnapshot URI: http://user:Password@192.168.3.222/cgi-bin/snapshot.cgi?
2021.09.15 18:43:33 3: IPCAM (CAMEingang) - ExecuteSnapshotRequest blocking: 0, camUrl: http://user:Password@192.168.3.222/cgi-bin/snapshot.cgi?
2021.09.15 18:43:35 3: IPCAM (CAMEingang) - Snapshot Image Format: jpg
2021.09.15 18:43:35 4: IPCAM (CAMEingang) - snapshot ./www/snapshots/CAMEingang_snapshot.jpg written.
2021.09.15 18:43:35 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt
2021.09.15 18:43:35 4: IPCAM (CAMEingang) - set: name:CAMEingang cmd:? list:cmd pan pos raw tilt

MadMax-FHEM

Dir ist aber schon aufgefallen, dass die meisten Logeinträge mit Level 4 sind.

Normalerweise ist Level 3 und da können "Ausführungen" (z.B. set-Befehle) kommen...
...alles höher als 4 ist "Informativ" etc. und da kann/darf durchaus mehr kommen...

https://wiki.fhem.de/wiki/Verbose

Somit würde ich finden, dass diese 3 Einträge schon i.O. sind:
Zitat
2021.09.15 18:43:33 3: IPCAM (CAMEingang) - getSnapshot URI: http://user:Password@192.168.3.222/cgi-bin/snapshot.cgi?
2021.09.15 18:43:33 3: IPCAM (CAMEingang) - ExecuteSnapshotRequest blocking: 0, camUrl: http://user:Password@192.168.3.222/cgi-bin/snapshot.cgi?
2021.09.15 18:43:35 3: IPCAM (CAMEingang) - Snapshot Image Format: jpg

Die anderen sollten weg sein, sobald du verbose löschst (Standard ist 3 / sollte) oder eben selber kleiner 4 setzt...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

misux

Ja, das mit Verbose kenne ich, abe mich nur gewundert das es so oft von einem und dem selben ist... aber ok. verbose auf 1 gesetzt.

Vielen Dank!

misux

Hi! Im Moment reißt es irgendwie nicht ab.. Irgendwas ist immer... Habe heute im Log einen Eintrag bekommen beim Snapshot... Was bedeutet dieser?

2021.09.16 12:23:45 1: PERL WARNING: Use of uninitialized value $snapshot in string ne at ./FHEM/49_IPCAM.pm line 519.

delMar

Zitat von: misux am 16 September 2021, 15:11:50
Hi! Im Moment reißt es irgendwie nicht ab.. Irgendwas ist immer... Habe heute im Log einen Eintrag bekommen beim Snapshot... Was bedeutet dieser?

2021.09.16 12:23:45 1: PERL WARNING: Use of uninitialized value $snapshot in string ne at ./FHEM/49_IPCAM.pm line 519.

Das bedeutet, dass von der Kamera kein Snapshot geliefert wurde.
Die Kamera hat aber auch keinen Fehler geliefert.

Das ist mit blocking=1 aufgetreten, stimmts?
Wenn ich das weiß, kann ich die Meldung verbessern.

schöne Grüße
Martin
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

misux

Hmm... Das ist jetzt eine gute Frage... habe 2 Cams, neue Cams da meine alten einfach keinen screenshot mache wollten teilweise, egal wie. Nun haben ich eine mit blocking und die andere ohne... ::)

Ich stelle beide mal auf blocking 1 und beobachte es mal weiter und melde mich.

misux

Zitat von: delMar am 16 September 2021, 15:40:09
Das bedeutet, dass von der Kamera kein Snapshot geliefert wurde.
Die Kamera hat aber auch keinen Fehler geliefert.

Das ist mit blocking=1 aufgetreten, stimmts?
Wenn ich das weiß, kann ich die Meldung verbessern.

schöne Grüße
Martin

Ja, Es tritt bei den Cams mit Blocking 1 auf. Habe jetzt das Attr bei diesen Cams jetzt gelöscht weil die diesmal keine Fotos gemacht hat...

nun heißt es weiter beobachten..

JudgeDredd

Hallo Zusammen,

ich setze das IPCAM Modul erst seit kurzem ein.
Soweit läuft das auch alles ganz gut.

Eine kleine Verständnisfrage hätte ich aber dann doch noch.
Im Internal SEQ steht ja die Nummer des letzten Snapshots drin.

Die Internals überleben ja keinen FHEM-Start.

So kommt es also, das nach jedem Neustart wieder der erste Snapshot überschrieben wird.
Unabhängig vom Attribut snapshots

Kann man das mit den Modul-Mitteln auch dahingehend ändern, das nach dem letzten erstellten snapshot weitergemacht wird ?

Zumindest habe ich nichts gefunden, was darauf schließen lässt, aber ich könnte da natürlich auch was übersehen haben.

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Hyper-V | Debian 12 (VM)

JudgeDredd

Zitat von: JudgeDredd am 23 September 2021, 13:59:34
Eine kleine Verständnisfrage hätte ich aber dann doch noch.
Ich glaube mein Verständnis war ein Falsches.
Ich war der Meinung, das das Modul bei Auslösung immer genau 1 Bild holt und die geholten Bilder nach <attr snapshots xy> wieder überschreibt (rotierend).
Offensichtlich war das wohl ein Irrtum.
Wäre es denkbar sowas im Modul in Zukunft darzustellen ?
Router: Eigenbau (pfSense)
FHEM: Hyper-V | Debian 12 (VM)