Angespornt vom super Wetter (Schnee!), habe ich nun meinen zweiten Fonera 2.0g in einen drahtlosen Kameraserver verwandelt. Zwar leider nicht für ältere Webcams, aber bei den UVC-kompatiblen Kameras gibt es ja auch einige schmucke Geräte.
Diesmal habe ich mir das OpenWRT-Image selbst zusammengebaut, im Endeffekt ist es reichtlich simpel, auf dieser Basis eine wireless Webcam zusammenzubauen, die, wie man sehen kann, auch bei unter -10 Grad Celsius noch funktioniert. Eine Creative Optia AF hatte ich schon im Sommer in ein entsprechendes Gehäuse (Baumarkt-Druckguß-300W-Halogenstrahler) gepackt und auf der Terrasse moniert (parallel zu einem ungeschützt aufgehängten alten Philips-pwc-Ei), nur leider klappte es seinerzeit nie, jene Cam weder mit blanken USB-Verlängerungskabeln noch mit aktiven USB2-Verlängerungskabeln noch mit letzteren plus eines außen dazwischengeschalteten netzgespeisten USB-2.0-Hubs irgendwie an den »cam-serv« und das darauf laufende »motion« anzuschließen. Lustige USB-Fehlermeldungen oder nur einen Start nach dem Reset überlebende Konstellationen waren die Folge; schade eigentlich, da jene Cam eine der wenigen ist, die unter Linux einen funktionierenden Autofocus mitbringen. Allerdings zeigt sich grade jetzt im Nachteinsatz, daß dieser Autofocus bei schlechten Lichtverhältnissen arg zum ziellosen pumpen neigt :(
Ich habe also heute abend, nachdem mein dedizierte Cam (s. o.) schneehöhenbedingt nur noch ein Schwarzbild zu liefern vermochte, auch meine zweiten Fonera 2.0g der kalten Unwirtlichkeit übereignet – und besagte Optia AF angeschlossen. Deren Bild liefert jetzt – leider liefert sie nur 800×600 als MJPEG-Stream – als kleines Einblendimage zusätzliches Bildmaterial, da mein Hauptimage ja schneehöhenbedingt uninteressant geworden ist.
Kurzer Abriß der eingesetzten Technik: Die »Himmelscam« als auch die »Parkplatzcam« sind Notebook-Pro-USB-Cams von Logitech, die an einem SheevaPlug (Parkplatz) bzw. einer Fonera-2.0g mit OpenWRT (Himmel); die Wetterdaten werden empfangen über FHEM in Verbindung mit CUL und CUN sowie S300TH/S555TH als Sensor. Ferner tut eine WS3600 Dienst, welche minütlich seriell über FHEM ausgelesen wird; deren Werte wandern allerdings, anders als jene der S300-Sensoren, noch nicht in die rrd-Datenhaltung, weshalb nur zwei Werte, die des Sensors in der Gartenhütte und die des Sensors oberhalb des Parkplatzes, in den Plot auftauchen. Bedingt durch die Funkübertragung gibt es gelegentlich Aussetzer, die im Graphen sich als fehlende Fortschreibung der entsprechenden Linie manifestieren; in der Folge fehlen dann entsprechend auch einen Tag später die als Fläche aufgetragenen Werte des Vortags. Warum es diese Aussetzer, insbesondere Nachts, gibt, ist eines der Themen, an denen ich derzeit kaue … Anyway, der Film der letzten zwei Tage:
Gütersloh, day & night
Der gestrige Tag im Zeitraffer:
Webcam via OpenWRT, Fonera 2.0n und binary-only Treiber
Vor einer Woche habe ich ja schon drüber geblogt, daß es von verschiedenen Herstellern mittlerweile sog. »Open-Source-Router« gibt, d. h. herstellerseits nicht nur nicht aktiv zu unterbinden versucht wird, daß alternative Firmware die Möglichkeiten der Hardware und die Wünsche des Käufers besser in Einklang bringt, sondern diese Entwicklung, die mit dem Linksys WRT54G vor etlichen Jahren begann, sogar aktiv untersützt wird.
Nachdem ich einen meiner Fonera 2.0g-Router in einen wireless Server für Webcams überführt habe, stieß ich jetzt auf den Fonera 2.0n, spricht eine vermeintlich bessere Version dieses Routers – eingebauter Switch (wie seinerzeit der WRT54g) statt »nur« einem zus. Port wie beim 2.0g, WLAN nach 802.11n (-Draft?) mit theoretisch ca. 100 MBits/sec netto statt »nur« 802.11g (2,4 GHz, max. 54 MBiz/sec brutto = ca. 20 MBit/sec netto) – zu einem auch nicht soo schlechten Preis (rd. 80 EUR derzeit). Tja, nur auf der Suche nach Hinweisen, warum mein geliebtes PWC-Modul nicht mehr in den Kamikaze-Releases von OpenWRT zu finden ist – damit ich auch meine alten VGA-Außen-Webcams auf stromsparende Kistchen klemmen kann –, stieß ich auf folgenden Forumsbeitrag:
Openwrt doesn’t support the fonera2n and thus doesn’t know the fonera2n+mipsel K(ernel)MOD packages have to be compiled against 2.6.21 as the ralink drivers which are binary…only support 2.6.21
Na doll; da hat sich also jetzt FON auf das gleiche Abstellgleis begeben wie vor Jahren Linksys, Asus und wie sie alle heißen, die auf die Broadcom-Plattform samt Broadcom-WLAN gesetzt haben — und da es von Broadcom, wie von Ralink, keine Open-Source-Treiber für jene Hardware gibt, stehen alle WRT- oder Asus-500g-Besitzer wie ich insofern im Regen, daß es nur einen, heute uralten, 2.4er Kernel für die Plattform geben kann und somit auch keine Treiber, die 2.4 nicht (mehr) unterstützen. So wird es denn auch in ein, zwei Jahren den Fonara-2.0n-Eigentümern gehen, deren Hardware an Softwareneuerungen nicht partizipieren kann. Schade; grade von einem Unternehmen wie FON hätte ich erwartet, daß sie auf eine Plattform setzen, die voll von Open-Source-Treibern unterstützt wird (so, wie es bei der Fonera 2.0g auch der Fall war).
Naja, ich werde dann wohl eine ältere OpenWRT-Version für meinen Asus 500g Deluxe nehmen, komischerweise gab’s für White Russian noch pwc-Treiber; für Kamikaze finde ich irgendwie nix fertiges; ich werde also wohl auch eine Buildumgebung mir noch einrichten müssen — wieder mal nix mit »mal eben schnell flashen« :-?
Das Video zum Tweet vom Freitag ;)
Ich habe meine (von Kodak gesponsorte) Zi8 ja meistens dabei, nicht zuletzt, da ich mein treues – Foto- und VGA-Video-taugliches – Nokia N95 zugunsten des Motorola Milestone nun auf’s Altenteil geschickt habe. (Gut, nun habe ich also ein Android-Handy mit eher mäßiger Kamera und nicht wirklich gutem Blitz sowie eine Full-HD-Handkamera, ebenfalls mit Fixfokus aber ohne Blitz, dabei … Aber filmen geht einfach besser mit der Zi8.) So denn auch zum Wochenendseinleitungssushiessen mit @ifranz & @_refugee_ Christian hatte denn auch ein neues Gadget dabei, Alex noch seine Fotoausrüstung (die ja mittlerweile auch filmen kann), und während unser toter, roher Fisch zerhackt und auf Reisbällchen gelegt oder in diesen versteckt wurde, machten wir, was alle erwachsenen Männer in dieser Situation tun:
;)
Qik und »HiRes« auf dem #Milestone – ein Test …
Die aktualisierte -Qik-App für Android verspricht, auf dem Droid (und damit, würde ich erwarten, auch auf dem Milestone), »HiRes«-Videos machen (und hochladen) zu können. Gut, also gleich mal bei @frostygeek ausprobiert (keine Gesichter, Privacy, you know?):
Also das abgelegte Qik-Video auf der SD hat die sagenhafte Auflösung von 320×240 Pixeln bei 9-10 fps – nennt mich verrückt, aber was das das mit »HiRes« bzw. »Qualität: Hoch« zu tun?
Sicher, verglichen mit meinem ersten Qik-Test (352×288 Pixel – absolut mehr als 320×240, oder ist mein bc karpott?) mit dem Milestone ist es relativ besser — aber es sind Lichtjahre bis zu guter Qualität; immerhin schreiben wir 2009 und lassen uns von 3.5G-Netzen bestrahlen, Upload nicht unter 384 kBit/sec bis zu ~2 MBit/sec im Falle des Milestone (und VF-D2-Netzes). Doch vergleicht selbst:
Um den Vergleichsreigen abzuschließen mal ein – ebenfalls als .3gp gespeicherter – Clip von der nativen Videoaufzeichnungsfunktion des Milestones; die Videoqualität haut mich jetzt nicht ganz vom Hocker — aber das mag daran liegen, daß ich eigentlich nur noch in 720p aufnehme (TZ7, Zi8). Hier ein kurzer Ausschnitt aus einem Testvideo mit dem Milestone, mittels »mencoder -oac copy -ovc copy -endpos 10« beschnitten und auf YouTube hochgeladen; und ja, die Artefakte sind auch in der Orginaldatei auf dem Milestone sichtbar. Auch ein ziemlich schwaches Bild :(
Nachdem die Qualität bei YouTube nach der Konvertierung dem Orginal meines Erachtens keineswegs gerecht wird, hier noch eine lokale, als Flash-Video reenkodierte Version:
Was bleibt? Nun, ich kann mit Qik – in Briefmarkenqualität – live von meinem Milestone aus Video (samt Audio ;)) streamen. Abgesehen vom fehlenden Sendungsbewußtsein ;) erst einmal eine nette Idee. Nur: wofür? In der real-existierenden Umsetzung?
Sorry, Qik, aber mit 320×240, da möchte ich meinen Namen eigentlich nicht mehr in Verbindung gebracht wissen; dann nehme ich lieber auf und »sende« nicht-live via YouTube — was neckischerweise auch vom (Google-dominierten) Android-Gerät aus abgespielt werden kann. Mein Milestone-Browser jedenfalls konnte mir meine eigene Aufnahme vorhin über HSPA nicht anzeigen (auch wenn »1x angesehen« angezeicht wurde auf meiner Qik-Profilseite) …
Rolling my own wireless webcam
Ich erwähnte es ja schon, zum Jahresende 2009 steht in der heimischen IT der Kehraus an, Entsorgung von Altlasten und Konsolidierung, insbesondere unter dem Aspekt der Energieeinsparung — GreenIT@Home, wenn man es verschlagworten wollte ;)
Ein Schritt wird es sein, die im Haus verteilten Pizzaschachtel-PCs, die lokal 1-3 USB-Kameras angeschlossen haben und mittels motion ihre Daten auf ein zentrales NFS-Share schieben, durch »etwas besseres« zu ersetzen.
Habe ich durchaus Erfolgt mit motion auf dem SheevaPlug gehabt (2-3 Bilder/Sekunde wurden bei erkannter Bewegung aufgezeichnet), so bin ich nun über mjpeg-streamer gestolpert – und begeistert. Denn statt bis zu 100% (motion) verbrät mjpeg-streamer auf dem SheevaPlug keine nennenswerte CPU-Leistung, und das bei 12 Bildern/Sekunde in einer Auflösung vom 960×720 Pixeln (die Kamera würde auch 1280×960 machen, aber dies liefert sie leider nur per YUV ab, nicht als MJPEG-Datenstrom; und grade dieses Feature moderner, UVC-kompatibler, Webcams macht sich ja, wie der Name schon andeutet, mjpg-streamer zu nutze: ein aufwendigen Kodieren, die Frames werden einfach von der Cam entgegengenommen und Netzanfragern als MJPEG-Datenstrom gegeben). Ein besonderes Feature aus meiner Sicht: während auf Rechner X motion sich den MJPEG-Stream zwecks Überwachung und Aufzeichnung reinzieht, kann ich auf Rechner Y (in meinem LAN) mit besagten 12 Bildern/Sekunde »aus dem Fenster schauen«. R0xx0r!
Na, und wenn das so super auf ‘nem 1,2 GHz-full-blown-Ubuntu läuft, dann gucken wir doch mal bei OpenWRT nach, ob uvcvideo und mjpg-streamer nicht auch schon zum Repertoire gehören, liegt hier doch noch ein Asus WL-500g Deluxe V mit 2x USB 2.0 rum …
Tja, Denkfehler eins: jene Plattform leidet noch immer unter den Binary-only-Treibern von Broadcom für die entsprechenden Broadcom-Devices; no meat bei 2.6. Und grade die »Portierungen« auf MIPS & Co. sind für 2.6er Geräte viel weiter, umfassender. Kurz: kein mjpg-streamer, kein uvcvideo im brcm-2.4-Repository. Also 2.6 nehmen und auf WLAN verzichten? Aber da, wo der hinsoll, wäre WLAN (als Client) ganz praktisch …
Ach, ich habe ja noch ‘n Fonera 2.0g da, Atheros-basiert und voll unterstützt, dann flashe ich den doch mal eben auf OpenWRT Kamikaze 8.09.2-2RC2, sprich, das aktuelleste, drauf …
Genau: Denkfehler Nummer zwei. Neu heißt nicht unbedingt gut, ich habe mich über das Web-GUI 3x ausgesperrt, sodaß ich neu flaschen mußte – Halleluja!
Naja, wie auch immer: ein auf Kamikaze geflashter Fonera 2.0g kann ebenfalls eine (identische) Webcam mit 960×720 Pixeln per mjpg-streamer bedienen – allerdings liegt die Systemlast hier deutlich höher (ok, hier werkelt auch »nur« ein Atheros AR2315 (MIPS 4KEc V6.4) mit, IIRC, 180 MHz; kein Vergleich zum SheevaPlug):
Mem: 17348K used, 12568K free, 0K shrd, 1220K buff, 6308K cached CPU: 6% usr 12% sys 0% nice 31% idle 0% io 9% irq 39% softirq Load average: 0.89 0.88 0.67 PID PPID USER STAT VSZ %MEM %CPU COMMAND 1065 1059 root R 8492 28% 56% mjpg_streamer -i input_uvc.so -f 12 - 1060 1059 root S 8492 28% 3% mjpg_streamer -i input_uvc.so -f 12 - 1064 1023 root R 1960 7% 2% top 980 1 root S 1388 5% 1% /usr/sbin/ntpclient -i 60 -s -l -D -p 1022 860 root S 1996 7% 0% /usr/sbin/dropbear -p 22 1058 1 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 - 1063 1059 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 - 1059 1058 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 - [...]
Ich weiß jetzt nicht, woran dies leigt, evtl. ist das USB-Subsystem nicht wirklich für USB2-Datenraten ausgelegt, keine Ahnung. Siehe Fritz!Box 7170, da scheint ja durchaus das eine oder andere Mal gepfuscht zu werden; grade im Embedded-Bereich bedeutet eine USB-2.0-Schnittstelle nicht zwingend, daß diese auch performant ist :(
Jedenfalls habe ich mir mit der Fonera 2.0g und OpenWRT einen »WLAN-Webcam-Adapter« gebaut; die Fonera verbindet sich drahtlos mit meinem – im Garten nur noch schwachen – WLAN, mjpg-streamer wird von einem auf einem zentralen Mehrkern-Rechner laufenden motion abgefragt und ich brauche außer Strom für die Fonera und einem Platz für die Webcam – schwierig, wenn man so wie ich gerne »das Wetter« filmen möchte, es sind ja Persönlichkeitsrechte der Nachbarn zu beachten usw. – genau nix mehr. Und ich kann mir die Videoqualität – durch die Wahl der USB-Webcam – quasi aussuchen. Und wenn man das Ganze auf die Spitze treiben wollte, evtl. klappte es sogar mit einem 3G-USB-Stick parallel zur Webcam, die Bilder per UMTS/3G zugänglich zu machen. Hier muß ich aber mal gucken, welche Datenmenge das ist ;)
Mir schwebt eigentlich vor, in festen Zeitabständen einen Snapshot zu machen (das kann mjpg-streamer auch, aber dann müßte ich auch noch NFS mounten oder SMB), parallel dazu die Wetterstationsdaten auszulesen, jene per Overlay über das Webcam-Bild zu legen und daraus dann erst dem Zeitraffer-Film zu machen. Letztlich wären ja bei 960×720 noch Pixel frei, wenn man ein HD-Ready-Filmchen daraus machen wollte … Da könnten dan auch noch rrd-Graphen Platz finden … Mal schauen; erst einmal muß ich am Wochenende den Platz optimieren, hinsichtlich Objekt wie auch WLAN-Abdeckung – noch gibt’s gelegentlich leider Dropouts:
Soundtrack: »Lonely for TV« from »Not From Georgia« (»Eagle Rock Entrées«), License: CC-BY-NC-SA.
Ist Open Source jetzt »in«?
Ich habe mich länger nicht mehr mit Accesspoints (vorzugsweise auf Linux-Basis) auseinandergesetzt, da mein heimisches Reich abgedeckt und eine weitere Verbreitung, inklusive dedizierte Funkverbindung zu einem Nachbarn, nicht notwendig ist bzw. mit vorhandenen Fritz-Boxen und Foneras abgedeckt werden könnte.
Allerdings möchte ich meine in die Jahre gekommene und aus Gründen den Bequemlichkeit sich angesammelt habende Flotte von heimischen Pizza-Schachtel-Servern aus, vornehmlich, finanziellen Gründen – das, was wir an die Stadtwerke für Strom abdrücken, müßte eigentlich für ein eigenes Blockheizkraftwerk reichen – durch Konsolidierung und Hardwareoptimierung ablösen.
Der erste Schritt in jene Richtung war die Anschaffung eines NSLU2 samt 1-TB-USB-Drive, die Datensicherung sollte über ein identisches System abgewickelt werden, sofern mich die Performance des debianisierten Slugs überzeugte. Erste Transfers sind nun gelaufen …
/dev/sda3 889G 440G 441G 50% /data
… und mit rd. 8 MByte/sec per SMB zum virtualiserten XP bin ich erst einmal zufrieden.
Abzulösen sind jetzt noch ein alter »Alles-Server« (da rennt in einer UML auch mein Mailserver *sigh*), ein nach doppeltem RAID-Fehler vor ~2 Jahren schnell hochgezogener Notfall-Fileserver (n x 250 GB; das geht auf eine weitere TB-USB-HDD, die dann nächtlich per rsync gespiegelt wird) sowie der alte Router-und-140-GB-bereitstellende-Server. Dessen Daten immerhin sind schon auf der Platte am Slug gelandet, Abschaltung wohl in dieser Woche. (Als neuen Router habe ich da schon so eine Pizza-Schachtel aka Scenic Xs laufen; da ich VDSL 25 habe und darüber OpenVPN (gesamter Traffic wird in zu einem Housingserver verschlüsselt und erst dort findet der Internet-Übergang statt) mache, ist’s mit einer Fritz!Box da leider performancemäßig nicht getan.)
Ach so, ja, und mein Außen-Kamera- und Heimautomationsserverchen im Wohnzimmer (Typ: Scenic Xs) gehört natürlich auch abgelöst/konsolisiert. Initial wollte ich das auf den neu aufgebauten HDTV-VDR-Rechner packen (Athlon K10 Dual-Core & nVidia-Grafik, VDPAU-tauglich für FullHD bei ca. 10% CPU (1,35 GHz)), aber derzeit überlege ich, statt dieses Watt-Boliden im Wohnzimmer lieber eine Ion-Plattform als reine Streaminglösung hinzustellen, die DVB-S2-Karten kämen dann in eine dedizierte Kiste im Keller; vielleicht eine aufgebohrte Box als Router- und DVB-Streamer dafür nehmen?
Naja; für die Kameraserver suche ich noch nach preisgünstigen Lösungen, die leistungsfähig genug für USB2/HD-Kameraauflösung sind (1280×960 oder größer, 1-5 fps reichen da aber) — und kam dabei auf den SheevaPlug.
Und da USB-Kameras an den 7170er-Fritzboxen nicht tun (kein isochroner Modus in AVMs AHCI(?)-USB-Treiber implementiert), entsann ich mich grade der guten alten WLAN-Router mit OpenWRT, wo z. T. Webcam-Streaming-Lösungen (für VGA-Auflösungen und drunter jedenfalls) existier(t)en. Erstaunt mußte ich feststellen, daß sowohl D-Link als auch Netgear ganz offen WLAN-Accesspoints/-Router anbieten, die nicht nur mit Linux betrieben werden sondern wo auch der Hersteller eigene Erweiterungen unterstützt; bei Netgears WNR3500L gleich mit einer eigenen Webseite, passend »myopenrouter« betitelt.
Ich finde das recht bemerkenswert; Netgear geht auf den ersten Blick einen radikalen Ansatz, bietet neben der eigenen Firmware auch OpenWRT und -Abkömmlinge für das Gerät an; und mit unter 75,– EUR ist das Gerät – bedenkt man die 4 GBit-Switchports, das 802.11n-WLAN sowie den einen USB2-Port – auch noch recht günstig. Ich bin versucht, damit einen GBit-Verteilswitch (Netgear GS108T) sowie den betagten WRT54G im EG zu ersetzen …
… aber auch D-Links Angebot klingt interessant (unter 60,– EUR derzeit), wobei ich mich frage, was ein 100-MBit/sec-Port an einem 802.11n-Gerät (mit latent über 100 MBit/sec netto) zu suchen hat.
Jedenfalls ist es spannend zu sehen, daß nach Fon, wo bei der Fonera 2 ja auch eigene Anwendungen installiert werden dürfen (man muß sie also nicht mehr um die Fon-Software erleichtern), IIRC, und dem laaaangen Erfolg des WRT54G, zuletzt in der WRT54GL-Inkarnation, auch andere Hersteller anfangen und auf die »Community« setzen, die ggf. einen Mehrnutzen für die Anwender aus den Geräten herauszukitzeln in der Lage ist. Ganz offiziell, ohne schrauben, löten oder tricksen — doch, das finde ich richtig gut.
Das ifranzl und der Kindle
Im Nachgang der ifranznation-Show mit Teymur Madjderey (aka @icedsoul der anschließenden Burgerrunde und dem gadgetreichen Ausklang des Abends gab’s für @ifranz noch ein Highlight zum krönenden Schluß — Teymurs Kindle:
Schnitt, as usual, mit LiVES (4 Crashes); vielleicht habe ich die magischen Menüs noch nicht gefunden, für den Fall, daß ich sie wegen Nichtexistenz nicht gefunden haben sollte, das Problem ist folgendes: man kann die Schnipsel in den Zeitleisten leider nicht wirklich gut – lies: framegenau – positionieren, daher leider keine wirklich sauberen Übergänge zwischen Normal- und 2x-Schnipseln. Naja. im 10, 15 Jahren noch oder so, irgendwann nach der world domination von Linux, wird man damit sicher auch ohne gebrochene Finger und aus Wut über den 32. Absturz binnen 17 Minuten zerborstenen Tastaturen (Scherz) Videos bearbeiten können. *sigh*
#SheevaPlug – der Naßmacher
Länger schon suche ich kostengünstige, kleine, energiesparende Helferlein, die meinen Fuhrpark an verstreuten PCs und damit auch die Stromrechnung dezimieren könnten.
Ich glaube, ich habe die aktuelle Traumbox gefunden – SheevaPlug, ein sog. “Stecker-Computer“, also – in der Marketing-Theorie – so klein wie ein Steckernetzteil, aber ein kompletter – headless – Computer. Zu einem Preis, der den Einsatz in so manch einer Steckdose ermöglichen könnte; die Kistchen kosten unter 100 GBP/USD pro Stück. Meiner ist – Freitag morgen bei NewIt in UK bestellt – am Montag angekommen, und dem abebbenden Trend hinterherhetzend, habe auch ich ein »Unboxing«-Video gedreht ;)
Da Google ja Flash nicht auf Android bekommt, gibt’s jetzt ‘nen eigenen blogdoch-YouTube-Channel, da YouTube leider die einzige von Android derzeit unterstützte Video-Plattform darstellt. *sigh*
Gut, ich wäre nicht ich, hätte ich nicht was mäkeln ;) Das erste Feeling – grade nach meiner Debian-Lenny-Installationsorgie auf meinem NSLU2 – ist gigantisch, das Kistchen fühlt sich flott an und auch die seit dem überraschenden Ableben des »cam-serv1« brachliegende Parkplatz-Cam (USB2, 1280×960) läuft nun wieder:
top - 00:58:39 up 6:51, 2 users, load average: 0.79, 0.78, 0.76 Tasks: 55 total, 2 running, 53 sleeping, 0 stopped, 0 zombie Cpu(s): 63.4%us, 0.5%sy, 0.0%ni, 36.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 513752k total, 280372k used, 233380k free, 0k buffers Swap: 0k total, 0k used, 0k free, 207368k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3028 wusel 18 -2 90120 48m 10m S 62.9 9.7 61:41.47 motion 2237 root 18 -2 8748 2796 2192 R 0.5 0.5 0:22.76 sshd 3038 root 18 -2 2524 1144 924 R 0.5 0.2 0:27.83 top 1 root 20 0 2892 1888 568 S 0.0 0.4 4:44.44 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd [...]
Ja, 512 MB RAM, irgendwas von 1-GHz-ARM-Power, da geht schon was. »motion« ist auf …
width 1280
height 960
framerate 2
threshold 25000
ffmpeg_cap_new on
ffmpeg_timelapse 1
ffmpeg_timelapse_mode hourly
ffmpeg_variable_bitrate 2
ffmpeg_video_codec msmpeg4
… eingestellt, hat also durchaus was zu tun — sobald ich eine bessere Auslösung gefunden habe (PS20 PIRI via FHEM?), würde ich aus Effizienzgründen die Aufzeichnung extern triggern, aber derzeit geht’s halt nicht ohne Pixel-für-Pixel-Vergleich … Immerhin, das schafft die Box; was ich noch nicht gesehen habe, trotz Forcierungsversuch, ist ein durch Bewegung getriggertes Video, bislang werden nur die Timelapses aufgezeichnet. Aber das kann auch an Späßchen mit den Codecs usw. liegen, armel ist eben nicht x86 …
Was ich am SheevaPlug vermisse: ein weiterer USB2-Bus (nicht: ein zweiter. ge-HUB-ter Port), ein zusätzliches >= 100-MBit/sec-Interface (zu dem vorhandenen 1 GBit/sec-Anschluß), um den Plug als Gateway/Firewall einzusetzen (ok, man könnte das ggf. per USB-Ethernet nachrüsten) und, da es ja eine »Plug«-Technik ist, X10 und ein Powerline-Interface. Grade das die letzten beiden Dinge nicht vorhanden sind, erscheint mir fragwürdig. Gut, Powerline als auch X10 sind nun Dinge, die regulatorisch wie technisch (120V, 60 Hz vs. 240V/50 Hz) m. W. nicht weltweit eingesetzt werden können. Aber einen SheevaPlug gleichzeiig als (Ether-) Netzanschluß benutzen zu können, das hätte schon was. (X10, nunja, vielleicht eher eine Nischenanwendung; aber wenn sich die n Sheevas im Haus gleich über’s Stromnetz vernetzen könnten, das wäre schon ein Feature, meine ich.)
Naja, mal sehen, was ich mit dem Plug noch alles anstelle; in rd. einer Woche, so hoffe ich, sollte der 2. Plug aus der Sammelbestellung des deutschen SheevaPlug-Forums eintrudeln, dann habe ich auch mehr »Spielmasse« und werde FHEM samt FHZ & CUL, die beide daran hängen, darauf umzuziehen versuchen.
Praise the cool guys …
┌────────────────┤ [!!] Configuring network-console-menu ├────────────────┐ │ │ │ This is the network console for the Debian installer. From here, you │ │ may start the Debian installer, or execute an interactive shell. │ │ │ │ To return to this menu, you will need to log in again. │ │ │ │ Network console option: │ │ │ │ Start installer │ │ Start installer (expert mode) │ │ Start shell │ │ │ └─────────────────────────────────────────────────────────────────────────┘
Also, daß ist schon ziemlich geil, was die Jungs da beim NSLU2-Installer vollbracht haben.
The installation will take roughly 4 hours (or slightly more if you have a slow Internet connection). At the end of the installation, the installer will write the new kernel to flash.
Okay, final results dauern also noch etwas ;)