Modul IPCAM überarbeitet

delMar · 18 April 2021, 15:10:49

Zitat von: tremichl am 17 April 2021, 11:58:51
Klingt sehr gut! Vielleicht sollte man zur Sicherheit noch die Anzahl der retrys begrenzen (Attribut?), denn es könnte im ungünstigsten Fall die CAM auch nach einem retry wieder ein "unknown" liefern. Dann hätten wir eine Schleife...

LG, Michael

Also ich hätte generell nur einen retry gemacht.
Denkst du, es macht Sinn, eine freie Anzahl zu definieren?

schöne Grüße
Martin

tremichl · 18 April 2021, 16:10:02

Es ist ja leider nicht vorhersehbar wann die CAM "busy" ist. Außer bei 2 Requests in kurzer Zeit natürlich. Ich schätze daher, dass EIN retry die Chance verdoppelt um ein Bild zu erhalten. Wir können es gerne so versuchen. Die sichere Methode wäre meiner Meinung nach, solange retries zu schicken bis ein Bild da ist. Wirklich elegant ist das nicht, aber in dieser Konstellation fällt mir nichts bessere ein....

Was denkst du?

LG, Michael

delMar · 18 April 2021, 16:16:54

Zitat von: tremichl am 18 April 2021, 16:10:02
Es ist ja leider nicht vorhersehbar wann die CAM "busy" ist. Außer bei 2 Requests in kurzer Zeit natürlich. Ich schätze daher, dass EIN retry die Chance verdoppelt um ein Bild zu erhalten. Wir können es gerne so versuchen. Die sichere Methode wäre meiner Meinung nach, solange retries zu schicken bis ein Bild da ist. Wirklich elegant ist das nicht, aber in dieser Konstellation fällt mir nichts bessere ein....

Was denkst du?

LG, Michael

Solang requests zu schicken, bis ein Bild da ist, kann man natürlich machen.
Ob nach 17 requests mit 2 sekunden Intervall (konstruiertes Beispiel) die Person immer noch an der Tür steht, ist allerdings fraglich.

Versuchen wir's mal mit einem einzigen Request.
Wenn du feststellst, dass das immer noch nicht zufriedenstellend läuft, geb ich die Anzahl von Wiederholungen noch als Attribut mit rein.
Mit mehreren Wiederholungen muss ich nämlich einen Counter mitlaufen lassen, was ich mir so erspare.

schöne Grüße
Martin

tremichl · 18 April 2021, 16:41:45

Da hast du natürlich recht, schauen wir einmal ob ein retry das Problem löst bzw. wesentlich verbessert.

Danke!

LG, Michael

PS: Habe gerade von deinem "Door-Man" gelesen. Kann man ja jetzt alles schon mit IPCAM und einigen notify bzw. doif realisieren. Aber alles in einem Modul zu haben wäre natürlich sehr elegant, zumal ein Bild vom "Türklingler/in" mittlerweile ja zu einer Standard-Anforderung wird

delMar · 18 April 2021, 18:13:36

Update ist drin. Doku direkt im Modul.

den retryCount gibts jetzt trotzdem, weil den Counter brauchte ich sowieso, sonst wär endlos oft wiederholt worden. Nun gibts das also gleich als Attribut.

unknownFormatRetryCount
unknownFormatRetryDelay
handleAnyXmlAsSvg

Die beiden ersten Attribute sind wohl selbstredend.

Das dritte (handleAnyXmlAsSvg) basiert auf folgender Erkenntnis:
die bisherige Regex zum Check von SVG war nicht ganz richtig, weil jedes XML-Dokument als SVG identifiziert wurde.
Ich habe sie nun so abgewandelt, dass entweder SVG-Files, oder SVG-Dokumente (welche trotzdem einen XML header haben) als SVG erkannt werden.
Ein XML-Header alleine, ohne SVG-Tag hinten dran, wird nun nicht mehr als SVG identifiziert (was vorher der Fall war).

Bei mir, Michael, sollte nun also die Response deiner Kamera immer unknown Format liefern, wenn das XML kommt (weils bei dir ja tatsächlich kein SVG ist). Und dann greift retryCount und retryDelay.
Lass uns hier bitte wissen, bei wievielen Retries du dich dann eingependelt hast.

