Mathias Dalheimer

Warum ACTA eher so meh ist.

2012-02-09T00:00:00+01:00

ACTA, das Anti-Counterfeiting Trade Agreement, ist momentan in aller Munde. Das ist eigentlich schon bemerkenswert für ein derart abstraktes Abkommen — es geht schließlich nicht direkt um unmittelbare Konsequenzen, im Gegenteil: ACTA ist überaus löchrig formuliert und für den Laien kaum nachvollziehbar. Auch in der Tagespresse spielt das Thema kaum eine Rolle. Was steckt also dahinter? Was veranlasst polnische Politiker, mit Guy Fawkes-Masken im Parlament zu sitzen?

Fotos aus Disneyland

Nehmen wir einmal einen Teilbereich von ACTA, der sich auf Diensteanbieter (Provider) im Internet bezieht. Demnach sind Provider für Urheberrechtsverletzungen ihrer Nutzer auf ihren Angeboten haftbar. Die Provider wären damit (obwohl das nicht direkt in ACTA so drin steht) gezwungen, Inhalte ihrer Kunden vor der Veröffentlichung auf Urheberrechtsverletzungen zu überprüfen.
Das da ist zum Beispiel Kevin (CC-BY):

Kevin war offenbar zu Gast in irgendeinem Disneyland und hat sich einen Hut gekauft. Eigentlich ein harmloses Bild, kein Problem, bitte weitergehen — derartiges findet sich in Massen auf Twitter (Suche nach #mickeymouse). Allerdings hat Twitter unter ACTA ein Problem mit dem Bild von Kevin: Um die Rechte von Disney zu wahren (und aus der Störerhaftung wegen Urheberrechtsverletzungen zu vermeiden) müsste Twitter alle Bilder automatisiert auf das Vorhandensein von Mickey Mäusen scannen. Das legitime Bild von Kevin ist allerdings für einen Computer verdammt schwer von einer potentiellen Urheberrechtsverletzung wie das Profilbild hier zu unterscheiden. Im Zweifelsfall tut Twitter aber aus eigenem Interesse gut daran, Kevins Bild nicht anzunehmen.

In letzter Konsequenz bedeutet ACTA für Twitter also, möglichst viele Inhalte präventiv zu filtern, sprich: zu zensieren. Da dies realistisch nur automatisiert geschehen kann, muss sich ein Diensteanbieter also entscheiden, wie "scharf" die Filter eingestellt werden müssen. Im Zweifelsfall werden tendenziell mehr Informationen weggefiltert als zwingend notwendig.

Privatunternehmen zensieren

Das oben beschriebene Szenario lässt sich aus dem deutschen Vertragstext direkt nicht ableiten. Interessanter ist vielmehr, dass der Text sehr viel Raum für die Interpretation zulässt. Die EU-Kommission hat eine Roadmap für eine sog. "Enforcement-Richtlinie" vorgelegt, welche das ACTA-Handelsabkommen in europäisches Recht umsetzen soll. In dem Entwurf heisst es (gefunden bei RA Stadler):

Other possible impacted parties may include various intermediaries such as Internet Platforms, Internet Service Providers or transport establishments who could play an important role in the fight against infringements of intellectual property rights.

Diese Konkretisierung von ACTA lässt sich sehr genau auf Kevins Bild anwenden. Dazu kommt, dass hier auch ISPs direkt angesprochen werden. In Analogie zu Twitter, die neue Tweets und Bilder im Hinblick auf ihren Inhalt kontrollieren müssten, müssten also auch normale Internetanbieter mein Surfverhalten überwachen.

Das ACTA-Abkommen ist kein Gesetz, es ist ein Handelsabkommen zwischen Staaten. Es wurde hinter verschlossenen Türen ohne Beteiligung der Internetnutzer ausgehandelt und muss — sollte es ratifiziert werden — in europäisches Recht umgesetzt werden. Gleichzeitig wird man sich bei der Umsetzung von härteren Maßnahmen auf "internationale Verpflichtungen" berufen. Insofern hat RA Stadler Unrecht, wenn er sagt, dass im Prinzip alle Forderungen von ACTA im deutschen Recht sowieso umgesetzt sind.

The Coming War on General Computation

Cory Doctorov hat auf dem 28C3 einen spannenden Vortrag gehalten, der den Blick für die gegenwärtigen Konflikte schärft (Mitschrift "The Coming War on General Computation"). Ich möchte diesen Vortrag uneingeschränkt jedem empfehlen, der den großen Zusammenhang von ACTA etc. verstehen möchte. Der Talk ist auf Youtube und auch zum Download verfügbar.

Unsere Gesellschaft hat bis jetzt keinen sinnvollen Ausgleich zwischen den legitimen Interessen der Urheberrechtsinhaber und der Nutzer von Computern gefunden. Computer sind Maschinen, die Informationen verarbeiten, indem sie diese kopieren und verändern. Wenn ich eine Email schreibe und versende, verschwindet sie nicht von meinem Computer und taucht beim Empfänger wieder auf. Im Gegenteil, meine Email wird zu meinem Mailserver kopiert, dann zu weiteren Mailservern, bis sie schließlich beim Empfänger ankommt. Computer sind darauf angewiesen, perfekte Kopien schnell anzufertigen und diese gegebenenfalls zu verändern.

Statt über nachhaltige Geschäftsmodelle nachzudenken versucht die Lobby der Rechteinhaber, meinen Computer seine Kernkompetenz (das Kopieren) durch künstliche Beschränkungen wie DRM abzugewöhnen. ACTA etc. geht nun noch einen Schritt weiter und versucht, Privatunternehmen als Hilfssheriff zu missbrauchen. Dabei ist absehbar, dass diese Unternehmen Inhalte falsch einschätzen und zensieren.

Fefe hat die Relationen treffend festgestellt: Die Müller Milch Gruppe hat einen Jahresumsatz von 2,3 Milliarden Euro, die Musikindustrie liegt bei 1,7 Milliarden Euro. Genausowenig, wie ich akzeptieren würde, dass ein Konzern der Milchwirtschaft meine Freiheit einschränkt, akzeptiere ich das von der noch kleineren Musikverlegerlobby.

Constraint Programming und Sudokus: 20ms

2011-09-18T00:00:00+02:00

Sudoku ist in meinen Augen ein eher langweiliges Puzzle, ich steh mehr auf Solitaire. Aber Sudoku eignet sich sehr gut als Beispielproblem für Constraint Programming. Die Regeln sind einfach: Ziffern von 1 bis 9 werden in eine 9x9-Matrix eingefügt, sodass

in jeder Zeile keine Ziffer doppelt vorkommt
in jeder Spalte keine Ziffer doppelt vorkommt
in jeder kleinen 3x3-Submatrix keine Ziffer doppelt vorkommt.

Üblicherweise sind je nach Schwierigkeitsgrad unterschiedlich viele Zahlen vorgegeben, sodass der Lösungsraum beschränkt wird. Bei schwereren Sudokus ist der Lösungsraum so stark beschränkt, dass nur eine Lösung möglich ist.

Bild: CC-BY Tim Psych

Zum Lösen von Sudokus gibt es verschiedene Ansätze, z.B. Backtracking oder auch brute-force Algorithmen. Als Beispiel sei folgender Algorithmus genannt:

 solve(puzzle[][]) {
    if all cells are known:
      return success immediately
    for each unknown cell (x, y):
        for each possible digit 1..9:
            puzzle[x][y] = digit
            if(valid(puzzle)) solve(puzzle)
            puzzle[x][y] = unknown
 }

Dieser rekursive Algorithmus versucht einfach für alle 81 Felder, eine Zahl zu finden, die keine Constraints verletzen. Dabei kostet der Aufruf

 if(valid(puzzle))

nochmal erheblich Rechenzeit, da sowohl Spaltenconstraint als auch Zeilen- und Submatrixconstraint geprüft werden müssen.

Was ist Constraint Programming?

Im Gegensatz zum imperativen Algorithmus oben (“tue A, dann B, dann …”) gehört Constraint Programming (CP) zu den deklarativen Ansätzen, d.h. es werden nur die Anforderungen an eine valide Lösung spezifiziert. Der Lösungsweg wird dann dynamisch durch die Programmierumgebung bestimmt.

Formal kann man ein Constraint Satisfaction Problem (CSP) wie folgt definieren: Gegeben sei eine Menge von n Entscheidungsvariablen x_i. Der zulässige Wertebereich D_i der Entscheidungsvariablen wird die Domäne der Entscheidungsvariable genannt und kann beliebige Symbole (Integer, Reals, oder auch Mengen) enthalten.

Ein Constraint c(x₁, x₂, …, x_n) ist eine Relation, die den Lösungsraum einschränkt. Wenn (x₁, x₂, …, x_n) in S liegt und S eine Untermenge von D₁ x … x D_n ist, dann ist der Constraint erfüllt. Üblicherweise wird ein Constraint als Funktion f beschrieben, so dass f(x₁, x₂, …, x_n) = 1 genau dann wenn das Constraint erfüllt ist. Ein Constraint Satisfaction Problem (CSP) kann man nun wie folgt definieren:

Gegeben sind n Domänen D₁ x … x D_n und m Constraints f₁, …, f_m. Eine Lösung (x₁, x₂, …, x_n) erfüllt

f(x₁, x₂, …, x_n) = 1 für 1 ≤ k ≤ m
x_j ist Element von D_j für 1 ≤ j ≤ n

Um aus einem CSP ein Optimierungsproblem zu formulieren kann man natürlich noch eine Zielfunktion hinzufügen, z.B.

Minimize/Maximize g(x₁, x₂, …, x_n)

Man sieht: Die Anforderungen an eine Lösung sind sehr flexibel und können quasi alles abbilden. Das Schöne an Constraint Programming: Es ist eine eigenständige Disziplin und hat viele Bibliotheken hervorgebracht. Effektiv kann man also sein Problem beschreiben und die Bibliothek den Rest machen lassen. Insbesondere für sich ändernde Problemstellungen ist diese Methode praktisch. Eine weitergehende Einführung in Constraint Programming ist in Lustig/Puget, “Program Does Not Equal Program” zu finden.

Sudoku als CSP

Zurück zum Sudoku: Die eingangs beschriebenen Restriktionen für eine korrekte Lösung lassen sich direkt in Constraints für einen CSP-Solver übersetzen. Dabei unterstützen viele Solver den Benutzer mit vorgefertigten, mächtigen Constraints. Ein Beispiel dafür ist das alldifferent-Constraint, mit dem man schnell beschreiben kann, dass alle Elemente in einer Menge unterschiedliche Werte haben sollen. Das Constraint ist quasi für Sudoku gemacht.

Mein Code für einen einfachen CSP-basierten Sudokusolver ist auf Github (gonium/sudoku) zu finden. Ich benutze die C++-Solverbibliothek gecode, d.h. diese muss installiert sein, bevor der Code übersetzt werden kann. Ein einfaches

 $ make

sollte das Binary build/src/sudokusolve erzeugen. Ein Aufruf sieht so aus:

 $ ./build/src/sudokusolve
 Setup - Using this sudoku:
  9 0 0 1 0 4 0 0 2
  0 8 0 0 6 0 0 7 0
  0 0 0 0 0 0 0 0 0
  4 0 0 0 0 0 0 0 1
  0 7 0 0 0 0 0 3 0
  3 0 0 0 0 0 0 0 7
  0 0 0 0 0 0 0 0 0
  0 3 0 0 7 0 0 8 0
  1 0 0 2 0 9 0 0 4
 Setup - row constraints
 Setup - column constraints
 Setup - square constraints
   9 5 7 1 8 4 3 6 2 
   2 8 1 9 6 3 4 7 5 
   6 4 3 7 2 5 1 9 8 
   4 9 6 3 5 7 8 2 1 
   8 7 5 4 1 2 9 3 6 
   3 1 2 8 9 6 5 4 7 
   7 2 9 5 4 8 6 1 3 
   5 3 4 6 7 1 2 8 9 
   1 6 8 2 3 9 7 5 4

Das hier verwendete Sudoku ist fest einkompiliert (hey, das hier ist nur ein Proof of Concept!). Es handelt sich dabei um die Instanz “Star Burst Leo”, von der bekannt ist, dass sie nur eine Lösung besitzt. Die Laufzeit für den Solver beträgt auf meinem Notebook ca. 20ms - nicht schlecht für eine fast automatische Methode. Der Solveraufruf in src/sudokusolve.cpp sieht so aus:

 SudokuSolver* s = new SudokuSolver(star_burst_leo);
 Gecode::DFS<SudokuSolver> e(s);
 delete s;
 while (SudokuSolver* result = e.next()) {
   result->print(std::cout);
   delete result;
 }

Nice and clean. Die while-Schleife gibt einfach alle gefundenen Lösungen aus — diese Instanz hat jedoch nur eine. Der Solver verbirgt sich hinter Gecode::DFS. Dies ist ein generischer Solver, der eine Depth-First-Search benutzt. In der Klasse SudokuSolver wird das CSP formuliert. Aus lib/sudokusolver.cpp:

 std::cout << "Setup - Using this sudoku:" 
 for (int i=0; i<9; i++){
   for (int j=0; j<9; j++) {
     int v = sudokuproblem[i*9 + j];
     std::cout << " " << v;
     if (v != 0)
       rel(*this, m(j,i), IRT_EQ, v );
   }
   std::cout << std::endl;
 }
 std::cout << "Setup - row constraints" 
 for(int i=0; i<9; i++)
   distinct(*this, m.row(i));
 std::cout << "Setup - column constraints" 
 for(int i=0; i<9; i++)
   distinct(*this, m.col(i));
 std::cout << "Setup - square constraints"
 for(int i=0; i<9; i+=3)
   for(int j=0; j<9; j+=3)
     distinct(*this, m.slice(i, i+3, j, j+3));

Im ersten Teil wird das Sudoku ausgelesen und als einzelne Constraints in den Solver übernommen:

 rel(*this, m(j,i), IRT_EQ, v );

Sprich: An der Stelle (i,j) des Sudokus muss der Wert v (aus der Problemstellung) stehen. Ähnlich funktioniert auch das Setup der anderen Constraints, wobei hier der Constraint distinct benutzt wird. Das — sehr lesbare — Handbuch zu gecode liefert hier mehr Informationen.

Fazit

Constraint Programming ist IMHO eine sehr interessante und mächtige Technik. Wenn es um Fahrplanplanung oder Raumzuweisungen geht, kann Constraint Programming genau das richtige sein. In meinem kleinen Sudoku-Experiment funktioniert CP sowohl einfach als auch schnell.

Das bedeutet allerdings nicht, das CP für alle Probleme geeignet ist. Hier muss man im Einzelfall entscheiden. Dazu kommt, dass eventuell andere Algorithmen bessere Performance liefern. Wie immer: It depends. Einen Blick ist CP in jedem Fall wert.

Weiterführende Ressourcen

Lustig/Puget, “Program Does Not Equal Program”
Minion ist eine einfache Programmierumgebung für CP.
Gecode Homepage. Das Handbuch ist empfehlenswert.

Photovoltaikanlagen und der Eigenverbrauch

2011-06-13T00:00:00+02:00

Nachtrag 17.06.2011: FBonNET weisst im Photovoltaik-Forum darauf hin, dass die Eigenverbrauchsregelung im §33(2) EEG einen zweistufigen Tarif vorsieht: Falls der Eigenverbrauchsanteil größer als 30% ist, so wird nur der Anteil größer 30% mit dem höheren Vergütungssatz abgerechnet. Das war in meinem ursprünglichem Artikel so nicht beschrieben, dies habe ich angepasst. Ich setze voraus, dass mein Eigenverbrauchsanteil kleiner 30% ist.

Ich verbrauche ja eigentlich recht wenig Strom - mit einer 2,5kWp-Photovoltaikanlage könnte ich quasi meinen Strombedarf in der Jahressumme komplett selbst decken. Dabei hilft natürlich, dass ich kaum daheim bin :-) Allerdings wohne ich zur Miete, und eine eigene Dachfläche ist derzeit kaum in Sicht. Also: Die folgenden Überlegungen sind rein hypothetisch, wenn auch mit realen Daten hinterlegt.

