volkszaehler / volkszaehler.org

Open Source Smart Meter with focus on privacy - you remain the master of your data.
https://volkszaehler.org
GNU General Public License v3.0
212 stars 84 forks source link

Fehlerhafte Berechnung bei weit auseinanderliegenden Messpunkten #665

Closed mtdcr closed 6 years ago

mtdcr commented 6 years ago

Ich hatte seit letztem Sommer keine neuen Messwerte mehr in der Datenbank und das System nun neu aufgesetzt.

Wenn ich mir einen beliebigen Zeitraum zwischen Sommer und gestern anzeigen lasse, wird mir darin stets derselbe Verbrauch angezeigt (z.B. bei „El. Energie (Zählerstände)“). Das liegt vermutlich daran, dass die Wertedifferenz nicht auf den ausgewählten Zeitraum skaliert wird.

Beispiel aus CSV export:

# source:;volkszaehler.org
# version:;0.3

# uuid:;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# title:;xxxxxxxxxxxxxxxxxx
# from:;2017-08-08 14:13:05
# to:;2018-01-24 20:45:03
# min:;2018-01-24 20:45:03; => ;0
# max:;2018-01-24 20:44:59; => ;876.986
# average:;876.984
# consumption:;3563652
# rows:;4
2017-08-08 14:14:05;300;1
2018-01-24 20:44:59;876.986;1
2018-01-24 20:45:03;0;1
# database:;pdo_mysql
# time:;0.02569
# uptime:;3642332770# load:;0.41, 0.29, 0.28
# commit-hash:;a74415fae1a2e52207d45ba3753484f2f995cccf# php-version:;xxxxxxxxxxxxxx# query:;SELECT e0_.id AS id_0, e0_.uuid AS uuid_1, e0_.type AS type_2, p1_.id AS id_3, p1_.pkey AS pkey_4, p1_.value AS value_5, e0_.class AS class_6, p1_.entity_id AS entity_id_7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid = ?) AND e0_.class IN ('channel', 'aggregator') ORDER BY p1_.pkey ASC
# query:;SELECT MAX(timestamp) FROM data WHERE channel_id=? AND timestamp < (SELECT MAX(timestamp) FROM data WHERE channel_id=? AND timestamp<?)
# query:;SELECT MIN(timestamp) FROM data WHERE channel_id=? AND timestamp>?
# query:;SELECT aggregate.type, COUNT(aggregate.id) AS count FROM aggregate INNER JOIN entities ON aggregate.channel_id = entities.id WHERE uuid = ? GROUP BY type HAVING count > 0 ORDER BY type DESC
# query:;SELECT COUNT(1) FROM data WHERE channel_id = ? AND timestamp >= ? AND timestamp <= ?
# query:;SELECT timestamp, value, 1 AS count FROM data WHERE channel_id=? AND timestamp >= ? AND timestamp <= ? ORDER BY timestamp ASC

Die hierfür im Frontend angezeigten 3,56MW sind der halbe Jahresverbrauch. Der ausgewählte Zeitraum ist aber nur 4s lang.

frankrichter commented 6 years ago

Die Middleware rechnet nur mit vorhandenen Datensätzen, es wird nicht interpoliert.

andig commented 6 years ago

Thema für die Maillingliste, kein Softwarefehler?

mtdcr commented 6 years ago

An wen richtet sich die Frage? Für mich steht fest, dass es ein Softwarefehler ist. Es sei denn man argumentiert, dass Designfehler keine Softwarefehler seien, weil die Software tut, was sie soll - nämlich ungenaue Ergebnisse zu produzieren, wie z.B. die Anzeige in der VolkszählerApp, dass wir sowohl monatlich, als auch wöchtentlich und täglich, durchschnittlich Stromkosten über 800 Euro hätten, obwohl der tatsächliche Durchschnitt durchaus richtig berechnet werden könnte.

Letztendlich ist ein knappes halbes Jahr ohne Messwerte nur eine vergrößerte Darstellung des Problems, das immer dann in Erscheinung tritt, wenn nicht exakt zur Startzeit eines Betrachtungszeitraums ein Messpunkt lag.

andig commented 6 years ago

Funktioniert wie vorgesehen. Für Deinen ausgewählten Zeitraum gibt es nicht genug Daten und eine Interpolation der Meßwerte zwischen 2 entfernten Meßwerten außerhalb des Intervalls findet nicht statt.

Fraglich ist allerdings ob Du für eine Auswertung nach dem letzten Intervall überhaupt einen Wert bekommen solltest (ist das hier der Fall)?

Nicht gut dokumentiert, aber für alle "Randfälle" hat VZ die implizite Annahme dass an den Intervallgrenzen genug Meßwerte vorhanden sind. Das gilt bei Aggregation (GROUP BY) auch für jedes Intervall innerhalb des Auswertungszeitraumes.

mtdcr commented 6 years ago

q.e.d.

andig commented 6 years ago

obwohl der tatsächliche Durchschnitt durchaus richtig berechnet werden könnte.

Gute Idee, aber alles andere als trivial. Machst Du einen PR?