[vz-dev] Hallo

[Steffen Vogel]

On Tue, 25 May 2010 07:07:53 +0200, Justin Otherguy
<justin at justinotherguy.org> wrote:
>> Was hällst du von einem zentralen Wiki? Diese
>> statische Hauptseite auf volkszaehler.org könnten man damit auch gut
>> abdecken.
> ich ziehe derzeit ein extern gehostetes Wiki vor - wenn wir da
allerdings
> nix G'scheites(TM) finden, können wir auch ein $WHATEVERWIKI auf
> volkszaehler.org aufsetzen.
> 
Ich habe mich selber noch nie so mit externem Hosting beschäftigt. Ich
ziehe die eigene Variante vor.
Hier hab ich einfach mehr Kontrolle, über Daten, Passwörter etc.. Backups
etc..
Und falls auch ein BT auf dem Server laufen würde. Warum dann kein Wiki?
Ein DokuWiki belastet den Server auch kaum. Da viele Sachen statisch in
eigenen Textdateien abgelegt werden.
Und wie gesagt es gibt ne Menge Plugins (Auch für Mantis btw.).

>>>> * Bugtracker auf eigenem Server?
>>>> Ich würde MantisBT [2] empfehlen. Dieser Bugtracker ist (wie DokuWiki
>>>> überigens auch) in PHP geschrieben. Hier könnte man mal alle
Probleme,
>>>> Bugs und vor allem Tasks, Todos organisieren und den Entwicklern
>>>> zuweisen.
>>> Ich persönlich hab jetzt nicht grade die besten Erfahrungen mit Mantis
>>> gemacht. Ist irgendwie einfach viel zu komplex für die meisten
>>> Anwendungsfälle und Einsteiger finden da nicht wirklich gut rein.
>>> Ich würde einfach den Bugtracker von github mit benutzen. Der macht
auf
>>> den ersten Blick einen besseren Eindruck....
>> 
>> Oh hab ich gar nicht gewusst das Github auch einen Bugtracker hat. Ja
>> dann ist das sicherlich besser. Integriert sich bestimmt auch besser
ins
>> VCS.
> kenne mantis und finde es gut; haben den BT von github nur gesehen, aber
> noch nicht genauer angeschaut; lasst uns den doch einfach mal testen

Ich habe mir das github Issue System gerade mal näher angesehn. Es ist
wirklich sehr rudimentär.
Ich würde hier aus den gleichen Gründen wie beim Wiki für ein eigene
Variante plädieren.
Es stimmt zwar das Mantis hier sehr komplex ist. Aber github fehlen hier
wirklich Funktionen,
die auf lange Sicht unverzichtbar sind: Milestones, Zuweisen an User etc..

> 
>> Ich muss mich auch mal näher mit git vertraut machen. Wenn ich was
finde
>> werde ich dir nen Link schicken.
> oh prima :-)
>
Au weia. Ich hab mir jetzt erstmal ein eBook über git gesucht. Sind ja
schon ein paar Unterschiede zu SVN.
Den dezentralen Ansatz find ich aber klasse.
Wenn ichs einigermaßen hinbekomme werd ich dann auch mal meine eigenen SVN
repos umziehen.
> 
> 
> 
>> rrdtool [1] ist hier das Stichwort. Das ist eine Round Robin Datenbank,
>> die im Prinzip genau das macht. Das rrdtool Projekt kann die Daten auch
>> gleich virtualisieren. Sicherlich eine Alternative die für embedded
>> System interessant ist. Da hier ein großes RDBMS und PHP Interpreter
>> überflüssig wäre.
> 
> Flukso verwendet ebenfalls rrdtool; ich konnte mich noch nicht ganz
dafür
> erwärmen - das liegt aber vielleicht daran, dass ich auch darüber noch
> zuwenig weiss.
> 
> Hier sieht der Idealfall m.E. so aus, dass wir rrdtool als DB-Backend
> unerstützen, so dass dann je nach Geschmack bzw. verfügbaren Ressourcen
das
> passende ausgewählt werden kann: PSQL/MySQL für die ausgewachsenen
> Linux-Büchsen, sqllite oder rrdtool für den Betrieb der kompletten
> Installation (Messung/Verarbeitung/Protokollierung/Auswertung) auf einem
> einzigen Embedded System. Bart sagte mir, dass er sich sich die Idee,
die
> Daten direkt auf dem Flukso zu speichern und dort auch wieder per
> Web-Server anzubieten, mal anschauen würde.