Für den Betrieb einer eigenen PV-Anlage finde ich den Eigenverbrauch besonders interessant, also den Strom meiner (hypothetischen) Photovoltaikanlage direkt im eigenen (realen) Haushalt zu verbrauchen. Aus der Sicht des Stromnetzes macht das durchaus Sinn, denn dann muss weniger Strom durch das Verteilnetz transportiert werden. Das hat auch der Gesetzgeber erkannt und fördert durch eine separate Eigenverbrauchsvergütung den lokalen Verbrauch:

Preiskategorie	ct/kWh
Einspeisevergütung	28.74
Eigenverbrauch < 30 Prozent	12.36
Eigenverbrauch > 30 Prozent	16.74
Strombezug (Lichtblick)	23.64

Alle Angaben in dieser Tabelle beziehen sich auf PV-Installationen kleiner 30 kWp auf Gebäuden, die im ersten Halbjahr 2011 ans Netz gingen (Quelle: Photon Mai 2011, S. 181). Rein rechnerisch gilt also: Entweder, man speist eine kWh Photovoltaik-Strom direkt in das Netz ein und erhält dafür 28.74 Eurocent. Oder man verbraucht die kWh direkt im eigenen Haushalt, was etwas komplizierter ist:

Bei einem Eigenverbrauchsanteil < 30% erhält man 12.36 Eurocent und spart (da man ja keinen Strom bezieht) gleichzeitig 23.64 Eurocent beim Stromkauf. Macht also 36.00 Eurocent.
Verbraucht man auf Jahressicht mehr als 30% seines eigenen Stroms, so ergibt dies 16.74+23.64=40.37 Eurocent für jede Kilowattstunde, die über den 30% liegen. Für den Anteil darunter bleibt es bei 36.00 Eurocent.

