Modul IPCAM überarbeitet

[MadMax-FHEM]

Hallo Martin,

Du doch auch

Ja, irgendwie wohl schon

Danke, du hast einen Bug entdeckt. Im Template ist ein Tippfehler. Fix wird heute noch eingecheckt.
das PAR muss klein geschrieben werden (falls du es bei dir gleich mal lokal beheben willst)
Ja, hier werd ich mal versuchen, dieses Verhalten besser zu dokumentieren.

Juhuuuu!
Gerne!

Äh, dumme Frage: was macht das??
Konnte auch in der Doku nichts finden...
...vielleicht bin ich auch "zu doof"

Habe mich noch nicht wirklich viel mit dem Modul auseinandergesetzt...
Die Kamera-Geschichte läuft schon lange:

zuerst eine brauchbare Kamera finden: pan/tilt/zoom, OHNE Cloud, "Bewegungserkennung" IN der Kamera, ein-/ausschalten der Erkennung (per cgi), rtsp-Stream und keine 200EUR+
(Hatte eine China-Kamera, leider ging da der Hack nicht mehr Dann eine Reolink, da ging das Ein-/Ausschalten der Erkennung nicht und dann eben diese Foscam   / eine Unifi-Kamera war ein totaler Fehlkauf: kein pan/tilt/zoom [gut das wusste ich ] und ich dachte noch ich könnte außen eine Kamera anbauen, naja kann man in Deutschland ja fast vergessen, wenn man nicht ein Haus mit Grundstück etc. hat   )

Hier ein paar Links zu cgi-Befehls-Dokus für Foscam (werde ich noch ins Wiki stellen bzw. glaube ich sind die da schon? Hatte ja vor einiger Zeit mal was ergänzt, zumindest für Reolink [solange ich die zum Testen hier hatte]):
https://www.foscam.es/descarga/Foscam-IPCamera-CGI-User-Guide-AllPlatforms-2015.11.06.pdf
https://www.themadhermit.net/wp-content/uploads/2013/03/FI9821W-CGI-Commands.pdf
https://www.manualslib.com/manual/1466496/Foscam-Cgi.html

Aber wie geschrieben: nicht alle dort aufgeführten Befehle funktionieren (entweder weil es neuere FW gibt oder weil eben "mein Typ" das [so] nicht kennt/kann)...

Dann hatte ich mich für die Foscam entschieden
Ein wenig rumprobiert. U.a. auch mit Zoneminder etc.
Mich aber dann für das IPCAM-Modul entschieden.
(keep it simpel / warum noch einen "Server" laufen lassen / die Foscam kann ja "Alarmvideos" auch per ftp ablegen, mal sehen)
Ein wenig rumprobiert und gesehen, dass es prinzipiell tut. Fertig

Dann überlegt: wohin mit der Kamera
(gut hätte ich vielleicht vorher tun sollen   / Aber es ist/war [und bleibt verm. auch] nur "Spielerei")

Und jetzt denke ich habe ich ein Plätzchen gefunden etc. und daher: weiter geht's, wie du merkst

Manche Attribute definieren ganze Pfade, manche nur Teile davon.
Ist notiert.
Ich denke, hier müssen unterschiedliche Templates pro Firmware gemacht werden.

Eigentlich nicht.
Also gut, ich weiß nicht wie sich andere FWs oder andere Foscam-Typen "verhalten".
Ich meinte, dass bestimmte Befehle ANDERS LAUTEN.
Und das schreibt man ja dann in das Attribut, also jeder selber?!
Zumindest für "nicht Standard Befehle" (wie pan/tilt/zoom usw. / wobei es da ja schon drauf ankommt, ob die Kamera das überhaupt kann   )...
Und ob versch. attrTemplates selbst für unterschiedliche Kamera-Typen des selben Herstellers Sinn machen: ich denk nicht mal das!?
Ein Hinweis, dass nicht alle Funktionen von allen Typen (des Herstellers) gehen und man ja dann die Attribute löschen kann (wenn man will / bzw.: sie funktionieren halt nicht / oder eben anpassen "muss") sollte doch reichen!?

Also ich hatte ja mal einen simplen Befehl zum Aktivieren/Deaktivieren der Erkennung, wie auch hier genutzt: https://www.home-assistant.io/cookbook/foscam_away_mode_PTZ/

https://ipaddress:443/cgi-bin/CGIProxy.fcgi?cmd=setMotionDetectConfig&isEnable=0&usr=admin&pwd=password

