Modul IPCAM überarbeitet

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

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Zitat von: delMar am 13 Mai 2021, 10:42:16
Wenn ich wieder mal mit der Bürste über den Code gehe, werd ich das verbessern.

Hallo Martin,

wenn du mal drüber schrubst, vielleicht packst du auch die Bürste aus:

Zitat von: https://forum.fhem.de/index.php/topic,10772.msg1147375.html#msg1147375
Es stehen user/pw sowohl im pan/tilt Kommando als auch in pathPanTilt.
Daher wird nun user/pw doppelt im Befehl mitgegeben.
Kein Problem es tut aber schön ist es nicht.

Wenn ich user/pw bei den pan/tilt Kommandos lösche (siehe auch list meines aktuellen, schon etwas "geschraubten" Devices), dann wird es nur einmal gesendet und die pan/tilt Kommandos sind auch "übersichtlicher" :)

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):
Zitat

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


Hier ein pan/tilt Kommando:
Zitat

    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...

Oder hast du da schon was gemacht und ich hab's überlesen?
(oder du einfach gemacht und nichts dazu geschrieben)

Wenn du was hast, dann packe ich wieder aus und teste mal wieder :)

Aber die Kamera hat (immer noch) geringe Prio...
...ist ja mehr "Spielerei"... ;)

DANKE, 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

Hallo

Zitat von: misux am 13 Mai 2021, 08:56:02
die _1 Datei benötige ich allerdings nicht mehr... kann man das irgendwie deaktivieren das diese nicht geschrieben wird?

mit dem morgigen Update kann man das Attribut snapshots auf 0 setzen.
Dann wird das Bild nur noch einmal geschrieben. Auch zB das Reading snapshot1 wird dann natürlich nicht mehr gesetzt werden.

Ist das Attribut snapshots nicht gesetzt, wird aus Rücksicht auf das bisherige Verhalten der Wert 1 angenommen, was weiterhin dazu führt, dass per Default das Bild zweimal geschrieben wird. Einmal mit dem Namen der im Reading last definiert ist, und einmal mit dem Namen aus snapshots1.

Bitte bei Problemen hier Bescheid geben. Ich hab zwar alle mir bekannten Anwendungsfälle durchgetestet, trotzdem kann mal was übersehen werden.


Das Thema mit user/pwd optimieren hab ich noch nicht begonnen, steht aber auch auf meiner Liste.
Könnte aber noch etwas dauern, da ich hier gewisste Code-Konstrukte neu durchdenken muss, inklusive der Möglichkeit, das bisherige Verhalten ohne Konfigurtionsänderung weiter zu erlauben.
Je nach Wetter könnte mich die Motivation aber auch früher packen - wie ich schon öfter feststellen durfte ;)


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

Zitat von: delMar am 15 Mai 2021, 12:28:21
Das Thema mit user/pwd optimieren hab ich noch nicht begonnen, steht aber auch auf meiner Liste.
Könnte aber noch etwas dauern, da ich hier gewisste Code-Konstrukte neu durchdenken muss, inklusive der Möglichkeit, das bisherige Verhalten ohne Konfigurtionsänderung weiter zu erlauben.
Je nach Wetter könnte mich die Motivation aber auch früher packen - wie ich schon öfter feststellen durfte ;)

Hallo Martin,

fühle mich ja irgendwie "angesprochen" ;)

Daher, wie bereits geschrieben: keine Eile.

Wollte nur "sagen", dass ich halt (erst wieder auspacke und) teste, wenn es was gibt...

Einfach melden, ich packe dann mal wieder aus und teste... :)

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

Zitat von: delMar am 15 Mai 2021, 12:28:21
Hallo

mit dem morgigen Update kann man das Attribut snapshots auf 0 setzen.
Dann wird das Bild nur noch einmal geschrieben. Auch zB das Reading snapshot1 wird dann natürlich nicht mehr gesetzt werden.

