Festplatten Standby

Stellt den Standby Timer der Sekundären Festplatte auf 10 Minuten.

hdparm -S120 /dev/sdb

Spart laut c't bis zu 4W. Auf der Betriebsystem-Platte ist es nutzlos, aber für einen NAS kann sich das aufsummieren.
Witzig ist, dass es danach eine spürbare Zeit (einige Sekunden) dauert, bis man wieder auf die Platte zugreifen kann.

Und zum Testen, schickt dieses Kommando die Festplatte sofort in den Standby:

hdparm -y /dev/sdb
hdparm -C /dev/sdb

Memo an mich selbst: Das Dollarzeichen durch eine Raute ersetzen, wenn ich root-Befehle aufschreibe.

Update: Da diese Methode bei manchen Festplattentypen (zB. meiner WD Caviar Green) nicht funktioniert, gibt es einen Daemon mit dem es klappt. hd-idle Konfiguration über /etc/default/hd-idle

Strom für einen Tag

Das Tollste, wenn man Daten gesammelt hat, ist zu sehen, dass sie plausibel sind. Dann hat der Messaufbau funktioniert: Die Gedanken, die man sich vorher darüber gemacht hat, waren richtig. Es funktioniert.

Dann ist es nebensächlich, ob sie neue Erkenntnisse liefern, oder nicht.

Ich habe also meine Stromverbrauchsdaten, die ich mit meinem alten Wildfire aufgenommen habe, einmal differenziert, um die Leistung zu erhalten und gegen die Uhrzeit aufgetragen.

Ich habe mal einen Tag mit typischen Stromverbrauch ausgesucht.

Was sieht man? 

Offenbar habe ich ca. 100W "Grundlast". Da fällt der Router und WLAN Access Point hinein (~20W), so wie ein Server (30W). 

Und die restlichen 50W? Die Heizung braucht noch Strom zum Pumpen und zur Steuerung, genauso wie Gefriertruhe und Kühlschrank. Diese Verbraucher habe ich auch für die kleinen periodischen Peaks in Verdacht. Und natürlich braucht auch mein Android basierter Strommesser selbst Strom -- vor allem für die Lampe (~10W).

Offenbar habe ich den ersten größeren Stromverbraucher um 11:00 angestellt. Es gab also keine getoasteten Brötchen oder Tee zum Frühstück. Der Stromverbraucher, der um 11:00 angeht, ist mein Computer -- ein alter mit großer Grafikkarte, der unter Last gerne mal 200W zieht. Zusammen mit den Bildschirmen (~25W+40W) komme ich damit an die 500W Grenze.

Der nächste Peak ist durch die Waschmaschine verursacht. Sie braucht erst jede Menge Leistung, um das Wasser auf 60°C zu bringen -- für das Drehen der Trommel offenbar weniger als mein Computer.

Der Peak dahinter gehört zum Trockner. Ja, man könnte viel Strom sparen, wenn man die Kleidung einfach so trocknen lässt, aber im Energie-Diagramm unten sieht man gut, dass er hier nicht viel mehr als 1kWh benötigt. Und ich habe abgewogen, dass mir das Aufhängen der Wäsche keine ca. 0,30€ wert ist.

Um ca. 17:00 geht wieder der bekannte Computer an und braucht für Skyrim wieder seine 200W. 

Man sieht um ~19:30 sehr schön, wie er wieder aus geht und danach der Backofen 2,5kW zieht um ein paar Nachos mit Käse zu überbacken (eigentlich sind es Tortillia-Chips; mit Käse überbacken transformieren sie sich zu Nachos -- laut Wikipedia).

Danach klingt der Abend Nachos essend und Serien sehend aus. Der Stromverbrauch des Beamers ist erstaunlich niedrig. LED-Beamer sind zwar noch dunkel, aber dafür offenbar ziemlich sparsam.

Und hier nochmal die integrierte Darstellung. Gut um abzuschätzen, wie viel man dann bezahlen muss -- wenn ich jeden Tag waschen würde.

Und für die, die es interessiert. Die Diagramme sind mit der phänomenalen matplotlib für Python gezeichnet.

Stromzähler mit Android

Da Gas ziemlich langweilig ist, habe ich eine neue App gebastelt, die den Stromzähler ausliest -- ohne OCR.
Dazu speichere ich die Zeitpunkte, an denen der rote Streifen auf der Scheibe im Stromzähler das Bild verlässt.

Der Versuchsaufbau: Man platziere das Android Gerät so, dass das drehende Element im Zähler im Preview liegt, aber nichts anderes rotes.

Die Funktionsweise: Die App holt sich während des Camera Previews jeden Frame in Form eines YUV-kodierten Arrays. Durch eine Funktion, die ich irgendwo geklaut habe (Quelle steht in den Quellen) rechne ich dies in ein RGB Array um, ziehe G von R ab. Dann bilde ich das Maximum der Differenz über das ganze Array und lege, wenn der rote Streifen gerade nicht im Preview ist, einen Schwellenwert fest. Wenn es eine fallende Flanke durch die Schwelle gibt, speichert sie den Zeitstempel in meine Dropbox. Von da aus parse und plotte ich sie per Python Skript.

