vzlogger/misc/docs/manual.lyx
2011-02-11 21:59:59 +01:00

657 lines
15 KiB
Text

#LyX 1.6.7 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
\textclass paper
\use_default_options true
\language ngerman
\inputencoding auto
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize default
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered true
\pdf_bookmarksopen true
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder true
\pdf_colorlinks true
\pdf_backref false
\pdf_pdfusetitle true
\papersize a4paper
\use_geometry false
\use_amsmath 1
\use_esint 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author ""
\author ""
\end_header
\begin_body
\begin_layout Title
volkszaehler.org
\end_layout
\begin_layout SubTitle
the open smartmetering platform
\end_layout
\begin_layout Standard
\align right
\begin_inset Graphics
filename /home/stv0g/workspace/volkszaehler.org/misc/graphics/logo.png
lyxscale 50
scale 20
\end_inset
\end_layout
\begin_layout Author
Steffen Vogel
\end_layout
\begin_layout Abstract
volkszaehler.org ist ein freier Smart Meter im Selbstbau.
Die anfallenden Stromprofile bleiben dabei unter der Kontrolle des Nutzers.
\end_layout
\begin_layout Abstract
Seit dem 1.1.2010 müssen Stromversorger ihren Kunden für Neubauten so genannte
"intelligente Stromzähler" (Smart Meter) anbieten.
Der Kunde soll dadurch seinen Stromverbrauch analysieren und optimieren
können.
\end_layout
\begin_layout Abstract
Das dabei anfallende Stromverbrauchsprofil erlaubt einen sehr detallierten
Einblick in den Tagesablauf des Nutzers (wann steht er auf? wann geht er
in's Bett? wann kocht er? wie oft verwendet er seine Spülmaschine? verändert
sich sein Verhalten? ...).
\end_layout
\begin_layout Abstract
Darum sollten diese Daten ausschließlich für den Nutzer selbst zur Verfügung
stehen - und das geht nur, wenn man sich den Smart Meter selbst baut.
Mit einem Materialeinsatz von ca.
100 €, etwas Geschick und Zeit lässt sich das mit Hilfe eines Standard-µC-Modul
s aufbauen.
\end_layout
\begin_layout Standard
\begin_inset Newpage pagebreak
\end_inset
\end_layout
\begin_layout Standard
\begin_inset CommandInset toc
LatexCommand tableofcontents
\end_inset
\begin_inset Newpage pagebreak
\end_inset
\end_layout
\begin_layout Section
Einführung
\end_layout
\begin_layout Standard
In diesem Artikel werden wir das Projekt vorstellen, einen generellen Überblick
über die einzellnen Kompontenten geben und auf die Implementierung eingehen.
Ich möchte damit den Einstieg in das Projekt erleichtern und neue Entwickler
motivieren sich zu beteiligen.
\end_layout
\begin_layout Standard
Einzellheiten zur Installation/Konfiguration eines eigenen volkszaehler.org
Setups finden Sie unsere Mailingliste
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
volkszaehler-dev@lists.volkszaehler.org
\end_layout
\end_inset
und im Wiki
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
http://wiki.volkszaehler.org
\end_layout
\end_inset
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset VSpace defskip
\end_inset
Neben dem
\series bold
Schutz der Privatsphäre
\series default
, hat das Projekt auch noch einige andere Ziele:
\end_layout
\begin_layout Itemize
eine kostenfreie Alternative gegenüber den kommerziellen Messstellenbetreibern
anbieten
\end_layout
\begin_layout Itemize
dem Nutzer ein Bewusstsein über seinen Verbrauch/Nutzungsverhalten aufzeigen
\end_layout
\begin_layout Itemize
Energie intelligenter zu nutzen
\end_layout
\begin_layout Itemize
die Breite Masse erreichen
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Daher stammt auch der Name
\series bold
volks
\series default
zaehler.org
\end_layout
\end_inset
\end_layout
\begin_layout Itemize
offene Protokolle und Standards zu vorrantreiben
\end_layout
\begin_layout Standard
Wir haben es uns zur Aufgabe gemacht diese Ziele durch eine lückenlose Kette
von quelloffener Soft- und Hardware zu erreichen.
Der Nutzer soll die Möglichkeit haben jeden einzellnen Schritt nachvollziehen
zu können.
Daraus folgt nicht, dass wir jede Zeile Code selbst geschrieben haben.
Wir nutzen eine Reihe anderer Software, die aber wiederum selbst quelloffen
ist.
\end_layout
\begin_layout Section
Aufbau
\end_layout
\begin_layout Standard
Das Projekt lässt sich in drei Bereiche aufteilen, die untereinander über
eine spezifizierte API kommunizieren.
Diese drei Module grenzen sich lokal, durch die verwendeten Technologien
und ihre Aufgabe voneinder ab.
Alle Module sollen untereinander austauschbar sein und sind in mehreren
Varianten verfügbar.
So kann den individuellen Bedürfnissen nach ein angepasstes Setup aufgebaut
werden.
\end_layout
\begin_layout Subsection
Controller
\end_layout
\begin_layout Standard
Die Aufgabe der Controller ist es Sensoren auszulesen und diese Daten direkt
an das Backend zu senden.
Meist sind sie direkt mit den Zählern/Sensoren verbunden.
Ein typischer Ort wäre also der Sicherungskasten.
Diese Controller sind dann meist in das lokale IP Netzwerk eingebunden
und senden ihre Daten an ein Backend.
Ausgehend von Prototyp sind im volkszaehler.org Projekt bisher die Atmel
AVR/Ethersex basierenden Controller am meisten verbreitet.
\end_layout
\begin_layout Standard
Als Sensoren werden hier für das Erfassen des Verbrauchs Impulszähler eingesetzt.
Diese signalisieren dem Controller durch einen elektrischen Impuls, das
eine bestimmte Menge an elektrischer Energie, Wasser oder Gas verbraucht
wurde.
Auch skalare Messgrößen wie z.B.
Temperatur, Luftdruck oder Luftfeuchtigkeit sind möglich, werden dann aber
nicht mehr durch Impulse erfasst.
\end_layout
\begin_layout Standard
Ein typisches Setup für ein Einfamilienhaus könnte folgendermaßen aussehen:
\end_layout
\begin_layout Itemize
3x 1-phasige S0-Stromzähler für den Hausanschluss
\begin_inset Foot
status open
\begin_layout Plain Layout
jede Phase erhällt einen Zähler
\end_layout
\end_inset
\end_layout
\begin_layout Itemize
1x S0-Wasserzähler
\end_layout
\begin_layout Itemize
1x S0-Gaszähler
\end_layout
\begin_layout Itemize
1x Sensor für die Außentemperatur
\end_layout
\begin_layout Subsection
Frontend(s)
\end_layout
\begin_layout Standard
Die Frontends visualisieren Messwerte und können zur Verwaltung genutzt
werden.
Durch ein zentrales Backend haben wir die Möglichkeit die Messwerte an
mehrere Frontends gleichzeitig zu verteilen.
Verschiedene Frontends, können die Daten dann unterschiedlich darzustellen.
\end_layout
\begin_layout Standard
Das Web-basierte Frontend für den Browser ist das bisher einzige Frontend
und ist quasi eine Referenzimplementierung der API.
Es unterstützt die volle Funktionalität des Backend und kann auch zur Verwaltun
g von Zählern genutzt werden.
Es nutzt AJAX um Daten dynamisch nachzuladen.
\end_layout
\begin_layout Standard
Inspiriert vom Wattson
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
http://www.diykyoto.com/uk/wattson/about
\end_layout
\end_inset
\end_layout
\end_inset
haben wir uns entschieden eine ähnliche interaktive Variante dieses Moodlights
zu entwickeln.
Derzeit experimentieren wir mit fnordlichtern
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
http://wiki.lochraster.org/wiki/Fnordlichtmini
\end_layout
\end_inset
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
Die möglichen Visualisierungsmethoden sind praktisch endlos.
Damit auch die Anzahl der möglichen Frontends.
Frontends dürfen nicht nur als abgeschlossenes System betrachtet werden.
Denkbar sind auch Plugins in bestehende Systeme (Social Networks, iGoogle,
Twitter).
\end_layout
\begin_layout Subsection
Backend
\end_layout
\begin_layout Standard
Im Backend werden die Messwerte der Sensoren gespeichert und ausgewertet.
Es handelt sich hierbei um ein PHP Skript welches auf einem Webserver läuft
und somit die Schnittstelle zwischen Controller und Frontend ist.
Daraus folgend muss es von den Controllern sowie von den Frontends via
HTTP erreichbar sein.
Ob der Backendserver nur über das lokale Netzwerk oder auch über das Internet
erreichbar ist, wirkt sich nur auf die Erreichbarkeit durch die Frontends
und die Controller aus.
So kann es durchaus erwünscht sein die Daten nur im lokalen Netzwerk vorzuhalte
n um sie gegen Zugriff über das Internet zu schützen.
\end_layout
\begin_layout Section
API
\end_layout
\begin_layout Standard
Die API definiert eine Schnittstelle zwischen Controllern und Backend, sowie
zwischen Backend und Frontends.
Die API orientiert sich am REST Entwurfsmuster.
Dabei kann jeder Zähler/Sensor/Gruppe (im folgenden als
\begin_inset Quotes eld
\end_inset
Entity
\begin_inset Quotes erd
\end_inset
bezeichnet) durch eine weltweit eindeutige UUID referenziert werden.
Diese UUID werden entsprechend RFC 4122 von Backend generiert und vergeben.
Dieser 128 Bit lange Identifier sichert uns auch gleichzeitig die Privatsphäre.
Die UUID ist praktisch eine Zugangskennung und sollte immer vertraulich
behandelt werden.
Da wir keinerlei nutzerbezogene Daten speichern kann diese UUID nur durch
den Zugriff eines Nutzers zugeordnet werden.
Daher empfiehlt sich der Einsatz von verschlüsseltem HTTPS.
\end_layout
\begin_layout Standard
Als Ausgabeformat nutzen wir das leichtgewichtige und menschenlesbare JSON.
\end_layout
\begin_layout Standard
Eine Referenz unserer API befindet sich im Wiki.
\end_layout
\begin_layout Subsection
Gruppierung
\end_layout
\begin_layout Standard
Zähler und Sensoren können zusammengefasst werden.
Diese Aggregatoren besitzen selbst wieder eine UUID und können dadurch
beliebig tief verschachtelt werden.
Hirachische Strukturen wie z.B.
Mehrfamilienhäuser, Wohngemeinschaften, Hotels, Gemeinden & Städte können
dadurch nachgebildet und gemeinsam ausgwertet werden.
\end_layout
\begin_layout Section
Implementierung
\end_layout
\begin_layout Standard
Dieser Abschnitt konzentriert sich auf die Implementierung des Backends.
Das Backend ist in PHP programmiert und kann auf jedem LAMP-ähnlichen System
betrieben werden.
\end_layout
\begin_layout Standard
Der Code ist stark Objekt orientiert.
Daher müssen wir PHP 5.3 vorraussetzen.
Diese Objekt orientierte Programmierung erlaubt es uns den Code übersichtlicher
und modularer aufzubauen.
Zukünftige Erweiterungen, neue Zählertypen können dadurch leichter in das
System integriert werden.
\end_layout
\begin_layout Subsection
MVC
\end_layout
\begin_layout Standard
Das Backend wurde nach dem
\series bold
M
\series default
odel
\series bold
V
\series default
iew
\series bold
C
\series default
ontroller Entwurfsmuster aufgebaut.
Jeder Request an das Backend muss über die Datei
\family typewriter
/htdocs/backend.php
\family default
erfolgen.
Sie ist quasi der
\begin_inset Quotes eld
\end_inset
Haupteingang
\begin_inset Quotes erd
\end_inset
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Dadurch ist sie auch das einzige PHP Skript, das über das öffentliche
\begin_inset Quotes eld
\end_inset
htdocs
\begin_inset Quotes erd
\end_inset
Verzeichnis zugänglich sein muss
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
Dort wird zunächst der PHP Interpreter konfiguriert (automatisches Laden
von Klassen, der Konfiguration, Fehlerbehandlung, Aufbau der Datenbankverbindun
g).
Danach wird direkt der Router initialisiert.
\end_layout
\begin_layout Subsubsection
Router
\end_layout
\begin_layout Standard
Der Router ist das Herz der MVC Struktur.
Er leitet den Request an den zuständigen Kontext
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Wir nutzen hier den Begriff
\begin_inset Quotes eld
\end_inset
Kontext
\begin_inset Quotes erd
\end_inset
um eine Verwechslung mit dem Hardware-Controllern zu vermeiden.
Entsprechend des MVC-Patterns ist hier der
\begin_inset Quotes eld
\end_inset
Controller
\begin_inset Quotes erd
\end_inset
gemeint.
\end_layout
\end_inset
weiter und antwortet mit dem korrekten Ausgabeformat.
\end_layout
\begin_layout Standard
Alle Anfragen an das Backend müssen einem bestimmten Schema entsprechen.
Hier wird auch der zuvor angesprochene Einsatz von REST deutlich.
\end_layout
\begin_layout Standard
\family typewriter
http://server:port/path/to/volkszaehler/backend.php/kontext/uuid.format?paramters=
values
\end_layout
\begin_layout Subsubsection
Kontext (Controller)
\end_layout
\begin_layout Standard
Das Backend hat verschiedene Aufgaben zu bewältigen.
Für jede dieser Aufgaben gibt es einen eigenen Kontext, der praktisch die
ganze Logik enthällt:
\end_layout
\begin_layout Itemize
Daten erfassen/ausgeben
\end_layout
\begin_layout Itemize
Entities erstellen/bearbeiten/abfragen
\end_layout
\begin_layout Itemize
Eigenschaften des Backends abfragen
\end_layout
\begin_layout Subsubsection
Datenabstraktion (Model)
\end_layout
\begin_layout Standard
Zur Datenbankabstraktion setzen wir Doctrine 2 ein.
Dieses Database Abstraction Layer (DAL) erlaubt es uns datenbankspezifische
Eigenheiten, SQL-Dialekte ähnliches zu ignorieren.
Doctrine unterstützt verschiede Datenbanken:
\end_layout
\begin_layout Itemize
MySQL
\end_layout
\begin_layout Itemize
SQLite
\end_layout
\begin_layout Itemize
PostgreSQL
\end_layout
\begin_layout Itemize
Oracle
\end_layout
\begin_layout Standard
Aufbauend auf das DAL kommt der Object Relational Mapper (ORM) von Doctrine
zum Einsatz.
Wir können mit den Daten nun als Instanzen von PHP-Objekten arbeiten.
SQL Queries sind nicht mehr nötig.
Für weitere Infos empfehle ich die Dokumentation des Doctrine Projekts.
\end_layout
\begin_layout Subsubsection
Ausgabe (View)
\end_layout
\begin_layout Standard
Das Backend kann in verschiedenen Formaten antworten:
\end_layout
\begin_layout Itemize
JSON (Standard)
\end_layout
\begin_layout Itemize
XML
\end_layout
\begin_layout Itemize
CSV
\end_layout
\begin_layout Itemize
Klartext
\end_layout
\begin_layout Itemize
Jpeg, PNG, Gif
\end_layout
\begin_layout Standard
Dabei ist JSON das bevorzugte Format, das auch von dem Webinterface genutzt
wird.
Die anderen Formate sind als Alternativ für Endgeräte ohne JSON Unterstützung
gedacht.
Wir können nicht garantieren, dass diese Formate den gleichen Funktionsumfang
wie das JSON Format besitzen.
\end_layout
\end_body
\end_document