Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1/12 Volker v...@gmx.de Hallo, ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/ volkszaehler/volkszaehler.org.git). Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der Version die ich am 3.1. installiert habe. Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert aktuell in der Statistik war eigentlich schon immer fehlerhaft , wenn keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon etwas schräg ;) Gruß Volker -- Volker Troyke Homepage: www.troyke.de E-Mail : v...@gmx.de
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hi Volker, 2014/1/12 Volker v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal reinschauen... Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert eigentlich 0 stehen. S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken, für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min eine 0 loggen könntest, dann wäre die Sache eindeutig. Gruß Volker Was mich wundert ist dass nicht auch andere Anwender das Problem der Nullwerte haben und schon immer hatten? vg Andreas Am 12.01.2014 13:19 schrieb Andreas Goetz: Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de Hallo, ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/__volkszaehler/volkszaehler.org.__git http://github.com/volkszaehler/volkszaehler.org.git). Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der Version die ich am 3.1. installiert habe. Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert aktuell in der Statistik war eigentlich schon immer fehlerhaft , wenn keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon etwas schräg ;) Gruß Volker -- Volker Troyke Homepage: www.troyke.de http://www.troyke.de E-Mail : v...@gmx.de mailto:v...@gmx.de -- Volker Troyke Homepage: www.troyke.de E-Mail : v...@gmx.de
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hi Andreas, das mit der Statistik war schon immer so. Die S0 Impulse schreibt ein AVR-Netio ein mal pro Minute in die Datenbank, aber ich vermute eben nicht, wenn gar kein Impuls kam. 0-Werte werden in der Datenbank so nicht auftauchen. Da muss ich mir das Teil mal ansehen, ob ich dem beibringen kann die Updates auch zu machen, wenn gar kein Impuls kam... Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ja ok wenn aber zwischen dem vorletzten Datenbankeintrag und dem letzten einige Minuten oder Stunden Zeit vergangen ist, muss der Verbrauchswert _dazwischen_ aber auch sehr klein oder fast 0 sein. Bei der aktuellen middleware wird der vorletzte und letzte Datenbankeintrag einfach mit einer Geraden auf der Höhe des letzten Verbrauchswerts verbunden. Und das stimmt so nicht. Der Verbrauchswert in der Statistik stimmt jedoch. Ich kann Dir eine SQL-Dump der letzen 3 Jahre zukommen lassen, das sind aber gezippt 18MB. Ich habe Dir den Link als PM geschickt. Das mit dem git reset habe ich versucht, die Darstellung ändert sich irgendwie nicht. Ist das richtig git reset feb7ca2b5fe3aa3023e7e640a6aaf4fd207ad95f um den letzten merge rückgängig zu machen? Egal auf welchen commit ich resette, die Darstellung ist immer falsch. Nur die Version die ich am 3.1. mit dem Install script installiert habe funktioniert... (und alles davor). Gruß Volker Am 12.01.2014 14:10 schrieb Andreas Goetz: Hi Volker, 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal reinschauen... Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert eigentlich 0 stehen. S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken, für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min eine 0 loggen könntest, dann wäre die Sache eindeutig. Gruß Volker Was mich wundert ist dass nicht auch andere Anwender das Problem der Nullwerte haben und schon immer hatten? vg Andreas Am 12.01.2014 13:19 schrieb Andreas Goetz: Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/__volkszaehler/volkszaehler.org/__pull/87 https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de mailto:v...@gmx.de mailto:v...@gmx.de Hallo, ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/volkszaehler/volkszaehler.org.git http://github.com/__volkszaehler/volkszaehler.org.__git http://github.com/__volkszaehler/volkszaehler.org.__git http://github.com/volkszaehler/volkszaehler.org.git). Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der Version die ich am 3.1. installiert habe. Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert aktuell in der Statistik war eigentlich schon immer fehlerhaft
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hi, 2014/1/12 Volker v...@gmx.de Hi Andreas, das mit der Statistik war schon immer so. Die S0 Impulse schreibt ein AVR-Netio ein mal pro Minute in die Datenbank, aber ich vermute eben nicht, wenn gar kein Impuls kam. 0-Werte werden in der Datenbank so nicht auftauchen. Da muss ich mir das Teil mal ansehen, ob ich dem beibringen kann die Updates auch zu machen, wenn gar kein Impuls kam... Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ja ok wenn aber zwischen dem vorletzten Datenbankeintrag und dem letzten einige Minuten oder Stunden Zeit vergangen ist, muss der Verbrauchswert _dazwischen_ aber auch sehr klein oder fast 0 sein. korrekt. Nicht 0 aber nahe dran. Bei der aktuellen middleware wird der vorletzte und letzte Datenbankeintrag einfach mit einer Geraden auf der Höhe des letzten Verbrauchswerts verbunden. Das klingt falsch. Darstellung steps? Mal schauen ob lines einen Unterschied macht. Und das stimmt so nicht. Der Verbrauchswert in der Statistik stimmt jedoch. Ich kann Dir eine SQL-Dump der letzen 3 Jahre zukommen lassen, das sind aber gezippt 18MB. Ich habe Dir den Link als PM geschickt. Angekommen, danke! Das mit dem git reset habe ich versucht, die Darstellung ändert sich irgendwie nicht. Ist das richtig git reset feb7ca2b5fe3aa3023e7e640a6aaf4fd207ad95f um den letzten merge rückgängig zu machen? Du musst die Nummer des Commits eingeben auf den Du kommen willst- also den davor. Im master Zweig ist der letzte vom 3. Januar (siehe git log): commit 7431faf4c6ebe7b18349919a02ed90a9fca3fac3 Author: andig cpui...@gmx.de Date: Wed Jan 1 18:52:20 2014 +0100 Allow --eval to access arrays by index Also git reset 7431faf4c6ebe7b18349919a02ed90a9fca3fac3 bzw. schrittweise von neu nach alt an diesen Zeitpunkt herantasten. Es wäre wirklich hilfreich wenn Du herausfinden könntest welcher Commit das Problem macht. Egal auf welchen commit ich resette, die Darstellung ist immer falsch. Nur die Version die ich am 3.1. mit dem Install script installiert habe funktioniert... (und alles davor). Dann müsste sich das mittels git reset ebenfalls hinbekommen lassen. Ist leider der einzige Weg den Schuldigen zu finden... vg Andreas Gruß Volker Am 12.01.2014 14:10 schrieb Andreas Goetz: Hi Volker, 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal reinschauen... Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert eigentlich 0 stehen. S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken, für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min eine 0 loggen könntest, dann wäre die Sache eindeutig. Gruß Volker Was mich wundert ist dass nicht auch andere Anwender das Problem der Nullwerte haben und schon immer hatten? vg Andreas Am 12.01.2014 13:19 schrieb Andreas Goetz: Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/__volkszaehler/volkszaehler.org/__pull/87 https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Also... 2014/1/12 Andreas Goetz cpui...@gmail.com Hi Volker, 2014/1/12 Volker v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Das Verhalten für 20:30 lässt sich erklären: commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a Merge: feb7ca2 ff2ced5 Author: Justin Otherguy 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. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Für die Wochendarstellung ok/aktuell ist die Ursache eine andere. Hier liegts daran, dass auf aggregierte Werte mit geringerer zeitlicher Auflösung (groupy=hour) zurückgegriffen wird. Wenn Dir das nicht gefällt kannst Du mal in der options.js mit der Variable speedupFactor rumspielen. Kleinere Werte bringen bessere Auflösung, sind aber auch langsamer wenn das FE dann kein groupby mehr auswählt... Erklärung nachvollziehbar und Problem gelöst? vg Andreas ...
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Am 12.01.2014 16:26 schrieb Andreas Goetz: Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Das ist vermutlich das Problem, dass der Ethersex Watchasync niemals Datenbankeinträge mit 0 schreibt, sondern erst wieder wenn Impulse eintreffen. Das erklärt die falsche Statistik für aktuell. Das Verhalten für 20:30 lässt sich erklären: 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. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Für die Wochendarstellung ok/aktuell ist die Ursache eine andere. Hier liegts daran, dass auf aggregierte Werte mit geringerer zeitlicher Auflösung (groupy=hour) zurückgegriffen wird. Ja aber auch hier darf in Zeitfenstern mit 0-Verbrauch die steps Linie nicht auf dem letzten wert kleben bleiben, weil das nicht der Realität entspricht. In der Datenbank werden in den Intervallen mit nahezu 0 Verbrauch auch keine S0-Impulse stehen. Es funktioniert ja auch mit der alten Version. Ich versuche das noch mal mit dem schrittweisen git reset. Würde es Dir helfen wenn ich Dir die funktionierende Version einfach mal vom Server abziehe und zukommen lasse? Wenn Dir das nicht gefällt kannst Du mal in der options.js mit der Variable speedupFactor rumspielen. Kleinere Werte bringen bessere Auflösung, sind aber auch langsamer wenn das FE dann kein groupby mehr auswählt... Erklärung nachvollziehbar und Problem gelöst? Die Erklärung warum das jetzt anders ist habe ich glaube ich verstanden, nur mit dem Endresultat der Darstellung bin ich gar nicht einverstanden ;) Gruß Volker -- Volker Troyke Homepage: www.troyke.de E-Mail : v...@gmx.de
[vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hallo zusammen,
beim Installieren der neuen aggregate-Tabelle von Andi bin ich mehr oder
weniger zufällig beim Betrachten der mysql-logs darauf gestoßen, dass
jedes s0-Event neben dem eigentlichen Insert offenbar immer auch einen
join und drei Updates ausführt:
911 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 =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1' WHERE
id = 71
911 Query UPDATE properties SET value = '1' WHERE
id = 69
911 Query UPDATE properties SET value = '1000'
WHERE id = 67
911 Query commit
Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).
Was mich wundert: warum muss der aufwändige join vorher ausgeführt
werden? Liefert bei mir z.B.
+-+--+---+--++-+-++
| id0 | uuid1| type2 | id3 | pkey4
| value5 | class6 | entity_id7 |
+-+--+---+--++-+-++
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 71 | active
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 70 | color
| navy| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 69 | public
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 67 | resolution
| 1000| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 72 | style
| steps | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 68 | title
| Strom-Ferienwohnung | channel | 14 |
+-+--+---+--++-+-++
6 rows in set (0.00 sec)
Muss das wirklich vor jedem Insert sein? Andi hat sich im Originalthread
ja schon dazu geäußert:
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Ok, soll mir recht sein.
Aber danach werden _immer_ die Werte für resolution, active und public
geupdatet (Unnötig, sind die alten Werte)
- das sind drei sinnlose Updates pro s0-insert.
Da die s0-Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last
4kWh, PV-Wechselsrichter gern auch mal 12kWh, zudem zwei
Geschoss-Stromzähler), könnt ich mir vorstellen, dass das ziemlich viel
unnötige Queries auslöst. Da kommt insgesamt schon einiges zusammen -
und wenn zu jedem Insert eines neuen Werts drei überflüssige Updates
kommen, ist mir klar, warum meine kleine Kiste etwas schwächelt...
Frage deswegen: Ist die Problematik bekannt? Kann das optimiert werden?
Vielen Dank und schöne Grüße!
Heiko
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hi Heiko, das hat aber nichts mit *S0VZ* zu tun, der Deamon macht keine Datenbankzugriffe ... Am 12. Januar 2014 21:53 schrieb Heiko Baumann h...@gmx.de: beim Installieren der neuen aggregate-Tabelle von Andi bin ich mehr oder weniger zufällig beim Betrachten der mysql-logs darauf gestoßen, dass jedes s0-Event neben dem eigentlichen Insert offenbar immer auch einen join und drei Updates ausführt:schnell. -- Grü|3e H3nr!k https://github.com/w3llschmidt
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
...und ist auch schon behoben?! Viele Grüße, Andreas Am 12.01.2014 um 22:15 schrieb W3ll Schmidt w3llschm...@gmail.com: Hi Heiko, das hat aber nichts mit S0VZ zu tun, der Deamon macht keine Datenbankzugriffe ... Am 12. Januar 2014 21:53 schrieb Heiko Baumann h...@gmx.de: beim Installieren der neuen aggregate-Tabelle von Andi bin ich mehr oder weniger zufällig beim Betrachten der mysql-logs darauf gestoßen, dass jedes s0-Event neben dem eigentlichen Insert offenbar immer auch einen join und drei Updates ausführt:schnell. -- Grü|3e H3nr!k https://github.com/w3llschmidt
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
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?
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?
Danke und gute Nacht :)
Heiko
Am 12.01.2014 22:25, schrieb Andreas Götz:
...und ist auch schon behoben?!
Am 12.01.2014 um 22:15 schrieb W3ll Schmidt w3llschm...@gmail.com
mailto:w3llschm...@gmail.com:
Hi Heiko,
das hat aber nichts mit *S0VZ* zu tun, der Deamon macht keine
Datenbankzugriffe ...