rrdtool ist soweit ich informiert bin dazu bestimmt Werte einem Zeitpunkt
zuzuweisen.
Ältere Werte bekommen eine bestimmte Unschärve. Dadurch können wir diese
Datenbank nicht für den
Impulsbasierten Ansatz nutzen. Ich habe noch kein performantes und gutes
Modul für php gefunden.
Auch ist rrdtool bei keinem regulären Hoster verfügbar. Ich denke wir
sollten rrdtool nicht auf dem Server einsetzen.
Vielleicht in Zukunft mal auf einem embedded Device.
Volkszähler soll fürs Volk sein. Das Volk hat keine Ahnung von rrdtool,
postgresql usw..
Einfache, quasi standarisierte, Softwarepackete sollten die Basis sein
(php, mysql).
Diese werden von jedem Webhostinganbieter unterstützt. Das soll jetzt
keine Absage an postgresql sein.
Ich liebe diese Datenbank. In der Realität sehe ich aber ihren Anteil für
mögliche Volkszähler unter 10%.

> 
> Noch eines:
> Ich denke, wir können an vielen Stellen von Barts Arbeit profitieren;
Bart
> kann deutsch lesen, hat aber wenig Übung im sprechen/schreiben -> sollen
> wir das Ganze auf englisch veranstalten, um hier einfacher zusammen
> arbeiten zu können?
> 
> Und: Flukso hat insbesondere bei der Visualisierung noch "Potenzial"; an
> der Stelle kann er am Ehesten von volkszaehler profitieren; darum
sollten
> wir unsere Zeit auch darauf konzentrieren (und genau das passiert a auch
> gerade: wir sprechen kaum über Controllerthemen).

Find ich gut :)
Flusko wird wohl die Auswertung, Speicherung und Visualisierung mit
rrdtool machen.
Das ist wohl der einfachste Ansatz den es gibt. Sicherlich auch perfomant.
Aber wie Justin es angesprochen hat
geht es noch schöner. Auch funktionell kann man hier noch mehr herraus
holen.
Denkbar wäre ein Leistungsspektrum, statistische Auswertungen, Kosten,
spitzen und minimal Leistung etc..

Um diese Auswertungen machen zu können, halte ich es für notwenig jeden
Impuls in die Datenbank zu legen.
Ein Round Robin Prinzip ist dadurch immer noch möglich. Die Datenmenge
kann also konstant bleiben.
Hier mal ein Entwurf für die Puls-Tabelle:

Spaltenname | Beschreibung
=======================================================================
mid         | Meter ID referenziert den Puls zu einem Zähler, der in einer
seperaten Tabelle gespeichert wird (inkl. Typ, Auflösung, Name etc..)
ts          | Timestamp der Messung/des Pulses in ms nach 1970
count       | Anzahl der Pulse seit des letzten Timestamps/Eintrag in der
Tabelle

Die letzte Spalte ist hier besonders interessant. Aktuelle Messwerte
werden immer einzeln (count=1) in die Datenbank geschrieben.
Jeder Puls bekommt also einen Eintrag in die Datenbank. Nur so ist es
möglich wirkllich alle Leistungsspitzen zu erfassen.
Nach dem Round Robin Prinzip können wir dann alte Einträge zusammenfassen.
In der Konfiguration könnte man die maximale Größe der Datenbank angeben.
Ein Algorithmus würde dann Puls-Packete zusammenfassen. Je älter die
Einträge desto größer die Pulspackete.

Ich versuche das ganze mal mit ein paar Daten zu verdeutlichen. Die Daten
hab ich mir einfach mal so ausgedacht.

mid | ts            | count |
=======================================================================
1   | t - 0         | 1     | <- neuester Puls (t = Gegenwart)
1   | t - 0.6       | 1     |
1   | t - 2.1       | 1     |
1   | t - 3.4       | 1     |
...
1   | t - 502.2     | 3     | <- ältere Pulse (aggregiert)
1   | t - 1000      | 6     |
1   | t - 1200      | 7     |
1   | t - 1900      | 9     |
1   | t - 2300      | 12    |
...
1   | t - 5500      | 20    |
1   | t - 8800      | 24    |
1   | t - 9200      | 26    |

Das löst aber nicht das Problem mit den Temperatursensoren etc. Diese
müssten ihre Werte ja in periodischen Intervallen an der Server schicken.
Es wäre jetzt denkbar diese zwei Zähler/Sensortypen beide zu
implementieren. Damit haben wir die Stärken beider Speichermethoden
kombiniert.
Das wäre relativ einfach durch das Vererben, wie ich es in eienr
vorherigen Mail beschrieben habe, möglich.

Meter __ PulseMeter __ PowerMeter
      \             \__ GasMeter
       \             \__ WaterMeter
        \             \__ RayMeter
         \             \__ RainMeter
          \
           \__ ValueMeter __ TempSensor
                          \__ WindSpeedSensor
                           \__ PressureSensor

Und so weiter, und so weiter. Das ist ja praktisch immer noch schön
erweiterbar.

Wir könnten dazu sogar die gleiche Tabelle benutzen. Die "count" Spalte
würden wir einfach "count_value" umbenennen.
Je nach dem was für einen Zählertyp "mid" referenziert wird diese Spalte
dann anders ausgewertet.

gruß Steffen