Ich nutze seit einiger Zeit das Modul IPCAM etwas intensiver. Dabei geht es hauptsächlich um den Schutz unserer Schildkrötenzucht. Dazu lasse ich mir, je nach Begebenheit bei Bewegung oder Öffnung der Gehegetür Bilder von verschiedenen IP-Cams (Vivotek) zusenden.
Leider ist es so, dass das Holen der Bilder per get IPCAM image FHEM immer für eine Weile blockiert (bis zu 5-6 Sekunden, je nach Geschwindigkeit der Kamera bzw. Auflösung der Fotos, Qualität etc.), was vor allem im Zusammenhang mit anderen Funktionen einer Alarmanlage Probleme macht. TTS Texte werden z.B. einfach verschluckt, Auslösungen verzögert etc.
Deshalb meine Frage: Ist es möglich, das Modul IPCAM Non-Blocking zu gestalten, wie es schon bei vielen Modulen in FHEM der Fall ist?
Laut maintainer.txt ist das hier für IPCAM der richtige Forenbereich. Ein einfaches Nein, falls es nicht geht (unwahrscheinlich) oder die Zeit nicht vorhanden ist, wäre nicht wirklich schön, weil es das Modul für gewisse Anwendungen quasi unbrauchbar macht, aber verständlich und völlig ausreichend. Dann würde ich eventuell selbst mal rein schauen, sobald es meine Zeit erlaubt.
martin war am 01 Juli 2015, 01:23:08 das letzte mal online, hat deine nachricht also wahrscheinlich noch nicht gelesen. schreib ihn doch mal per pm an. ansonsten ist gerade ja auch urlaubszeit ;-)
Hallo ich wollte mich mal erkundigen ob es hierzu Neuigkeiten gibt?
Dieses Problem ist wirklich sehr lästig, ich habe mich in einem anderen Thread schon an einer möglichen Problemlösung versucht aber leider ohne Erfolg.
Interessant, also bin ich leider nicht der einzige mit diesem Problem, ich bastle mir gerade eine Überwachung für die Eingangstür wenn jemand die Glocke betätigt.
Jetzt wundere ich mich nur, weshalb ich beim betätigen des Tasters (Logo, Taster wird über FHEM/Notify ausgewertet) mit Mails zugeflutet werde.
FHEM hängt scheinbar nach betätigen des Tasters, da er die Bilder von der Webcam holt und verlängert somit Automatisch die Zeit.
Sg
Hallo zusammen, gibt es zu diesem Thema Neuigkeiten? Ich habe ebenfalls das Problem, dass das Modul IPCAM regelmäßig fhem blockt. Das ist auch gu im apptime sichtbar.
name function max count total average maxDly
tmr-IPCAM_getSnapshot HASH(0x2a7ab07) 4011 132 62307 472.02 985 HASH(Cam)
Hallo zusammen,
ich hatte in der Vergangenheit bereits ebenfalls an dieser Frage gegrübelt. Das Problem dabei ist jedoch, wie man IPCAM konkret einsetzt.
Anwendungsfall: Bei Aktion, Bild erstellen und verschicken
Typisches Beispiel: Ein Bewegungsmelder/Schalter löst aus und IPCAM soll anschließend ein Snapshot erstellen, der dann an jemanden per Nachricht/Email/Whatsapp/Push/... verschickt werden soll.
In dem Fall wird das ganze üblicherweise über eine FHEM-Befehlskette im Notify gelöst:
set IPCAM pos 2 ; get IPCAM snapshot ; <...Bild versenden...>
Hierbei ist es notwendig, dass IPCAM Blocking arbeitet. Denn erst, wenn das Bild erfolgreich abgerufen und geschrieben wurde, kann das Bild versandt werden. Alternativ kann man das nur lösen mit einem Sleep der bspw. 5 Sekunden wartet bevor das Bild versandt wird, sofern IPCAM Non-Blocking arbeitet:
set IPCAM pos 2 ; get IPCAM snapshot ; sleep 5 ; <...Bild versenden...>
Anwendungsfall: zyklisches Bild erstellen zur Anzeige auf FHEM-Webseite/Dashboard/Tablet-UI
Sofern man nur via at zyklisch ein "get IPCAM snapshot" aufruft um immer ein aktuelles Bild im Frontend zu haben, würde eine Non-Blocking Implementierung hier keine Probleme bereiten.
Gruß
Markus
Ich denke, wenn man weiß, dass es Non-Blocking arbeitet und dann ein sleep einbaut, ist das kein Problem (Doku ist hier alles). Natürlich muss das sleep dann lang genug sein. Man kann das Versenden jedoch auch Abhängig vom erstellen des Bildes machen. Es gibt viele Möglichkeiten. Blocking ist dabei die schlechteste.
Ich habe mir selbst eine eine sub gebaut, die das Non-Blocking holen der Bilder erledigt. Dafür benötige ich IPCAM gar nicht mehr. Aus der sub heraus schreibe ich auch die entsprechenden Readings. Im Thread zu IPCAM habe ich die sub auch schon einmal gepostet.
ZitatAlternativ kann man das nur lösen mit einem Sleep der bspw. 5 Sekunden wartet bevor das Bild versandt wird, sofern IPCAM Non-Blocking arbeitet:
Mein Vorschlag: nach der Fertigstellung von dem nicht-blockierenden "get IPCAM snapshot" generiert das Modul ein Event.
Das tut es ja. Und das meinte ich auch mit "Man kann das Versenden jedoch auch Abhängig vom erstellen des Bildes machen."
Dann müsste man mit mehreren IPCAM Instanzen arbeiten, wenn man beide von mir beschriebene Anwendungsfälle abdecken will. Eine, die nur beim Auslösen eines Ereignisses ein "get <name> snapshot" macht und falls jemand immer ein aktuelles Bild auf dem Tablet sehen will, eine zweite die zyklisch mit at befeuert wird. Dann könnte man das machen.
Ich könnte es auf Non-Blocking umbauen, bin aber zeitlich gerade gut ausgelastet mit anderen Themen :)
Gruß
markus
Hallo zusammen,
gibt es hier schon etwas neues zu berichten?
Seit kurzem setze ich perfmon ein und bin bei der Auswertung auch auf ipcam als Verzögerer aufmerksam geworden. Ich sehe mich nicht im Stande die Umstellung auf Non-Blocking durchzuführen, könnte aber als Tester zur Verfügung stehen.
Wenn es Dir jetzt besser passt Markus!?
Gruß Marcel
Melde auch mal Interesse an, da ich auch des Öfteren Probleme habe, dass mein Fhem Verbindungen zu irgendwelchen Geräten verliert weil die CAM nicht schnell genug das Bild geliefert hat...
Hallo zusammen,
leider steht mir die Kamera, mit der ich seinerzeit IPCAM nutzte nicht mehr zur Verfügung. Daher habe ich IPCAM nicht mehr im Einsatz und auch keine Möglichkeit eine entsprechende Implementierung zu testen.
Gruß
Markus
Ok dann versuche ich mich die Tage mal selbst dran.
Hab das gestern wohl auf die Schnelle per Shellscript Aufruf (wget) als nicht-blockierende Lösung hinbekommen,
aber das wäre ja eine ganz gute Fingerübung um wieder ein wenig mehr in PERL und den FHEM Modulaufbau reinzukommen.
HttpUtils_NonBlockingGet ist ja gut dokumentiert, wird man also schon hinbekommen...
Stelle das Ergebnis dann mal hier rein, evtl. kann jemand mit mehr FHEM Developer-Hintergrund dann mal drüberschauen ob man das so übernehmen kann.
Mein Kameramudul für die Synology SSCam habe ich seinerzeit komplett nonblocking mit HttpUtils zusammengebaut. Möglicherweise kannst du dir da ein paar Anregungen holen.
LG
Heiko
Ok, so schwer war es gar nicht. :)
Habe die IPCAM_getSnapshot Funktion zweigeteilt in IPCAM_getSnapshot und IPCAM_saveSnapshot.
In IPCAM_getSnapshot wird der Request erstellt und je nach gesetztem async Attribut dann blockierend oder nicht-blockierend abgefeuert.
Das Ergebnis wird dann entweder sofort oder im Callback an IPCAM_saveSnapshot weitergereicht.
Hier geht es dann an sich unverändert weiter wie bisher.
Neu hinzugekommen sind an sich nur die Attribute async und asyncTimeout.
async ist per Default auf 0, damit bleibt das Modul kompatibel zur bisherigen Version und verändert nicht das Verhalten von bestehenden Notifies etc. bei existierenden Nutzern.
Commandref Einträge dafür habe ich auch hinzugefügt.
Hat evtl. jemand mit mehr Perl/FHEM Kentnissen die Muse meine Schandtaten in einem Diff-Viewer im Vergleich zur aktuellen Version anschauen? :)
Hallo zusammen,
ich wollte das Thema nochmal aufwärmen und anfragen ob es absehbar ist, dass der patch ins Modul übernommen wird?
LG
Hallo,
hätte auch interesse dran, hab auch öfters Probleme mit IPCAM :-(