Bestimmung des Eigenverbrauchs

Dies gilt natürlich nur, wenn man auch den entsprechenden Stromverbrauch zeitgleich zur Produktion hat. Die folgende Zähleranordnung stellt die entsprechende Erfassung von Bezug, Einspeisung und Produktion sicher:

Oft sind Einspeise- und Bezugszähler auch in einem Zweirichtungszähler integriert. Die Gleichzeitigkeit von Produktion und Eigenverbrauch ist durch diese Anordnung ebenfalls sichergestellt — wenn die PV-Anlage produziert, wird dieser Strom “zuerst” verbraucht. Erst dann wird eventuell notwendige zusätzliche Leistung aus dem Netz entnommen.

Mit diesen drei Messpunkten können nun alle für die Abrechnung relevanten Größen errechnet werden. In meiner Simulation (siehe unten) mache ich folgendes: Für jede Minute wird die Situation im Hausnetz analysiert und daraus die Stromflüsse abgeleitet. Der entsprechende C++-Code sieht so aus:

 for(uint16_t i=0; i<MINS_PER_DAY; i++) {
   netzsaldo[i]=consumption[i]-_production[i];
   einspeisung[i]=std::max(0, -netzsaldo[i]);
   eigenverbrauch[i]=std::min(_production[i], 
       consumption[i]);
   netzbezug[i]=std::max((int16_t) 0, netzsaldo[i]);
 }

Man sieht: Es reicht nicht aus, eine Überschlagsrechnung zu machen. Es kommt darauf an, wann ein Gerät betrieben wird. Am einfachsten versteht man das anhand eines (realen) Beispiels.

Ein ganz normaler Sommertag

Meinen kleinen Simulationscode habe ich dazu benutzt, einmal einen prototypischen Sommertag durchzurechnen. Zunächst einmal: Welche Daten gehen als Eingabe in die Simulation?

Meine (hypothetische) Photovoltaikanlage. Diese Daten sind aus einer (realen) Anlage in der Nachbarschaft abgeleitet und auf 2.5kWp skaliert. Die Tagesproduktion sieht so aus, man kann ein paar Wolken erkennen:
Mein Grundverbrauch. Wie oben bereits angedeutet bin ich oft nicht daheim, insofern ist diese Kurve recht unspektakulär. Morgens mache ich mir einen Cappucino, abends sitze ich am Rechner. Ansonsten sieht man nur meinen Kühlschrank.

Mit diesen Grundannahmen wäre das Modell recht langweilig, denn aufgrund meines geringen Tagesverbrauchs wäre ich nicht in der Lage, einen Eigenverbrauchsanteil > 30% zu erreichen. Ich simuliere daher noch eine Waschmaschine und einen Geschirrspüler. Die Simulation versucht, den Eigenverbrauch zu maximieren, indem sie die Einschaltzeitpunkte der Geräte optimiert. In der Realität wäre allerdings niemand da, der die Geräte dann einschalten kann. Eine Lösung zur Heimautomatisierung wäre in meinem Fall Pflicht.

Was errechnet nun die Simulation? Zunächst einmal ergibt sich nach der Optimierung der Einschaltzeiten folgender Netzsaldo:

Negative Werte stellen hier Einspeisung, positive Werte den Bezug dar. Ein Teil meines Cappuccino-Stroms kann die Photovoltaikanlage liefern, jedoch nicht alles. Auch bei der Waschmaschine, die hier um die Mittagszeit läuft, muss Strom aus dem Netz bezogen werden. Dafür läuft der Geschirrspüler (vor der Waschmaschine) ausschließlich mit dem PV-Strom.