Aber zum einen hat sich das angesprochene "cgi-Objekt" geändert: aus "setMotionDetectConfig" wurde "setMotionDetectConfig1" und auch der Aufruf ist anders, aufwändiger, da nicht nur (mehr) isEnabled mitgegeben werden muss/kann, sondern (leider) die ganze Config.

D.h. meine "damals" notierten Befehle gingen "plötzlich" nicht mehr. Ob das nun durch einen FW-Update kam (an den ich mich irgendwie gar nicht erinnere   ) oder ich nur dachte: oh, toll das geht und gar nicht getestet hatte: keine Ahnung
(vielleicht war ich bei der Analyse "damals" nicht gründlich genug und nur froh, dass ich eine Kamera gefunden habe für die es cgi-Beschreibungsdokumente gibt und auch ein Befehl dafür existiert / wobei ich mich zu erinnern glaube, dass ich das doch getestet habe, egal   )

Daher muss ich das auch separat machen, bzw. ist es verm. besser im Wiki aufgehoben.
Dazu brauche ich aber Zeit und muss es auch erst mal (ausgiebig) austesten...

Danke für dein ausführliches Feedback.
Ich werde sehen, dass ich das im Lauf der nächsten Abende Stück für Stück umsetzen kann.
Einheitliches Verhalten würde definitiv gut tun

GERNE!!

Ich habe die Kamera (daher) aktuell auch nur "teilweggepackt"

Ich habe ja noch das Attribut "credentials" entdeckt, werde ich auch mal "testen"...

Und dann gibt es ja noch "query". Mal sehen wie sich das verhält.
Also ob das dann "auf alle Kommandos" GLEICH wirkt (wie geschrieben), dann könnte ich ja auch das nehmen und user/pwd aus den pathCmd usw. rausnehmen...

Mal sehen.
Aber am WE habe ich leider keine Zeit dafür...
...bzw. warte ich eh erst mal auf die nächste Version

Danke, Joachim

[SimonFoag]

Hallo,
Nachdem ich jetzt mein FHEM auf mein NAS umgezogen habe und nun auch Performance Probleme (fast) ausschließen kann, hab ich nochmal ein bisschen getestet.
Mit ImageWithCallback bringt er mir immer den timedout Fehler. Egal mit welcher Zeit im Attribut.
Der image Befehl hingegen funktioniert bis jetzt gut.
Ich denke das beim Callback vielleicht die Zeit zu kurz ist bis er den nächsten Befehl auslöst?
Hm, eig nicht, weil er ja gar kein Bild von der Kamera bekommt...?!

Soviel zu meinem Test.

Vielen Dank und Grüße
Simon

[delMar]

Danke, dass du dir die Zeit nimmst, Simon.

Kannst du bitte bei Gelegenheit mal verbose auf 4 stellen und den Log output wo so ein timeout vorkommt hier posten?

Danke
Schöne Grüße
Martin

[delMar]

So: nochmal kurz zum Timeout Problem bei imageWithCallback.

Ich hab jetzt festgestellt, dass bei get image der eigentliche Request im Rahmen eines internal Timers gemacht wird (weil man ja auch snapshot sequenzen definieren kann). Auch wenn nur ein einzelnes Bild gemacht wird, wird der Request mit einem Internal Timer gemacht, aber eben mit delay 0.

Ich hab jetzt ein Update eingecheckt, wo auch imageWithCallback innerhalb eines internal timers mit 0 delay ausgeführt wird.
get image und get imageWithCallback funktionieren nach wie vor bei mir, dh schlechter sollte dadurch mal nix werden.

Im Idealfall funktioniert nun aber imageWithCallback ohne timeout.
Bitte um Feedback, das Update ist ab morgen früh verfügbar.

Ich habe in anderen Modulen schon ein- oder zweimal gesehen, dass diverse Befehle über timer ohne delay aufgerufen wurden.
Könnte es vielleicht sein, dass dieses timeout gehäuft dort auftritt, wo die FHEM Instanz vielleicht etwas gestresst ist?
Also nicht gestresst bezüglich reiner CPU-usage, sondern gestresst durch viele parallele Timer, dh viele Befehle in einer Queue, oder dergleichen?

Falls das auch nix hilft, wäre der nächste Schritt dann trotzdem, wahlweise per Attribut wieder blockierende Requests zu erlauben.

Hope that helps

Danke für eure Mitarbeit
schöne Grüße
Martin

[SimonFoag]

