Modul IPCAM überarbeitet

eldrik · 02 September 2021, 09:53:57

Zitat von: misux am 31 August 2021, 20:49:27
Hmm... Interessant!

Also mein Kumpel und ich wir nutzen seit anfang an mehrere Dahua Cams. Die liefen anfangs wirklich problemlos über ca 2 Jahre und dann fing es langsam an diese Timeouts zu produzieren was jetzt sehr oft vor kommt. Und es kommen immer die alten bilder wenn ein Timeout im Log war...

Es sind die Dahua IPC-HDBW4631R-S 6MP IP Camera und 4431CA. Aber wie gesagt am anfang lief es problemlos...

Ich teste noch das mit dem delay an den Cams, vielleicht hilft es... dann bin ich am ende meines Chinesisch...

Ein ähnliches Verhalten habe ich mit meinen IP Kameras auch gehabt, teilweise wurden keine Bilder geschrieben und in den Telegram oder Email Benachrichtigungen dann alte Bilder verwendet.

Ich bin dann auf die IPCAM Version vor 07.03.2021 21:57:20 zurückgegangen die noch keine unblocking beinhaltete.

Greetz
Eldrik

delMar · 02 September 2021, 10:51:33

Ich werd das blocking Verhalten wieder reingeben, sobald ich die Zeit finde.
Hoffentlich schon dieses Wochenende.

Sorry für die Umstände

schöne Grüße
Martin

misux · 03 September 2021, 22:29:00

Cool! Das klingt sehr gut!
Wenn das dann wieder wie früher funktionietrt, gibt es dennoch irgendwie die Möglichkeit die Bilder kleiner zu bekommen mit dem "get image"?
Für eine Telegrambenachrichtigung reicht eine Auflösung z.b. 1024x768 völlig aus...
Wäre sowas irgendwie möglich?

delMar · 06 September 2021, 10:58:49

Hallo,
ich hab soeben ein Update ins SVN gegeben, wird ab morgen früh im Update verfügbar sein.

Es gibt nun ein neues Attribut mit Namen blocking.
Wenn das auf 1 gesetzt ist, wird der Snapshot wieder wie früher per GetFileFromURLQuiet ausgeführt, nicht per HttpUtils_NonblockingGet.
Das Default-Verhalten bleibt non-blocking, da ich davon ausgehe, dass das für den Großteil der Kameras kein Problem darstellt.

Bitte um Feedback, ob das die Timeout-Problematik beseitigt.

Zitat von: misux am 03 September 2021, 22:29:00
Wenn das dann wieder wie früher funktionietrt, gibt es dennoch irgendwie die Möglichkeit die Bilder kleiner zu bekommen mit dem "get image"?
Für eine Telegrambenachrichtigung reicht eine Auflösung z.b. 1024x768 völlig aus...
Wäre sowas irgendwie möglich?

Das Bild wird 1:1 so verwendet wie es von der Kamera kommt.
Dh du müsstest in der snapshot-url der Kamera definieren, dass du eine geringere Auflösung willst.

An einen post-processing Schritt direkt im Modul hab ich schon mal nachgedacht:
neben Verringern der Bildgröße wäre zB auch ein Beschneiden des Bildes eine Option (Kamera macht 4K Bild, gespeichert und versendet wird aber nur ein kleiner Ausschnit daraus - würde sozusagen digitalem Zoom entsprechen)

Mir fehlt aber derzeit die Zeit dazu; erfahrungsgemäß wird das dann besser, wenn die Abende wieder länger werden

schöne Grüße
Martin

misux · 06 September 2021, 23:34:16

Klasse! Vielen Dank! Bin gespannt, werde es morgen updaten und anpassen und dann ein paar Tage beobachten und mich wieder melden.

Ja, das Bild in der Cam verkleinern wäre schon viel besser, geht aber leider nicht bei meinen Dahua Cams.

Drücke die Daumen das die längeren Abende stressfreier werden und vielleicht im IPCAM Modul früchte tragen

Bis dahin, Vielen Dank und klasse Arbeit!

misux · 08 September 2021, 13:03:35

Puh..
Nachdem ich das blocking auf 1 gesezt habe konnte ich an 2 Cams gar keine screenshots mehr machen... Weder manuell noch per doif.
nach langem hin und her probieren habe ich festgestellt das ich den screenshot nichtmal über den http abruf im Browser einsehen konnte... Heißt: die Cam hat sich was den screenshot irgendwie aufgehängt... Jedenfalls 2 cams von 5 mit komplett gleicher Cam/Firmware und einstellungen.