Etwas deutlicher sieht man das auch an dem Eigenverbrauch, sprich: Dem Anteil des PV-Stroms, der direkt im Haushalt verbraucht und mit 12.36 bzw. 16.74 Eurocent vergütet wird:

Trotzdem wäre ich nicht in der Lage, den Strombedarf all meiner Geräte aus der PV-Anlage zu decken. Folgende Leistung wird aus dem Netz bezogen:

Fazit

Inwiefern diese Simulation einen typischen Tag darstellt, kann ich momentan nicht genau belegen. Ich halte das Szenario jedoch für realistisch (mehr Statistik wäre notwendig, um das auch zu belegen).

Die Eckpunkte der Simulation:

Die PV-Anlage produziert 14,1909kWh. Bei direkter Einspeisung und einer Einspeisevergütung von 28,74 Eurocent würde die Anlage an diesem Tag 4,01744 Euro erwirtschaften. Gleichzeitig muss aus dem Stromnetz natürlich noch Strom für den Betrieb der Geräte gekauft werden: 7,67198kWh, macht -1,81366 Euro. Das Gesamtsaldo ist also 2,20379 Euro.
Für die Eigenverbrauchsoptimierung ergibt sich folgendes Szenario: Der Geschirrspüler wird um 10:15, die Waschmaschine gegen 12:20 eingeschaltet. Das sind jeweils die optimalen Einschaltzeiten, bei denen der Eigenverbrauchsanteil maximal ist. Die Einspeisung beträgt 8,7552kWh, dies entspricht 2,4786 Euro. Der Eigenverbrauch beträgt 5,4357kWh und wird mit 0,671853 Euro vergütet. Um den restlichen Strombedarf des Haushalts zu decken, müssen 2,23628kWh aus dem Netz bezogen werden, entspricht -0,528657 Euro. Das Gesamtsaldo beträgt also 2,62179 Euro. Wenn der Eigenverbrauch über das gesamte Jahr über 30% liegen würde, dann wäre die Vergütung nochmal höher.

Der Eigenverbrauch würde sich in diesem Szenario also knapp rechnen: Rund 41,8 Eurocent Mehrertrag würden sich realisieren lassen. Dem gegenüber stehen allerdings Investitionen in zusätzliches Zählerequipment. Ebenso unberücksichtigt sind Investitionen in ein Hausbussystem und eine Optimierung, welche die Einschaltzeitpunkte der Haushaltsgeräte optimiert.

Zusammenfassend lässt sich sagen, dass eine Diskussion über die Nutzung der Eigenverbrauchsregelung nur Sinn macht, wenn auch die Verbrauchsmöglichkeiten des PV-Stroms mit einbezogen werden. Auf der Intersolar 2011 war ich etwas verwundert, dass dieser Aspekt in vielen Gesprächen untergegangen ist. Bei anderen Stromverbrauchscharakteristiken kann die Rechnung auch anders aussehen, dies ist im Zweifelsfall nochmal separat zu simulieren. Wer mittags elektrisch kocht, dürfte auch andere Freiheitsgrade bei der Optimierung haben.

Was ein erschwingliches Hausbussystem anbelangt: Daran arbeite ich gerade im Projekt mySmartGrid. Auch die Eigenverbrauchsoptimierung ist Gegenstand der Arbeit meines Kollegen Matthias Klein. Stay tuned.

PID FTW!

2011-04-14T00:00:00+02:00

Silvia fühlt sich mittlererweile ganz wohl bei mir. Manchmal ist sie eine Zicke, aber die Qualität meines Cappuccinos scheint immer weniger mit der Anzahl der schwarzen Katzen im Stadtteil zu korrelieren. Wenn der Cappuccino nicht schmeckt, hab ich einen Fehler gemacht — so einfach ist das. Und auch Spinnen finden Silvia toll:

Das heisst aber nicht, dass es in Sachen Cappuccino nicht noch technische Weiterentwicklungen geben würde. Bis vor drei Wochen lief der PID-Controller, der die normale Temperaturregelung der Silvia ersetzt hat, nur als einfacher P-Controller, sprich: Da fehlte noch das komplette Feintuning. Der Hintergrund: Ich war mit dem Bare Bones Coffee Controller nicht wirklich zufrieden, der Code war nicht schön. Daher stand also eine Neuimplementation an. Gesagt, getan: Im ChaosCoffeeControl-Repository gibt es nun einen development-Branch, in dem der neue Code liegt. Einzig das Senden des DTR-Signals, um den µC neu zu starten und so über den Bootloader zu programmieren, ist noch etwas häßlich. Aber irgendwas ist ja immer.

Der PID-Algorithmus

Der PID-Algorithmus war dann auch recht schnell implementiert. Der Kern sieht so aus:

float curTemp=getTemperatureFloat();
float error = _pid_data.setpoint - curTemp;
_p_term = _pid_data.p_gain * error;
// iState keeps changing over time; it's overall 
// "performance" over time, or accumulated error
_iState += error;
// Use a static windup guard to keep the balance 
// of the istate.
if (_iState > WINDUP_GUARD) 
  _iState = WINDUP_GUARD;
else if (_iState < -WINDUP_GUARD) 
  _iState = -WINDUP_GUARD;
_i_term = _pid_data.i_gain * _iState;
// the dTerm, the difference between the temperature 
// now and our last reading, indicated the "speed," 
// how quickly the temp is changing. 
_d_term = (_pid_data.d_gain * (curTemp - _last_temp));
// now that we've use lastTemp, put the current temp 
// in our pocket until for the next round
_last_temp = curTemp;
// the magic feedback bit
_pid_value = _p_term + _i_term - _d_term;

Als ich dann von dem einfachen P-Regler auf den PID-Algorithmus umstellen wollte, funktionierte zunächst alles prima. Nach etwas Parameter-Raten war die Kombination P=60, I=0.48 und D=1800 recht brauchbar. Um die zu ermitteln habe ich den Regler zunächst als reinen P-Regler betrieben und P langsam erhöht. Bei P=100 schwingt das System, und zwar mit einer Periode von 250 Sekunden. Die Einstellregeln von Ziegler-Nichols ergeben dann die Parameter oben. Ich hab hierfür folgendes R-Skript benutzt:

K_P_krit<-100
T_krit<-250

print(paste("Estimation of PID controller ",
      "parameters for K_pkrit=",
      K_P_krit, " and T_krit=", T_krit));

K_P<-0.6*K_P_krit
T_N<-0.5*T_krit
T_V<-0.12*T_krit
K_I<-K_P/T_N
K_D<-K_P*T_V

print(paste("K_P: ", K_P));
print(paste("K_I: ", K_I));
print(paste("K_D: ", K_D));

Danach zeigt der Regler ein sehr stabiles Temperaturverhalten:

Klasse, denke ich mir, mahle Kaffee und will mir einen Cappuccino machen. Leider ist nach der Betätigung der Pumpe auf einmal der Mikrocontroller tot. WTF?

EMV — nicht witzig

Ich bin dann erst einmal für zwei Tage zurück zur Senseo-Kaffeemaschine. Es stellte sich heraus, dass die Pumpe massive Einstrahlungen in die Schaltung liefert. Da ein Atmel-Mikrocontroller Überspannungen an der Resetleitung als Aufforderung zur Hochvolt-Programmierung versteht, hat er sich quasi beim Anschalten der Pumpe selbst gelöscht.