Hi,
Vielen Dank das du dir so viel Mühe machst.
Ich habe nun mit Verbose 4 nochmal getestet. Und was soll ich sagen, es gab keinen Timedout mit get mageWithCallback. Das Update hab ich aber noch nicht gemacht.
Ich weiß nun wirklich nicht mehr an was es liegt, aller Wahrscheinlichkeit nach an der Kamera und WLAN Verbindung... ich kann's mir nicht anderst erklären.
Aber warum funktionierte gestern get image, und get imageWithCallback auf Teufel komm raus nicht?
Irgendwie passt das nicht zusammen.
Wie gesagt, FHEM hat keine Performance Probleme da es auf einem Leistungsstarken NAS läuft.
Ich spiel nachher das Backup ein und teste mal weiter.

Danke und Grüße
Simon

[delMar]

Hi Simon,

ich kann mir gut vorstellen, dass es an den Befindlichkeiten der Kamera liegt, obs funktioniert oder nicht.
Wenns aber einen Weg gibt, diese Befindlichkeiten auszugleichen, würd ich den gern finden.
Und ich hab faktisch ja einen Unterschied zwischen beiden Befehlen gefunden, somit war das schon guter Input von dir.
Jetzt hoff ich nur noch, dass du auch davon profitierst

schöne Grüße
Martin

[MadMax-FHEM]

Ich hatte ja auch mal die "Reaktions-Probleme"...
Kamera auch WLAN (jaja   )...

Aber nach einem Reset und neu (aber da war wohl bei mir so einiges "Verstellt" wegen "wildem" cgi-Kommandos "ausprobieren") geht es aktuell gut.
(hatte mich ja "entschuldigt" dass jetzt Timeouts eingebaut wurden und ich die [aktuell] gar nicht [mehr] brauche)

Gruß, Joachim

[delMar]

Also, das Forum is ja dazu da, um Probleme zu diskutieren.
Wenn für manche die Lösung darin besteht, Firmware Upgrades und Resets zu machen, dann ist das hier genau der richtige Platz, um dieses Wissen zu dokumentieren

Davon abgesehen denke ich, dass incrementalTimeout und InternalTimer mit 0 delay die Zuverlässigkeit des Moduls auf alle Fälle erhöhen.

Und das httpTimeout Attribut kann trotzdem sinnvoll sein. Speziell, wenn man sich zB images übers Internet von einer Weathercam holt.
Somit ist das soweit eine absolute Win/Win Situation

Schade bloß, dass wir von den grauen Bildern nix mehr gehört haben 

schöne Grüße
Martin

[tremichl]

Hallo!

In diesem Beitrag https://forum.fhem.de/index.php/topic,93480.0.html wird beschrieben, dass anstatt eines jpg ein svg File geschrieben wird. Ich kämpf schon länger mit diesem Problem, konnte aber keine Lösung finden. Daher möchte ich hier über meine Erfahrungen berichten und hoffe, dass jemand helfen kann das Problem zu lösen.

An vier verschiedenen Standorten betreibe ich je eine eigenständige FHEM Installation auf RASPI3 mit jeweils 3 bis 5 CAMs (Hikvision und chinesische XMEYE) und je einem NVR (Hikvision und Dahua). IPCAM funktioniert grundsätzlich von allen CAMs und auch über die NVRs (Danke für das Modul!). Nur bei den Hikvision DS-2CD2055FWD-I wird (durch ein notify) grundsätzlich auch ein jpg File angelegt, nur ab und zu (ca. jedes dritte bis fünfte Mal) wird ein svg File geschrieben. Wenn man zum Test im Modul in kurzen Abstand 2x get image drückt, kann man beobachten, dass erst ein svg File und kurz darauf ein jpg File angelegt wird. Ab und zu bleibt es beim svg und es gibt kein neues jpg. Häufiger tritt das Problem in der FHEM Installation auf, wo FHEM die CPU mit 15% bis 20% belastet. Bei 5%-10% CPU Auslastung eher selten. Habe auch 3 verschiedene Hikvision Firmware Versionen getestet. Immer das gleiche Verhalten. Mir scheint, dass es ein Timing Problem bei der Erkennung des Bildformates in Zusammenhang mit einigen CAMs gibt.

Wäre echt schön wenn das gelöst werden könnte.

LG, Michael   

Code Auswählen Erweitern

