[vz-dev] MAX 1800Watt

[Jakob Hirsch]

Steffen Vogel, 2010-12-27 20:52:

>  - Sensoren, die keinen Verbrauch erfassen, speichern hier ihre Werte (zb.
> Temperatur)
>  - Controller, die direkt aggregierte/summierte Werte senden, speichern
> hier den Verbrauch über das Intervall ab

Wie z.B. e6 mit "summarize events" :)

>  - Später wollen wir diese Aggregierung/Summierung noch nachträglich für
> alte Werte einführen, um hier etwas Speicherplatz zu sparen und die DB zu
> entlasten.
>    (vgl. rrdtool; round robin databases)

An rrd hatte ich auch schon gedacht, das ist ja eigentlich gerade für
solche Sachen gemacht, und Fluxo benutzt das ja auch (AFAICS). Ich
find's aber etwas sperrig und unflexibel.

Andererseits kann man sowas ja auch per script nachbauen. Die values
viertelstundenweise zu aggregieren und dann einen einen Wert (in der
Mitte des Intervalls) zu setzen, ist ja nicht so wild.  Evt. sollte man
noch den Fall "kein Impuls im Intervall" berücksichtigen, dann müßte man
sich den vorherigen und nächsten Impuls schnappen und entsprechend auf
die Intervalle verteilen. Wäre aus meiner Sicht aber schon die
Luxuslösung. Das wären ja < 5W (bei 15 min und 800 Impulse/kWh).

>>> Für die Implementierung fallen mir 2 Lösungen ein: - vor dem
>>> Eintragen eines Impulses könnten wir nach dem timestamp suchen; nur
>>> wenn dieser noch nicht vorhanden ist, tragen wir einen neuen ein;
>>> anderenfalls erhöhen wir "value" (das ist vermutlich aber Blödsinn)
>> Muß halt in einer Transaktion erfolgen.
> Soweit vom Datenbanksystem unterstützt, macht Doctrine das direkt.

Machen eigentlich alle DBMS, die wir unterstützen, oder?

>>> - wir tragen ein (wie derzeit) und falls das SQL-Statement mit einem
>>> Fehler endet (...schon vorhanden...) fragen wir den value ab und
>>> inkrementieren diesen
>> mysql hat genau für sowas "INSERT ... ON DUPLICATE KEY UPDATE
>> value=value+VALUES(value)". In anderen DBMS muß man das dann wohl über
>> Trigger machen. Ist nur die Frage, ob man sowas in Doctrine abbilden
>> kann...

Achso, vergessen: Ansonsten braucht man halt trigger dafür, z.B. bei
sqlite oder pgsql.

> Das wird wohl eher etwas schwierig. Hier würde ich vorschlagen, das
> timestamp Feld wieder unique zu machen.

ACK.

> Falls dann der selbe timestamp erneut eingefügt werden sollte, wird von
> PDO eine exception geworfen.
> Diese könnten wir mit try { } catch abfangen und den Werte mit per "UPDATE
> value = value + 1" erhöhen.

" + $input_value", kann ja auch was anderes als 1 rein kommen.

Allerdings müssen wir zwischen Werten wie Impulsen und Absolutwerten
(wie Temperatur etc.) unterscheiden!
Machen wir sowieso schon anhand von entities.type bzw. dem, was in
EntityDefinition.json steht.
btw, die Bezeichnungen dort sind nicht korrekt. Wie Jens schon angemerkt
hat, sind die Strommeter ja Energiezähler und keine Leistungsmesser,
auch wenn wir im Frontend das als Leistung darstellen. Dementsprechend
müßte der Name "work" oder "energy" und nicht "power" sein. Die Einheit
"kW/h" ist allerdings daneben. Mit den Strommetern messen wir "kWh",
wenn man das als Leistung darstellt, sind das "kWh/h" oder einfach "kW".
Das mag jetzt ein bisschen kleinlich erscheinen, aber das ist m.E.
notwendig, wenn jemand einen echten Leistungsmesser anschließen möchte.

> Schön hier jemanden mit etwas weitergehenden Datenbankkentnissen auf der
> Liste zu haben :)
> So Kommentare helfen echt weiter ;)

Äh, ja, gerne :)


Gruß
J