Also die Platine mit diversen Dioden und Kondensatoren ausgestattet. Der Schaltplan sieht nun so aus (großes PDF):

Danach lief die Maschine zumindest meistens. Irgendwo kommen immer noch Störungen rein, aber der Mikrocontroller resettet sich nur und startet dann wieder. Das ist unbefriedigend, wenn man Geräte an den USB-Port anschließen will:

Das Loch habe ich mit einer Lochstanze in die Rückwand der Silvia gestanzt. Der USB-Port ist von Neutrik und setzt auf der Innenseite auf eine USB-A-Buchse um. Ein USB-Kabel verbindet dann die Neutrik-Buchse mit dem Mikrocontroller.

Meine erste Maßnahme war das Schirmen der Kabel, die direkt an die Platine führen. Das hat allerdings nicht ausgereicht. Als nächstes habe ich zwischen Platine und Magnetventil eine Schirmung aus Alufolie angebracht — ebenso ohne Erfolg. Letztlich hat dann ein Entstörfilter (LC-Glied) direkt an der Pumpe funktioniert:

Silvia sieht nun innen so aus:

Der EMV-Filter ist im Vordergrund zu erkennen. Ausserdem sind alle Kabel in einen schwarzen, temperaturbeständigen EMV-Schutzschlauch eingepackt. Der Lohn der Mühe: Die Kaffeemaschine läuft nun störungsfrei, der Schaltplan ist vollständig. Schließt man einen Rechner via USB an, kann man Temperatur etc. in einer Konsole einstellen:

C8H10N4O2 menu
Press 'x' to leave, '?' for help
 b: print PID configuration
 o: toggle PID debug output
 +/-: increase/decrease adjustment delta, 
      current delta: 1.00000
 p/P: increase/decrease p gain
 i/I: increase/decrease i gain
 d/D: increase/decrease d gain
 r: reset PID configuration to default values
 s: save PID configuration to EEPROM
Current PID controller configuration:
 - temperature setpoint: 102.00000
 - P gain: 60.00000, I gain: 0.48000, 
   D gain: 1800.00000

Und nun?

Mögliche Erweiterungen in der Zukunft:

Ein automatischer Bezugstaster
Ein Durchflussmesser
Twitter-Anschluss

Stay tuned.

Das Leben ist zu kurz für schlechten Kaffee

2010-12-12T00:00:00+01:00

Nachdem die Morphy Richards nicht wirklich temperaturstabil war, musste eine Alternative her. Vor allem der Thread ”Silvia, mein Eisenschwein... öfföff” hat dann in der Folge zu kleineren eBay-Ausflügen geführt. Das Resultat ist eine gebrauchte Rancilio Silvia Modell 2009, sehr guter Zustand, und gar nicht teuer (ähem).

Die Espressomaschine ist technisch sehr einfach: Temperaturregelung über Thermostate (mit entsprechender Hysterese) und ansonsten nur ein paar Schalter, Kabel, Magnetventil und Pumpe. Simpel, dabei aber mit einem massiven Messingkessel und solider Verarbeitung ausgerüstet. Da die Maschine von vielen Leuten schon modifiziert wurde, ist sie eine ideale Basis für eigene Experimente. Noch bevor die Maschine da war hab ich mir zusätzliche Silikonkabel und Solid-State Relais geordert, um in diversen Basteltagen einen PID-Regler selbst einzubauen.

Zunächst muss jedoch der Status Quo dokumentiert werden. Also wie schon bei der Morphy Richards einen Temperatursensor auf den Tank geklebt und losgemessen:

Nach dem Aufheizen sieht man deutlich die Hysterese, verursacht durch die einfache Thermostatregelung. Die Temperatur pendelt zwischen 87°C und 109°C:

Beim Bezug schwankt die Temperatur ebenso. Im folgenden Bild habe ich bei ca. 105°C Kesseltemperatur den Bezug gestartet (erster Strich). Danach hab ich direkt auf Dampfbetrieb umgeschaltet und Milch aufgeschäumt. Der Sensor clippt jedoch bei 127°C:

Zusammenfassend kann man sagen, dass das Temperaturverhalten der Silvia im Originalzustand nicht wirklich prickelnd ist. Durch Temperatursurfen und andere Tricks kann man zwar die Temperatur beim Bezug in recht engen Grenzen halten, aber das ist nicht wirklich praxistauglich. Diverse Hersteller bieten daher einen PID-Regler speziell für diese Maschine als Umrüstsatz an. Keiner dieser Regler ist wirklich ein Open Source-Produkt — uncool, wenn man damit basteln möchte.

DIY PID-Regler

Also selbst einen Regler entwerfen. Die Reglersoftware basiert momentan noch auf dem Bare Bones Coffee Controller, einem Arduino-basierten PID. Ich habe einen anderen Temperatursensor, nämlich den DS18S20, verwendet — insofern habe ich den Code entsprechend angepasst. Darüber hinaus gibt es momentan die ersten Anfänge einer Autotuning-Routine, doch darüber später mehr.

Nachdem die grobe Richtung für die Software feststand ging es an die Hardware. Der Schaltplan V0.1 sieht so aus (aufs Bild klicken für eine PDF-Version):

Im Prinzip ist die Schaltung ein kleiner Arduino, der zusammen mit einem FTDI TTL-USB-Konverter mit der Aussenwelt kommunizieren kann. Am Arduino Pin 9 hängt ein SSR, welches das Heizelement im Kessel schaltet. Der Onewire-Bus für den Temperatursensor ist an Arduino Pin 7 angeschlossen. Auf Lochraster aufgebaut sieht die Schaltung so aus:

Ich habe wenig Lust, die Maschine bei jedem Softwareupdate auseinander zu bauen, daher muss der Mikrocontroller einen Bootloader haben. Praktischerweise bringt Arduino gleich einen mit. Dieser kann direkt aus der Arduino-GUI über einen ISP-Programmer auf den Chip kopiert werden. Leider kennt die Arduino-GUI meinen geliebten USBasp-Programmer jedoch nicht. Die Abhilfe findet sich nach kurzer Recherche im Internetz: Einfach die folgenden Zeilen in die “programmer.txt” im Verzeichnis “hardware” der Arduino-Installation hinzufügen:

usbasp.name=USBasp
usbasp.communication=usb
usbasp.protocol=usbasp

Danach bietet die Arduino-GUI auch ein Flashen über meinen Programmer an. Den Mikrocontroller also in mein Pollin-Board gesteckt, programmiert und wieder zurück auf die Lochraster-Platine. Fortan kann der Mikrocontroller über USB programmiert werden.

Bleibt noch die Frage, wie der Mikrocontroller mit Strom versorgt werden kann. Einen Trafo in das Gehäuse zu setzen wäre zwar eine Möglichkeit, erscheint mir jedoch aufgrund der offenen Verkabelung etwas unsicher. Daher habe ich ein kleines Steckernetzteil mit einer Eurobuchse in selbstverschweissendes Klebeband eingepackt und mit Silikonkabeln versehen:

Diese Variante hat zusätzlich den Vorteil, ziemlich kompakt zu sein.

Einbau