defmod CAM_TERRASSE IPCAM 10.152.52.101
attr CAM_TERRASSE userattr cams cams_map structexclude
attr CAM_TERRASSE basicauth admin:xxx
attr CAM_TERRASSE delay 0
attr CAM_TERRASSE group IPCAM
attr CAM_TERRASSE icon it_camera
attr CAM_TERRASSE model Hikvision
attr CAM_TERRASSE path ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
attr CAM_TERRASSE snapshots 1
attr CAM_TERRASSE storage /opt/fhem/www/snapshots

Code Auswählen Erweitern

2021.04.16 12:04:08 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:08 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:12 5: IPCAM (CAM_TERRASSE) - remove old reading: snapshot1
2021.04.16 12:04:12 3: IPCAM (CAM_TERRASSE) - getSnapshot URI: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:12 3: IPCAM (CAM_TERRASSE) - ExecuteSnapshotRequest camUrl: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:13 3: IPCAM (CAM_TERRASSE) - Snapshot Image Format: JPEG
2021.04.16 12:04:13 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot.jpg written.
2021.04.16 12:04:13 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot_1.jpg written.
2021.04.16 12:04:13 4: IPCAM (CAM_TERRASSE) - image: CAM_TERRASSE_snapshot_1.jpg
2021.04.16 12:04:13 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:13 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:14 5: IPCAM (CAM_TERRASSE) - remove old reading: snapshot1
2021.04.16 12:04:14 3: IPCAM (CAM_TERRASSE) - getSnapshot URI: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:14 3: IPCAM (CAM_TERRASSE) - ExecuteSnapshotRequest camUrl: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:15 5: IPCAM (CAM_TERRASSE) - remove old reading: snapshot1
2021.04.16 12:04:15 3: IPCAM (CAM_TERRASSE) - getSnapshot URI: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:15 3: IPCAM (CAM_TERRASSE) - ExecuteSnapshotRequest camUrl: http://admin:xxx@10.152.52.101/ISAPI/Streaming/channels/101/picture?snapShotImageType=JPEG
2021.04.16 12:04:15 3: IPCAM (CAM_TERRASSE) - Snapshot Image Format: SVG
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot.svg written.
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot_1.svg written.
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - image: CAM_TERRASSE_snapshot_1.svg
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:15 3: IPCAM (CAM_TERRASSE) - Snapshot Image Format: JPEG
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot.jpg written.
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - snapshot /opt/fhem/www/snapshots/CAM_TERRASSE_snapshot_1.jpg written.
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - image: CAM_TERRASSE_snapshot_1.jpg
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt
2021.04.16 12:04:15 4: IPCAM (CAM_TERRASSE) - set: name:CAM_TERRASSE cmd:? list:cmd pan pos raw tilt

[delMar]

Hallo Michael,

die Formaterkennung basiert auf der Analyse der ersten 64 bytes (oder so) des empfangenen Files.

Hier die Reihenfolge:

