[vz-dev] Neues Backend

Sun May 30 17:58:34 CEST 2010

Hallo Steffen,

Am Sonntag, 30. Mai 2010, 14:28:35 schrieben Sie:
> Moin,
> 
> (schicke diesen Faden, den ich off-List angezettelt habe, nun wieder dahin,
> wo er auch hingehört - on-list)
> 
> In die Diskussion selbst will ich im Moment mal gar nicht allzu tief
> eingreifen -
Justin macht sichs da einfach ;-)

> ich gebe nur an ein paar Stellen meinen Senf dazu (...warum
> ist das eigentlich so?)
> 
> Am 30.05.2010 um 12:59 schrieb Steffen Vogel:
> > Hi flo :)
> > 
> > Am Sonntag, den 30.05.2010, 12:37 +0200 schrieb Florian Ziegler:
> >> Hallo Ihr beiden,
> >> 
> >> Ich denke, wir sollten erstmal definieren, was das Backend denn
> >> eigentlich machen soll. Ich verstehe das so:
> >> 
> >> Funktion 1:
> >> 	Zur Installation Kanäle anlegen und verwalten. Macht bei mir
> >> 
> >> channel_admin.php nur spartanisch aber tut.
> >> 
> >> Funktion 2:
> >> 	Pulse in DB loggen. Das macht httplog.php doch schon ganz gut. Der 
Kern
> >> 
> >> besteht da ja nur aus 5 Zeilen Code. Hier halte ich es nicht unbedingt
> >> für sinnvoll eine DB-Abstraktion einzuführen, das bläht den Code doch
> >> mehr auf, als das es ihn übersichtlicher macht. Wenn wir z.B. als DB
> >> mysql,pgsql und sqlite unterstützen, kommen einfach drei verschiedene
> >> 'db_connects' und 'INSERTS' untereinander, das werden keine 100 Zeilen
> >> Code und ist für Embedded Systeme auch ressourcenschonender als dafür
> >> extra ne Datenabstraktion zu laden.
> >> 
> >> Funktion 3:
> >> 	Pulse unter Angabe des Zeitbereiches (von bis) und des
> >> 
> >> Aufsummierungsintervalls aus DB lesen und als JSON an den Browser
> >> zurückschicken. Das macht bei mir smartmeter.json.php. Hier ist eine DB-
> >> Abstraktion evtl. sinnvoller.
> >> 
> >> Alles andere würde ich komplett im JavaScript abwickeln. Bin der
> >> Meinung, dass das Backend nicht dafür verantwortlich ist, abhängig von
> >> der Displaygröße andere Daten zu liefern, das muss der Client
> >> erledigen.
> >> Ob der Client die Daten dann per flot oder jqPlot ausgibt sollte dabei
> >> doch für das Backend keine Rolle spielen?!
> >> Die Schnittstelle (also das JSON Format) können wir langfristig mit
> >> flukso absprechen und vereinheitlichen.
> > 
> > Ich dachte hier geht es um die Schnittstelle Controller -> Backend? Oder
> > doch um Backend -> Browser?
> > 
> >> Bleibt es bei diesen drei Funktionen, bin ich der Meinung muss man das
> >> zumindest Im Moment nicht wie bei Steffen auf 25 Dateien verteilen.
> > 
> > Ja mit den Dateien habe ich es vielleicht etwas übertrieben. Das sind
> > aber im Prinzip alle Dateien die man auch in Zukunft braucht.
> > 
> > Im Grunde hast du ja recht mit diesen drei Aufgaben des Backends.
> > Mal mit dem MVC Pattern ausgedrückt:
> > 
> > Model		=> Datenbank
> > View		=> Browser (teils auch im Backend)
> > Controller	=> Backend
> > 
> > Jedoch gehört für mich zum Backend auch noch eine gewisse
> > Verwaltungsebene. Also das Verwalten von Gruppen/Usern, Zählern,
> > Einstellungen (Zählerbeschreibungen, Auflösungen, Kosten etc).. Das
> > Zurücksetzen der Zähler, generieren von Reports müsste auch im Backend
> > gelöst werden.
> > 
> > Ich finde die Darstellung sollte im Browser laufen. Die Berechnung auf
> > dem Backend (Min, max, avg, Statistiken etc.).
> > Zu den Berechnung zähle ich auch das Aggregieren der Pulse.
> > 
> > Ich halte dich Strukturierung in Klassen für äußerst wichtig.
> > Andere Ausgabeformen (SMS, auf dem Server gerenderte Graphen, Email,
> > Benachrichtigungen etc.) müssen teils auch auf dem Server erzeugt
> > werden.
> > 
> > Hier sollte man klar definierte Interfaces (wie auch bei den Zählern
> > (include/classes/meter.php)) haben.
> > 
> >> Wegen der Energieanzeige. Ich hab da mal im Frontend ein Balkendiagramm
> >> draus gemacht:
> >> http://volkszaehler.f10-home.de/smartmeter.html
> >> Info: Energie - Bereich: Jahr - Gruppierung: Monat - Kanäle addieren.
> >> Ich denke jetzt wird klar, was ich damit meine. Alternativ kann man
> >> statt der Energie auch noch die Kosten pro Intervall mit angeben.
> > 
> > was hältst du davon noch ne zweite Liste einzurichten?
> > volkszaehler-dev, volkszaehler? Einmal für Anwender und einmal für
> > Entwickler? Es sind ja bereits ein paar Installationsfragen aufgekommen.
> 
> die zweite Liste hatte ich als Option vorgesehen; wäre kein Problem (drum
> hat diese hier ja auch schon -dev anhängen); allerdings finde ich das noch
> zu früh: - die Abonnenten wäre wohl die gleichen
> - die Themen, die für Anwender relevant sind, fliessen sicher auf absehbare
> Zeit noch in die Entwicklung ein ("ah, stimmt, das ist aber eine gute
> Idee..." -> ...)
> 
> Finde also, dass wir uns das im Moment mal noch verkneifen sollten.
> 
> >>> Ja Strukturell hat sich einiges geändert. Z.B. referenzieren UUIDs
> >>> keine User mehr. Bei mir hat jeder Zähler eine eigene UUID. Dann gibt
> >>> es ein n-zu-n Mapping von Usern zu Zählern. Dadurch können mehrere
> >>> User einen Zähler Betrachten.
> >> 
> >> ist das nicht genau das, was wir vermeiden wollen? also die Zuordnung
> >> eines Users zu einem Zähler? Oder was verstehst du unter User zu Zähler
> >> Mapping?
> > 
> > Naja es muss ja kein User sein. Ich denke nur dass wir alle Zähler
> > möglichst getrennt verwalten sollten. Dann kann der Nutzer selber
> > entscheiden welche Daten er zusammengefasst angezeigt bekommen will.
> > 
> > So kann z.B jeder User seinen eigenen Stromzähler haben.  Zwei Nachbarn
> > können sich jedoch zb einen Temperatur Sensor teilen.
> > 
> > Oder in einer WG: es gibt einen Gesamtzähler den alle Bewohner sehen
> > können.
> > Jeder Bewohner hat dann für sein eigenes Zimmer nochmal einen eigenen.
> > Hier eine Gruppierung auf Controller Ebene einzuführen (per UUID) finde
> > ich nicht so gut. Das muss nicht immer der Realität entsprechen. Und man
> > hat dadurch eine Begrenzung auf einen Controller.
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).

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

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

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.

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?

Wenn wir uns auf ein gemeinsamses Format der JSON Daten einigen, können wir 
die Auswerung 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.

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?

> 
> z. Info: woher kommt die Zuordnung uuid - Controller überhaupt?
> 
> Ich hatte zwischenzeitlich auch mal die Idee, eine uuid pro Zähler zu
> verwenden, fand das dann aber unpraktisch, wenn ich zum Abrufen des
> Profils 3 uuids übergeben muss. Das können wir gerne hier auf der Liste
> diskutieren. Stellt sich auch hier die Frage, was dagegen spricht, beide
> Varianten vorzusehen. Die Auswirkungen auf die Serverseite wären m.E.
> gering: - Logging: wir würden den Parameter für den Kanal (bzw. Zähler)
> vorsehen; dieser könnte dann auch optional sein - Auswertung: wir würden
> vorsehen, dass die einer uuid zugeordneten Zähler aus der DB ausgelesen
> werden; hat der Benutzer sich für 1:1 entschieden, hat diese Liste eben
> nur einen Eintrag für eine uuid

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.

> 
> 
> Gruss, J.