Zuerst musste ich die Halterung für die Pumpe drehen und einen kleinen Halter installieren, um genug Platz für meine Stromversorgung zu haben. Das Netzteil liegt dabei nicht auf dem Boden der Maschine auf - selbst wenn sich dort Wasser sammelt, sollte das Netzteil trocken bleiben:

Die Versorgungsspannung für das Netzteil greife ich direkt hinter dem Hauptschalter der Silvia ab:

Die Kabelschuhe habe ich nach dem Foto nochmal separat isoliert. Die Lochrasterplatine wird mit Distanzhülsen am Träger der Maschine befestigt:

Unter der Platine ist nun auch das Netzteil installiert. Die weisse Folie hinter der Platine ist Overheadfolie, welche eine Lücke in der Rückwand wasserdicht verschliesst. Das Solid State Relay (SSR) findet seinen Platz auf der anderen Seite der Trennwand, ähnlich wie bei den Auber-PIDs:

Es ist wie das Netzteil mit Silikonkabeln sowohl mit der Kesselheizung als auch mit dem Mikrocontroller verbunden. Die Anschlüsse sind so gewählt, dass das SSR den 100°C-Thermostaten ersetzt. Für Dampf etc. wird also nach wie vor der andere Thermostat benutzt. Auch der Sicherheitsthermostat am Kessel behält seine Funktion.

Abschliessend noch ein Foto von der Seite: Alles passt unter die Abdeckung für den Wassertank. Sollte also hier einmal Wasser von oben eindringen, so sind alle Komponenten davor geschützt.

Der Lohn der Mühe

Nach diversen kleineren Softwareanpassungen läuft das System nun. Allerdings ist der PID-Regler noch nicht kallibriert - im Moment sind die I- und D-Komponenten ausgeschaltet. Wie vorher auch habe ich das Heizverhalten über den Temperatursensor aufgezeichnet und ausgewertet. Da nun der Temperatursensor am PID hängt, muss die Aufzeichnung direkt aus den Logausgaben des PIDs erfolgen. Dazu zunächst einmal die Konfiguration des seriellen Devices prüfen:

 $ stty -f /dev/cu.usbserial-A600e1dh 
 speed 9600 baud;
 lflags: -icanon -isig -iexten -echo
 iflags: -icrnl -ixon -ixany -imaxbel -brkint
 oflags: -opost -onlcr -oxtabs
 cflags: cs8 -parenb

Wenn alles passt kann die Aufnahme gestartet werden:

 $ cat /dev/cu.usbserial-A600e1dh | tee run1.txt

Dort zeigt sich jedoch nur das Menü, welches der PID normalerweise über die serielle Konsole ausgibt. Um automatische Updates zu erhalten, muss ein “u” an den PID gesandt werden:

 $ echo "u\n" > /dev/cu.usbserial-A600e1dh

Der Temperaturverlauf nach dem Aufheizen hat schon eine ganz andere Form:

Der Sollwert liegt bei 104°C. Wenn Silvia aufgeheizt ist, wird die Temperatur in einem Korridor zwischen 103°C und 105.5°C gehalten — entspricht einer Hysterese von 2.5°C. Verglichen mit der alten Hysterese von 22°C wesentlich besser, vor allem, wenn man in Betracht zieht, das hier nur ein P-Regler arbeitet. Das macht sich leider bemerkbar, wenn kaltes Wasser in den Kessel einströmt. Testweise habe ich die Temperatur im Siebträger gemessen:

Jeweils bei den vertikalen Markierungen habe ich einen Bezug simuliert. Die gute Nachricht: Bei allen Bezügen liegt die Temperatur bei 96°C, d.h. die korrekte Temperatur liegt an. Die schlechte Nachricht: Die Temperatur im Kessel sinkt stark ab. Ausserdem überschwingt die Temperatur im Anschluss auch relativ stark. Diese Phänomene sollten jedoch durch einen vollen PID-Regler abgemildert werden. Die Temperaturmessung im Siebträger macht ein Type K-Thermocouple, angeschlossen an ein Multimeter:

Probleme

Noch ist das Projekt nicht abgeschlossen, denn es gibt noch viel zu tun:

Der PID-Algorithmus braucht Feintuning. Die Autotuning-Routine funktioniert so nicht, hier gibt es noch etwas Arbeit. Dann gehören die Überschwinger aber hoffentlich der Vergangenheit an.
Der Controller resettet sich manchmal nach dem Bezug. Ich gehe davon aus, dass durch das Abschalten der Pumpe und des Magnetventils ein paar Störungen den Reset auslösen. Mehr Kondensatoren in der Spannungsversorgung sollten helfen.
Das USB-Kabel muss verschwinden und wird durch eine Neutrik USB-Buchse nach aussen geführt.
Ich mag den Arduino-Code nicht. Hier steht noch ein Rewrite in puren, AVR-GCC-kompatiblen Code an.
Ein anderes Userinterface als mein Laptop. Der steht meistens nicht neben der Kaffeemaschine. Ausserdem soll die Bedienung die Optik der Silvia nicht zerstören.

Mein momentaner Zwischenstand liegt auch bei github im ChaosCoffeeControl-Repository. Stay tuned.

Morphy Richards auf dem Prüfstand

2010-11-21T00:00:00+01:00

Guter Espresso heisst: Richtige Temperatur. OK, noch viele andere Dinge, aber die Temperatur hat einen erheblichen Einfluss darauf, wie gut das Aroma der Kaffeebohne extrahiert wird. Wenn natürlich der Kaffee schon schlecht ist, kann auch kein guter Espresso herauskommen.

Stellt sich also die Frage: Wie verhält sich mein 30 Euro eBay-Schnäppchen in dieser Disziplin? Die Morphy Richards 47507 ist eine kleine Thermoblockmaschine, d.h. sie enthält keinen Kessel, sondern heizt über einen Thermoblock das Wasser direkt auf. Das Verfahren ähnelt einem Durchlauferhitzer. Der Vorteil dieser Technik ist die geringe Vorheizzeit. Dafür hat die Technik aber den Nachteil, dass die Temperatur des Brühwassers relativ stark schwankt.

Nach einem kurzen Blick auf meine Werkbank steht die Wahl des Materials auch fest: Ein DS18S20, kombiniert mit einem Arduino-Klon. Der DS1820 ist ein One-Wire Temperatursensor mit einer Genauigkeit von 0.5°C. Ein einfacher Arduino-Sketch zum Auslesen ist auch schnell gefunden. Das Ganze war schnell zusammengelötet und mit Sugru am Thermoblock befestigt:

Dabei natürlich etwas Wärmeleitpaste auf den Sensor, damit eventuelle Luftspalte die Wärmeübertragung nicht behindern können.

Die Messungen

Das Sugru muss über Nacht aushärten. Heute hab ich dann eine kleine Messung gemacht. Der DS1820 kann Temperaturen bis 125°C messen - während der Dampfphase reicht das leider nicht aus. Eigentlich schade, denn die Sensoren sind genau und einfach in der Anwendung. Sugru ist übrigens bis 165°C stabil, also bestens als Montagematerial in Kaffeemaschinen geeignet. Der Temperaturverlauf sieht so aus:

Die horizontale Linie markiert 95°C, also quasi die Idealtemperatur. Während der initialen Heizphase schwankt die Temperatur zwischen 85°C und 104.5 ° C:

