blogdoch — jetzt wird zurückgeblogt
Kurzer Zeitraffer von heute Mitternacht bis Mittag von öffentlichen Webcams in Bielefeld, Detmold, Lemgo und meiner Parkplatz-Cam in Gütersloh – Schnee ja, Chaos nein würde ich sagen:
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:
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« :-?
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: