Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?

[Andreas Goetz]

Hallo Heiko,

2014/1/12 Heiko Baumann h...@gmx.de

  Hm. Ich hab vorhin mit git pull meinen vz geupdatet:

 pi@BauratPi /var/www/volkszaehler.org $ sudo git pull
 remote: Counting objects: 73, done.
 remote: Compressing objects: 100% (70/70), done.
 remote: Total 73 (delta 29), reused 34 (delta 3)
 Unpacking objects: 100% (73/73), done.
 From git://github.com/volkszaehler/volkszaehler.org
ec0c82d..ba113f6  master - origin/master
 Updating ec0c82d..ba113f6
 Fast-forward
  .../Interpreter/CounterInterpreter.php |   27 ++
  lib/Volkszaehler/Interpreter/MeterInterpreter.php  |3 +-
  .../Interpreter/SQL/MySQLAggregateOptimizer.php|   90
 +++-
  lib/Volkszaehler/Interpreter/SQL/SQLOptimizer.php  |3 +-
  lib/Volkszaehler/Interpreter/SensorInterpreter.php |3 +-
  lib/Volkszaehler/Model/Property.php|   13 ++-
  lib/Volkszaehler/View/CSV.php  |   52 +++
  lib/Volkszaehler/View/JSON.php |   32 ++-
  lib/Volkszaehler/View/JpGraph.php  |8 +-
  lib/Volkszaehler/View/XML.php  |   80
 ++---
  misc/tools/vzclient|   16 ++--
  test/Tests/DataCounterTest.php |2 +-
  test/Tests/DataMeterTest.php   |2 +-
  13 files changed, 135 insertions(+), 196 deletions(-)

  - damit sollten doch alle updates drin sein, oder?


Ja- Commit 8ac2c5039273b590aec2a9890f87400c08b949a8 liegt dazwischen.



 Im mysql-log gehts aber nach wie vor extrem wüst zu:
 17345 Connect   vz@localhost on volkszaehler
 17345 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
 e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
 e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
 JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
 'ae9d1b00-f2f5-11e2-8a1f-0dad1c039958') AND e0_.class IN ('channel',
 'aggregator') ORDER BY p1_.pkey ASC
 140112 22:33:47 17345 Query START TRANSACTION
 17345 Query INSERT INTO data (timestamp, value,
 channel_id) VALUES ('1389562426842', '1', 16)
 17345 Query UPDATE properties SET value = '1' WHERE id
 = 83
 17345 Query UPDATE properties SET value = '1' WHERE id
 = 81
 17345 Query UPDATE properties SET value = '360'
 WHERE id = 79
 17345 Query commit
 17345 Quit

 Insofern also alles beim alten. Wie krieg ich die neueste Version?


Ich kann's nicht mehr nachvollziehen:

SELECT e0_.id AS id0, e0_.uuid AS uuid1, e0_.type AS type2, p1_.id AS id3,
p1_.pkey AS pkey4, p1_.value AS value5, e0_.class AS class6, p1_.entity_id
AS entity_id7 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
START TRANSACTION
INSERT INTO data (timestamp, value, channel_id) VALUES (?, ?, ?)
COMMIT

Bist Du sicher dass der Code den Du siehst auch wirklich der ist der
ausgeführt wird?

vg
Andreas

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hallo Volker,

über die Wochenansicht muss ich nochmal nachdenken, bei der Tagesansicht
ist alles- bis auf Verschiebung um einen TS- ok.

2014/1/12 Volker v...@gmx.de

 ...

 commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a
 Merge: feb7ca2 ff2ced5
 Author: Justin Otherguy jus...@justinotherguy.org
 mailto:jus...@justinotherguy.org

 Date:   Sun Jan 12 03:26:35 2014 -0800

  Merge pull request #87 from andig/master-timestampfix

  Make all interpreters use timestamp at end of period

 Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die
 Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt;
 aber
 halt anders. gleiches Bild, der 0-Wert wird nur später erreicht.
 Schau Dir für eine Erklärung gerne mal den PR an.


 Ich stecke jetzt in den Details nur wenig drin, ich finde nur das die
 grafische Darstellung falsch ist. Um bei dem Beispiel des Tageswertes zu
 bleiben: Um ca. 20:15 wird ein Eintrag mit n S0-Impulsen in die Datenbank
 geschrieben. Der Verbrauch geht danach auf nahezu 0. Um ca. 21:15 wird
 vermutlich ein einziger S0-Impus in die Datenbank geschrieben. Dann
 berechnet sich doch der Momentanverbrauch zwischen 20:15 und 21:15 aus der
 Zeitspanne (hier 1 Stunde) und dem in der Zeit aufgelaufenen Impulsen (hier
 1). Die grafisch Darstellung und auch der Cursor zeigt in dem Zeitfenster
 aber irgendwas von 570W - und das ist schlichweg falsch.




Dazu gehören folgende Timestamps (CSV Export und DB-Werte), Uhrzeit habe
ich mit ausgerechnet:

   1388775808000 591
20:03:28
DB  1388775872000 618,75
20:04:32 22  1388775936000 591
20:05:36 21  138877600 253
20:06:40 9  1388780096000 0,439
21:14:56 1  1388780288000 9
21:18:08 1  1388781888000 20,25
21:44:48 18
Bis 20:04 feuert S0 ordentlcih, Leistung  500.
bis 20:06 gehen die Impulse deutlich zurück Leistung 253 (der Abfall)
Erst 21:14 kommt wieder was- Leistung annähernd 0.

Was jetzt tatsächlich unschön ist ist, dass die Steps einen Timestamp
verschoben scheinen, also step-after statt step-before. Der Effekt
tritt auf da die MW-Timestamps jetzt korrekt sind, eigentlich ist die
Grafik falsch.

Ich muss mal schauen ob sich das sinnvoll ändern lässt, zur Not muss der
commit wieder raus.

vg
Andreas