Code Auswählen Erweitern


  return "JPEG" if /^\xFF\xD8/;
  return "PNG"  if /^\x89PNG\x0d\x0a\x1a\x0a/;
  return "GIF"  if /^GIF8[79]a/;
  return "TIFF" if /^MM\x00\x2a/;
  return "TIFF" if /^II\x2a\x00/;
  return "BMP"  if /^BM/;
  return "ICO"  if /^\000\000\001\000/;
  return "PPM"  if /^P[1-6]/;
  return "XPM"  if /(^\/\* XPM \*\/)|(static\s+char\s+\*\w+\[\]\s*=\s*{\s*"\d+)/;
  return "XBM"  if /^(?:\/\*.*\*\/\n)?#define\s/;
  return "SVG"  if /^(<\?xml|[\012\015\t ]*<svg\b)/;
  return "unknown";


Du siehst also, als erstes wird durchaus nach JPG und PNG gecheckt, SVG is wirklich das letzte, auf das geprüft wird.
Und: es ist nur dann SVG, wenn das File mit etwas XML-artigem beginnt. Ansonsten würde "unknown" geliefert werden.

Hast du in das SVG schon mal mit einem Editor reingeschaut?
Kanns sein, dass das eben kein Bild ist, das geliefert wird, sondern eine Fehlermeldung, in Form eines SVG? (vielleicht wegen zu hoher Last auf Seiten der Kamera?)

Wie auch immer: wenn das Modul das Problem ist, dann löse ich das natürlich gern.

schöne Grüße
Martin

[tremichl]

Hallo Martin,

danke das war ein guter Tip. Das steht im File:

Code Auswählen Erweitern

<?xml version="1.0" encoding="UTF-8"?>
<ResponseStatus version="1.0" xmlns="http://www.hikvision.com/ver10/XMLSchema">
<requestURL>/Streaming/channels/1/picture</requestURL>
<statusCode>2</statusCode>
<statusString>Device Busy</statusString>
</ResponseStatus>

Cam gibt in dem Moment wohl kein Bild her weil "Device Busy" 

Habe zwar auch schon auf der CAM Seite versucht mit verschiedenen Einstellungen H264, H265, Bildgröße und Qualität, hat aber nix gebracht. Könnte IPCAM vielleicht kurz warten bis ein jpg kommt? Oder noch einen Request senden?

LG, Michael

[delMar]

Danke für das File.
Tatsächlich ist das nur ein XML, garkein SVG.
Hier wird im Modul einfach angenommen, dass XML Files automatisch SVG Files sein müssen.
Edit: das kommt (nach etwas recherche) daher, dass es auch SVG Dokumente gibt, worin mehrere svg-Tags vorkommen können. Und diese Dokumente sind dann als XML deklariert.

Fraglich bleibt aber, wie oft denn eine Kamera ein XML oder ein SVG schicken würde, welches relevanten Inhalt hat.
Ob's nicht einfach besser wäre, XML und SVG als "unknown" zu bezeichnen?

Warten bis ein JPG kommt, kann ich nicht.
Weil das Bild immer als Antwort auf einen get image Request kommt.
Wenn die Kamera sagt, die Antwort ist abgeschlossen, dann kommt auch nix mehr, auf das man noch warten könnte.

Noch einen Request senden könnte man schon, vielleicht gibts aber auch noch einen anderen Weg.

Auf welcher Basis werden denn die Bilder aufgenommen?
Zeitlich gesteuert, oder durch einen auslösendes Ereignis? (du hast ein notify erwähnt)

schöne Grüße
Martin

[tremichl]

Martin, danke für die prompte Antwort.

Was ich beobachtet habe geht es rund 5-10x gut, dann kommt einmal ein svg (busy) File. Bei einem "Doppelklick" kommt immer erst ein svg File und meistens danach das Bild.

Sonst mach ich das so, wie es wahrscheinlich häufig gebraucht wird. Klingeltaster macht über ein notify ein Bild welches dann per E-Mail verschickt wird. Zusätzlich gibt es ein Popup im FTUI. Ähnlich mache ich das bei einem Alarm. Wenn nun gar kein neues Bild gespeichert wird sondern nur ein svg bzw xml File, wird das vorhandene (alte) Bild verschickt. Das irritiert natürlich.

In diesem Fall wäre es elegant, wenn das Modul erkennt das die CAM "busy" war (eventuell xml lesen und dann löschen) und etwas später noch einen Request sendet bis ein neues Bild da ist. Es ist mir schon klar, dass man aufpassen muss dass keine endlos Schleife entsteht. Offensichtlich gibt es mehrere CAMs die sich so verhalten wie die Hikvision, vielleicht sind es auch deren OEM Produkte. Bekomme die nächsten Tage noch eine Dahua Cam, werde testen wie sich die verhält. Beim Dahua NVR ist es so, dass manchmal gar kein Bild kommt und sonst auch nix, da ist dann ein xml File mit Info noch hilfreicher....

Auf der CAM Seite habe ich nichts gefunden was sie "responsiver" macht. Würde sonst halt die Hardware tauschen, ist aber auch nicht optimal da die CAMs ja eigentlich sehr gut sind. Und für andere User wäre das Problem damit nicht gelöst ist. Vielleicht fällt dir noch was dazu ein?

Jedenfalls danke für deine Arbeit!

LG, Michael

PS: Hier habe ich eine Doku gefunden welche die xml Ausgabe beschreibt u.A. auch die ResponseStatus Page
https://ipvm-uploads.s3.amazonaws.com/uploads/5f72/4020/324284210-HIKCGI-Integration-Guide.pdf

[delMar]

Danke für die Erläuterungen.

Mein Vorschlag: ich gebe zwei Attribute dazu.

1. retryOnUnknownFormatAfter Wenn das Datei Format unknown ist, wird nach den hier angegebenen Sekunden ein re-try gemacht.
2. handleXmlSvgAsUnknown Wenn als Format SVG oder XML identifiziert wird (was mMn nach keine gültigen Images einer Webcam sind), werden diese nicht als SVG, sondern als 'unknown' gemeldet. Was dann in deinem Fall den Mechanismus aus (1) aktivieren würde.

Deal?

schöne Grüße
Martin

[tremichl]

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