Das ist natürlich relativ weit von der optimalen Brüh-Temperatur entfernt. Eine Rancilio Silvia hat ein ähnliches Problem, dem man jedoch mit Hilfe eines PID-Reglers abhelfen kann. Bei der Zubereitung eines Cappucinos tritt folgender Verlauf auf:

Beim ersten vertikalen Strich (T=2300) hab ich einen Leerbezug gemacht. Die Temperatur sinkt daraufhin doch recht stark. Bei T=2475 hab ich dann den Bezug gestartet, also 175 Sekunden (knapp 3 Minuten) nach dem Leerbezug. Die Temperatur war noch etwas zu gering. Bei T=2615 habe ich dann auf Dampf umgeschaltet, die Heizleuchte ging bei T=2576 wieder aus. Die Temperatur war trotzdem zu gering, als ich bei T=2615 den Dampfhahn aufdrehte — da kam nur ein warmes Lüftchen aus der Dampflanze. Die Temperatur im Thermoblock steigt allerdings weiter - bei 127°C clippt der Sensor, die Temperatur war denke ich aber deutlich über 130°C.

Der Espresso war übrigens akzeptabel. Unbewusst habe ich quasi Temperatursurfen betrieben. In Zukunft werde ich nach dem Leerbezug einfach drei Minuten warten, dann sollte die Temperatur relativ nahe bei 95°C sein.

Alternativ dazu könnte ich natürlich auch einen PID-Regler nachrüsten - aber der Aufwand lohnt sich für die kleine Maschine nicht. Das mache ich dann nach dem nächsten Upgrade ;-)

Materialien

Der Arduino-Sketch zum Auswerten des DS1820
Das R-Script zur Erzeugung der Plots
Die Messwerte
Für die Zukunft: Bare Bones Coffee Controller, eine PID-Regelung auf der Basis eines Arduinos.
Recht ähnliche Herangehensweise: The PID Project — hab ich allerdings erst später gefunden.

Smart Meter-Datenkabel selbst gemacht: libehz

2010-10-24T00:00:00+02:00

Hinweis 13.06.2011: Die in diesem Artikel beschriebene Schaltung funktioniert sehr gut mit Zählern von Hager. Andere Zähler (z.B. der Fa. Easymeter) liefern jedoch nur ein sehr schwaches Signal, sodass die Schaltung hier versagt. Dominik Keller, einer meiner Studenten, arbeitet an einer verbesserten Schaltung. Seinen aktuellen Zwischenstand hat er hier dokumentiert: Optoreader im mySmartGrid Developer Wiki. Wir werden — sobald die Schaltung fertig gestellt ist — einen Bausatz anbieten.

Mit Smart Metern sollen Stromkunden Ihren Stromverbrauch genauer kontrollieren können. Aber: Wer geht schon regelmäßig in den Keller, um seinen Stromzähler abzulesen? Der elektronische Haushaltszähler (eHZ), in Deutschland durch den VDE definiert und bei diversen Herstellern zu beziehen, schreibt eine Infrarotschnittstelle für den Stromkunden vor. Dort sollen beliebige Geräte den Momentanverbrauch, den Zählerstand und andere Informationen auslesen können.

Das Problem dabei: Die optischen Ausleseköpfe (z.B. von PE Technik) sind ziemlich teuer, die Preise für einzelne Geräte schwanken zwischen 100 und 300 Euro. Für eine simple serielle Schnittstelle ein stolzer Preis!

Also: Selbst ist der Mann. Meine ersten Experimente mit einem TSOP-1738 scheiterten. Dieser Standardbaustein empfängt Infrarotsignale im Bereich 880nm und wird normalerweise in Infrarotfernbedienungen eingesetzt. Dafür ist er auch optimiert: Ein integrierter Bandpass filtert eingehende Signale. Dazu erwartet der Baustein alle Signale aufmoduliert auf einen Träger von 38kHz — normalerweise um Sonnenstrahlen von “echten” Fernbedienungssignalen zu unterscheiden. Ich konnte damit zwar Signale im Oszilloskop sehen, aber diese waren im Wesentlichen Binärabfall. Also: 880nm scheint zu funktionieren, der TSOP-1738 kann allerdings nur bis zu 2400 Baud übertragen. Der von mir verwendete eHZ von Hager sendet laut Datenblatt aber mit 9600 Baud. Der Binärabfall kommt also durch eine zu geringe Samplingrate zustande.

DIY-Empfänger

Mit einer Infrarotdiode vom Typ BPW82 funktioniert der Empfang allerdings prima. Im Oszilloskop erkennt man, das die Diode in Kombination mit einem Spannungsteiler ein Signal mit ca. 0.7V zwischen logisch LOW und HIGH ausgibt. Das Signal ist die obere, gelbe Linie in folgendem Screenshot:

Das reicht leider noch nicht aus, um via TTL-USB-Konverter ausgelesen zu werden. In einer nächtlichen Hackaktion mit eBrnd und ‘ (vielen Dank an die Beiden!) entstand die folgende Transistorschaltung:

Damit wird der Pegel auf ein akzeptables Niveau gebracht und zudem noch das Signal geschärft. Im Oszilloskop-Screenshot oben ist die untere, grüne Linie das aufbereitete Signal. Auf Lochraster aufgebaut sieht die Schaltung (ohne TTL-USB-Adapter) so aus:

Rechts erkennt man die Infrarotdiode, eingebettet in ein Stück Schaumstoff und professionell festgeklebt™. Der Schaumstoff hält die Diode an der richtigen Stelle direkt über der Sendediode des eHZ. Gleichzeitig wird Infrarotlicht aus der Umgebung abgeschirmt. Ich hatte bis jetzt keine Probleme mit Umgebungslicht.

Die Daten

Mit einem USB-TTL-Adapter kann man sich nun den Klartext in einer Terminal anschauen. Ich verwende dafür einen Kermit mit folgenden Einstellungen (in der .kermrc, 9600 7N1):

 SET LINE /dev/cu.SLAB_USBtoUART
 SET SPEED 9600
 SET COMMAND BYTESIZE 7
 SET PARITY NONE
 SET STOP 1
 SET CARRIER-WATCH OFF

Der eHZ gibt die folgenden Werte alle 1-4 Sekunden (abhängig von der Last am Zähler) aus:

 /HAG5eHZ010C_EHZ1vA02
 
 1-0:0.0.0*255(1095100000067865)
 1-0:1.8.0*255(000001.2963)
 1-0:96.5.5*255(82)
 0-0:96.1.255*255(0000067865)
 1-0:52.7.0*255(228.38*V)
 1-0:51.7.0*255(000.16*A)
 1-0:41.7.0*255(+00026*W)
 1-0:96.50.0*0(45)
 1-0:96.50.0*1(07D0)
 1-0:96.50.0*2(16)
 1-0:96.50.0*3(11)
 1-0:96.50.0*4(1F)
 1-0:96.50.0*5(18)
 1-0:96.50.0*6(003D381B070AF6B0CF05140900009F80)
 1-0:96.50.0*7(00)
 !

Die Daten sind jeweils mit einer OBIS-Kennzahl versehen. Die Wirkleistung auf L2 hat z.B. die Kennzahl „1-0:41.7.0” und den Wert 26W. Nun fehlt noch eine kleine C++-Applikation, welche die Datagramme auswertet und sauber zugänglich macht.