Soweit die Theorie. Jetzt muss ich nur noch darauf warten, dass genug Daten für eine Auswertung vorliegen.
Ich stelle mir schon vor, was man alles damit machen könnte:

• FFTs, um die Intervalle zu finden, in denen die Gefriertruhe zum Kühlen anspringt. 
• Sehen, wie hoch der Leerlaufstromverbrauch ist.
• Abschätzen, wie viel Strom durch Waschmaschinen und Trockner verbraucht wird.
• Sehen, ob sich die Lautstärke der gehörten Musik im Stromverbrauch niederschlägt.
• Erfahren, was mehr Strom braucht: Das Popkorn zu machen oder den Film zu gucken.

Gas ist langweilig

Mein Gaszähler hat erste Ergebnisse geliefert. Leider klappt das mit dem OCR nicht perfekt, was vermutlich an der durch die Geometrie des Gaszählers bedingten suboptimalen Ausleuchtung liegt. Ich habe die gröbsten Fehler per Hand bereinigt und geplottet. Man erkennt, dass sich die Heizung nachts ausschaltet.

Aber irgendwie ist es doch recht langweilig.

Gaszähler mit Android

Da ich jetzt ja Entwickler bin, habe ich meine erste ((mehr oder weniger) nützliche) App geschrieben und auf mein altes HTC Wildfire installiert. Es macht jetzt in festen Intervallen Fotos vom Gaszähler, lädt sie per Dropbox API, die ein sehr schönes Tutorial bietet, auf meinen Computer (FTP wäre ja zu langweilig -- und in Zeiten der Cloud muss einfach alles übers Internet gehen ;) ), wo ich sie nach etwas preprocessing (ausschneiden, normalisieren, monchromatisieren, weichzeichnen) mit Imagemagick per Tesseract OCR auslese. Das ist zwar nicht perfekt zuverlässig, aber besser als es per Hand zu machen.

Die Lampe ist übrigens da, damit das Handy fokussieren kann. Im Gegensatz zu neueren Gräten ist es zu dumm den Blitz zu benutzen beim fokussieren. Aber keine Angst: Es ist eine sparsame LED ;)

Dabei habe ich gelernt, dass Java irgendwie seltsam ist, aber man von Eclipse so gut unterstützt wird, dass man eine lauffähige App schreiben kann, obwohl man Java vorher nur vom hörensagen kannte.
Und was ich nochmal hervorheben möchte: Es gibt nahezu perfekten Linux Support für das Android SDK. Wäre ja auch seltsam, wenn nicht. Ich musste nur eine "udev rule" hinzufügen, mein Nexus 4 anstöpseln und in Eclipse auf "Run" klicken. Und schon wurde ein Foto nach dem anderen in meine Dropbox geladen :D

Als nächstes werde ich zu Auswertung übergehen. Mal sehen, wie gut man sehen kann, wann ich die Heizung aufdrehe.

Update: Auswertung ist da.

Update 2:
Mit folgendem Codeschnipsel hat das auslesen am besten geklappt. Wobei man beim -crop natürlich nur die Zahlen ausschneidet und die -blur Parameter stark von der Auflösung abhängen.

convert -crop 488x60+186+414 -normalize -enhance -monochrome -blur 10x1.5 $i out.png
tesseract out.png cur -psm7 nobatch digits 1&>2 /dev/null

Leider führt bei mir ein Schatten dazu, dass die erste Stelle nach dem Komma oft fehlerkannt wird, sodass ich mich einem vielversprechenderem Ansatz gewidmet habe: Den roten Strich auf dem drehenden Rad zu erkennen.

Entwickler-Optionen Android 4.2

Wie wird man ein Android-Sofware-Entwickler? Nun seit 4.2 ist es ganz einfach: Ihr tippt sieben mal auf die Build Nummer in der Telefoninfo und fertig.

Jetzt, wo man also die Fähigkeiten, die es braucht, um eine App zu schreiben, per Voodoo erlangen kann, sollte ich auch eine App schreiben ;)

Empirische Zombie Forschung

Ich habe heute eine kleine Zombie-Simulation in Python gebastelt. Und ich habe dabei gelernt, dass Verfolgen leichter ist als Fliehen: Obwohl die Nichtinfizierten 20% schneller sind, werden nach kurzer Zeit immer alle gebissen. Vielleicht liegt es aber auch an der schlechten Strategie, immer geradlinig vor dem nächsten Zombie zu fliehen. Man wird leicht in Ecken gedrängt oder von mehren Zombies eingekreist. Aber ich hielt das für realistisch: Wenn Zombies hinter dir her sind, rennst du und denkst dir keine optimale Fluchtroute aus. Obwohl diese kleine Simulation zeigt, dass das schlauer wäre.

Ich werde, sobald ich wieder Lust habe, versuchen jedem Zombie eine Art Potential zu geben und die Menschen entlang des Gradienten fliehen zu lassen. Mal sehen, ob man mit der Strategie besser überlebt. Wenigstens könnten meine Probanden dann vor zwei Zombies gleichzeitig fliehen.

Und auf lange Sicht sollte man wohl noch so etwas wie ein Sichtfeld hinzufügen und Gewehre und Hunde und Cricketschläger und was man sonst noch alles aus den entsprechenden Fachfilmen kennt.