Hmm.. nach einem Neustart der Cams ging der screenshot wieder. Nun weiß ich nicht woran es liegt... Was dafür sorgt das die cams den screenshot manchmal komplett blockieren....

Bin noch dran, aber irgendwas sagt mir das es nicht unbedingt am FHEM liegt... vielleicht aber an der Kombination WIE FHEM/IPVAM den Screenshot abholt... vielleicht kommt die Cam damit irgendwie nicht klar...

Maista · 08 September 2021, 13:15:50

@misux
Kann zwar nichts zu deinem Problem direkt beitragen, aber ich habe mir neulich eine TP-LINK Webcam gekauft um zu sehen welche Katze ihr Unwesen im Keller treibt.
Bei der TP-LINK App gibt es eine Punkt der das zeitgesteuerte reseten der Kamera ermöglicht!
Auch die Survillance Software der Synology NAS bietet diesen Punkt.
Hatte mich schon gefragt warum es dies gibt.
Sehe nun aber das es durchaus Sinn machen kann

Vielleicht bietet deine Cam ja ebenfalls diese Funktion.

Gruß Gerd

delMar · 08 September 2021, 13:44:57

Danke für euren Input.

Zitat von: misux am 08 September 2021, 13:03:35
Bin noch dran, aber irgendwas sagt mir das es nicht unbedingt am FHEM liegt... vielleicht aber an der Kombination WIE FHEM/IPVAM den Screenshot abholt... vielleicht kommt die Cam damit irgendwie nicht klar...

Also das IPCAM Modul nutzt nur die gegebenen Funktionen von HttpUtils.
Ich wüsste im generellen aber nicht, wie man einen Request so vermurksen kann, dass die Gegenseite abstürzt (falls nicht die Gegenseite auf irgendwelche Werte allergisch reagiert).

Cam-Neustart macht bestimmt Sinn, ich starte meine Kameras 1x die Woche neu.

schöne Grüße
Martin

misux · 08 September 2021, 14:58:23

Jap, diese Funktion nutze ich JEDEN Tag um 03 Uhr morgens... ist schon komisch das die Cam inzwischen solche Probleme damit hat... der Stream den die Synology abgreift und aufnimmt geht problemlos, der substream den ich zur schnellen mobiln ansicht nutze funtzt auch und der dritte stream den der Raspi mit rpisurv auf meine monitore zaubert geht auch problemlos... aber der screenshot überlebt oft keinen Tag... Mist... $:-\$

delMar · 08 September 2021, 15:33:04

Zitat von: misux am 08 September 2021, 14:58:23
aber der screenshot überlebt oft keinen Tag... Mist... $:-\$

Du könntest alternativ noch probieren, den Screenshot direkt von einem der Video-Streams abzugreifen, anstatt separat über die snapshot-url der Kamera. Synology kann das uU.

schöne Grüße
Martin

misux · 08 September 2021, 16:28:58

Na das ist doch die Idee schlecht hin!
Hmm... warum wird das eigentlich nicht immer so gemacht, dachte jedenfalls das das so an sich irgendwie im Hinergrund passiert... Das Problem ist, ich habe keine Ahnung wie ich das im Fhem einbinden soll...

Habe was im Internet gefunden was an sich funktionieren soll, hat aber mit FHEM nix zu tun..

avconv ist wohl das Zauberwort..

der code soll so sein: avconv -rtsp_transport tcp -i rtsp://ip/channel -r 1 -vframes 1 Foto.jpg

denke so kann man auch den channel frei wählen und somit auch die auflösung die auf dem channel eingestellt ist...

könnte man das vielleicht irgendwie in dein IPCAM Modul einbinden?

delMar · 08 September 2021, 16:48:29

Zitat von: misux am 08 September 2021, 16:28:58
Problem ist, ich habe keine Ahnung wie ich das im Fhem einbinden soll...

Ich kann nur mit einem Vergleich antworten:
ZoneMinder bietet pro Kamera nicht nur die Stream-URL an, sondern auch eine Snapshot-URL.
Dh den Snapshot krieg ich von ZoneMinder, nicht von der Kamera direkt.
Und ZoneMinder zieht sich den vom Stream raus (und macht nicht zB cgi-bin/getSnapshot.cgi oder sowas)

Und diese Snapshot-URL kann ich problemlos von IPCAM aus verwenden.