C++-Client für den eHZ

Einen minimalen Client in C++ gibt es nun schon einmal im Repository auf Github.. Im Moment funktioniert der Client auf meinem Mac, allerdings sollte er auf jeder Plattform mit termios-Support laufen (also auch Linux). Mit einem einfachen

 ehzread /dev/cu.SLAB_USBtoUART

gibt der Client die Datagramme des eHZ auf der Konsole aus. Der Sourcecode ist recht simpel. Im Wesentlichen wird ein Filedesktriptor (tty_fd) an das Terminal-Device gebunden:

 // 7n1, see termios.h for more information
 memset(&tio,0,sizeof(tio));
 tio.c_iflag=0;
 tio.c_oflag=0;
 tio.c_cflag=CS7|CREAD|CLOCAL;           
 tio.c_lflag=0;
 tio.c_cc[VMIN]=1;
 tio.c_cc[VTIME]=5;
 
 tty_fd=open(argv[1], O_RDWR | O_NONBLOCK);      
 cfsetospeed(&tio,B9600);            // 9600 baud
 cfsetispeed(&tio,B9600);            // 9600 baud

In einer Endlosschleife liest der Client dann von tty_fd und gibt die Zeichen auf der Konsole aus. Hier kann dann ein Parser ansetzen.

Hilfreiche Ressourcen

In Deutschland hat der VDE in zwei Lastenheften die Anforderungen an Smart Meter definiert: Lastenhefte EDL und eHZ beim FNN
Vishay BPW82 Datasheet
Betriebsanleitung des Wechselstromzählers EHZ161WA von Hager: Hier ist der Aufbau der Datentelegramme und die Kommunikationsparameter beschrieben.
Beschreibung des IEC 62056-21 Datenformats
Wikibook: Serial Programming
PCRE-CPP: Beispiel auf stackoverflow.com

Webserver Performance

2010-10-10T00:00:00+02:00

Since I now have a shiny new blog, I was curious how the runtime behaviour (loading times etc.) improved. As a first indicator, I use the developer tools included in Webkit (via Google’s Chrome):

	html	style	image	font	total
old blog	439 ms	317 ms	430 ms	210 ms	1.5 s
new blog	112 ms	61 ms	39 ms	56 ms	195 s

As you can see, the new (static) website performs much better than the old (wordpress-based) one. Both pages were served from my Linux server, over the internet. I am currently sitting at the local university which has a decent internet connection, so it is safe to assume that the internet connectivity does not influence the measurements significantly.

Apache Benchmark

For a real world benchmark, I assume 5 clients to access the site concurrently. Of course this does not reflect a Slashdotting, but I want to see the impact of PHP page creation vs. static pages. Apache provides a nifty tool for running such benchmarks, called ab. The ab command simulates a number of clients and measures the response times of a webserver. By default, ab prints a short statistic summary, but does not output the page load time by request. The parameter “-g” dumps these times in a file:

 $ ab -n 1000 -c 5 -g oldblog.txt $URL

Please note that the ab tool does not evaluate the HTML file, so included pictures and CSS files are not loaded. Therefore I measure my webserver, the PHP blog software, and the SQL database in combination. I used the ggplot2 package in GNU R to generate some graphs:

 require(ggplot2);
 old<-read.table("oldblog.txt", header <- TRUE);
 png(filename = "old-hist.png", width = 480,\
   height = 400);
 qplot(ttime, data=old, geom="histogram",\
   binwidth=25) + scale_x_continuous("Load time (ms)")\
   + opts(title="Old Blog");
 dev.off();

My old blog suffers from the PHP page generation. The median of the turnaround times is 724ms, slightly higher than the value measured with just one browser. This is a clear indicator that the webserver is already saturated. Another sign of saturation is the long tail of up to 4.7s.

The plot of the new blog looks rather uninteresting. The site is much faster — a single page is delivered in 38ms (median), with a maximum of 163ms. The server does not seem to be saturated by the 5 simulated clients.

To push my little virtual server to the limits, I increased the number of concurrently simulated clients from 5 to 250. The median of the turnaround time is now 824ms, with a maximum of 7.1s.

In other words: static websites rock, they’re fast and secure. No more wordpress security updates for me.

Jekyll for the Rescue

2010-10-03T00:00:00+02:00

I am tired of Wordpress. Don’t get me wrong, Wordpress is a really powerful blogging engine. But do I really need to have a complex software to do my occasional blogging? Whenever I need to do something that is not built directly into Wordpress, I start hunting for a plugin that does the trick. Then I fiddle it into my template, and during the next security upgrade, everything breaks. The consequence: I don’t update my Wordpress installation often, which is a really bad idea. Most compromised webservers have been opened using the web applications they serve.

In the early days I wrote a small generator that took a bunch of scripts that generated a static site and uploaded it to a simple webspace. Although simple, it worked great and did not require any scripting language or database on the server side. Now, I am going back to it.

Meet Jekyll

Jekyll is a static site generator written in Ruby by Tom Preston-Werner, co-founder of github.com. In “Blogging Like a Hacker” he introduces the system. I write this text in vim. Then, jekyll takes the text (formatted in Markdown syntax) and renders the website, using various template files. The tags are stored as properties associated with each post. When I create the website using a Rakefile, a task collects all tags, builds index pages and creates the tag cloud. In addition, the list of blog entries is updated and formatted. Everything is nice and simple. An integrated Webrick server allows me to check how the page looks in a web browser.

This is the first time in years that I actually care about the look of a website. Since jekyll does not provide a default layout, I wrote one from scratch and learned a lot along the way. The layout is implemented using the Blueprint framework. The font (“Vollkorn”) is provided by Google. I used Adobe’s Kuler to select the colors. Surprisingly, this was much simpler than to fiddle with various Wordpress templates.

The cool thing is that I can store the whole website in a git repository (its just text, after all) and use rsync to push it onto my server. No dynamic components are needed. One disadvantage is that I don’t have comments yet, but I’ve seen people integrating Disqus, so it can be done.

Helpful links

What follows is a collection of links that were helping me to understand Jekyll and CSS:

The image has been CC’ed by B Tal, thanks!

Mathias Dalheimer

Warum ACTA eher so meh ist.

Fotos aus Disneyland

Privatunternehmen zensieren

The Coming War on General Computation

Constraint Programming und Sudokus: 20ms

Was ist Constraint Programming?

Sudoku als CSP

Fazit

Weiterführende Ressourcen

Photovoltaikanlagen und der Eigenverbrauch

Bestimmung des Eigenverbrauchs

Ein ganz normaler Sommertag

Fazit

PID FTW!

Der PID-Algorithmus

EMV — nicht witzig

Und nun?

Das Leben ist zu kurz für schlechten Kaffee

DIY PID-Regler

Einbau

Der Lohn der Mühe

Probleme

Morphy Richards auf dem Prüfstand

Die Messungen

Materialien

Smart Meter-Datenkabel selbst gemacht: libehz

DIY-Empfänger

Die Daten

C++-Client für den eHZ

Hilfreiche Ressourcen

Webserver Performance

Apache Benchmark

Related Links

Jekyll for the Rescue

Meet Jekyll

Helpful links