Weitere Informationen

Allein, nicht allein, doch allein und überhaupt: RRD cross-platform
Friday, January 29, 2010, 17:00 - Geeks & Co., Painseeker, Linux, Hausautomation, PlugComputing
Allein zu sein, das ist kein schönes Gefühl. Komischerweise bekomme ich das bei meinen Projekten des öfteren ;)

Nachdem ich nun einen meiner SheevaPlugs zum primären Hausautomatisationsknoten gemacht habe und FHEM darauf auch schön läuft, war der nächste logische Schritt, auch die Langzeitdatenaufzeichnung mittels RRD zu aktivieren, um den betagten, energiehungrigeren FSC Scenic xS entsorgen und einmotten zu können.

Und wenn man die Daten erst mal hat, das Auswerten kann ja auch von anderen System erfolgen, NFS und ähnliches macht's möglich … ja, aber nicht bei plattformabhängigen Datenbasen, wie sie RRD nun einmal leider erzeugt: 
wusel@server-1:~$ rrdtool info /mounts/plug-2/rrd-fhem/Parkplatz_TH/temperature.rrd 
ERROR: This RRD was created on another architecture
Schön, daß wir drüber gesprochen haben … Ich hatte das in der Tat vergessen, aber für optimale Performance schreibt RRD nuneinmal die lokale Speicherabbildung des Daten in die Datei. Und die Darstellung unterscheidet sich leider zwischen Ubuntu auf armel und Ubuntu auf x86 — die Ausgabe ist keine rauspatchbare Schikane, denn rrdtool testet nach dem Einlesen einen »magischen Wert«, und der differiert, leider, obwohl beide Plattformen nach »little-endian«-Notation laufen.

Ich fühlte mich erst einmal allein gelassen, nachdem ich googelte und mehr so nichts deutlich neueres als eine Frage aus 2002 bzw. vage Diskussionen zu dem Thema fand:
Aber, niemals die Hoffnung aufgeben — und siehe, Überlegungen gibt es schon und ein Projekt für die Übergangszeit, welches mir helfen könnte — also doch nicht alleine!

Gelesen, gezogen, geinstalliert; geht nicht: 
wusel@server-1:~$ tird-rrdtool -arch arm dump /mounts/plug-2/rrd-fhem/Huette_TH/temperature.rrd 
ERROR: This RRD was created on other architecture
Und wieder zu früh gefreut und auch wieder allein; armel wird augenscheinlich nicht unterstützt; klar, das Gros der bisherigen Router auf einer Embedded-Plattform waren vom Typ mips.