Dh du müsstest checken, ob Synology oder rpisurv diese Option anbieten.

Den Rahmen dieses Moduls würde das allerdings sprengen...

schöne Grüße
Martin

eldrik · 09 September 2021, 08:31:48

Zitat von: misux am 08 September 2021, 16:28:58
Na das ist doch die Idee schlecht hin!
Hmm... warum wird das eigentlich nicht immer so gemacht, dachte jedenfalls das das so an sich irgendwie im Hinergrund passiert... Das Problem ist, ich habe keine Ahnung wie ich das im Fhem einbinden soll...

Habe was im Internet gefunden was an sich funktionieren soll, hat aber mit FHEM nix zu tun..

avconv ist wohl das Zauberwort..

der code soll so sein: avconv -rtsp_transport tcp -i rtsp://ip/channel -r 1 -vframes 1 Foto.jpg

denke so kann man auch den channel frei wählen und somit auch die auflösung die auf dem channel eingestellt ist...

könnte man das vielleicht irgendwie in dein IPCAM Modul einbinden?

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

Code Auswählen

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

Code Auswählen

curl auf.

Aufruf in FHEM aus einer 99_myUtils Sub

Code Auswählen

system("/opt/fhem/FHEM/99_ipcam_briefkasten.sh");

Befehl im Shell Skript

Code Auswählen

#!/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

delMar · 09 September 2021, 09:14:08

Hallo Eldrik,

wenn du wieder mal Zeit und Muße hast, wärs sehr interessant, zu sehen, ob mit dem letzten Update die Blocking variante wieder besser funktioniert für dich.

IPCAM selber macht ja eigentlich auch nichts anderes, als der curl Befehl, den du im Shell Script ausführst, von daher wärs auch spannend, herauszufinden, ob IPCAM auch blocking wirklich mehr zeitlichen Versatz hat.

Danke jedenfalls für dein Feedback

schöne Grüße
Martin

eldrik · 09 September 2021, 09:43:43

Zitat von: delMar am 09 September 2021, 09:14:08
Hallo Eldrik,

wenn du wieder mal Zeit und Muße hast, wärs sehr interessant, zu sehen, ob mit dem letzten Update die Blocking variante wieder besser funktioniert für dich.

IPCAM selber macht ja eigentlich auch nichts anderes, als der curl Befehl, den du im Shell Script ausführst, von daher wärs auch spannend, herauszufinden, ob IPCAM auch blocking wirklich mehr zeitlichen Versatz hat.

Danke jedenfalls für dein Feedback

schöne Grüße
Martin

Hi,

ja ich hatte die letzte Version bereits ausprobiert, ich wühle gerade mal die Meldungen aus dem Log von vor ein paar Tagen.

Mit Blocking 0 erhalte ich leider bei meiner Beispielkamera:

Code Auswählen

2021.09.06 18:59:02.902 0: IPCAM (cam_briefkasten) - error while getting snapshot http://IPADRESSE//webcapture.jpg?command=snap&channel=1 - http://IPADRESSE//webcapture.jpg?command=snap&channel=1: empty answer received

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)

Code Auswählen

2021.09.06 20:12:00.476 5: IPCAM (cam_vorne) - remove old reading: snapshot1
2021.09.06 20:12:00.478 5: IPCAM (cam_haustuer) - remove old reading: snapshot1
2021.09.06 20:12:00.479 5: IPCAM (cam_stellplatz) - remove old reading: snapshot1
2021.09.06 20:12:05.017 3: IPCAM (cam_vorne) - getSnapshot URI: http://IPADRESSE/webcapture.jpg?command=snap&channel=0
2021.09.06 20:12:05.018 3: IPCAM (cam_vorne) - ExecuteSnapshotRequest blocking: 1, camUrl: http://IPADRESSE/webcapture.jpg?command=snap&channel=0
2021.09.06 20:12:05.232 3: IPCAM (cam_vorne) - Snapshot Image Format: jpg
2021.09.06 20:12:05.285 4: IPCAM (cam_vorne) - snapshot /opt/fhem/Haustuer_Aufnahmen/cam_vorne_snapshot.jpg written.
2021.09.06 20:12:05.344 4: IPCAM (cam_vorne) - snapshot /opt/fhem/Haustuer_Aufnahmen/cam_vorne_20210906_201205.jpg written.
2021.09.06 20:12:05.344 4: IPCAM (cam_vorne) - image: cam_vorne_20210906_201205.jpg

Greetz
Eldrik