Für alle, die das vorherige XML-Verhalten trotzdem benötigen (wofür auch immer), gibt es nun eben das Attribut handleAnyXmlAsSvg, welches bei jedem XML den Dateityp SVG liefert (wie bisher also. Es wird wirklich die alte Regex verwendet).

Und danke noch zum Feedback für Doorman. Das motiviert auf jeden Fall schon mal zum Weitermachen.
Genau, grundsätzlich kann man das auch mit Notify, etc lösen. Aber die Aufgeräumtheit war auch für mich ein Argument.
Und ich plane ja auch noch ein Widget fürs Tablet-UI, und dafür benötigt man dann ein konkretes Device, woher soll man sonst eine Liste von Ereignissen etc herkriegen.

schöne Grüße
Martin

tremichl · 18 April 2021, 19:19:54

Super, danke!

Nach einem FHEM-Update ist noch das File vom 12.04.2021 drin....muss ich sonst noch was machen?

LG, Michael

delMar · 18 April 2021, 20:27:53

Im Update kommt das File erst ab morgen ca 8 Uhr früh mit.

Im Wiki wäre aber hier https://wiki.fhem.de/wiki/Update ganz unten beschrieben, wie du dir einzelne Dateien direkt sofort holen kannst.

schöne Grüße
Martin

tremichl · 18 April 2021, 23:16:45

Vielen Dank für die Nachhilfe!
Kurzer Test, sieht sehr gut aus.
retrycount 3
retrydelay 1

Werde noch ausführlicher testen und berichten.

Nochmals danke für die Arbeit!

LG, Michael

tremichl · 19 April 2021, 16:55:41

Hallo Martin,

die Erweiterung funktioniert wie erwartet und ist sehr hilfreich. Habe unterschiedliche Parameter versucht. Delay von 0.1 bis 10 Sekunden, Retry von 1 bis 20. Mit Delay 1 und 10 Retries kommt man öfter zum Erfolg als ohne Retries. Leider ist es so, dass auch in diesem Fall (10 Sekunden lang Retries) noch immer Bilder "verloren" gehen. Im log kann man schön sehen, dass das Format immer "unknown" ist, bis eben die Zeit abgelaufen ist. Das heißt, dass sie CAM gelegentlich Sekunden lang (teilweise bis zu 20 Sekunden) keine Snapshots liefert. Dank deiner Hilfe habe ich das Problem eingrenzen können. Offensichtlich haben andere User auch schon ähnliche Erfahrungen gemacht und keine Lösung gefunden:
https://github.com/home-assistant/core/issues/45259
https://www.reddit.com/r/homesecurity/comments/iitbc0/hikvision_camera_returns_device_busy_most_of_the/

Fazit: Die neuen Attribute bringen eine signifikante Verbesserung, können aber die von der Hikvision-CAM versachten Probleme nicht endgültig lösen. Für mich ist die Lösung Hikvision-Cams nicht als Doorcam einzusetzen.

Nochmals vielen Dank!

Liebe Grüße, Michael

delMar · 19 April 2021, 17:06:20

Zitat von: tremichl am 19 April 2021, 16:55:41
Fazit: Die neuen Attribute bringen eine signifikante Verbesserung, können aber die von der Hikvision-CAM versachten Probleme nicht endgültig lösen. Für mich ist die Lösung Hikvision-Cams nicht als Doorcam einzusetzen.

Danke für die Erkenntnisse und die Links an dieser Stelle.

Wärs eine Möglichkeit, einen permanenten Videostream zu haben und von diesem einen Snapshot abzugreifen?
Das würde dann eigentlich außerhalb der Kamera passieren.

schöne Grüße
Martin

tremichl · 19 April 2021, 18:53:42

Videostreams liefert die CAM natürlich. Weiß aber nicht ob das gut ist, wenn man RASPI mit FHEM drauf zusätzlich mit einem permanenten Video-stream beschäftigt. Als Workaround nutze ich jetzt NVRs für die Snapshots. Das klappt sowohl mit Dahua als auch Hikvision.

Was natürlich schön wäre, wenn man nach Bedarf (z.B. nach Türklingel 30 Sekunden lang) in FTUI einen Videostream zeigen könnte. Aber da denkst du ja scheinbar schon in deinem Doorman Projekt darüber nach.

LG, Michael

delMar · 20 April 2021, 08:12:43