Tcha. Da habe ich also nun meine Daten auf einem kleinen, energiesparenden – aber eben FPU-schwachen – »Plug«, nur weiterverarbeiten unter x86 kann ich sie derzeit nur, wenn ich sie periodisch auf dem Plug ex- und dann auf x86 wieder importierte. Das hätte ich gerne *nur* auf x86 gemacht, aber dazu jetzt ein static binary unter qemu für meine arm5el-Systeme zu bauen, sprengt doch etwas den Rahmen; da wird das kleine Kistchen halt die eine oder andere CPU-Überstunde schieben müssen, bis rrdtool 1.5 cross-platform-Unterstützung mitbgringt … (Oder ich versuche mich an einem "repacking" der Daten beim Einlesen, aber wahrscheinlich ist's es soo einfach nicht, wenn man die Datenrepräsentation sich ansieht.)

Mental note: if using UBI, better have UBI in your kernel
Friday, December 25, 2009, 08:12 - Geeks & Co., Painseeker, Linux, PlugComputing
Alas, I tried to upgrade to – self-build – kernel 2.6.32.2 again, and bricked my SheevaPlug, again.

Fortunately, all info needed to boot from a working uImage off USB is available within uBoots environment variables: 
Marvell>> usb start; fatload usb 0 0x00800000 uImage
(Re)start USB…
USB:   scanning bus for devices… 2 USB Device(s) found
       scanning bus for storage devices… 1 Storage Device(s) found
reading uImage
…
…
…………………………………………………………………………………………………………………………………………………………………………………………….
…

2620504 bytes read
Marvell>> setenv bootargs $(bootargs_console) $(mtdpartitions) ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs ; bootm 0x00800000
This finally loaded the uImage (Sheeva's version of good-old zImage) from the attached USB drive, provided the kernel command line with the (still working) in-flash root-fs and jumped to the kernel images as loaded into RAM. Cool stuff. Reason for this: UBI/UBIFS is not selected per default for the platform. Booting from an UBI device and an UBI-filesystem on it without the kernel even knowing how to spell UBI leads to the well-know panic() :-) 
Linux version 2.6.32.2 (wusel@greebo) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #2 PREEMPT Fri Dec 25 04:16:40 CET 2009
Cool stuff – short nights ;)

Safely bricking my SheevaPlug …
Thursday, December 24, 2009, 11:40 - Geeks & Co., Painseeker, Linux, PlugComputing, CloudComputing
As I received my second SheevaPlug Development Kit yesterday, it was time to actually try flashing it; the first unit was ordered with an UBIFS installation from NewIT – which runs great! –, this time I saved the about 5 UKP and intended to try to convert the unit from jffs2 to ubifs myself. Given that there even exists a ready-to-run Installer, how difficult could that be?

Ah, well … To make the story short – it's Christmas Eve after all –, I bricked it. On the first opportunity ;)

As it turned out, using an USB 2.0 2-GB-stick, off which the WD TV Live happily boots a Debian live system (courtesy of b-rad), didn't go too well with the SheevaPlug: using the Installer stuff, I wiped the NAND, flashed a new uBoot and then SheevaPlug rebooted, trying to fetch kernel and rootfs from the attached USB stick. It tried. It resetted even USB, I think. Then it gave up with an "drive not ready"-message => now my SheevaPlug was stuck uBooting into failing to flash, great. At least I was able to witness this all live via "minicom -o /dev/ttyUSB0", this being a development kit. Ah, and yes, even without a working uBoot I should be able to reflash uBoot through this JTAG-and-serial-via-USB connection; although I prefer not to need that …

Running out of options (that is: free USB sticks; it is said in the Forums that using an USB HDD might yield exactly this, that is a not ready drive at the time SheevaPlug wants to fetch the data), I pulled out the MicroSD-to-SD-adapter out of my Zi8, put the tiny 4-GB-MicroSD it contained into a USB-MicroFlash-adapter, wrote the Installer-data onto it, safely unmounted it, attached it to the USB host port of the SheevaPlug … and rebooted the SheevaPlug.

This time it worked as advertised: the NAND got erased, reprogrammed, the Plug rebootet, fetched kernel and rootfs from the USB device, flashed that, rebootet again – and I had my SheevaPlug the way I like (and need) it: booting really fast, having modules for all kinds of uses where they belong (as delivered, there was an empty /lib/modules/`uname -r` – so, no luck with an USB hub to start with); guys, this is really, really cool stuff! (Ok, not the Plug itself, mine at least get's pretty hot even doing nothing.)

Instead of a former ~120 second boot cycle, I'm now down to … 
dhcp-server:~# ssh root@plug-2 shutdown -r now \; exit ; rc=0; date ; while [ $rc -eq 0 ]; do ping -W 1 -c 1 plug-2 >/dev/null ; rc=$? ; done ; date ; rc=1; date ; while [ $rc -eq 1 ]; do ping -W 1 -c 1 plug-2 >/dev/null ; rc=$? ; done ; date
root@plug-2's password: 
Thu Dec 24 10:59:54 CET 2009
Thu Dec 24 10:59:59 CET 2009
Thu Dec 24 10:59:59 CET 2009
Thu Dec 24 11:00:25 CET 2009
… roughly 30 seconds from "shutdown" to "pinging again". This rocks ;)

Merry Christmas!

Wireless-Web-Cam, die 2.
Sunday, December 20, 2009, 23:01 - Geeks & Co., Linux, WLAN, PlugComputing
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 800x600 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:




Rolling my own wireless webcam
Friday, December 11, 2009, 17:29 - Geeks & Co., Linux, Technologien, WLAN, IPTV, PlugComputing
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 960x720 Pixeln (die Kamera würde auch 1280x960 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 960x720 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 960x720 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.



Zurück Weiter