Ist das Attribut snapshots nicht gesetzt, wird aus Rücksicht auf das bisherige Verhalten der Wert 1 angenommen, was weiterhin dazu führt, dass per Default das Bild zweimal geschrieben wird. Einmal mit dem Namen der im Reading last definiert ist, und einmal mit dem Namen aus snapshots1.

Bitte bei Problemen hier Bescheid geben. Ich hab zwar alle mir bekannten Anwendungsfälle durchgetestet, trotzdem kann mal was übersehen werden.


schöne Grüße
Martin

Hervorragend! Funktioniert supi! Vielen Dank!

misux

Hallo nochmal..

Eine Frage weil mir das so nie aufgefallen ist...

Wo ist der Unterschied zwischen get und execute? Müssen beide passieren?


2021.05.27 13:12:15 3: IPCAM (CAMEingang) - getSnapshot URI: http://pi:Uxxxxxxx@192.168.2.102/cgi-bin/snapshot.cgi?chn=[1]
2021.05.27 13:12:15 3: IPCAM (CAMEingang) - ExecuteSnapshotRequest camUrl: http://pi:xxxxxxx@192.168.2.102/cgi-bin/snapshot.cgi?chn=[1]

delMar

Zitat von: misux am 28 Mai 2021, 07:51:23
Wo ist der Unterschied zwischen get und execute? Müssen beide passieren?


2021.05.27 13:12:15 3: IPCAM (CAMEingang) - getSnapshot URI: http://pi:Uxxxxxxx@192.168.2.102/cgi-bin/snapshot.cgi?chn=[1]
2021.05.27 13:12:15 3: IPCAM (CAMEingang) - ExecuteSnapshotRequest camUrl: http://pi:xxxxxxx@192.168.2.102/cgi-bin/snapshot.cgi?chn=[1]


hier wird eigentlich nur an zwei verschiedenen Stellen die URL gelogged.
der erste Log-Eintrag direkt beim Erstellen der URI (wo zb einfügen von user/pwd gemacht wird und über dieses statement verifiziert werden kann)
der zweite Eintrag beim Absenden des Requests.
also ja: eigentlich müssen beide passieren.

Für den alltäglichen Betrieb benötigt man eigentlich keines der beiden. In dem Fall würde ich empfehlen, verbose auf 0 zu stellen. Fehlermeldungen und Probleme werden nämlich auch da ausgegeben.

Ich hoffe, das beantwortet deine Frage

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


Dreggwatz

Erstmal vielen dank für das Modul, lief bislang einwandfrei bei mir. Irgendwie hab ich unbewusst etwas zerschossen und finde den Fehler nicht.
Der Befehl get image funktioniert nicht mehr und im Log kommt diese Fehlermeldung (auth und IP unkenntlich, passt aber).
Wenn ich den Pfad im Browser eingebe bekomme ich das Kamerabild. Kann mir jemand sagen was ich in Fhem zerbröselt habe? Kameras sind Hikvision, wie gesagt lief bislang seit gut 1,5 Jahren onewallfree  ;)
Danke

IPCAM (Cam.Treppe) - getSnapshot URI: http://xxx:xxx@IP:80/Streaming/channels/1/picture?snapShotImageType=JPEG
2021.06.01 22:11:33.471 1: ERROR: Another HttpUtils_NonblockingGet with the same hash is in progress
2021.06.01 22:11:33.471 1: stacktrace:
2021.06.01 22:11:33.471 1:     main::HttpUtils_NonblockingGet      called by FHEM/HttpUtils.pm (865)
2021.06.01 22:11:33.471 1:     main::HttpUtils_ParseAnswer         called by FHEM/HttpUtils.pm (642)
2021.06.01 22:11:33.472 1:     main::__ANON__                      called by fhem.pl (770)
2021.06.01 22:11:33.472 0: IPCAM (Cam.Treppe) - error while getting snapshot http://xxx:xxx@IP:80/Streaming/channels/1/picture?snapShotImageType=JPEG - Another HttpUtils_NonblockingGet with the same hash is in progress

