Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Sven peitz, 2013-09-14 11:07: $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id) FROM data WHERE channel_id LIKE '14')); ... Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man dieses beschleunigen kann? Der subquery macht einen table-scan über die komplette data-Tabelle, was dauert natürlich entsprechend lange. So ist es kein Problem (wenn auch nicht schön): SELECT value FROM data WHERE channel_id=14 AND timestamp=(select max(timestamp) FROM data WHERE channel_id=14); Allerdings sollte man nicht ohne Grund direkt auf der DB arbeiten. Das Vorgehen wie von Andreas Götz ist auch deutlich einfacher (Abfrage mit from=now).
Re: [vz-dev] Performanceoptimierung MeterInterpreter
Andreas Goetz, 24.04.2013 17:31: beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das Frontend kann ja eh nicht mehr darstellen. müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese auch erstmal aus MySQL abgeholt werden. Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist, weil alle rows erstmal von der Platte gelesen werden müssen. Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren. Die untenstehende Methode erledigt das und kann in MeterInterpreter eingefügt werden (siehe unterer Teil nach EmptyIterator). Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist das allerdings auch nicht gerade hochperformant gelöst (mit callbacks und Interface-Klasse). Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt anders ist. Hast du denn mal gemesen, ob's damit wirklich signifikant schneller geht? Also ein time curl 'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440tuples=100' mit beiden Methoden (mehrmals ausgeführt). Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau steht schon länger auf meiner Liste. Das könnte man aber allerdings auch mit SQL machen
Re: [vz-dev] Error executing grouped queries
Andreas Goetz, 11.04.2013 08:21: Wäre Klasse wenn die Anpassungen (inkl. Fix für from/to) es ins zentrale Git schaffen würden. Ich hab mal nen pull-request gestellt. Vielleicht ist JO so gnädig :) Mein fork sollte aber auch immer eine funktionale Version haben, ich committe normalerweise nur, wenn ich das lokal getestet habe. Mal schauen, ob group mal richtig gemacht wird. Eine Idee dazu hätte ich schon, die zufälligerweise durch eine andere Änderung erheblich vereinfacht wird (Werte isochron zusammenfassen statt anhand der Anzahl). Hab nur aktuell keine Zeit dafür...
Re: [vz-dev] Daemon und Script gleichnamig beim 1wirevz und s0vz
Bernd Gewehr, 09.04.2013 07:39: Hallo, ich habe festgestellt, dass der simple Aufruf von sudo 1wirevz restart nicht ... Bitte, _nie_ einen neuen Thread eröffnen, indem man auf eine bestehende Mail der Liste antwortet, ansonsten geht das Threading in jedem anständigen MUA kaputt.
Re: [vz-dev] jsonp support für vz
On 07.04.2013 13:23, Andreas Goetz wrote: Jetzt fehlt nur noch ein eleganter weg, zusätzliche MWs in der Konfiguration anzugeben. In der Konfiguration von was?
Re: [vz-dev] jsonp support für vz
On 04.04.2013 19:14, Andreas Goetz wrote:
Das hab ich glatt übersehen :/, content-type ist definition falsch. Ich
fände dennoch callback statt padding als Parameter schöner- dann
liesse sich nämlich auch jQuery getJSON nutzen. Mit der jetzigen Lösung
Wenn ich die Beschreibung von getJSON richtig verstanden habe (es ist
leider nicht explizit beschrieben), funktioniert das mit jedem
Parameter, der vor =? steht, in unserem Fall also padding=?.
Ich finde padding als Parametername auch nicht so prall (auch wenn es
technisch korrekt ist), aber ohne Not ändert man sowas nicht.
muss man zwangsweise auf $.ajax ausweichen um die notwendigen Parameter
reinzufummeln. Aber ja- es ist möglich ;)
Also der Unterschied zwischen
$.getJSON(url, data, success)
und
$.ajax({dataType: json, url: url, data: data, success: success});
ist jetzt nicht soo riesig...
Re: [vz-dev] jsonp support für vz
Hi,
Andreas Goetz, 03.04.2013 08:46:
ich hatte den Wunsch, remote (d.h. per iphone-app) auf die mw
zuzugreifen. Aus Sicherheitsgründen ist das nur per JsonP, nicht jedoch
json möglich.
interessante sache irgendwie...
es ist doch eigentlich im frontend vorgesehen, kanaele von verschiedenen
middlewares abbonieren zu koennen - funktionierte das bisher garnicht?!
Kann nicht. Allerdings habe ich auch keinen Platz in rigendeiner Config
gefunden wo ich eine zweite MW hätte eintragen können- für's durch JS
hacken fehlte mir bisher die Zeit. Wäre aber eine spannende Aufgabe auch
daran ein wenig zu basteln.
Das ist jetzt auch schon möglich. Kann man einfach selbst testen, indem
man in seinem Frontend einen der öffentlichen Kanäle von
demo.volkszaehler.org abonniert.
https://github.com/volkszaehler/volkszaehler.org/pull/44
Ich paste einfach mal meinen Kommentar von dort:
JSONP wird bereits über den Parameter padding unterstützt, siehe
http://wiki.volkszaehler.org/development/api/reference?s[]=padding#json
Dieser wird auch schon vom frontend benutzt, wenn man eine andere als
die lokale middleware ausgewählt hat.
Allerdings belässt padding den Content-type auf application/json, das
sollte wohl wie bei dir application/javascript sein, das sollten wir
noch fixen.
In der jetzigen Version ist das allerdings ein potentielles
Sicherhitsrisiko- es lassen sich ja nicht nur Daten abfragen sondern
auch löschen. Was fehlt ist m.E. eine Konfigurationsoption mit der jsonp
standardmäßig erstmal deaktiviert ist.
Warum sollte JSONP für die middleware ein Sicherheitsrisiko sein? Wenn
man die UUID kennt und die middleware erreichen kann, kann man das auch
so über die API machen.
Was ich an JSONP skurril finde (zumindest soweit ich das verstanden
habe): Wegen der same-origin-policy kann man nicht einfach JSON
benutzen. Um das zu umgehen, lädt man sich javascript-code von einem
fremden Server!?! Ich habe zumindest nirgendwo gesehen, daß geprüft
wird, ob der Server tatsächlich sowas wie callback_methode({daten...})
zurückgibt, oder nicht beliebigen anderen javascript-code, der z.B. die
cookies ausliest und für alle Kanäle ein delete macht.
Re: [vz-dev] Error executing grouped queries
Hi, Andreas Goetz, 03.04.2013 19:50: Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal gefixt. Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde (mit Update der Doku..)- die Logik ist wirklich krank :/ Das dürfte schon klappen :) Ok, schicke ich per PM hinterher. Hab ich mir angeschaut. Das Problem ist, daß du im März Daten hast, aber nicht im Februar. Die Auswertung läuft aber so, daß mit group die Daten einzelner Monate zusammengefasst werden und dann von processData wie sonst auch verarbeitet werden, d.h. vom ersten Tupel wird nur der timestamp genommen und der Rest verworfen, bei dir eben die zusammengefassten Daten vom März. Ohne mittelgroße Umbauten oder unschöne Hacks ist das aber leider nicht zu fixen.Ich schau's mir evt. nochmal an, aber du solltest nicht darauf warten... Workaround für dich: Einen einzelnen Impuls (mit Wert 0) für Ende Februar einfügen (28.2. 23:59:59).
Re: [vz-dev] Error executing grouped queries
On 02.04.2013 08:31, Andreas Goetz wrote: die letzten Commits in Deinem Git sind ewig alt- bin ich wirklich an der richtigen Stelle gelandet bzw. ist alles drin? Welcher Branch? Was meinst du mit ewig alt? Laut https://github.com/jahir/volkszaehler.org/commits/master ist der letzte commit vom 1.4.
Re: [vz-dev] Error executing grouped queries
On 30.03.2013 16:00, Andreas Goetz wrote: Klasse- stehe zum Testen bereit (gerne auch an cpui...@gmx.de). Was die Du kannst mal meinen Fork unter git://github.com/jahir/volkszaehler.org.git probieren. Leistungsberechnung angeht habe ich ein weiteres Problem- nämlich die Tatsache, dass die Durchschnittswerte alle falsch sind. Es wird jeweils 0 (oder ein Werte nahe 0) ausgegeben, auch wenn eindeutig mehr angefallen ist. Hm, das passt bei mir: # from: 2013-03-31 23:59:28 # to: 2013-04-02 01:38:51 # min: 2013-04-01 06:59:14 = 290,816 # max: 2013-04-01 21:59:34 = 298,388 # average: 297,783 # consumption: 7640 # rows: 27 2013-03-31 23:59:28;298,279;60 2013-04-01 00:59:49;297,348;59 2013-04-01 01:59:20;298,1;60 2013-04-01 02:59:43;298,175;59 ... Mhm- bei mir haut das mit dem Average nicht hin. Wenn's bei Dir läuft dann muss ich wohl auch an der Stelle ein bisschen in den Code einsteigen. Du kannst ja mal einen relevanten Zeitraum exportieren (vorzugsweise mit mysqldump volkszaehler data --where=channel_id=... and timestamp between ... and ...), dann kann ich mal schaue, was da falschläuft.
Re: [vz-dev] null-tupel vom MeterInterpreter
Thorben Thuermer, 11.02.2013 10:34: ich haette gesagt, den graphen ueber den letzten tatsaechlich bekannten datenpunkt weiter zu rendern ist nicht wenig noetig/sinnvoll genug, um dafuer soeinen hack in Machen wir ja nicht, der Hack war nur dafür da, tatsächlich bis zum _letzten_ Datenpunkt zu zeichnen und nicht nur bis zum vorletzten. das mit dem duplizieren hatte mich verwirrt, weil ich eher davon ausgegangen waehre, das das ohnehin schon end-timestamps sind. Ne, sieht man ja in der foreach-Schleife obendran, da wird für jedes Tupel der vorherige Timestamp genommen.
Re: [vz-dev] null-tupel vom MeterInterpreter
On 10.02.2013 22:00, Thorben Thuermer wrote: folgendes problem: der 'hack' einen aktuellen leistungswert aus einem kanal auszulesen, in dem man daten mit from=X seconds ago anfordert, und dann den letzten wert nimmt, funktioniert wohl nicht mit s0-zaehlern, weil der MeterInterpreter immer ein tupel mit value=null ans ende haengt. Das ist leider wirklich ein übler hack. Ich hatte das mal eingebaut, damit das Frontend die letzte bekannte Leistung bis zur zugehörigen End-Zeit zeichnet (ansonsten gibt's da nur einen vertikalen Strich). Wie schon in der commit-message von damals geschrieben, gehört das eigentlich überhaupt nicht in die middleware, sondern ins frontend, zumindest das null-Tuple. Werd ich mal entsprechend umbauen. (Das null-Tupel ist ein Hack damit flot weiß, daß dort die Kurve fertig ist.) Bei (teil-)duplizieren Tupel ist es nicht ganz so einfach. In der Ausgabe der middleware gibt es ja keine Intervalle, sondern nur tupel mit timestamp und Wert, das Intervallende ist einfach der timestamp vom nächsten Interval. Das wurde wohl mal so gewählt, weil Flot das genau so erwartet. Beim letzten Interval klappt das aber nicht, da fehlt dann das Intervallende, obwohl die Middleware das ja kennt. Der Trick war dann eben, die selbe Leistung mit der Start-Zeit des nächsten Intervalls einzufügen. Ja, nicht schön. Für Vorschläge, wie man's besser machen könnte, bin ich offen. Mir fallen spontan drei Möglichkeiten ein: 1) statt der Start-Zeit die End-Zeit in den Tupel ausgeben. O.g. Problem würde dann nur beim allerersten bekannten Intervall auftreten, das könnte man wohl verschmerzen. Allerdings müßte das Frontend dann ein neues Array mit der jeweiligen End-Zeit zusammenbauen und den momentan benutzten Trick selbst benutzen. Nicht so toll. 2) Die middleware könnte die rohen Impulse ausgeben, dann müßte eben das Frontend die Leistungen selbst berechnen. Kein Hexenwerk, aber der von dir angesprochene Hack zum aktuellen Leistungswert auslesen würde dann auch nicht einfach so gehen. Könnte man mit einem zusätzlichen Parameter lösen (rawData=1 oder so), aber dann hätte man Code doppelt und auch noch in zwei verschiedenen Programmiersprachen. Also auch nix. 3) die Endzeit vom letzten Interval nicht in tuples ausgeben, sondern mit einem eigenen key. Wie ich gerade gesehen habe, machen wir das sogar schon, from und to sind ja nicht die Werte aus dem request, sondern die der tatsächlcih betrachteten Daten. Das frontend müßte das also nur entsprechend auswerten... Hm, 3) erscheint mir jetzt als noch am geschicktesten. Wenn nix dagegen spricht, würde ich das einfach mal so einbauen. da wird erst das letzte tupel dupliziert(?) ohne den callback dafuer aufzurufen, Ja, weil der callback für das tupel, das kopiert wird, schon aufgerufen wurde. Der callback gibt eh nur das tupel mit ggf. geändertem Wert zurück (siehe addData() in den View-Klassen). kann jemand mit durchblick in der middleware (herr hirsch?) aufklaeren, wozu das dient? HTH. Und danke für den (impliziten) Anstoß, daß endlich mal geradezuziehen.
Re: [vz-dev] null-tupel vom MeterInterpreter
On 11.02.2013 00:56, Jakob Hirsch wrote: 3) die Endzeit vom letzten Interval nicht in tuples ausgeben, sondern mit einem eigenen key. Wie ich gerade gesehen habe, machen wir das sogar schon, from und to sind ja nicht die Werte aus dem request, sondern die der tatsächlcih betrachteten Daten. Das frontend müßte das also nur entsprechend auswerten... Hm, 3) erscheint mir jetzt als noch am geschicktesten. Wenn nix dagegen spricht, würde ich das einfach mal so einbauen. So: https://github.com/jahir/volkszaehler.org/commit/e1ddcda8bab985cc8471cc212a998261035c0ba2 Bitte mal testen. Wenn nix dagegen spricht, schieb ich das hoch.
Re: [vz-dev] Frontend Graph-Fehler: falsche Peaks
On 07.02.2013 19:55, Bernd Gewehr wrote: Das wird nix bringen, da ich mit dem Datenauszug absteigend sortiert nach value nur belegen wollte, dass da so hohe Werte nicht drin sind... Das sieht man so garnicht. Deine values sind offenbar Zählerstände, die Leistungen daraus werden per delta_Zählerstand/delta_t berechnet.
Re: [vz-dev] Volkszaehler.org und Solar
On 27.12.2012 19:01, sollner11 wrote:
Du meinst die ausgefüllte Fläche unter den Linien?
ja, bzw.
bei der oberen Linie=Wirkenergie des Haus-Zweirichtungszählers sollte es:
bei positiven Werten bis Nulllinie Farbe1 sein
bei negativen Werten bis Nillinie Farbe2 sein
und
bei der unteren Linie=Wirkenergie des Erzeugungszählers sollte es:
bei bis Nulllinie oder eben bis negativer oberen Linie sein
geht das auch?
Ja, dafür gibt es das Threshold-Plugin (siehe
http://people.iola.dk/olau/flot/examples/thresholding.html).
Wenn du's fest aktivieren willst: wui.js, vz.wui.drawPlot, bei lines: {
... } ein fill: true hinzufügen.
sorry, ich habe zwar in dev gepostet, bin aber nur user ;-)
kannst du das etwas erläutern?
Naja, in wui.js, Zeile 586, nach dem lines: { eine Zeile mit fill:
true, einfügen.
Re: [vz-dev] iskra mt171
Henry van Gestel, 17.12.2012 23:14: The Perl module IO::Termios ist not installed. run apt-get install libio-termios-perl to fix that. After some study I solved with artikel : http://world.std.com/~swmcd/steven/perl/module_mechanics.html e.g. Downloading: IO-Termios-0.01.tar, IO-Tty-1.07.tar You should really not install modules or any other software on a debian system (or any other system with package management) unless you know what you are doing (which I don't think you do, with all due respect). Just use the command I gave above (an apt-get update before may be needed), and you won't need any fiddling with source tars or trickery with environemnt variables, plus you get updates automatically from debian. If you need a module, lib or programm that is not installed, just use apt-cache search, which would have given you the libio-termios-perl package. For Perl modules you usually don't even need that, as Perl module packages in debian are named after the module, e.g. the module Foo::Bar is in libfoo-bar-perl.
Re: [vz-dev] iskra mt171
Henry van Gestel, 18.12.2012 11:24:
the apt-get didn’t gave me the wanted results.
If you post the output of apt-get and of iskra2.pl, I could tell you
what's wrong.
The perl script (iskra2.pl http://iskra2.pl)is giving me output but
never stops, the time between data is increasing filled up with 0a LF
I think it Should stop after giving the telegram with data, am I
correct in this?
Yes, that's how the script is intended to work. Just stop it with
ctrl-break after the message finished cycle.
If you comment out (i.e. insert a # in the first column) the while (1)
{ in line 76 and the } in line 110, it will only run once.
Re: [vz-dev] iskra mt171
On 17.12.2012 21:56, Henry van Gestel wrote: Your latest perl program iskra2.pl gaves a problem on RPI Can't locate IO/Termios.pm in @INC The Perl module IO::Termios ist not installed. run apt-get install libio-termios-perl to fix that.
Re: [vz-dev] iskra mt171
On 17.12.2012 00:28, Udo1 wrote: Also da ist schon eine 5, aber wie gesagt: - bei 000 bis 040 bekomme ich Daten, aber nur mit 300 bps - bei 050 bekomme ich gar keine Antwort Evt. liegt's aber auch an Perl bzw. IO::Termios, ich hatte da auch schon beim auslesen meiner S0's (events aus /dev/input/..) und meiner Tecalor-Wärmepumpe (seriell) komische Effekte, in C hat's dagegen einwandfrei und zuverlässig geklappt. Ich schreib mal mein iskra2vz.pl in C um, vielleicht klappt's ja dann. Also mein Englisch ist nicht besonders gut. required ist nicht der richtige Ausdruck. Die 5 zeigt, das man mit 9600bd weiter machen kann, man muss nicht. Schon klar, man wählt über die zweite Ziffer aus, welche Baud-Rate man möchte, von 0 für 300bps bis 5 für 9600bps. Der Port muß nach dem Kommand natürlich auch noch auf die richtige Geschwindigkeit umgeschaltet werden. Aber selbst wenn ich mit 040 4800bps auswähle, kann ich weiter ohne Umschaltung, also mit 300bps lesen, was mich vermuten läßt, daß der MT171 einfach so ranzlig ist, daß er das ignoriert.
Re: [vz-dev] Letzten aktuellen Leitungswert einer uuid auslesen
On 15.11.2012 23:51, Sven Peitz wrote: DELETE FROM data where timestamp=0 9 Datensätze gelöscht Ok. Da ist wohl irgendwann mal was schiefgelaufen... delete from data where id in (select id from dupes); 0 Datensätze gelöscht. Auch gut, dann hattest du sonst keine Duplikate. Ok soweit so gut, ach und ich habe leider nur phpmyadmin zugriff... Wußte ich leider nicht, ich arbeite meistens direkt auf der mysql-shell, da geht man schnell mal davon aus, daß das jeder so macht :) Nun so wie es sein soll? Ja, tiptop, so soll das sein :)
Re: [vz-dev] Letzten aktuellen Leitungswert einer uuid auslesen
Sven Peitz, 15.11.2012 08:59: so hier mal die aktuellen Daten CREATE TABLE `data` ( `id` int(11) NOT NULL AUTO_INCREMENT, `channel_id` int(11) DEFAULT NULL, `timestamp` bigint(20) NOT NULL, `value` double NOT NULL, PRIMARY KEY (`id`), KEY `data_channel_id_idx` (`channel_id`), CONSTRAINT `data_ibfk_1` FOREIGN KEY (`channel_id`) REFERENCES `entities` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=9394957 DEFAULT CHARSET=latin1 ok, wie vermutet kein key über channel_id+ts. jetzt habe ich nach Datensicherung versteht sich ein ALTER TABLE data ADD UNIQUE KEY `chan_ts_idx` (`channel_id`,`timestamp`), DROP KEY `data_channel_id_idx`; gemacht und bekam folgendes #1062 - Duplicate entry '10-0' for key 'chan_ts_idx' Wie gesagt, da hast du offenbar Duplikate in der Datenbank, in dem Fall für die channel_id 10 und den timestamp 0. Da es eher unwahrscheinlich ist, daß du am 1.1.1970 Einträge gemacht hast, sind das wohl fehlerhafte Daten. Die kannst du mit DELETE FROM data where channel_id=10 AND ts=0 oder gleich mit DELETE FROM data where ts=0 alles mit ts=0 löschen. Um alle Duplikate zu löschen, machst du das (dauert je nach Datenmenge aber eine Weile): create temporary table dupes as select d2.id from data d1, data d2 where d1.idd2.id and d1.timestamp=d2.timestamp and d1.channel_id=d2.channel_id; und delete from data where id in (select id from dupes); Für den unique key dann das ausführen: alter table data drop key chan_ts_idx, add unique key chan_ts_idx (channel_id, timestamp); Der unique key ist zwar nicht zwingend notwendig, sorgt aber zumindest für ein bisschen Daten-Sauberkeit.
Re: [vz-dev] Letzten aktuellen Leitungswert einer uuid auslesen
On 14.11.2012 21:13, Sven Peitz wrote: Ich konnte leider noch nicht herausfinden wie ich nur den letzten Wert lese, und ja es sind tatsächliche Watt. Ist nicht implementiert. Workaround wäre z.B. sowas: curl -s http://url/deiner/middleware.php/data/deine_UUID.csv?from=$[$(date +%s)-300]000 | tail -n2 | head -n1 | cut -f2 -d';' Je nachdem wie oft du Werte reingekommst, kannst du die 300 Sekunden verkleinern oder mußt sie vergrößern. Statt tail -n2 | head -n1 sollte eigentlich ein tail -n1 ausreichen, allerdings hängt die Middleware momentan leider noch einen dummy-Wert an, damit das Frontend den letzten echten Wert anzeigt. Das muß da raus, das gehört in's Frontend. Demnächst... Die gesamte Abfrage dauert bei mir so 10-15 Sekunden. Dann hast du wahrscheinlich keinen passenden Index in deiner data-Tabelle. In älteren vz-Versionen war das ein Problem. Mach mal ein SHOW CREATE TABLE data, das sollte ungefähr so aussehen: CREATE TABLE `data` ( `id` int(11) NOT NULL AUTO_INCREMENT, `channel_id` int(11) DEFAULT NULL, `timestamp` bigint(20) NOT NULL, `value` double NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `chan_ts_idx` (`channel_id`,`timestamp`), CONSTRAINT `data_ibfk_1` FOREIGN KEY (`channel_id`) REFERENCES `entities` (`id`) ) Falls bei dir der Index über (`channel_id`,`timestamp`) fehlt, kannst du ihn so einrichten: ALTER TABLE data ADD UNIQUE KEY `chan_ts_idx` (`channel_id`,`timestamp`); Das dauert je nach Datenmenge etwas, weil die Tabelle komplett kopiert wird und dabei noch der Index neu erstellt werden muss. Wenn du eine Fehlermeldung wegen non-unique Werten bekommst, kannst du das UNIQUE auch weglassen. Ich würde aber eher empfehlen, die Duplicate zu löschen: 1. Mit SELECT id FROM data WHERE channel_id=CHANNEL AND timestamp=TIMESTAMP jeweils die IDs raussuchen. 2. Mit DELETE FROM data WHERE id=ID einen der beiden löschen. Wenn du noch einen Index _nur_ auf timestamp oder sogar channel_id hast (in der Klammer), kannst du den so löschen (weil unnötig): ALTER TABLE data DROP KEY `key-name`; Oder gleich beim Anlegen des ersten Index mit entsorgen, dann geht's schneller, weil nur einmal umkopiert werden muss: ALTER TABLE data ADD UNIQUE KEY `chan_ts_idx` (`channel_id`,`timestamp`), DROP KEY `key-name`; key-name übernimmst du oben von der Ausgabe von SHOW CREATE TABLE data, zwischen KEY und (...). Äh, ja, wenn dir das jetzt zuviel Text war: Einfach mal die Ausgabe von SHOW CREATE TABLE data posten, dann sehen wir weiter.
Re: [vz-dev] vzcompress: Korrupte Daten bei absoluten Sensoren
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.11.2012 13:46, Florian Knodt wrote: seit einiger Zeit liegt in misc/tools das Script vzcompress, welches den Ansatz hat Daten in der Datenbank zusammenzufassen um so auf kosten der Genauigkeit Speicherplatz zu sparen. In der aktuellen Naja, Genauigkeit, ich würde es eher zeitliche Auflösung nennen, aber egal :) Version werden hierzu die Werte eines Zeitraums ausgelesen, als Summe gespeichert und dann die vorherigen Einzelwerte gelöscht. Dies funktioniert für Pulsbasierte Sensoren (Interpreter\MeterInterpreter) ganz gut, bei Sensoren mit absoluten Messwerten (Interpreter\SensorInterpreter) müsste allerdings statt einer Summe der Mittelwert gespeichert werden, in der aktuellen Ausführung werden hierdurch die bestehenden Daten solcher Kanäle quasi unbrauchbar. Ja, hört sich sinnvoll an. Zumindest mal in der aktuellen Version zur Sicherheit den Channel-Typ überprüfen, damit keine Daten kaputt gemacht werden. Für nicht-MeterInterpreter fragt sich dann nur noch, welcher Zeitstempel für den Mittelwert genommen werden soll. Bei MeterInterpreter ist das einfach der letzte, bei SensorInterpreter wäre das der Mittelwert der Zeitstempel, oder? Eventuell kann man das verwendete Interpretermodell per API oder direkt aus der lib/Definition/EntityDefinition.json auslesen und so die Methode zur Zusammenfassung in vzcomress passend zum aktuellen Kanal wählen. Naja, m.E. unnötige Komplexität, ich würde die erlaubten Typen (also aktuell nur power) erstmal direkt in das Skript reinschreiben, ist ja nicht so, daß sich da ständig was ändert... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQlpUxAAoJEANsCm3lNaE7D4cH/0MPOIhzsS7HXplS3fyfLNG5 ucZPkZ6jLUAetE6z8iBj8tszjsvwlWLVHC0apcBLlK9Gr6z1rL4RPqnRRk28xWuf f5lBeu6hF+AxHZhCsCLDwECEuYNmHp4RoKmwqpw/Yyyz1gbXpgxmIk8qO6CzzU/s xrL16GfO7e8y86Y/S0kWBnZQwF/v/a70vPnYhX5U0Smkb1O9GioFNf0dv7IwmVW8 tRo4+08Dcz3SD8hKxEKeYwwXdH7SWQKs+0DhM1bUa9pBrqoJgUb5nVB1b1AxmyGo fwq86f95W01CyNZjX/oo/jfcH3T8YJbKNZVYeJzPckWNiTaOObtjtyVU4SEBgQQ= =qaYC -END PGP SIGNATURE-
Re: [vz-dev] vzcompress: Korrupte Daten bei absoluten Sensoren
On 04.11.2012 14:19, Hartmut Hoffmann wrote: Meine Frage, warum macht ihr das nicht direkt als funktion innerhalb mysql ? Und dann noch ggf. automatisch durch mysql ausführen lassen ? Ich gehe mal davon aus, du meinst stored procedures und den mysql event scheduler. Der Hauptgrund dafür ist: - es hat noch keiner implementiert (lies: patches welcome) Die restichen Gründe sind direkt davon abgeleitet: - stored procedures sind gut, um anderen (evt. mehreren) Clients eine definierte Schnittstelle zur Verfügung zu stellen, für sowas wie vzcompress bietet das m.E. keinen Vorteil. - wir wollen uns nicht auf ein DBMS einschränken (auch wenn 99% mysql benutzten dürften). Bei SPs hat jedes DMBS m.W. seinen eigenen Dialekt (kann mich aber auch irren), vzcompress sollte einigermaßen unabhängig vom DBMS sein (ungetestet, hab aber auf Anhieb nichts mysql-spezifisches darin gefunden) - Die für SPs benutzte Sprache ist so ziemlich das übelste, was ich bisher gesehen habe (zumindest seit ich mal Cobol lernen mußte, und das ist schon lange her). Alleine schon das Errorhandling ist gruselig, umständlich und völlig undurchsichtig. Ich wüßte wirklich nicht, warum man das freiwillig und ohne wirklich gute Grunde benutzen sollte, wenn man das gleiche Ergebnis mit script-code erreichen kann, der verglichen damit gut zu lesen, warten und debuggen ist. /rant
Re: [vz-dev] momentane Stromleistung mit Ethersex erfassen
Klaus Reichenecker, 28.06.2012 11:58: Es müsste doch möglich sein, z.B. über ein kleines control6-Skript die Impulse zusätzlich mit zu loggen, dann alle 10 Sekunden einen Durchschnittswert zu berechnen ? Und wenn in den letzten 10s kein Impuls kam? :) Im Prinzip würde das wohl schon gehen: Für jeden (konfigurierten) Channel die timestamps der letzten beiden Impulse merken und bei Abfrage daraus die Leistung berechnen. Man müßte dann halt auch noch konfigurieren, wieviel Energie ein Impuls entspricht. Relativ viel Aufwand für zu wenig Ergebnis. Das sollte eigentlich über die middleware möglich sein, allerdings kann die das auch noch nicht... noch :)
Re: [vz-dev] Anregung
Thorben Thuermer, 2012-05-07 13:08: nur so als Anregung: [...frontend/middleware feature-request...] das problem ist, dass es keinen aktiven entwickler gibt der an frontend und middleware arbeitet, deswegen passiert da auch nichts. Blödsinn. Nur weil sich mal ein oder zwei Monate Ruhe ist, heißt das nicht, daß da keiner mehr aktiv ist. Da es effektiv nur 2,5 Entwickler gibt, deren Freizeit beschränkt ist (und im Frühjahr die Konkurrenz auch noch größer ist) und die mit dem aktuellen Stand vielleicht sogar ganz gut leben können (ständiges Mosern erhöht übrigens auch nicht Motivation) oder sich das eine oder andere vielleicht in ihren eigenen Stand reingehackt haben, kann das durchaus mal vorkommen. Zum Thema: Man müßte properties um valid_from und valid_until erweitern und das Frontend müßte das entsprechend auswerten, also statt summe(values)*cost eben die values und Kosten selbst aufsummieren. Also kein Hexenwerk, aber sicher auch nicht high-prio, es gibt durchaus noch ein paar andere Baustellen. @Tom: Am besten im Mantis als feature request eintragen, dann wird's zumindest mal nicht vergessen... Vorerst kannst du als Workaround bei einer Kosten-Änderung einfach einen neuen Kanal anlegen und den zusammen mit dem alten in eine Gruppe packen (Aggregator gibt's m.W. ja leider auch noch nicht).
Re: [vz-dev] VZ auf iConnect
Stefan Seegel, 2012-02-29 18:25: Beim Installieren der Volkszählergeschichten (install.sh) sind dann allerdings Probleme aufgetreten, weil keine Verbindung zur Datenbank aufgebaut werden konnte. Mit ist aufgefallen das der MySql Daemon und Webserver (noch) gar nicht laufen. Wie kriegt man das alles ans Laufen? /etc/init.d/mysql start (ab squeeze geht auch service mysql start), apache2 dann analog. Damit das beim booten automatisch passiert: update-rc.d mysql enable Für weitere Infos dazu bitte Google bemühen, das sind absolute Basics und das hier soll keine allgemeine Support-Liste sein. Dann schonmal vorgegriffen, sollte das ganze eines Tages funktionieren: Kann ich mir auf der Kiste einen GCC installieren, und damit für das iConnect eine Applikation bauen? Würde mir dann auf die Schnelle für Ja. Ich hab auch avr-gcc drauf und bau mir damit die Images für meinen Net-IO.
Re: [vz-dev] Probleme mit Ethersex S0
Tom Weber, 2012-02-21 16:55: ... ooohkeeh - der Fehler saß vorm Monitor ;-) Die Option Use Polling ... muss wohl Deaktiviert sein. Habe es im Eifer des Gefechts wohl falsch gelesen. Polling braucht man nur, wenn man den ATMega32, der beim Net-IO dabei ist, mit mehreren S0 benutzen möchte, weil der wohl Interrupts nur auf einem Eingang kann (oder so). Funktionieren sollte das Polling aber unabhängig davon trotzdem. Wobei ich es persönlich überflüssig finde, abgesehen davon daß es den watchasync-Code (noch) unübersichtlicher macht.
Re: [vz-dev] vz auf 11-Webserver ?
Klaus Reichenecker, 2012-01-17 01:08: Oh je, so langsam bin ich überfordert Mag nicht mal jemand eine Anleitung schreiben wie das geht ? Wenn du's hinbekommen hast, darfst du das gerne machen :) Ansonsten sollte das nicht so problematisch sein. Man muß halt ein paar Besonderheiten beachten, weil man weder OS- noch DB-root ist. Wenn du ein bisschen auf Antworten deiner Mails eingehen würdest, könnte man dir übrigens auch besser helfen. (z.B.: Shell-Account? PHP-Version?) Meinen eigenen Server bekomme ich nicht zum laufen, irgendwas haut da mit der Datenbank nicht hin, ich rätsle noch. Wo hängt's denn? Wie bekomme ich denn die manuelle Installation hin ? Ich kann bei 11 kein Doctrine usw. installieren ? Die Installation beschränkt sich im Minimalfall darauf, die aktuelle Version von http://www.doctrine-project.org/projects/orm/download runterzuladen, entpacken, in den Webspace hochladen (vorzugsweise im VZ-Verzeichnis unter lib/vendor/doctrine) und den Pfad in der volkszaehler.conf.php entsprechend anzupassen. Wenn du einen shell-account hast, kannst du für die Installation wohl auch PEAR benutzen. ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] vz auf 11-Webserver ?
On 16.01.2012 21:30, Klaus Reichenecker wrote: Ich habe heute festgestellt, das ich seit Jahren ein 11-Web-Hosting-Paket habe, das auch PHP und MySQL unterstützt. Müsste darauf der VZ auch funktionieren ? Das wichtigste ist eigentlich PHP 5.3, der Rest sollte passen. Das kannst du rausfinden, indem du eine Datei (z.B. info.php) mit dem Inhalt ?php print phpinfo(); ? auf den Server hochlädst und mit dem Browser aufrufst. Wie bekomme ich die aktuelle Version auf den Server ? Oder mache ich einen grundsätzlichen Denkfehler, das Ganze kann gar nicht gehen und es braucht einen dedizierten Rechner dafür ? Nein, einen dedizierten Server brauchst du nicht. Das aktuelle install-script ist ein shell-script und funktioniert entsprechend nur mit einem shell-Zugang. Wenn du das bei deinem Paket nicht hast, mußt du die manuelle Installation machen oder auf deinem Rechnr installieren, per ftp hochschieben und die vz-Datenbank und -User dort anlegen. ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] Blindleistung im Privat-Haushalt?
On 15.01.2012 17:44, Udo1 wrote: Soweit ich weiß wird bei privaten Kunden ja auch nur der Wirkleistungsverbrauch berechnet. Ja, deshalb weil die alten Ferraris-Zähler nur Wirkleistung messen konnten. Was meinst du weshalb die VNBs u.a. so scharf darauf sind eHZs einzubauen. Man kann mit den Ferraris-Zählern durchaus Blindleistung messen (Hummel-Schaltung). Das wurde/wird in energieintensiven Betrieben gemacht und die müssen dafür auch bezahlen. Daß ein VNB sich für die Blindleistung von einzelnen Haushalten interessiert, glaube ich eher nicht. Andererseits, das wäre auch mal ein neues Preismodell :) Mit meiner Wärmepumpe wäre ich damit aber nicht gut dran... ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] Zugang zum Frontend absichern
p...@gmx.de, 2012-01-12 14:28: Äh, ok, aber wozu? Bzw. wie liest du dann mit dem Frontend die Daten wieder aus? Siehe meine Apache config von vorher in diesem Faden. Das Frontend liegt auf einer Domain. Diese wird auf SSL gezwungen und mit Apache Auth geschützt. Um einen Bypass für den Controller zu bilden hab ich jetzt eine Subdomain, die auf den gleichen Ornder zeigt. Einziger Unterschied ist dass ich nicht auf SSL zwinge und mit mod_rewrite alle Aufrufe verbiete die keien Daten hinzufügen. Ich erlaube also nur /middleware.php/data... und POST. Die Config hab ich mir schon angeschaut, aber mir ist nicht klar, wozu du den Aufwand treibst. Das Frontend sind lediglich statische Dateien, die vom Server ausgeliefert weden, da hast du keinen Vorteil, wenn du das irgendwie sicherst. Diese Dateien kann sich auch jeder selbst irgendwohin legen und damit das selbe machen wie mit dem Frontend auf deinem Server. Und wie greifst du denn von deinem Frontend auf die Middleware zu, wenn nur POST erlaubt ist? Und wozu soll der getrennte vhost für die Controller-Zugriffe gut sein? ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] Maßstab
p...@gmx.de, 2011-12-14 12:32: Bevor man hier diverse Automatismen entwickelt: Kann man nicht einfach bei den Kanälen eine Eigenschaft Sekundäerachse einfügen? Also von mir aus gerne. Ließe sich auch einfacher umsetzen... Ich stell mein Zeug auch lieber selbst ein, Justin hat's lieber schlicht (Apple-User halt, die lassen sich Entscheidungen lieber abnehmen :) So kann jeder selbst entscheiden ob er den jeweiligen Kanal auf der Primär- oder der Sekundärachse haben will. Dadurch treten unangenehme Man muß sich dann nur noch merken, welche Kurve zu welcher Achse gehört... ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] Maßstab
Harald Koenig, 2011-12-14 11:26: zwei strom-kanaele mit sehr unterschiedlich grossen messbereichen (hausanschluss mit 100kW, einzelmessungen im 100W bis kW bereich). auch die wuerden wir gerne auf unterschiedichen skalen gleichzeitig darstellen koennen. Wozu? Ich sehe gerade keinen Fall, bei dem beides gleichzeitig interessant ist. Ja, ich schau mir auch gerne den Verbrauch meines Haushalts zusammen mit dem der Wärmepumpe an, aber auch nur aus Bequemlichkeit... also bitte keinen harten automatismus wenn temperatur dann zweite skala sondern *noch* flexibler (und mehr als 2 skalen: z.b. hauptanschluss, klima, temperatur!). Mehr als zwei ist halt schwierig, weil's unsere Grafik-Lib nicht unterstützt... ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] Web-Frontend; komische Anzeige des Verbrauchs ?
Klaus Reichenecker, 2011-11-18 01:19: Du hast vollkommen Recht mit deiner Erklärung, sehr gut erklärt im letzten Beitrag, mein Mathe-LK ist zu lange her, eigentlich muss die Fläche unter der Linie ja die Leistung darstellen, somit dürften Ne, die Fläche ist die Energie. Die Höhe der Linie ist die Leistung. eigentlich einzelne Impulse gar nicht im Diagramm auftauchen ? Die Impulse sind die seitliche, vertikale Begrenzung der horizontalen Linien. Das kommt daher, daß die Leistung (zwangsläufig) aus der zeitlichen Differenz zwischen zwei Impulsen berechnet wird. Gibt es in VZ für mich als Laien eine Möglichkeit, die Anzahl der Impulse zu prüfen ? Wäre sicher auch mal interessant, um zu kontrollieren, ob alles richtig mitgeloggt wird ? siehe http://wiki.volkszaehler.org/development/api/reference#daten-kontext: $ curl http://server/pfad/data/deine_UUID.json?from=01-01-2010to=01-02-2010 Ansonsten einfach mal in's access-log vom Apache schauen, da wird ja auch jeder request mitgeloggt. Wie habt Ihr denn eure Sensoren entprellt ? Irgendwann soll z.B. der Siehe http://wiki.volkszaehler.org/hardware/controllers/avr_net-io#s0-anschluss. Ist Ethersex überhaupt in der Lage, innerhalb von 250 ms 2 Nachrichten an VZ zu schicken ? (Summarize Events in WatchaSync ist ausgeschaltet) Nein, aber die Events werden gespeichert und dann nacheinander rausgeschickt. Die Länge der Event-Queue kann man in watchasync unter Buffersize konfigurieren (default ist glaub ich 64). Ist aber kaum sinnvoll, das auf 1 oder so runterzusetzen. Dein Prellen bekommst du wahrscheinlich relativ einfach per Hardware (C) weg, von daher würde ich da eher nicht in watchasync rumpatchen... ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
Re: [vz-dev] libsml vzlogger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steffen Vogel, 2011-10-16 15:42: Bisher konnte ich ich nur Pakete für die amd64 und armel Architekturen compilieren. Hat jemand zufällig ne i386 Kiste rumstehen und würde dafür die Paktete bauen? Das geht auch auf deiner x64-Kiste: Einfach mit debootstrap ein x86-chroot einrichten. Infos gibt's unter http://wiki.debian.org/Debootstrap. Die empfehlen dafür eigentlich pbuilder, das ist aber etwas aufwendiger. Hm, packages für ein öffentliches repository sollte man das wohl schon sowas einsetzen... Gruß J -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOnZH0AAoJEANsCm3lNaE72fYH/3MBeWCE+5NGra2edgVwwAsx QStabFELq/6na2o7PAqMsEcoXUGHIFXdU38gezMq0f7bZCRsm+aV/rFwpBb2GsH+ +9oWElBl7J+kB2T+X6v4EJTqV7nJoANpjx8wlWF2e9PnqDZotolQbEFJVQkm7lq2 2O9AxPquUryoalBo5mdwqnuisH45tYaudxwnbYWckKoAGro1W7epmgv3w8fte1HA VHYXnGVxhIRbvOGPedss1ldzlk6MSTk7l/hA0N4OGmVicwmD01uwj55cUsXVVMBz tKxhzJBnkooHMFJAJrqiFRKN3YU2ElVOvifBJx2EDN0LHlXIm4QIwb3N5ChiRIY= =Xj4U -END PGP SIGNATURE- ___ volkszaehler-dev mailing list volkszaehler-dev@lists.volkszaehler.org https://volkszaehler.org/mailman/listinfo/volkszaehler-dev
