hi mamba,
was soll ich sagen - die macken werden weniger - ich brauch wohl noch ein icmp von dir

/var > ./dream_motion
[: unknown operand
[: 0: unknown operand

dream-motion script v0.5 by mamba0815@gmx.li, public domain

ip-cam IP address: 192.168.1.251
ip-cam user-ID: root
ip-cam password: admin
tv output: on
logging: on
motion alarms saved: ./log/jpg/dream_motion_alarmX.jpg
------------------------------------------------------------
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
* icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
* icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
* icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
* icmp_current: [: -lt: argument expected
bin/icmp: unexpected EOF while reading image file '/tmp/dream_still.bmp'
bin/icmp: use -h option for help
[: .: unknown operand
icmp_current: [: -lt: argument expected

/var >

hi mamba, sieht nicht so aus:
/var/webcam > ./webcam_1 http://192.168.1.251:2000 0 1 60 10 1
./webcam_1: error while loading shared libraries: libcurl.so.2: cannot open shar
ed object file: No such file or directory
/var/webcam > ls
libcurl.so.2 libjpeg.so.62.0.0 webcam_1 webcam_2
/var/webcam >

ich bin mir aber nicht so sicher mit den Variablen, mit denen ich das script starten muss: Das erste ist die Quelle - ist klar, das zweite steht für Bild in Originalgröße oder nicht - ist auch klar, das dritte ist Farbe oder nicht - auch klar, das vierte (<threshold>) weiß ich nicht recht, ist das der Auslösewert?, das fünfte (<delay>) ist die Darstellungsdauer - denke ich und das sechste ist der Debugmodus - ist auch klar.
Sag mal was, obs so stimmt - unabhängig davon, daß es erstmal nicht geht...

kamikazemike
Ey Klasse - das head läuft - prima Arbeit
2 Sachen:
1. bekommste das für tail und für echo (wird lt. mamba gebraucht) auch hin?
2. wie kann ich erreichen, daß ich irgendwo nur head eingebe und er die neue Version nimmt und nicht die alte. Derzeit gehts nur, wenn ich explizit z.B. var/bin/head -c eingebe. Selbst im var/bin-Ordner muss ich ./head eingeben - wenn ich nur head mache, nimmt er selbst dort das alte - gibts da ein paar variablen, die ich z.B. in der init setzen kann?

stimmt, aber es gibt danach trotzdem jedes mal noch die Fehlermeldung aus - schau mal im anderen Board...

Gibts jemanden, der die gesamte Busybox neu Kompilieren kann auf Basis GLIBC 2.3.4? Ich hab genug Platz in meinem Var - der liegt aufm USB - das reicht Dicke fürn paar Versuche - da werden wohl etliche Dateien notwendig sein...

Das head alleine reicht leider nicht aus, die 7000er nimmt es nicht, selbst wenn man es ihr direkt ins verzeichnis legt, von der aus ein anderes script ausgeführt wird. und beim expliziten Ansprechen meckert es trotzdem noch rum (hatte hier head mal direkt in var gelegt - gleicher fehler aber auch in var/bin):

/var > head -c
head: invalid option -- c
BusyBox v1.01 (2006.08.19-02:16+0000) multi-call binary

Usage: head [OPTION]... [FILE]...

/var > ./head -c
./head: option requires an argument -- c
Try `./head --help' for more information.
./head: relocation error: ./head: symbol __fpending, version GLIBC_2.2 not defin
ed in file libc.so.6 with link time reference
/var >

Die 7000er spricht immer von einer GLIB_2.2, während die 7020er die GLIB_2.3.4 verwendet.
Ich denke, hier muss direkt die andere Busybox ins var/bin mit allem was dazugehört... zse, zse, zse...

mamba, schließ mich deiner Meinung an, vielleicht kann man das eine oder andere noch beschleunigen...
(sofern es denne mal auf ne 7000er zum laufen kommt )

Hallo,

wie kann man es ermöglichen, den busybox-Befehl head mit der Option -c auf der DM7000 lauffähig zu machen?
Auf der DM7020 - auch mit neuestem Enigma1 geht das.

mamba, die Frage kann ich dir recht einfach beantworten - die Cam generiert das Bild 30x pro sekunde. Die wget-Funktion ist einfach zu langsam im Herunterladen des einen Bildes, bevor die Cam das nächste erzeugt. Da ist ein gewisser Schreib-Lese-Zugriff in der Cam, der da nicht richtig geht - ist schlecht - ist aber so - müssen wir mit leben - kann bei anderen Cams auch so sein.
Daher meine Idee der mehrfachen Prüfung in der von mir vorgeschlagenen Variante. Erst wenn "schnelle" Prüfzyklen in der Anzahl X hintereinander eine "erfolgreiche" Veränderung erzielen, wird die Darstellung ausgelöst. Die Anzahl der Prüfungen wäre als Variable in der Config eventuell gut aufgehoben - je nach dem, was man für eine Cam hat (Besser/Schlechter), kann man dann den Wert für sich selbst anpassen. Ist halt ein Parameter, der die "Bilddarstellungsauslösungs-geschwindigkeit" zu Gunsten einer Anzeigegenauigkeit verändern kann. Dies würde im Übrigen auch das Problem (weiter oben beschrieben) abdecken, daß wenn sich das Kind nur mal dreht (oder beim Türwächter ein Schmetterling vorbeifliegt), nicht gleich die Bilddarstellung ausgelöst wird.
Daher Standart 3-5 sek., dann Überprüfung alle 1/2 sek (oder so schnell, wies geht), dann Darstellung. Sollte bei der Schnellen Überprüfung nur 1 Vergleich keine Bewegung ergeben, wird sofort wieder in die Standart 3-5 sek. umgeschalten...

Übrigens, weist du schon, daß es auf der Grandtec-Website die Firmware 1.7 für die Cam gibt - nur so als Tip - hat nichts mit dem Thema hier zu tun - ich weiß auch nicht was daran anders/besser ist...

mamba, dies hatte ich dir doch auch schon eher geschrieben (Beitrag vom 15.09.06 - 11.14), das steht in dem KB-Artikel von MS drin, das dieser REG-Eintrag die Lösung ist.
LazyT, wenn du die Idee von mamba aufgreifen willst, auf der Seite http://www.thomvo.de/ gibt es etliche Livestreams, da kannste bestimmt einen davon zum Testen gebrauchen - die stehen dort auf der Seite unter Livestream - z.B. die weiße Kamera mit dem blauen Wellensittich ist lustig...

Das Problem der fehlerhaften Bewegungserkennung kann doch recht einfach geklärt werden (aus Anwendersicht):
Beim normalen Erkennen wird ein Bild ca. alle 3-5 sek. gescannt. Bei Bewegungserkennung werden die nachfolgenden Bilder alle 1 sek.gescannt. Wenn dort auch Bewegungen sind, dann erst wird die Anzeige ausgelöst...

Wenn ihr das Bild schonmal runterrechnet (zum Vergleichen), fände ich es extrem sinnvoll, es als PiP aufm Fernseher auszuwerfen (nat. nur bei Bewegung). Wenn dies schneller geht, läuft dann das Bild flüssiger - auch während des weiteren Vergleiches im Hintergrund. Wenn ich das Bild dann per Tastendruck aufs Vollbild hole, braucht man für die Zeit des Vollbilds auch keinen Vergleich mehr im Hintergrund machen - solange Vollbild - solange fortlaufende Darstellung. Wenn dann per Tastendruck das Bild weggemacht oder andere Taste das Bild wieder auf PiP-Größe reduziert wird, dann findet auch wieder der Vergleichsmechanismus Anwendung. Das würde doch die Performance einer flüssigen Darstellung extrem verbessern.

1. lt. Mamba wirds im kleinen Bild auch mit Bildanalyse schneller

2. Im großen Bild wirds ohne Bildanalyse schneller - ich will ja bei Volldarstellung eh sehen, was los ist - mich auch mal so an meiner Kleinen erfreuen etc. - Da brauch ich auch keine Analyse - das Bild soll im Vollbild gar nicht weggehen.

LazyT Für die Darstellung 1 könntest du doch deine PiP-Routinen schon so ähnlich verwenden - so mit Größe - Darstellungsort etc. - Man bräuchte doch das Rad nicht neu erfinden - die Teile, die man so bräuchte sind doch alle schon perfekt gelöst, nat. nur, wenn du nichts dagegen hättest. Die Bildgrößen, die du dort so nimmst, können doch auch gleich für die Bildanalyse hergenommen werden - auch wenn das Bild gerade angezeigt wird... was meinst du?

Zitat

Original von mamba0815
Ich bin schon weiter am Optimieren, d.h. ich wäre über Ideen/Anregungen zur Verbesserung sehr interessiert.

Hi Mamba, ich hab doch schon einiges in meinen Beiträgen in dem Tread geschrieben - mehr fällt mir dazu auch erstmal nicht ein - bis dahin ists eh noch ein ganzes Stück Arbeit.

Wenn LazyT in seinem Script das wget gleich einbaut, dann ist es wohl auch einfacher dein motion auch gleich mit einzubauen, denn motion steht ja zwischen wget und Ausgabe auf Fernseher...

Wenn das Laden der Bilder und Vergleichen der Veränderungen klappt, wäre der nächste Schritt das PiP mit Option per Taste zum Großbild.
Mamba, vielleicht kannste jetzt schon eine Taste belegen, beim Drücken wird das Bild auch sofort schon angezeigt ( LazyT - später als Film - aber soweit sind wir ja noch nicht )

Eins fällt mir doch noch ein - versuch mal dein Script dahinein zu optimieren, daß er erst bei sagen wir mal 3-5 sekunden hintereinander Veränderungen das Bild bringt - damit unterdrücken wir z.B. ein einfaches Drehen des Kindes o.ä.

mamba,

coole Sache, das imgcmp. Aber sag mal ich hab mir mal das pdf von der Homepage angeschaut, das Tool müsste doch die jpgs direkt miteinander vergleichen können, warum wandelst du sie erst ins *.pnm-Format? Ich weiß, das Beispiel dort ist mit dem Format aufgeführt, aber haste es mal mit jpg direkt probiert? Spart Rechenleistung...
Noch ein Vorschlag: Lad nur am Anfang und dann eventuell alle 30 sek. ein einziges Bild von der Cam in den tmp-Speicher der Dream und nimm immer dieses Bild zum Vergleich mit all den folgenden Bildern. Vielleicht verträgt das imgcmp sogar direkt den http://root:admin@192.168.xxx.xxx/still.jpg-Link als zu vergleichendes Bild ( mit oder ohne wget - ich glaubs zwar nicht, aber Versuch macht klug)
Anders herum muss man aber auch sagen, daß ein Vergleich wie in deinem Falle alle 2 oder bis 5 sek. eh die Rechenleistung nicht so übermäßig belasten wird. Ist ein echt Klasse Ansatz zum Erkennen von Bewegungen auf dem Bild. Anhand des Zahlenwertes (Sollte wohl zum Schluss ein Eintrag in einer Config sein) wird man dann wohl das Bild auf den Fernseher bringen können - prima Idee...

LazyT sag mal haste eine Idee, wie man ein jpeg durch Dauernachladen als einigermaßen Flimmerfreien Film auf den Monitor bekommt?

Das Bild stammt übrigens von meiner Cam, die ist im Baldarin des Babybettes mit Blick nach unten befestigt. Dieses Bild ist ein Infrarot-Bild, welches genau so auch im Tuxwetter als Vollbild auf den Fernseher kommt. Für die Babycam-Anwendung dürfte daher auch eine Schwarz-Weiß-Ausgabe (Falls es Probleme der Rechenleistung geben sollte) zugunsten einer flüssigen Wiedergabe als Film ausreichend sein.
Für einen eventuellen Einsatz als Türwächter wäre wohl eher eine Farbausgabe zu bevorzugen - da auch Tagaufnahmen stattfinden, aber ich glaub da sind wir lange noch nicht...

.

LazyT
die Cam ist dumm, man stellt einfach die Parameter ein und los gehts. Ich zeigt dir ein Beispiel im Anhang.
Problem ist auch, man könnte der Cam sagen, daß sie das Bild auf einen FTP-Server läd - da kommen aber dann tonnenweise Bilder an, die z.B. heißen bild120612311.jpg usw. Da wird jedesmal Zeit/Datum mit eingebaut, sprich man weiß nicht welches das aktuelle ist & der Ordner wird zugemüllt. Daher ist der Zugriff auf die Cam zu dem Bild still.jpg die beste Variante. Ich glaube du hattest mal irgendwo (oder wars ein anderer?) was von MD5-Hash-Vergleich geschrieben. Dies wird daher auch nicht klappen, da das Bild mit kleinen (feinen) Streifen versehen ist, welche sich ständig ändern. Man sieht diese zwar nicht unbedingt im Gesamteindruck, aber der MD5-Wert ist immer wieder ein anderer. Daher meine Idee des Bildausschnitts zu vergleichen im Abstand von x Sekunden. Sprich alle x Sekunden wird ein Bild gezogen, (der Bildausschnitt) mit dem vorherigen verglichen (dabei eine %-Abweichung zugrunde legen - wegen der kleinen Streifen) und bei Abweichung dann ein ständiges Bilder laden und auf den Fernseher als PiP schicken fortwährend, solange sich der Bildauschnitt ändert und danach + x-Sekunden. Im Falle der Anzeige wird dann die Taste x bei Bedarf gedrückt, um die fortlaufenden Bilder im Großbild zu sehen oder die Taste y für die PiP-Darstellung. Mit der Taste z kann auch zwischendurch mal das Bild, wie als wäre eine Bewegung drin, auf den Fernseher gezogen werden.

LazyT

prima, daß jetzt langsam Schwung in die Sache kommt.

Sag mal, um den "umständlichen" Weg des Zwischenkopierens zu umgehen, würde dein Script auch mit

webcam http://user:password@<ip-der-cam>/still.jpg 0 1 5

umsetzbar sein? Könnte mir vorstellen, daß dies einen Zwischenschritt erspart und die eh schon begrenzten Dream-Resourcen etwas entlastet.

Das Bild wird im übrigen bis 30 mal/Sekunde auf der Webcam aktualisiert, wenn man das Java-Script aufm PC aufruft, bekommt man einen richtig schönen flüssigen Film. Sieht absolut Klasse aus, die Kleine mit Infrarot zu sehen, wenn sie sich wurschtelt, dreht usw. (Hat schon fast eine Spur Vojeurismus an sich, aber bei einem reichlich 3 Monate Baby ist das bestimmt noch ok )
Später hat mal einer geschrieben, braucht man dann eh WLAN-Roaming und GPS-Tracking, da ists mit der Webcam vorbei
Die Ausgabe aufm Fernseher könnte auch so ablaufen...

mamba,

hab das Problem mit der benutzer-password-Anzeige gefunden - falls es dich interessiert http://support.microsoft.com/?kbid=834489

LazyT,

ich glaub, so langsam kommt Schwung in die Sache...
Meine Kleine ist jetzt schon bei 5kg und 60cm, ich kann mamba nur recht geben...
Hast du selbst Kinder?

mamba

Komisch, beim Mozilla gehts, nur beim internet-explodierer gehts nicht...

Einen Beispiel Source hab ich leider nicht, ich kann dir aber eine andere Kleinigkeit geben, welche zwar nichts mit der Dream, aber mit der Idee zu tun hat.
Probier mal dies als html-Datei:

<script language="javascript">
newImg = new Image();
var imgsrc = "";
function StreamError()
{
newImg.onload="";
newImg.onerror="";
newImg.src="http://www.domain.de/webcam/error.jpg";
document.images.angelpage.src=newImg.src;
}
function StreamLoad()
{
uniq = new Date();
uniq = uniq.getTime();
document.images.angelpage.src=newImg.src;
newImg.src=imgsrc+"?"+uniq;
}
function StreamInit()
{
imgsrc = document.images.angelpage.src;
uniq = new Date();
uniq = uniq.getTime();
newImg.onload=StreamLoad;
newImg.onerror=StreamError;
newImg.src=imgsrc+"?"+uniq;
document.images.angelpage.onload="";
}
document.write('<img src="http://user:password@<ip-der-cam>/still.jpg" name=angelpage onload="StreamInit()"

alt=Interessantes mit JavaScript width=320 height=240>');
</script>

Musst natürlich deine Daten noch anpassen...

mamba,

ja geht mir auch so mit der Cam, besonders beim WLAN-Betrieb kann ich dir jetzt schon sagen, daß du Probleme bekommen wirst. Das Teil will einfach kein WLAN aufbauen... Abhilfe habe ich in einem Forum irgendwo gelesen, es scheint wohl am Netzteil zu liegen. Die haben einfach beim Upgrade der Webcam auf WLAN vergessen, die Leistung des Netzteils zu erhöhen, da scheint die Spannung auf ein Level zu fallen, die dann kein WLAN mehr zulässt. Brauchst dann wohl ein stärkeres Netzteil - nur schon mal zur Info...
Eins hab ich mal Probiert, wenn ich den Link http://user:password@<ip-der-cam>/still.jpg direkt mit den richtigen Werten im I-Explorer eingebe, kommt: Seite kann nicht angezeigt werden. Ist das normal? Eigentlich sollte der doch dann auch das Bild anzeigen..
mmh.. merkwürdig...

mamba0815
genau so sehe ich das auch... Hast du auch solch eine Webcam, wie unter meinem Link?
Das Bild wäre wohl im USB oder im tmp bestens aufgehoben - ich weiß nur nicht, ob der tmp-Bereich durch häufiges Beschreiben irgendwann die "Hufe hoch schraubt" - hat da einer Erkenntnisse? Da würde ich dann wohl eher vorziehen, den USB-Stick irgendwann mal abzuschießen...
Die Frage ist ja hier nach wie vor, ob man das PIP-Plugin in eine neuere Version bringen kann, mittels der dann die Babyfon-Überwachung nach Bewegungsauswertung möglich wäre...
Am besten wäre dazu, man baut den wget-Befehl direkt ins Plugin ein und prüft fortdauernd das Bild direkt auf der Cam, dann braucht man es gar nicht mehr auf die Dream zu laden...

PS: neben der Haustürfunktion würde dies sogar dann mit jeder Webcam aus dem WWW funktionieren - immer wenn sich was tut, zeigts ein Bild an..

alles klar...