Zitat von: tremichl am 19 April 2021, 18:53:42
Videostreams liefert die CAM natürlich. Weiß aber nicht ob das gut ist, wenn man RASPI mit FHEM drauf zusätzlich mit einem permanenten Video-stream beschäftigt.
Als Workaround nutze ich jetzt NVRs für die Snapshots. Das klappt sowohl mit Dahua als auch Hikvision.

Der NVR öffnet wohl ebenfalls einen permanenten Stream, von wo dann die Snapshots abgegriffen werden. Deshalb funktionierts dort auch.

Ob das gut wäre, hängt wohl vom Raspi ab. Bei mir macht ein RPi4 einen permanenten Stream mit 1280x720. Dabei benötigt einer der CPU-Cores ca 60 %.
Bei einem 3B wären das wahrscheinlich gegen 100%, ist aber trotzdem nur einer der Cores (gibt ja 4 davon)

Ich hab dazu die folgende Lösung im Einsatz. Allerdings ohne Docker, hab mir nur aus dem Dockerfile eine Anleitung für FFmpeg und ffserver rausgezogen.
https://github.com/eroji/rtsp2mjpg

Alternativ geht natürlich auch sowas wie ZoneMinder.
Meine Reolink mag aber nicht so mit der aktuellsten ZoneMinder Version (lange Geschichte, wird wohl bald ein Wiki-Eintrag draus werden), deshalb verwende ich das gerade nicht.

Zitat von: tremichl am 19 April 2021, 18:53:42
Was natürlich schön wäre, wenn man nach Bedarf (z.B. nach Türklingel 30 Sekunden lang) in FTUI einen Videostream zeigen könnte.
Aber da denkst du ja scheinbar schon in deinem Doorman Projekt darüber nach.

Das mit dem Timer geht sogar schon.

schöne Grüße
Martin

misux · 13 Mai 2021, 08:56:02

HI!

ich habe meine Cams eingebinden und lass immer einen screenshot machen bei gewissen Situationen mit eine DOIF.

Ist es irgendwie möglich es fest zu legen das NUR 1 Bild geschossen wird?
Bei mir werden immer 2 Bilder gemacht : CAMEingang_snapshot.jpg und CAMEingang_snapshot_1.jpg siehe Bild.
Das kostet rechenpower und schreibkraft auf der SD karte... diese beiden Dateien werden immer zur glichen Zeit geschrieben. die _1 Datei benötige ich allerdings nicht mehr... kann man das irgendwie deaktivieren das diese nicht geschrieben wird? Es sind nämlich exat die gleichen Bilder...

Vielen Dank!

MadMax-FHEM · 13 Mai 2021, 10:00:06

Wie wär's mit einem list des IPCam-Devices?
(statt einen Screenshot vom Dateisystem

)

Im Log steht (evtl. verbose erhöhen) drin was an die Kamera geschickt wird.
Werden da 2 Bilder "abgerufen"?

Wie wird das DOIF getriggert?
Evtl. auch list davon.

Durch was wird das DOIF getriggert?
Evtl. auch list davon.

EDIT: ok, selber bei mir noch mal geschaut. Vermutlich ist das, wenn man eine Serie macht (machen lässt). So kann man sich die Serie ansehen (Bilder mit Nummern) aber auch einfach nur das letzte Bild (der Serie). Bei "Serie = 1" sieht es verm. so aus. Allerdings: ich denke nicht, dass dadurch (alleine bzw. besonders) die SD Karte leidet. Wie oft nimmst du denn Bilder auf? Und wie oft wird (im Vergleich dazu) in die Logs geschrieben etc. UND: ich würde einen wichtigen Raspberry PI (wenn schon) dann mit SSD nutzen... "Spielsysteme" kann man ja gerne mit SD betreiben... Nur meine Meinung.

Gruß, Joachim

delMar · 13 Mai 2021, 10:42:16

Stimmt, da werden immer zwei Bilder gemacht.
Ich hab das noch nie als Problem gesehen (auch aus den Gründen die Joachim genannt hat)

Aber ich verstehe den Einwand schon auch.
Wenn ich wieder mal mit der Bürste über den Code gehe, werd ich das verbessern.
Wahrscheinlich wird man das Attribut snapshots dann auf 0 setzen können, und dann wird das _1 Bild nicht geschrieben.

Danke für euren Input

Schöne Grüße
Martin