[vz-dev] Neues Backend

[Steffen Vogel]

Am Sonntag, den 30.05.2010, 17:58 +0200 schrieb Florian Ziegler:
> Hallo Steffen,

Hi Flo :)

> da sollten wir evtl mal eine Liste mit Anwendungsfällen sammeln, und dann 
> entscheiden, welche wir davon unterstützen wollen.
> 
> Beispiele:
> 1. Ein Haushalt mit 3 Phasen für den Gesamtverbrauch + 1 Phase der 
> Photovoltaikanlage. Hausbesitzer sieht alle Kanäle.
> 
> 2. Ein Haushalt mit 3 Phasen für den Gesamtverbrauch + 1 Phase nur Keller mit 
> Gefriertruhe. Hausbesitzer sieht alle Kanäle.
> 
> 3. WG mit 3 Phasen Gesamtverbrauch + 1 Phase je Bewohner. Alle sehen den 
> Gesamtverbrauch, jeder nur seinen Zimmerverbrauch.
> 
> 4. Anwesen mit zwei Häusern je 3 Phasen für den Gesamtverbrauch.
> 
> 5. Zweifamilienhaus mit je 3 Phasen für den Gesamtverbrauch + ein 
> Temperatursensor. Jeder Wohnungseigentümer darf seinen Strom + gemeinsame 
> Temperatur ansehen.
> 
> 
> So wie ich dich verstanden habe, gibt es eine Tabelle für User mit einer uuid 
> und eine Tabelle mit Kanälen ucid (unique channel id).

Genau. Bisher sieht meine Usertabelle nur eine Integer User ID vor. Aber
was spricht eigentlich gegen eine UUID und UCID. Finde ich gut. Werde
ich gleich auch mal umsetzen.

> 
> Zum User werden außer der uuid keine Infos gespeichert!

Bisher habe ich noch ein sha1 gehashtes Passwort und eine
EmailAdresse/Username gespeichert. Aber im Prinzip dürfte eine 16byte
lange UUID schon genug Sicherheit bieten. Ist halt nur etwas blöd sich
jedes mal mit einer UUID einzuloggen, die man sich sowieso nciht merken
kann.

> 
> Jeder User kann in einem n:m mapping die ihm bekannten ucids hinzufügen.

Genau.

> 
> Ist es dann für Beispiel 4 notwendig noch 'Zwischengruppierung' einzufügen: 3 
> ucids gehören zum einen Haus, die anderen 3 zum anderen Haus.

Hab ich bisher nicht so vorgesehen. Wäre das denn rein logisch nötig? Im
Prinzip ist es ja kein Problem.
> 
> 
> 
> Frage:
> Mein Ansatz ist bisher komplett Server-Client basiert. D.h. im PHP Code wird 
> kein HTML ausgegeben (bis auf channel_admin.php).
> Wollen wir das beibehalten und auch die Verwaltung (anlegen von Kanälen, 
> hinzufügen zum User) per AJAX erledigen, oder willst du eher einen klassischen 
> Ansatz mit einer HTML-Template Funktion verwenden?

Diese strikte Trennung ist klasse und würde ich wenn möglich auch
beibehalten.
Wobei beide Lösungen in meinem Backend kein Problem währen. Es gibt dann
einen UserController, der bestimmte Schnittstellen
(UserController::addChannel() bereit hält.

> 
> Wenn wir uns auf ein gemeinsamses Format der JSON Daten einigen, können wir 
> die Auswertung per jqPlot und das Backend unabhängig voneinander entwickeln. 
> Das war auch meine Idee dabei, dass man das Backend und Frontend im Browser 
> austauschen kann.

Gerne. Habe habe gerade mal einen ersten Blick in dein JSON Format
geworfen. Dazu habe ich noch ein paar Fragen:

- Du überträgst nur die Timestamps?
- Und berechnest die Leistung dann im Browser?

Ich habe mein Backend momentan so aufgebaut, dass diese Berechnungen auf
dem Server erledigt werden. Ich habe da primär an andere Ausgabeformen
gedacht. Z.B eine Mail mit einem "Monatsreport" oder eine SMS mit der
Warnung über eine neue Leistungsspitze.. Oder sei es das Rendern von
Graphen auf dem Server um sie auf mobilen Geräten anzuzeigen (Nicht
jedes Geräte hat ja eine aktuelle und schnnelle JS-Engine).

In diesem Fall wäre eine Auswertung der Daten im Backend notwenig.
Ich habe auch schon ein paar Methoden zur Auswertung per SQL entworfen.
Mit "Self-Joins" ist es möglich die Leistung (also die Bildung der
Differentialquotienten) durch den Datenbankserver berechnen zu lassen.
Auch Min/Max/Avg Werte wären so kein Problem.
Ich glaube aber, dass wir dort nicht so weit kommen, da viele
Datenbanksysteme z.B SQLite die nötigen Funktionen nicht unterstützen.
Dafür wäre die sicherlich die schnellste Möglichkeit.

> 
> Ich würde sagen, du versuchst erstmal deinen Code so hinzubekommen, dass er 
> passende JSON für meine Auswertung ausspuckt, dann können wir das ganze ja mal 
> gegeneinander werfen. Im zweiten Schritt schmeißen wir den Code von Justin weg 
> und mergen unser beider Code.
> ACK?

ACK. Ich werde meinen Code mal an dein Frontend anpassen. Die Frage mit
der Berechnung können wir ja immer noch später klären.
Ich denke die Urversion können wir endgültig aufgeben. 

> Da sollten wir evtl mal die Begriffe definieren.
> ist 'Zähler' ein Hutschienenzähler für eine Phase (also ein Kanal), oder ein 
> Controller, der 3 Phasen zählt.
> 

Wie wäre es mit:

* "Ein Kanal (engl. Channel) bezeichnet einen Zähler (engl. Meter) oder
Sensor (für Temperatur, Wind, Luftdruck etc.).
Er wird durch eine UCID (unique channel id) eindeutig referenziert."

* "Ein Controller erfasst die Werte der "Kanäle" und leitet sie an einen
Backendserver weiter.
Dabei sorgt er durch Zwischenspeicherung der Messwerte bei
Verbindungsproblemen vor und entlastet die Verbindung zwischen
Controller und Backendserver."

* "Das Backend ist für die Speicherung und Verarbeitung der Messwerte
zuständig. Die Verwaltung von Usern, Kanälen ist auch Aufgabe des
Backends.
Es besteht aus Webserver, Datenbank, und PHP Interpreter."

* "Das Frontend ist für die Visualisierung der Messwerte verantwortlich.
Typischerweise wird hierzu ein Browser verwendet, der mit Hilfe von
Javascript die Daten anzeigt."

Mich freut es, dass wir die Diskussion beginnen konnten. Ich werde
versuchen unsere Ergebnisse im Wiki zu sammeln.

gruß Steffen

-- 
Steffen Vogel
Roonstraße 106
Köln

Cell: +49 (176) 96978528
Web: http://www.steffenvogel.de
Mail & MSN: info at steffenvogel.de
ICQ: 236033
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20100530/9a063b1a/attachment.pgp