Re: [vz-dev] Alternative Implementierung für vzcompress
Am Montag, 15. April 2013 um 22:15 schrieb Florian Knodt: Am 2013-04-14 12:50, schrieb Daniel Lauckner: Scheint so als würde das Script die letze Zeile falsch interpretieren. oh ja, stimmt, da ist was in der Schleife faul Und ist repariert. Danke! Bislang hab ich mit der aktuellen Version keine Probleme gehabt. mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
On Fri, 26 Apr 2013 22:49:55 +0200 sollner11 p...@macpat.de wrote: hallo, vzlogger2 lief jetzt bei mir sauber durch vzlogger2? hab' ich was verpasst? [Bildschirmfoto 2013-04-26 um 22.17.24.png] das waehren 1kb text... oder halt 150kb bitmapgrafik als screenshot eines terminalemulators mit unglaublich schoenem antialiasing (und ekelhafter farbkombination)... (mime-encodet dann 200kb) die du gerade an 100(te?) leute geschickst hast. mein mobilfunk-datentarif bedankt sich uebrigens auch. Frage: wie kann ich in phpmyadmin noch die paar peaks rauslöschen? es müssen ja irgendwelche unsinnigen Zählerstände sein indem du zur richtigen zeit navigiegert und die zum richtigen channel gehoerigen eintraege loeschst? Danke nochmal allen Gruss - T. Am 26.04.2013 um 22:40 schrieb Florian Knodt f.kn...@yotaweb.de: Am 2013-04-25 22:42, schrieb Florian Knodt: Zudem nutzt VZ innodb, welches ebenfalls nochmal mehr Speicher frisst als das übliche MyISAM. Ich ziehe die Aussage zurück - es wird InnoDB genutzt wenn vorhanden. Ich hatte eben versehentlich das schema-create auf einem host mit innodb=OFF ausgeführt und die Tabellen wurden augenscheinlich korrekt mit MyISAM angelegt. Wäre (wenn es nicht im Raspi-Image schon so drin ist) für die Raspi-Nutzer ein Blick wert, denn Speichertechnisch sollte MyISAM wie erwähnt (auf Kosten der Geschwindigkeit) besser abschneiden. -- Mit freundlichen Grüßen || Sincerely yours Florian Knodt ·· Im Teich 11 ·· 56648 Saffig www.adlerweb.info · www.56648.de · @adlerweb
Re: [vz-dev] Alternative Implementierung für vzcompress
haben sie dir ein bier gegeben auf dem camp? ;-) Am 27.04.2013 um 15:23 schrieb Thorben Thuermer r...@constancy.org: On Fri, 26 Apr 2013 22:49:55 +0200 sollner11 p...@macpat.de wrote: hallo, vzlogger2 lief jetzt bei mir sauber durch vzlogger2? hab' ich was verpasst? [Bildschirmfoto 2013-04-26 um 22.17.24.png] das waehren 1kb text... oder halt 150kb bitmapgrafik als screenshot eines terminalemulators mit unglaublich schoenem antialiasing (und ekelhafter farbkombination)... (mime-encodet dann 200kb) die du gerade an 100(te?) leute geschickst hast. mein mobilfunk-datentarif bedankt sich uebrigens auch. Frage: wie kann ich in phpmyadmin noch die paar peaks rauslöschen? es müssen ja irgendwelche unsinnigen Zählerstände sein indem du zur richtigen zeit navigiegert und die zum richtigen channel gehoerigen eintraege loeschst? Danke nochmal allen Gruss - T. Am 26.04.2013 um 22:40 schrieb Florian Knodt f.kn...@yotaweb.de: Am 2013-04-25 22:42, schrieb Florian Knodt: Zudem nutzt VZ innodb, welches ebenfalls nochmal mehr Speicher frisst als das übliche MyISAM. Ich ziehe die Aussage zurück - es wird InnoDB genutzt wenn vorhanden. Ich hatte eben versehentlich das schema-create auf einem host mit innodb=OFF ausgeführt und die Tabellen wurden augenscheinlich korrekt mit MyISAM angelegt. Wäre (wenn es nicht im Raspi-Image schon so drin ist) für die Raspi-Nutzer ein Blick wert, denn Speichertechnisch sollte MyISAM wie erwähnt (auf Kosten der Geschwindigkeit) besser abschneiden. -- Mit freundlichen Grüßen || Sincerely yours Florian Knodt ·· Im Teich 11 ·· 56648 Saffig www.adlerweb.info · www.56648.de · @adlerweb
Re: [vz-dev] Alternative Implementierung für vzcompress
Frage: wie kann ich in phpmyadmin noch die paar peaks rauslöschen? es müssen ja irgendwelche unsinnigen Zählerstände sein indem du zur richtigen zeit navigiegert du meinst, ich brauch für das vz-projekt ne pappwand mit anleitungen, die strikt einzuhalten sind? wie bei einem russischen Kernkraftwerk? Software ist gut, wenn sie mich aushält oder Dieter ... oder Bernd ;-) und die zum richtigen channel gehoerigen eintraege loeschst? es sind alles Zählerstände, bei denen ein folgender Wert kleiner ist als der (falsche) Vorgänger und sind sicher das Ergebnis eines abgekackten vzlogger kann man die nicht einfach gleich verwerfen? P.
Re: [vz-dev] Alternative Implementierung für vzcompress
hallo, nochmaliger versuch: aber zuerst mysqldump inkl. Fehlermeldungen oot@raspberrypi:/home/pi/bin# ./mysql-backup Sichere Datenbank volkszaehler in Datei /home/pi/backup/mysql/20130425_2033-mysqldump-volkszaehler.bz2 mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `data` at row: 1610089 -rw-r- 1 root root 14M Apr 25 20:37 /home/pi/backup/mysql/20130425_2033-mysqldump-volkszaehler.bz2 root@raspberrypi:/home/pi/bin# ./mysql-backup Sichere Datenbank volkszaehler in Datei /home/pi/backup/mysql/20130425_2037-mysqldump-volkszaehler.bz2 mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect -rw-r- 1 root root 14 Apr 25 20:37 /home/pi/backup/mysql/20130425_2037-mysqldump-volkszaehler.bz2 root@raspberrypi:/home/pi/bin# dmesg | grep Kill [188519.226013] Out of memory: Kill process 2521 (mysqld) score 617 or sacrifice child [188519.226036] Killed process 2521 (mysqld) total-vm:327616kB, anon-rss:51932kB, file-rss:0kB [190498.491819] Out of memory: Kill process 25926 (mysqld) score 615 or sacrifice child [190498.491838] Killed process 25926 (mysqld) total-vm:326240kB, anon-rss:77008kB, file-rss:0kB Fehler bei vzcompress2.php folgen Gruss Am 24.04.2013 um 17:08 schrieb sollner11 p...@macpat.de: dmesg | grep Kill
Re: [vz-dev] Alternative Implementierung für vzcompress
On Thu, 25 Apr 2013 20:39:24 +0200 sollner11 p...@macpat.de wrote: mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `data` at row: 1610089 root@raspberrypi:/home/pi/bin# dmesg | grep Kill [188519.226036] Killed process 2521 (mysqld) total-vm:327616kB, anon-rss:51932kB, file-rss:0kB [190498.491819] Fehler bei vzcompress2.php folgen kannst du dir sparen. du hast wie vermutet eindeutig zuwenig ram in deinem himbeerkuchen, um diese datenbank zu bearbeiten. wenn nichtmal mysqldump moeglich ist, ist das schon bedenklich. eine moeglichkeit waehre noch, dass die tabelle beschaedigt ist (bei den vielden kills kein wunder), mysql eine automatische reparatur versucht, und dafuer dann das ram nicht reicht. in jedem fall bleibt dir nur, entweder mehr ram freizuschaufeln, oder eine auslagerungsdatei dazuzunehmen (wird aber langsam sein), und/oder die datenbank (notfalls in binaerform wenn dumpen nicht klappt) auf ein system mit mehr ram zu uebertragen und dort zu verkleinern. Gruss - T. Am 24.04.2013 um 17:08 schrieb sollner11 p...@macpat.de: dmesg | grep Kill
Re: [vz-dev] Alternative Implementierung für vzcompress
On Tue, 23 Apr 2013 23:05:11 +0200 Florian Knodt f.kn...@yotaweb.de wrote: Naend, Am 2013-04-23 19:00, schrieb sollner11: macht man nochmal, geht er paar minuten weiter und steigt wieder aus sollte man irgendwas ausschalten? (mysql, vzlogger usw.) [...] string(44) Lost connection to MySQL server during query der Datenbankserver trennt laut Meldung die Verbindung. hoechstwahrscheinlich weil der kernel wegen speichermangel den mysql-prozess beendet, einfach mal: dmesg | grep Kill - T.
Re: [vz-dev] Alternative Implementierung für vzcompress
On Wed, 24 Apr 2013 16:40:04 +0200 sollner11 p...@macpat.de wrote: der Datenbankserver trennt laut Meldung die Verbindung. hoechstwahrscheinlich weil der kernel wegen speichermangel den mysql-prozess Ich habe ja keine Ahnung, allerdings konnts ich in TOP beobachten, wie ein Prozess nach oben kam ich kann mich nicht genau erinnern, kswap, oder so? nach google aber auf jeden Fall etwas, dass Speicher umsortiert, freimacht...keine Ahnung interessanter sind die angaben ueber den freien speicher, hast du ueberhaupt eine swap partition/datei? wobei das auf einem himbeerkuchen auch wenig hilft, da der langsame zugriff auf eine sd-karte oder eine platte am usb das problem nicht unbedingt loest. beendet, einfach mal: dmesg | grep Kill also: dmesg | grep Kill ausführen und dann das script starten? nein, das ausfuehren, nachdem der fehler aufgetreten ist, das sucht (grep Killed) die entsprechende meldung aus dem kernel-log (dmesg). (es koennte auch klappen, dass die meldung vom letzten versuch noch im log steht) sieht dann zB so aus: [21748986.774751] Killed process 4662 (firefox) muss oder sollte man mysql und den logger anhalten? du kannst mysql nicht anhalten, um vzcompress auszufuehren, weil vzcompress ueber mysql auf die daten zugreift...!!! vzlogger braucht nicht soviel resourcen, als dass es einen unterschied machen wuerde. im zweifallsfall musst du (einmalig?) deine datenbank auf einen leistungsfaehigeren rechner kopieren, um sie mit vzcompress zu bearbeiten. - T.
Re: [vz-dev] Alternative Implementierung für vzcompress
nein ... geht nichts
eine Datenbank mit 4 Kanälen, Laufzeit ein Monat
er rödelt ne Weile
bei manchen Zeitpunkten ist es sehr zäh ... man sieht die minuten langsam an
sich vorbeiziehen
dann hängt er an einzelnen Minuten fest ... steigt aus
macht man nochmal, geht er paar minuten weiter und steigt wieder aus
sollte man irgendwas ausschalten? (mysql, vzlohher usw.)
Gruss
Am 21.04.2013 um 20:14 schrieb sollner11 p...@macpat.de:
Hallo,
EntityDefinition.json ist die richtige
ja, hatte es da gemacht
er rödelt noch:
Processing Sensor ID 4...
Compressing datapoints between 05.01.2013 18:14:54 and 19.03.2013 17:52:25
using a 60 second timeframe
Removed 3028791 Datapoints in 6013 Seconds.
Processing Sensor ID 6...
Compressing datapoints between 05.01.2013 18:14:54 and 19.03.2013 17:52:27
using a 60 second timeframe
Removed 2019882 Datapoints in 5202 Seconds.
Processing Sensor ID 7...
Compressing datapoints between 05.01.2013 18:41:50 and 19.03.2013 17:52:25
using a 60 second timeframe
Processing: 07.02.2013 02:15:50 - 07.02.2013 02:16:50 (44%)...
das ist der mit der alten (nicht aktiven) Installation
der andere (aktive) ist irgendwann ausgestiegen:
root@raspberrypi:/var/www/volkszaehler.org/misc/tools# php vzcompress2.php
Processing Sensor ID 2...
Compressing datapoints between 21.03.2013 18:32:45 and 21.04.2013 00:30:58
using a 60 second timeframe
Processing: 29.03.2013 14:18:45 - 29.03.2013 14:19:45 (26%)...
array(3) {
[0]=
string(5) HY000
[1]=
int(2013)
[2]=
string(44) Lost connection to MySQL server during query
}
werde ich mal nachts machen, und den vzlogger killen
Gruss
Re: [vz-dev] Alternative Implementierung für vzcompress
Naend, Am 2013-04-23 19:00, schrieb sollner11: macht man nochmal, geht er paar minuten weiter und steigt wieder aus sollte man irgendwas ausschalten? (mysql, vzlohher usw.) [...] string(44) Lost connection to MySQL server during query der Datenbankserver trennt laut Meldung die Verbindung. Sind irgendwelche Query-Limits für den VZ-User gesetzt? Andernfalls kenne ich das Phänomen nur von überlasteten oder defekten MySQL-Servern, letzeres trat in letzter Zeit bei mir öfter auf, irgendwie zerschießen die letzten Versionen bei mir auf mehreren Systemen die Datenbanken am Fließband - nach export/import ging es bei den meisten wieder. Dummerweise hats meinen VZ auch gestern erwischt, dort wollte ich jetzt in Einem auf MariaDB umsteigen, daher kann ich grade nicht groß testen. Sollte es doch Überlastung sein hab ich jetzt mal eine Delay-Funktion eingebaut um die Requests händisch auszubremsen, unten mal mit verschiedenen Werten testen. -- Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo,
ich möchte nun noch meine DB schrumpfen.
1. ich hole mir das Script
2. ich lege in /misc/tools/ die vzcompress2.php an
3.
Was muss ich alles editieren?
4. Pfad
define('VZCOMPRESS2_VZPATH', '../../');
was kommt da rein?
5. compressscheme
muss ich Channel irgendwie editieren, wenn ich alle haben will?
Danke und Gruss
Sillner11
Am 16.04.2013 um 23:07 schrieb Florian Knodt f.kn...@yotaweb.de:
Nabend,
Am 2013-04-16 10:55, schrieb Andreas Goetz:
Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende
und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt
sollte das ähnlich funktionieren.
Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0)
weglässt, ist jetzt auch dieser Fall mit abgedeckt.
Moment, Moment, ich glaub mit reinem SQL geht das nicht - wenn ich richtig im
Kopf hab werden bei MeterInterpreter ja die Pulse notiert, also dürften in
dem Fall gleiche Werte 0 nicht gelöscht werden, sonst stimmen die Messwerte
danach nicht mehr. Obs MeterPreter ist steht allerdings nur in der JSON, nit
in der SQL.
...und ggf. nicht so weit im Frontend zoomen kann (...)
Auch ein guter Punkt- aber das gleiche Problem, welches auch bei
Komprimierung der Werte besteht, oder?
Jein - bei der jetzigen Komprimierung hat man ja meist noch recht kleine
Zeiträume - 5Min, 15Min, wegen mir ne Stunde - an einem guten Sonnentag
könnte aber der öffentlich Stromzähler (wenn man sich selbst versorgt) fast
12h ohne Änderung, also mit hierüber gelöschten Messwerten, da stehen. Wird
aber wohl für die meisten Bereiche eher uninteressant sein.
Ich bin gespannt- gibts eigentlich ein GIT dafür?
Nun es liegt zumindest auf Github ;) - ist allerdings eine branch des vz-git,
nichts eigenes nur für das Script.
https://github.com/adlerweb/volkszaehler.org/tree/vzcompress2
--
Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
- VZCompress2 installieren und als Cronjob starten evtl. mit # disabled im
Standard
cd /var/www/volkszaehler.org/misc/tools
sudo
wgethttps://raw.github.com/adlerweb/volkszaehler.org/vzcompress2/misc/tools/vzcompress2.php
sudo nano vzcompress2.php
Zeile /../../ ersetzten durch /var/www/volkszaehler.org/
Sudo crontab -e
Zeile 1 1 * * * php /var/www/volkszaehler.org/misc/tools/vzcompress2.php
/var/log/vzcompress.log hinzufügen, dann Strg+k+x
Mit den besten Grüßen
Bernd Gewehr
Burgstr. 45F
45289 Essen
02014784606
015209328236
Am 21.04.2013 um 15:04 schrieb sollner11 p...@macpat.de:
Hallo,
ich möchte nun noch meine DB schrumpfen.
1. ich hole mir das Script
2. ich lege in /misc/tools/ die vzcompress2.php an
3.
Was muss ich alles editieren?
4. Pfad
define('VZCOMPRESS2_VZPATH', '../../');
was kommt da rein?
5. compressscheme
muss ich Channel irgendwie editieren, wenn ich alle haben will?
Danke und Gruss
Sillner11
Am 16.04.2013 um 23:07 schrieb Florian Knodt f.kn...@yotaweb.de:
Nabend,
Am 2013-04-16 10:55, schrieb Andreas Goetz:
Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende
und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt
sollte das ähnlich funktionieren.
Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0)
weglässt, ist jetzt auch dieser Fall mit abgedeckt.
Moment, Moment, ich glaub mit reinem SQL geht das nicht - wenn ich richtig
im Kopf hab werden bei MeterInterpreter ja die Pulse notiert, also dürften
in dem Fall gleiche Werte 0 nicht gelöscht werden, sonst stimmen die
Messwerte danach nicht mehr. Obs MeterPreter ist steht allerdings nur in der
JSON, nit in der SQL.
...und ggf. nicht so weit im Frontend zoomen kann (...)
Auch ein guter Punkt- aber das gleiche Problem, welches auch bei
Komprimierung der Werte besteht, oder?
Jein - bei der jetzigen Komprimierung hat man ja meist noch recht kleine
Zeiträume - 5Min, 15Min, wegen mir ne Stunde - an einem guten Sonnentag
könnte aber der öffentlich Stromzähler (wenn man sich selbst versorgt) fast
12h ohne Änderung, also mit hierüber gelöschten Messwerten, da stehen. Wird
aber wohl für die meisten Bereiche eher uninteressant sein.
Ich bin gespannt- gibts eigentlich ein GIT dafür?
Nun es liegt zumindest auf Github ;) - ist allerdings eine branch des
vz-git, nichts eigenes nur für das Script.
https://github.com/adlerweb/volkszaehler.org/tree/vzcompress2
--
Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
danke
ich will das an einer SD machen, die bis vor 14 Tagen aktiv war
geht das, obwohl vzlogger nicht läuft und auch keine Optoköpfe dranhängen
ist ein zweiter Raspi, hängt in der Luft sozusagen
Gruss
Am 21.04.2013 um 15:27 schrieb Bernd Gewehr be...@gewehr.net:
- VZCompress2 installieren und als Cronjob starten evtl. mit # disabled im
Standard
cd /var/www/volkszaehler.org/misc/tools
sudo
wgethttps://raw.github.com/adlerweb/volkszaehler.org/vzcompress2/misc/tools/vzcompress2.php
sudo nano vzcompress2.php
Zeile /../../ ersetzten durch /var/www/volkszaehler.org/
Sudo crontab -e
Zeile 1 1 * * * php /var/www/volkszaehler.org/misc/tools/vzcompress2.php
/var/log/vzcompress.log hinzufügen, dann Strg+k+x
Mit den besten Grüßen
Bernd Gewehr
Burgstr. 45F
45289 Essen
02014784606
015209328236
Am 21.04.2013 um 15:04 schrieb sollner11 p...@macpat.de:
Hallo,
ich möchte nun noch meine DB schrumpfen.
1. ich hole mir das Script
2. ich lege in /misc/tools/ die vzcompress2.php an
3.
Was muss ich alles editieren?
4. Pfad
define('VZCOMPRESS2_VZPATH', '../../');
was kommt da rein?
5. compressscheme
muss ich Channel irgendwie editieren, wenn ich alle haben will?
Danke und Gruss
Sillner11
Am 16.04.2013 um 23:07 schrieb Florian Knodt f.kn...@yotaweb.de:
Nabend,
Am 2013-04-16 10:55, schrieb Andreas Goetz:
Bei MeterInterpreter die nullen, bei SensorInterpreter
aufeinanderfolgende und identische Werte würde ich sagen - wenns bei
letzterem gleich bleibt sollte das ähnlich funktionieren.
Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0)
weglässt, ist jetzt auch dieser Fall mit abgedeckt.
Moment, Moment, ich glaub mit reinem SQL geht das nicht - wenn ich richtig
im Kopf hab werden bei MeterInterpreter ja die Pulse notiert, also dürften
in dem Fall gleiche Werte 0 nicht gelöscht werden, sonst stimmen die
Messwerte danach nicht mehr. Obs MeterPreter ist steht allerdings nur in
der JSON, nit in der SQL.
...und ggf. nicht so weit im Frontend zoomen kann (...)
Auch ein guter Punkt- aber das gleiche Problem, welches auch bei
Komprimierung der Werte besteht, oder?
Jein - bei der jetzigen Komprimierung hat man ja meist noch recht kleine
Zeiträume - 5Min, 15Min, wegen mir ne Stunde - an einem guten Sonnentag
könnte aber der öffentlich Stromzähler (wenn man sich selbst versorgt) fast
12h ohne Änderung, also mit hierüber gelöschten Messwerten, da stehen. Wird
aber wohl für die meisten Bereiche eher uninteressant sein.
Ich bin gespannt- gibts eigentlich ein GIT dafür?
Nun es liegt zumindest auf Github ;) - ist allerdings eine branch des
vz-git, nichts eigenes nur für das Script.
https://github.com/adlerweb/volkszaehler.org/tree/vzcompress2
--
Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Ja funktioniert - der greift direkt auf die Datenbank zu, es müssen dazu keine
weiteren Dienste laufen.
Noch ein Hinweis an die anderen hier: inzwischen ist die Funktion mit der
Logdatei mit drin
sollner11 p...@macpat.de schrieb:
danke
ich will das an einer SD machen, die bis vor 14 Tagen aktiv war
geht das, obwohl vzlogger nicht läuft und auch keine Optoköpfe
dranhängen
ist ein zweiter Raspi, hängt in der Luft sozusagen
Gruss
Am 21.04.2013 um 15:27 schrieb Bernd Gewehr be...@gewehr.net:
- VZCompress2 installieren und als Cronjob starten evtl. mit #
disabled im Standard
cd /var/www/volkszaehler.org/misc/tools
sudo
wgethttps://raw.github.com/adlerweb/volkszaehler.org/vzcompress2/misc/tools/vzcompress2.php
sudo nano vzcompress2.php
Zeile /../../ ersetzten durch /var/www/volkszaehler.org/
Sudo crontab -e
Zeile 1 1 * * * php
/var/www/volkszaehler.org/misc/tools/vzcompress2.php
/var/log/vzcompress.log hinzufügen, dann Strg+k+x
Mit den besten Grüßen
Bernd Gewehr
Burgstr. 45F
45289 Essen
02014784606
015209328236
Am 21.04.2013 um 15:04 schrieb sollner11 p...@macpat.de:
Hallo,
ich möchte nun noch meine DB schrumpfen.
1. ich hole mir das Script
2. ich lege in /misc/tools/ die vzcompress2.php an
3.
Was muss ich alles editieren?
4. Pfad
define('VZCOMPRESS2_VZPATH', '../../');
was kommt da rein?
5. compressscheme
muss ich Channel irgendwie editieren, wenn ich alle haben will?
Danke und Gruss
Sillner11
Am 16.04.2013 um 23:07 schrieb Florian Knodt f.kn...@yotaweb.de:
Nabend,
Am 2013-04-16 10:55, schrieb Andreas Goetz:
Bei MeterInterpreter die nullen, bei SensorInterpreter
aufeinanderfolgende und identische Werte würde ich sagen - wenns bei
letzterem gleich bleibt sollte das ähnlich funktionieren.
Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0)
weglässt, ist jetzt auch dieser Fall mit abgedeckt.
Moment, Moment, ich glaub mit reinem SQL geht das nicht - wenn ich
richtig im Kopf hab werden bei MeterInterpreter ja die Pulse notiert,
also dürften in dem Fall gleiche Werte 0 nicht gelöscht werden, sonst
stimmen die Messwerte danach nicht mehr. Obs MeterPreter ist steht
allerdings nur in der JSON, nit in der SQL.
...und ggf. nicht so weit im Frontend zoomen kann (...)
Auch ein guter Punkt- aber das gleiche Problem, welches auch bei
Komprimierung der Werte besteht, oder?
Jein - bei der jetzigen Komprimierung hat man ja meist noch recht
kleine Zeiträume - 5Min, 15Min, wegen mir ne Stunde - an einem guten
Sonnentag könnte aber der öffentlich Stromzähler (wenn man sich selbst
versorgt) fast 12h ohne Änderung, also mit hierüber gelöschten
Messwerten, da stehen. Wird aber wohl für die meisten Bereiche eher
uninteressant sein.
Ich bin gespannt- gibts eigentlich ein GIT dafür?
Nun es liegt zumindest auf Github ;) - ist allerdings eine branch
des vz-git, nichts eigenes nur für das Script.
https://github.com/adlerweb/volkszaehler.org/tree/vzcompress2
--
Florian
--
Mit freundlichen Grüßen || Sincerely yours
Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
www.adlerweb.info · www.56648.de · @adlerweb
Re: [vz-dev] Alternative Implementierung für vzcompress
Ja funktioniert - der greift direkt auf die Datenbank zu, es müssen dazu keine weiteren Dienste laufen. danke hab mal einfach todesmutig eingetippt: root@raspberrypi:/var/www/volkszaehler.org/misc/tools# php vzcompress2.php Processing Sensor ID 4... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 196 PHP Warning: Could not detect inperpreter for type electric meter in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 203 Processing Sensor ID 6... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 196 PHP Warning: Could not detect inperpreter for type electric meter in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 203 Processing Sensor ID 7... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 196 PHP Warning: Could not detect inperpreter for type electric meter in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 203 Processing Sensor ID 9... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 196 PHP Warning: Could not detect inperpreter for type powersensor in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 203 Done. Purged Datapoints from 4 Channels in 0 Seconds ??? hab ich was vergessen zu editieren, oder Noch ein Hinweis an die anderen hier: inzwischen ist die Funktion mit der Logdatei mit drin muss man das noch machen? https://github.com/volkszaehler/volkszaehler.org/pull/43/files Gruss
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo Florian, mit etwas mehr Zeit kann ich Dir jetzt ausführlicher antworten. Zur Erinerung nochmal das Statement (mit kleinen Optimierungen): -- delete - all channels delete from data where id in ( select id from ( select o.channel_id, o.id, ( select max(timestamp) from data i_p where i_p.channel_id = o.channel_id and i_p.timestamp o.timestamp ) as prev_ts, p.id as prev_id, p.value as prev_value, ( select min(timestamp) from data i_n where i_n.channel_id = o.channel_id and i_n.timestamp o.timestamp ) as next_ts, n.id as next_id, n.value as next_value from data o left join data p on p.timestamp = prev_ts and o.channel_id = p.channel_id left join data n on n.timestamp = next_ts and o.channel_id = n.channel_id where o.channel_id in (select id from entities where class = channel) and p.value = o.value and n.value = o.value and o.value = 0 ) ) On 15.04.2013 22:34, Florian Knodt wrote: Nabend die Dritte, das ist jetzt die 0-Wert-Löschung? Er sucht 3 aufeinanderfolgende Werte eines Kanals und löscht wenn alle 0 sind den Mittleren, richtig? Wenn Du Dir das innere SELECT anschaust siehst Du, dass alle Datensätze zurückgegeben werden, die den gleichen Wert aufweisen wie der vorherige und nächste Datensatz im gleichen Kanal- das sind also die innenliegenden Datensätze einer Folge. Mit dem äußeren SELECT wird diese Liste auf die IDs reduziert und der Löschung zugeführt. Die Einschränkung auf Nullwerte erfolgt mit dem letzten Teil der WHERE-Clause. Am 2013-04-14 20:22, schrieb Andreas Goetz: eine Optimierung welche mir für vzcompress noch einfiele wäre die Löschung (nicht nur Komprimierung) redundanter Nullwerte. Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt sollte das ähnlich funktionieren. Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0) weglässt, ist jetzt auch dieser Fall mit abgedeckt. 0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen in die Darstellung einbaut. Guter Punkt, das hätte ich glatt verpennt… Leider funktioniert das nach meinen Tests trotzdem nicht. Die Werte stehen korrekt in der DB, werden per JSON korrekt zurückgeliefert, aber im Chart wird die letzte Null eines Bereiches ignoriert. Ursache ist mir nicht klar. Nachteilig ist natürlich dass man nich tmehr so einfach auf der Datenbank Werte mehrerer Kanäle für einen Timestamp zusammenjoinen kann ...und ggf. nicht so weit im Frontend zoomen kann - afair zeigt das nichts an wenn keine Daten vorhanden sind. Wenn wir den ganzen (Sonnen)Tag von 0 reden und z.B. auf Stundenansicht gehen könnte das ggf. auch etwas seltsam aussehen Auch ein guter Punkt- aber das gleiche Problem, welches auch bei Komprimierung der Werte besteht, oder? Im SQL könnte man den maximalen Zoomraum durch Einschränkung der WHERE-Clause vor Löschung schützen: ... and p.timestamp o.timestamp - 1*60*1000 and n.timestamp o.timestamp - 1*60*1000 damit sind dann nur Datensätze betroffen, deren Vorgänger und Nachfolger _innerhalb_ eines angegebenen Intervalls liegen (vmtl. müsste man sich aber eher auf den Intervallanfang/ende konzentrieren- das braucht noch etwas Bastelei). Der Weg sollte der gleiche sein. Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein? noch? ich mach von meiner Seite keinen Schreibschutz drauf und deklariere es als fertig ;) Spaß beiseite: Ist notiert und hört sich erfolgsversprechend an, wenn ich etwas Zeit bekomme und der Schleifenbug raus ist schau ichs mir an. Ich bin gespannt- gibts eigentlich ein GIT dafür? Viele Grüße, Andreas
Re: [vz-dev] Alternative Implementierung für vzcompress
Nabend, Am 2013-04-16 10:55, schrieb Andreas Goetz: Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt sollte das ähnlich funktionieren. Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0) weglässt, ist jetzt auch dieser Fall mit abgedeckt. Moment, Moment, ich glaub mit reinem SQL geht das nicht - wenn ich richtig im Kopf hab werden bei MeterInterpreter ja die Pulse notiert, also dürften in dem Fall gleiche Werte 0 nicht gelöscht werden, sonst stimmen die Messwerte danach nicht mehr. Obs MeterPreter ist steht allerdings nur in der JSON, nit in der SQL. ...und ggf. nicht so weit im Frontend zoomen kann (...) Auch ein guter Punkt- aber das gleiche Problem, welches auch bei Komprimierung der Werte besteht, oder? Jein - bei der jetzigen Komprimierung hat man ja meist noch recht kleine Zeiträume - 5Min, 15Min, wegen mir ne Stunde - an einem guten Sonnentag könnte aber der öffentlich Stromzähler (wenn man sich selbst versorgt) fast 12h ohne Änderung, also mit hierüber gelöschten Messwerten, da stehen. Wird aber wohl für die meisten Bereiche eher uninteressant sein. Ich bin gespannt- gibts eigentlich ein GIT dafür? Nun es liegt zumindest auf Github ;) - ist allerdings eine branch des vz-git, nichts eigenes nur für das Script. https://github.com/adlerweb/volkszaehler.org/tree/vzcompress2 -- Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Am 2013-04-14 12:50, schrieb Daniel Lauckner: Scheint so als würde das Script die letze Zeile falsch interpretieren. oh ja, stimmt, da ist was in der Schleife faul -- Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Am 2013-04-14 20:22, schrieb Andreas Goetz: eine Optimierung welche mir für vzcompress noch einfiele wäre die Löschung (nicht nur Komprimierung) redundanter Nullwerte. Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt sollte das ähnlich funktionieren. 0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen in die Darstellung einbaut. Guter Punkt, das hätte ich glatt verpennt… Nachteilig ist natürlich dass man nich tmehr so einfach auf der Datenbank Werte mehrerer Kanäle für einen Timestamp zusammenjoinen kann ...und ggf. nicht so weit im Frontend zoomen kann - afair zeigt das nichts an wenn keine Daten vorhanden sind. Wenn wir den ganzen (Sonnen)Tag von 0 reden und z.B. auf Stundenansicht gehen könnte das ggf. auch etwas seltsam aussehen Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein? noch? ich mach von meiner Seite keinen Schreibschutz drauf und deklariere es als fertig ;) Spaß beiseite: Ist notiert und hört sich erfolgsversprechend an, wenn ich etwas Zeit bekomme und der Schleifenbug raus ist schau ichs mir an. -- Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Im Prinzip ja- aber alle, nicht nur 3! Von meinem iPhone gesendet Am 15.04.2013 um 22:34 schrieb Florian Knodt f.kn...@yotaweb.de: Nabend die Dritte, das ist jetzt die 0-Wert-Löschung? Er sucht 3 aufeinanderfolgende Werte eines Kanals und löscht wenn alle 0 sind den Mittleren, richtig? -- Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Am Sonntag, 14. April 2013 um 11:26 schrieb Daniel Lauckner: Sieht bei mir im Moent so aus (Z. 259 - 263): 'default' = array( //Definition for all other channels (1*24*60*60)= (1*60), //Older than 1 Days (org: 7) Datapoint per 1 Minute (30*24*60*60) = (5*60), //Older than 30 Days Datapoint per 5 Minutes //(6*30*24*60*60) = (15*60), //Older than 6 Month Datapoint per 15 Minutes //(365*24*60*60) = (30*60), //Older than 1 Year Datapoint per 30 Minutes Processing Sensor ID 7... Compressing datapoints between 17.03.2013 14:39:26 and 13.04.2013 10:40:14 using a 60 second timeframe Removed 2834 Datapoints in 623 Seconds. Skipping compression pass for datapoints between 14.04.2013 10:40:16 and 15.03.2013 09:40:16 using a 300 second timeframe: No Datapoints found Hab was getestet: (1*24*60*60)= (1*60), //Older than 1 Days (org: 7) D$ (30*24*60*60) = (5*60), //Older than 30 Days Datapoint $ (6*30*24*60*60) = (6*60), //Older than 6 Month Datapoint p$ Processing Sensor ID 7... Compressing datapoints between 17.03.2013 14:39:26 and 13.04.2013 11:25:49 using a 60 second timeframe Removed 1777 Datapoints in 601 Seconds. Compressing datapoints between 17.01.2013 16:55:47 and 14.03.2013 13:59:03 using a 300 second timeframe Removed 558059 Datapoints in 3917 Seconds. Skipping compression pass for datapoints between 14.04.2013 11:25:51 and 16.10.2012 11:25:51 using a 360 second timeframe: No Datapoints found 17.01. ist der erste Tag meines volkszählers. Scheint so als würde das Script die letze Zeile falsch interpretieren. mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo Zusammen, eine Optimierung welche mir für vzcompress noch einfiele wäre die Löschung (nicht nur Komprimierung) redundanter Nullwerte. Hintergrund: bei normalen Stromzählern (aber auch Verbrauchsmessern) ist tagsüber während die PV läuft der Bezug meist 0, ebenso sind Einspeisung und Erzeugung nachts eigentlich immer 0. Diese Nullen ließen sind- bis auf die jeweils erste und letzter einer 0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen in die Darstellung einbaut. Nachteilig ist natürlich dass man nich tmehr so einfach auf der Datenbank Werte mehrerer Kanäle für einen Timestamp zusammenjoinen kann- aber andererseits ist auch klar, dass kein Wert automatisch eine 0 im Verbrauch bedeutet. Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein? Viele Grüße, Andreas
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo, Am 11.04.2013 20:16, schrieb Daniel Lauckner: den Eindruck das die DB bei den 5-Minutenwerten nicht von Anfang an bearbeitet sondern irgendwo einsteigt. Falls ja, wo ist das definiert? das sind die compressscheme-Zeilen unten im Script, genauer die erste Zahl des Arrays. Im Original heißt es z.B. (7*24*60*60)= (1*60), (30*24*60*60) = (5*60), (6*30*24*60*60) = (15*60) (365*24*60*60) = (30*60) In dem Fall würden Daten, welche neuer als 7 Tage (also neuer als die kleinste Definition, in dem Fall 7*24*60*60 Sekunden) sind NICHT komprimiert. Werte die älter sind erhalten einen Wert pro Minute (1*60 Sekunden), Daten älter als 30 Tage (30*24*60*60 Sekunden) ein Wert pro 5 Minuten (5*60 Sekunden) etc. Wenn du jetzt die 5 Minuten früher haben willst müsstest du den ersten Wert der Zeile mit den 5 Minuten ändern, z.B. auf (14*24*60*60) um alle Daten älter als 14 Tage zu bearbeiten. -- Mit freundlichen Grüßen Florian Knodt signature.asc Description: OpenPGP digital signature
Re: [vz-dev] Alternative Implementierung für vzcompress
Abend, Am Samstag, 6. April 2013 um 01:49 schrieb f.kn...@yotaweb.de: Am 2013-04-05 21:08, schrieb Daniel Lauckner: Aber eine Frage: Du sind jetzt 4 Regeln definiert nach denen gelöscht/zusammengefasst werden soll. Mir würden 2 reichen. Kann ich die Zeilen 262 und 263 einfach löschen? Ja, in dem Bereich kann alles entsprechend den jeweiligen Anforderungen geändert/gelöscht werden. Hab das Script zwischenzeitlich drüberrumpeln lassen (mit vzlogger im Hintergrund - kein Problem). Bin aber von 6,5 Mio Datensätzen nur auf 4,5 Mio gekommen. Hatte (wenn ich nebenbei draufgeschaut hab) den Eindruck das die DB bei den 5-Minutenwerten nicht von Anfang an bearbeitet sondern irgendwo einsteigt. Falls ja, wo ist das definiert? mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Abend, Florian Auch von mir ein herzliches Dankeschön für das Script. Am Samstag, 6. April 2013 um 20:54 schrieb Bernd Gewehr: Ich überlege, ob mir eine Optimierung einfällt, um die redundante Bearbeitung der alten Daten immer und immer wieder zu umgehen: Mir ist aufgefallen das das Script beim Zeitraum immer die selben Sekunden (26 bei 1 Minute, 47 bei 5) anzeigt. Wenn der verbleibende Datensatz auf dieser Sekunde liegt müsste man damit doch auch Arbeiten können? Ein logfile ist in php möglicherweise am einfachsten, oder? /var/log/vzcompress.log könnten alle Ergebnisse und die letzte ID oder das letzte timestamp/Channel_id-Pärchen enthalten. Wenn man sie löscht, dann geht's von vorne los... Oder so. Einfach in der Handhabung und ressourcenschonend. Das spart Zeit und CPU-Last, denn mein vzlogger steigt regelmäßig aus, wenn der vzcompress Cronjob losrennt. Ich hatte vzlogger immer vorher beendet weil ich eh damit gerechnet habe das er abschmiert. mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Nabend, Am 2013-04-07 22:46, schrieb Daniel Lauckner: Mir ist aufgefallen das das Script beim Zeitraum immer die selben Sekunden (26 bei 1 Minute, 47 bei 5) anzeigt. Wenn das Script etwas zusammenfasst basiert Datum/Zeit auf der Startzeit, ist also nicht zwingend konstant. Es ist allerdings auch schon eine Optimierung in der Art drin: Das Script überspringt das Zusammenfassen (=UPDATE) wenn im Zeitraum nur ein Datensatz vorhanden ist. Übrig bleiben dann bei schon bearbeiteten Bereichen nur die lesenden Datenbankabfragen (SELECT), also im Prinzip das selbe wie eine Abfrage auf Basis der Uhrzeit. Ein Logfile mit den letzten Timestamps wäre schneller als die ganzen SELECT-Abfragen, allerdings verliert man so auch etwas Flexibilität - über die API ist es möglich Daten mit älteren Timestamps einzufügen (nutze ich z.B. für einige Sensoren, welche nur alle x Stunden synchronisiert werden oder offline laufen und manuell importiert werden), die würden dann nicht verarbeitet. Das spart Zeit und CPU-Last, denn mein vzlogger steigt regelmäßig aus, wenn der vzcompress Cronjob losrennt. Ich hatte vzlogger immer vorher beendet weil ich eh damit gerechnet habe das er abschmiert. Nunja, eigentlich sollte er das nicht tun - die meiste Arbeit sind vermutlich die SELECT-Abfragen zum zusammenfassen, dabei dürfte MySQL aber keinen LOCK o.Ä. versuchen. Was ich mir nur vorstellen kann wäre, dass der DB-Server je nach Hardware ins Stocken kommt und vzlogger in einen Timeout läuft. Generell sehe ich jedenfalls kein Problem - auf meinem E450 gehen während das Script läuft keine neuen Daten verloren, allerdings nutze ich nur direkte HTTP-Requests, und nicht den vzlogger. Eventuell könnte ein usleep/sleep nach dem UPDATE oder gar SELECT helfen die Last zu reduzieren - wenn das Script per cron o.Ä. läuft lässt sich der Geschwindigkeitsverlust sicher verschmerzen. Am 2013-04-06 20:54, schrieb Bernd Gewehr: Wann wird das file im VZ-git sichtbar? Ist noch nicht eingeschickt, ich wollte es erst etwas abhängen lassen, sodass die gröbsten Fehler vorher raus sind Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
On Thu, 4 Apr 2013 23:21:57 +0200
Thorben Thuermer r...@constancy.org wrote:
On Thu, 4 Apr 2013 23:15:43 +0200
Bernd Gewehr be...@gewehr.net wrote:
Nachtrag: Die angeblichen Duplikate sind nicht von derselben Channel_ID:
id channel_id timestamp value
2522215 10 1362713770632 20352394
2522216 6 1362713770632 288.3 Alle
nein.
in der data tabelle wirst du keine duplikate finden,
weil der unique key verhindert, das die eingetragen werden.
(doppelte eintraege fuer paare von (channel_id,timestamp).
die eintraege dort haben unterschieliche ts.
unterschieliche channel_ids natuerlich.
- T.
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Bernd Gewehr
Gesendet: Donnerstag, 4. April 2013 23:13
An: 'volkszaehler-users'; 'volkszaehler.org'
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Hallo,
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Daniel Lauckner
Gesendet: Donnerstag, 4. April 2013 23:09
An: volkszaehler.org
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 15:03 schrieb f.kn...@yotaweb.de:
Da hab ich wohl nen Hinweis vergessen - dieser Commit für die
EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der
JSON-Datei:
https://github.com/volkszaehler/volkszaehler.org/pull/43.
Hab die Zeile geändert und jetzt ein Problem mit den Zugriffsrechten:
string(63) DELETE command denied to user 'vz'@'localhost' for table
'data'
}
PHP Fatal error: SQL FAILURE in /home/pi/bin/vzcompress2.php on line 232
Ich nutze Sudo php vzcompress2.php - da läufts als root...
Mein Problem sind angebliche Duplikate:
Processing Sensor ID 6...
Compressing datapoints between 05.03.2013 22:06:10 and 24.03.2013 16:11:28
using a 60 second timeframe
Processing: 08.03.2013 04:35:10 - 08.03.2013 04:36:10 (12%)...
array(3) {
[0]=
string(5) 23000
[1]=
int(1062)
[2]=
string(51) Duplicate entry '6-1362713770632' for key 'ts_uniq'
}
PHP Fatal error: SQL FAILURE in
/var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 226
Kann man solche Fehler nicht einfach überspringen und dennoch weitermachen?
Danke und Gruß,
Bernd
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo! Das Problem mit den vermeintlichen Duplikaten ist durch den Scriptablauf zu erklären: In dem Moment, in dem der neue bleibende Wert in die DB geschrieben werden soll, wird zuvor nicht sichergestellt, dass diese Kombination von ts und ch_id nicht schon existiert. Daher wird dann beim Schreibversuch in die DB der Duplikatfehler ausgegeben. Dies kann also immer mal auftreten, bei mir in 4 Wochen ungefähr 6 mal. Wenn das Script nicht angepasst wird, ist es für einen unbeobachteteren Ablauf per cronjob eher nicht geeignet, da es immer wieder abbrechen wird. Ich kann das leider nicht... Gruß Bernd
Re: [vz-dev] Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 23:32 schrieb Thorben Thuermer: der vz-user hat keine delete-rechte, weil die middleware normalerweise nie daten loescht - sollte man wohl mal weniger restriktiv anlegen. Hab ich jetzt gemacht und das Script läuft im Moment. Aber eine Frage: Du sind jetzt 4 Regeln definiert nach denen gelöscht/zusammengefasst werden soll. Mir würden 2 reichen. Kann ich die Zeilen 262 und 263 einfach löschen? mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Nabend, Am 2013-04-05 21:08, schrieb Daniel Lauckner: Aber eine Frage: Du sind jetzt 4 Regeln definiert nach denen gelöscht/zusammengefasst werden soll. Mir würden 2 reichen. Kann ich die Zeilen 262 und 263 einfach löschen? Ja, in dem Bereich kann alles entsprechend den jeweiligen Anforderungen geändert/gelöscht werden. Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Nabend, Am 2013-04-05 09:49, schrieb Bernd Gewehr: In dem Moment, in dem der neue bleibende Wert in die DB geschrieben werden soll, wird zuvor nicht sichergestellt, dass diese Kombination von ts und ch_id nicht schon existiert. Jepp - den Index hatte ich wohl übersehen und bei meinem Datenbestand war offenbar nichts zum auslösen drin. Hab jetzt das DELETE vor das UPDATE gesetzt, da es in einer Transaktion steht sollte von der Sicherheit trotzdem nichts abhanden kommen. Florian
Re: [vz-dev] Alternative Implementierung für vzcompress
Mahlzeit, Am 2013-04-04 06:56, schrieb bernd: [...] PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type powersensor in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 [...] Da hab ich wohl nen Hinweis vergessen - dieser Commit für die EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der JSON-Datei: https://github.com/volkszaehler/volkszaehler.org/pull/43. -- Mit freundlichen Grüßen Florian Knodt
Re: [vz-dev] Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 15:03 schrieb f.kn...@yotaweb.de:
Da hab ich wohl nen Hinweis vergessen - dieser Commit für die
EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der
JSON-Datei:
https://github.com/volkszaehler/volkszaehler.org/pull/43.
Hab die Zeile geändert und jetzt ein Problem mit den Zugriffsrechten:
Processing Sensor ID 7...
Compressing datapoints between 06.03.2013 12:39:28 and 28.03.2013 22:00:35
using a 60 second timeframe
Processing: 06.03.2013 12:39:28 - 06.03.2013 12:40:28 (0%)...
array(3) {
[0]=
string(5) 42000
[1]=
int(1142)
[2]=
string(63) DELETE command denied to user 'vz'@'localhost' for table 'data'
}
PHP Fatal error: SQL FAILURE in /home/pi/bin/vzcompress2.php on line 232
Leider ist mir das Script zu hoch, ich versteh kein Stück was da vor
sich geht (oder gehen soll).
mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo,
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Daniel Lauckner
Gesendet: Donnerstag, 4. April 2013 23:09
An: volkszaehler.org
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 15:03 schrieb f.kn...@yotaweb.de:
Da hab ich wohl nen Hinweis vergessen - dieser Commit für die
EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der
JSON-Datei:
https://github.com/volkszaehler/volkszaehler.org/pull/43.
Hab die Zeile geändert und jetzt ein Problem mit den Zugriffsrechten:
string(63) DELETE command denied to user 'vz'@'localhost' for table
'data'
}
PHP Fatal error: SQL FAILURE in /home/pi/bin/vzcompress2.php on line 232
Ich nutze Sudo php vzcompress2.php - da läufts als root...
Mein Problem sind angebliche Duplikate:
Processing Sensor ID 6...
Compressing datapoints between 05.03.2013 22:06:10 and 24.03.2013 16:11:28
using a 60 second timeframe
Processing: 08.03.2013 04:35:10 - 08.03.2013 04:36:10 (12%)...
array(3) {
[0]=
string(5) 23000
[1]=
int(1062)
[2]=
string(51) Duplicate entry '6-1362713770632' for key 'ts_uniq'
}
PHP Fatal error: SQL FAILURE in
/var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 226
Kann man solche Fehler nicht einfach überspringen und dennoch weitermachen?
Danke und Gruß,
Bernd
Re: [vz-dev] Alternative Implementierung für vzcompress
On Thu, 4 Apr 2013 23:15:43 +0200
Bernd Gewehr be...@gewehr.net wrote:
Nachtrag: Die angeblichen Duplikate sind nicht von derselben Channel_ID:
id channel_id timestamp value
2522215 10 1362713770632 20352394
2522216 6 1362713770632 288.3 Alle
nein.
in der data tabelle wirst du keine duplikate finden,
weil der unique key verhindert, das die eingetragen werden.
(doppelte eintraege fuer paare von (channel_id,timestamp).
die eintraege dort haben unterschieliche ts.
- T.
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Bernd Gewehr
Gesendet: Donnerstag, 4. April 2013 23:13
An: 'volkszaehler-users'; 'volkszaehler.org'
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Hallo,
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Daniel Lauckner
Gesendet: Donnerstag, 4. April 2013 23:09
An: volkszaehler.org
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 15:03 schrieb f.kn...@yotaweb.de:
Da hab ich wohl nen Hinweis vergessen - dieser Commit für die
EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der
JSON-Datei:
https://github.com/volkszaehler/volkszaehler.org/pull/43.
Hab die Zeile geändert und jetzt ein Problem mit den Zugriffsrechten:
string(63) DELETE command denied to user 'vz'@'localhost' for table
'data'
}
PHP Fatal error: SQL FAILURE in /home/pi/bin/vzcompress2.php on line 232
Ich nutze Sudo php vzcompress2.php - da läufts als root...
Mein Problem sind angebliche Duplikate:
Processing Sensor ID 6...
Compressing datapoints between 05.03.2013 22:06:10 and 24.03.2013 16:11:28
using a 60 second timeframe
Processing: 08.03.2013 04:35:10 - 08.03.2013 04:36:10 (12%)...
array(3) {
[0]=
string(5) 23000
[1]=
int(1062)
[2]=
string(51) Duplicate entry '6-1362713770632' for key 'ts_uniq'
}
PHP Fatal error: SQL FAILURE in
/var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 226
Kann man solche Fehler nicht einfach überspringen und dennoch weitermachen?
Danke und Gruß,
Bernd
Re: [vz-dev] Alternative Implementierung für vzcompress
On Thu, 4 Apr 2013 23:13:21 +0200
Bernd Gewehr be...@gewehr.net wrote:
Hallo,
schoen dass du versuchst, zitatantworten zu benutzen,
aber das klappt nur wenn das zitat auch durchgehend als
solches gekennzeichnet ist,
da man sonst deine antwort nicht vom zitat unterscheiden kann.
-Ursprüngliche Nachricht-
Von: volkszaehler-dev-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Daniel Lauckner
Gesendet: Donnerstag, 4. April 2013 23:09
An: volkszaehler.org
Betreff: Re: [vz-dev]Alternative Implementierung für vzcompress
Am Donnerstag, 4. April 2013 um 15:03 schrieb f.kn...@yotaweb.de:
Da hab ich wohl nen Hinweis vergessen - dieser Commit für die
EntityDefinition müsste noch rein, sonst verschluckt sich PHP an der
JSON-Datei:
https://github.com/volkszaehler/volkszaehler.org/pull/43.
Hab die Zeile geändert und jetzt ein Problem mit den Zugriffsrechten:
string(63) DELETE command denied to user 'vz'@'localhost' for table
'data'
}
PHP Fatal error: SQL FAILURE in /home/pi/bin/vzcompress2.php on line 232
der vz-user hat keine delete-rechte, weil die middleware normalerweise
nie daten loescht - sollte man wohl mal weniger restriktiv anlegen.
Ich nutze Sudo php vzcompress2.php - da läufts als root...
als welcher user das script laeuft ist nicht relevant,
sondern welcher mysql-account fuer die db zugriffe verwendet wird.
hier ist wohl bei root der mysql root-user hinterlegt,
bei 'pi'aber nur der vz-user.
Mein Problem sind angebliche Duplikate:
Processing Sensor ID 6...
Compressing datapoints between 05.03.2013 22:06:10 and 24.03.2013 16:11:28
using a 60 second timeframe
Processing: 08.03.2013 04:35:10 - 08.03.2013 04:36:10 (12%)...
array(3) {
[0]=string(5) 23000
[1]=int(1062)
[2]=string(51) Duplicate entry '6-1362713770632' for key 'ts_uniq'
}
PHP Fatal error: SQL FAILURE in
/var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 226
Kann man solche Fehler nicht einfach überspringen und dennoch weitermachen?
wenn das denn sinnvoll waehre?!
das script fasst ja mehrere eintraege zu einem zusammen,
und solle eigentlich die alten loeschen.
der fehler kann nur bedeuten, dass die alten noch drinstehen -
da muss irgendwas schieflaufen.
habe das script nicht im detail angeschaut, muss der autor sagen.
Danke und Gruß,
Bernd
- T.
Re: [vz-dev] Alternative Implementierung für vzcompress
Abend, Florian Knodt schrieb: Getestet (im Sinne von es sind noch Daten da die stimmen könnten) ist das Ganze gegen MySQL und SensorInterpreter, andere Sensoren sollten funktionieren, Bei mir leider nicht, ich hab 3 Kanäle vom Typ electric meter und 2 power sensor. Gekürzte Ausgabe: Processing Sensor ID 9... PHP Warning: Invalid argument supplied for foreach() in /home/pi/bin/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type electric meter in /home/pi/bin/vzcompress2.php on line 161 Processing Sensor ID 10... PHP Warning: Invalid argument supplied for foreach() in /home/pi/bin/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type powersensor in /home/pi/bin/vzcompress2.php on line 161 Done. Purged Datapoints from 5 Channels in 0 Seconds mfg Daniel Lauckner
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo! On Wed, 3 Apr 2013 23:51:44 +0200, Daniel Lauckner mail...@jahp.de wrote: Abend, Florian Knodt schrieb: Getestet (im Sinne von es sind noch Daten da die stimmen könnten) ist das Ganze gegen MySQL und SensorInterpreter, andere Sensoren sollten funktionieren, Bei mir leider nicht, ich hab 3 Kanäle vom Typ electric meter und 2 power sensor. Bei mir leider auch nicht: Ungekürzte Ausgabe: pi@raspberrypi /var/www/volkszaehler.org/misc/tools $ php vzcompress2.php Processing Sensor ID 6... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type powersensor in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 8... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type gas in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 9... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type water in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 10... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type powersensor in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 13... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 18... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 19... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 20... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 21... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 22... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 23... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Processing Sensor ID 24... PHP Warning: Invalid argument supplied for foreach() in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 154 PHP Warning: Could not detect inperpreter for type temperature in /var/www/volkszaehler.org/misc/tools/vzcompress2.php on line 161 Done. Purged Datapoints from 12 Channels in 0 Seconds Hier noch die entities: id uuidtypeclass 6 635481a0-6fcd-11e2-8587-... powersensor channel 8 8102dbc0-6fcd-11e2-a8b7-... gas channel 9 89a19f80-6fcd-11e2-be46-... water channel 10 ebb9c9b0-7058-11e2-b5ed-... powersensor channel 13 fc73fdb0-831f-11e2-ab63-... temperature channel 15 a10a70a0-8390-11e2-9181-... group aggregator 16 5ac74c10-8391-11e2-967f-... group aggregator 17 a2484840-83fa-11e2-94eb-... group aggregator 18 27fd1e00-89c9-11e2-bc92-... temperature channel 19 3a513760-89c9-11e2-8948-... temperature channel 20 3c391a00-8a11-11e2-92ec-... temperature channel 21 1e6e25a0-8a11-11e2-96be-... temperature channel 22 2414a2e0-8a11-11e2-8319-... temperature channel 23 2dd2cb00-8a11-11e2-b8a9-... temperature channel 24 16a5a410-8a11-11e2-bfb5-... temperature channel Hier noch die Properties: id entity_id pkeyvalue 30 6 [-]
[vz-dev] Alternative Implementierung für vzcompress
Nabend, im November gab es eine Diskussion bezüglich vzcompress und korrupten Daten. Ursache war, dass das jetzige Tool nur für S0-Sensoren (MeterInterpreter) geeignet ist und die Art der Komprimierung beispielsweise Daten absoluter Sensoren (SensorInterpreter) unbrauchbar macht. Damals ist das Thema irgendwie vom Radar verschwunden. Bei digitalen Osterputz ist das Thema bei mir wieder hoch gekommen, denn die VZ-Datenbank hatte zwischenzeitlich stolze 10GB belagert. Da sich mein Perl in Grenzen hält habe ich das Ganze nach QnD neu in PHP implementiert. Das Script liest die verfügbaren Kanäle und deren Konfiguration aus der Datenbank bzw. den Definitionsdateien. Die Zugangsdaten für die DB kommen direkt aus der VZ-Config, sollte also im misc/tools-Verzeichnis ohne Konfiguration laufen. Im Script können global oder pro Kanal Kompressionsschema hinterlegt werden, standardmäßig ist derzeit folgendes als globale Definition drin: Newer than 7 Days Keep Original Older than 7 Days Datapoint per 1 Minute Older than 30 Days Datapoint per 5 Minutes Older than 6 Month Datapoint per 15 Minutes Older than 1 Year Datapoint per 30 Minutes Unterstützt werden sollten alle Sensoren auf Basis der derzeitigen Interpreter-Modelle (SensorInterpreter, MeterInterpreter, CounterInterpreter). Hierbei gilt: SensorInterpreter = Mittelwert MeterInterpreter = Summe CounterInterpreter = Maximalwert Als Zeitstempel wird immer das Ende der zusammengefassten Zeitperiode verwendet. Die Live-Statusmeldungen können z.B. für langsame SSH-Sitzungen abgeschaltet werden. Getestet (im Sinne von es sind noch Daten da die stimmen könnten) ist das Ganze gegen MySQL und SensorInterpreter, andere Sensoren sollten funktionieren, bei anderen Datenbanken könnte es Probleme geben, da die SQL-Queries recht unsauber drin sind. Wer etwas in die Richtung sucht, mutig ist und ein aktuelles Backup hat darf sich natürlich mal versuchen: https://github.com/adlerweb/volkszaehler.org/blob/vzcompress2/misc/tools/vzcompress2.php. -- Mit freundlichen Grüßen Florian Knodt signature.asc Description: OpenPGP digital signature