MadMax-FHEM

Schon mal mit dem Fehler im Forum gesucht? ;)

https://forum.fhem.de/index.php/topic,120244.msg1147323.html#msg1147323

Ob es da eine Lösung gibt habe ich jetzt nicht (zu Ende) verfolgt...
...aber zumindest klingt es nach demselben Problem...

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)

Dreggwatz

#369
Hi Joachim,
danke für den Hinweis, scheinbar kommt die Fehlermeldung bei einigen Modulen. Weiss auch nicht ob dies mit dem nicht anlegen des Image überhaupt etwas zu tun hat. Bin halt in der Log drüber gestolpert...
Muss ich mal weiter so stöbern, denn löschen und neu Anlegen der IPCAM Devs hat auch nicht zum Erfolg geführt.

Edit: geht wieder, Fehler auch weg - keine Ahnung was da los war...

delMar

Danke, Dreggwatz, dass du das Problem hier dokumentiert hast.
Ein weiterer Punkt, das vorherige, blocking Verhalten per Attribut weiter zu erlauben.

Ich werd mir das auf die Todo-Liste schreiben.

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

HI!

Ist es irgendwie möglich es so einzustellen sodass das gemachte snapshot eine kleinere auflösung hat als das von der Camera?
Mein und von meinem Kumpel das Problem ist das die original snapshots ca 500-700Kb groß sind. wir lassen uns oft die bilder per Telegram senden direkt nach dem schnappschuss und das klappt irgendwie nicht immer weil vermutlich der schreibvorgang zu lange dauert oder keine Ahnung... Dann bekommen wir immer ein altes Bild wenn an der Tür klingelt...

Wenn die Datei kleineer wäre, so um die 50-100Kb oder eine Auflösung von 1024x768 wäre das vielleicht etwas problemloser...

einen Logeintrag kann ich jedenfalls sehen wenn das Bild nicht geschrieben werden kann...
2021.08.29 19:54:15 0: IPCAM (CAMHof) - error while getting snapshot http://pi:InsAHhnsu@192.168.1.201/cgi-bin/snapshot.cgi? - read from http://192.168.1.201:80 timed out

delMar

Hi misux,

erste Frage: mit welchem Befehl sendet ihr denn die Bilder?
Mit get imageWithCallback sollte eigentlich sichergestellt sein, dass keine alten Bilder verschickt werden.

Außer natürlich, die Kamera liefert ein Timeout.
Wenn das allerdings der Fall ist, dann wird das nachträgliche verkleinern des Bildes auch keinen Unterschied machen (weil ja von der Kamera garkeins gekommen ist).

Ich bin nicht sicher, ob hier nicht zwei unterschiedliche Probleme angesprochen werden.

Kamera-Timeouts wurden jedenfalls früher schon mal besprochen:
https://forum.fhem.de/index.php/topic,10772.msg1149708.html#msg1149708
aber keine wirkliche Lösung gefunden.

zweite Frage: welche Kamera hast du denn?


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.

rob

Zitat von: misux am 29 August 2021, 20:35:21
... Dann bekommen wir immer ein altes Bild wenn an der Tür klingelt...
Hallo.

Das Problem hatte ich anfangs auch so ähnlich: es kam immer ein altes Bild, weil Cam+Modul schneller liefern konnten, als vom System weggeschrieben wurde. Bei mir hatte es genügt, das Delay im CAM-Device zu setzen:
attr MyCAM delay 2
Vielleicht einen Versuch wert damit zu experimentieren :)
Sollte z.B. ein recht langes Delay keinen Erfolg bringen, müsste das Problem imho woanders zu suchen sein, als in der Schreibgeschwindigkeit.

Viele Grüße
rob

misux

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...