Re: [vz-dev] Aggregierung von Daten im vzlogger ? BETATESTER gesucht !
Am Samstag, 13. April 2013 um 20:57 schrieb Peter Evertz: > Am 08.04.2013 12:09, schrieb Peter Evertz: >> Der vzlogger liefert für SML Messsages scheinbar jeden Messwert an die >> middleware. Das führt zu grossen Datenmengen und auch Lastproblemen >> auf schwacher Hardware ( z.B. raspi ). >> >> Ich überlege den vzlogger so zu erweitern dass er in einem Zeitfenster >> aggregiert. > Furchtlose betatester vor: https://github.com/peterevertz/vzlogger.git Check. > Ich konnte es nur mit protocol "sml" testen. Es sollte aber für alle > "APIs" und "meters" funktionieren. Bei mir liest vzlogger auch nur ML-Zähler. > "aggtime" : 15, /* Das ist die Zeit die mindestens "gesammelt" > wird */ In Sekunden? > "aggmode" : "MAX", /* MAX = maximum des > Aggregationszeitraum (für Zähler), AVG = Durchschnitt im > Aggregationszeitraum (für sensoren), NONE (default) keine aggregierung */ > Es ist auch die Kombination "aggtime > 0" und ohne aggmode ( = NONE) > sinnvoll: Dabei werden die Daten gesammelt und in einem Schwung an die > middleware übertragen. Für Impulszähler wäre ein weiterer Mode nötig: Summe. Außerdem finde ich es eine enorme Fehlerquelle das so zu konfigurieren. Der passende Mode sollte in der json für die Meterconfig hinterlegt sein und in der Userconfig nur aktiviert werden. Aber zum Testen ok. Einen großen Unterschied bei der CPU-Last im "Leerlauf" konnte ich nicht feststellen. vzlogger braucht soviel wie vorher, die php-Prozesse der middleware(?) auch (bei mir <10%). Scheinen aber in der Anzahl weniger geworden zu sein. Da das aber nicht mein Hauptproblem war hab ich da seither auch nicht so genau drauf geachtet, also bitte nicht böse sein wenn ich das falsch wiedergegeben habe. mfg Daniel
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo, Am Samstag, 13. April 2013 um 14:57 schrieb Florian Knodt: > 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) 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 > 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. So wie ichs jetzt konfiguriert habe müsste das Script alle Datensätze älter als 30 Tage auf 300-Sekunden zusammenfassen. Macht es aber nicht (ich hab mal die %-Anzeige deaktiviert): 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 mfg Daniel
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
[vz-dev] SD-Karte
Hallo, meine Sammlung nicht RPi kompatibler SD Karten wächst. Wer kann mir eine wirklich im RPi funktionierende 32 GB SD Karte nennen? Die ganzen Web-Links sind zum Teil so alt, dass es die Karten schon gar nicht mehr gibt und die empfohlenen funktionieren teilweise trotzdem nicht... Danke und Gruß Bernd<>
Re: [vz-dev] SD-Karte
Hallo, Am 2013-04-14 13:41, schrieb Bernd Gewehr: Wer kann mir eine wirklich im RPi funktionierende 32 GB SD Karte nennen? Die ganzen Web-Links sind zum Teil so alt, dass es die Karten schon gar nicht mehr gibt und die empfohlenen funktionieren teilweise trotzdem nicht... Bei mir werkelt eine SanDisk Ultra bisher problemlos - ist allerdings auch nicht unbedingt günstig… Florian
Re: [vz-dev] SD-Karte
Dito- allerdings 16gb. Von meinem iPhone gesendet Am 14.04.2013 um 13:48 schrieb f.kn...@yotaweb.de: > Hallo, > > Am 2013-04-14 13:41, schrieb Bernd Gewehr: >> Wer kann mir eine wirklich im RPi funktionierende 32 GB SD Karte >> nennen? Die ganzen Web-Links sind zum Teil so alt, dass es die Karten >> schon gar nicht mehr gibt und die empfohlenen funktionieren teilweise >> trotzdem nicht... > > Bei mir werkelt eine SanDisk Ultra bisher problemlos - ist allerdings auch > nicht unbedingt günstig… > > Florian
[vz-dev] vzlogger.init
Hallo, das init-script zu vzlogger aus dem Volkszaehler GIT geht von der Existenz eines Benutzers vzlogger in einer Gruppe vzlogger aus. Auf dem “normalen” RPi haben wir den nicht. Was wird empfohlen: User und Gruppe anlegen? Beides auf root setzen? Danke und Gruß Bernd P.S.: Warum wird eigentlich das init-Script im “Standard” nicht verwendet? Macht doch mehr Sinn als den vzlogger per Aufruf aus der rc.local zu starten, oder?<>
Re: [vz-dev] Aggregierung von Daten im vzlogger ? BETATESTER gesucht !
Am Samstag, 13. April 2013 um 20:57 schrieb Peter Evertz: > Furchtlose betatester vor: https://github.com/peterevertz/vzlogger.git Da passt was nicht. Ich habe 2 Meter, zusammen 3 Kanäle, alle SML. Zuerst hatte ich noch einen Fehler in der Config (die aggtime vergessen) was starke Peaks zur Folge hatte. Das gabs in der Vergangenheit auch _gelegentlich_, hab mir deswegen erstmal keine Gedanken gemacht. Jetzt hab ich in ch0 einen Wert alle 60s. Gut soweit. Aber in ch2 (ch1 ändert sich der Zählerstand grad nicht). sind es ein Wert etwa alle 180s. Obwohl bei mtr1 auch 60s aggtime eingestellt wurden. http://www.jahp.de/volkszaehler/vzlogger-agg-fehler.jpg mfg Daniel
Re: [vz-dev] Aggregierung von Daten im vzlogger ? BETATESTER gesucht !
Am 14.04.2013 15:29, schrieb Daniel Lauckner: Am Samstag, 13. April 2013 um 20:57 schrieb Peter Evertz: Furchtlose betatester vor: https://github.com/peterevertz/vzlogger.git Da passt was nicht. Ich habe 2 Meter, zusammen 3 Kanäle, alle SML. Zuerst hatte ich noch einen Fehler in der Config (die aggtime vergessen) was starke Peaks zur Folge hatte. Das gabs in der Vergangenheit auch _gelegentlich_, hab mir deswegen erstmal keine Gedanken gemacht. Jetzt hab ich in ch0 einen Wert alle 60s. Gut soweit. Aber in ch2 (ch1 ändert sich der Zählerstand grad nicht). sind es ein Wert etwa alle 180s. Obwohl bei mtr1 auch 60s aggtime eingestellt wurden. http://www.jahp.de/volkszaehler/vzlogger-agg-fehler.jpg mfg Daniel Wann hast Du das repository gezogen ? Gestern nacht um ca. 2Uhr habe ich noch einen Fehler in der Funktion Buffer:clean() gefunden und gefixed. Was hast Du in die Konfig geschrieben als "aggtime" ? Auch bei beiden Meter definiert ? Bei jedem channel aggmode gesetzt ? Wie oft liefert dein Zähler Daten ? Ich habe auch zwei Zähler. Die liefern ca. jede Sekunde Daten. Ich habe 6 Kanäle 3 mal Leistung, 3 mal Zählerstand. Ich habe eine aggtime von 15 Sekunden und entsprechend MAX bei Zählern und AVG bei Leistung. Die Kurven sehen alle OK aus. Die Kurve aus Leistung und Zählerstand sind fast identisch. Kannst Du mal den debug mode anmachen "verbosity : 15" und ins Logfile schauen. Dann siehst Du wann welche Werte wozu aggregiert wurden. Wenn Du willst kannst Du mir auch config und Logfile als PM schicken und ich schaue mal was da schief läuft. Danke fürs testen !! Grüße Peter
[vz-dev] Update vom GIT
Hallo! kann jemand mal posten, wie ein Update vom Git zu machen ist? Einfach wieder git clone git://github.com/volkszaehler/volkszaehler.org.gitim /var/www/ folder und alles drüberbraten? Danke und Gruß Bernd<>
Re: [vz-dev] Update vom GIT
Hallo Bernd, geh in den Ordner und dann git pull Gruß __ /homas Am 14. April 2013 18:23 schrieb Bernd Gewehr : > Hallo! > > kann jemand mal posten, wie ein Update vom Git zu machen ist? > > Einfach wieder > > > git clone git://github.com/volkszaehler/volkszaehler.org.git > > im /var/www/ folder und alles drüberbraten? > > Danke und Gruß > > Bernd >
Re: [vz-dev] S0 Meter direkt an RS232 und Raspberry Pi
Am 11. April 2013 22:35 schrieb Thorben Thuermer : > On Thu, 11 Apr 2013 20:29:03 +0200 Jan Tamm wrote: > > Am 11. April 2013 09:55 schrieb Thorben Thuermer : > > > ich habe den code schonmal gelesen und einen groeberen bug gefixt, > > > wohl dummerweise mal wieder nur in einer (der c-) version, > > > anscheinend hast du gerade den gleichen in der c++ version gefunden? > > > > http://volkszaehler.org/pipermail/volkszaehler-users/2012-December/000757.html > > > > https://github.com/volkszaehler/vzlogger/commit/d5c0a10ec3a08c47dd0d55972ce3d3a8b4906c25 > > > > > > Genau, der Bug ist in der C++ Version noch enthalten. Zusätzlich wurde > der > > > Meter in der C++ Version aber ergänzt, sodass er nun drei Readings > > > ermittelt: > > 1) Identifier "counter" mit value gleich einem internen Zähler, der > erhöht > > wird. Mein Verständnis war, dass bei Countern immer nur Impulse > übermittelt > > werden, und im Frontend der value Wert ignoriert wird (was leider die > > Aggregation in der Middleware vor dem Frontend unmöglich macht). Also > > sollte der doch Value 1 haben. > > 2) Einen NilIdentifier mit Wert 1 der sich mir nicht erschließt. Habt Ihr > > eine Idee was das sein könnte? > > 3) einen Power Identifier der die errechnete Leistung ausgibt. Leider > > werden zur Errechnung der Leistung jedesmal zwei Impulse gezählt und > nicht > > ein Zeitstempel vom vorherigen Lauf herangezogen. Folglich wird im > counter > > nur jeder zweite Impuls weitergegeben. > > der code war mir noch nicht bekannt, muss ich bei gelegenheit mal > reinschauen... > vielleicht moegen die autoren mal was dazu sagen? > > > Ganz komisch wird es, das zwar die drei Readings errechnet werden aber > die > > Funktion mit "return 1" nur den ersten Wert im counter zurückgibt, der > wie > > oben beschrieben nur die halbe Frequenz hat. Also insgesamt bin ich > stutzig > > ob jemand den S0 Meter in der c++ Variante nutzt. > > vermutlich nicht. > in der C-version sollte er aber soweit funktionieren, mit dem erwaehnten > fix. > Da sich niemand gemeldet hat, habe ich selbst Änderungen eingebaut. Wenn ich, wie in der C++ Version angefangen, auch den aus den Impulsen ausgerechnete Leistung übergeben will, muss ich den MeterS0 umstellen und StringIdentifier einbauen. Damit brechen wir die Kompatibilität zu der C Version. Da ist es wohl besser, den C++ Code der C Version anzugleichen und weiterhin ohne Identifier die Impulse zurückzugeben. Wie würde das nun ins Repository kommen, kann ich einfach einen Pull Request starten? --Jan
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] Zähler die SML nur im Pull Mode unterstützen - Möglichkeiten mit vzlogger
Hallo Peter,
Vielen Dank schonmal. Es scheint zu funktionieren.
Der Zähler antworet schon mal. Jedoch hält sich ITF anscheinend nicht an
den Standard.
Ich könnte dir mal eine komplette Antwort zukommen lassen.
Ich versuche derweil den Zähler mit SML Kommandos abzufragen.
---
[Apr 14 21:18:01][mtr0] Creating new meter with protocol sml.
[Apr 14 21:18:01][sml] pullseq len:216 found
[Apr 14 21:18:01][mtr0] Meter configured.
[Apr 14 21:18:01] New meter initialized (protocol=sml)
[Apr 14 21:18:01] Have 1 meters.
[Apr 14 21:18:01][main] foreground=1, daemon=0, local=1
[Apr 14 21:18:01] NOT Daemonize process...
[Apr 14 21:18:01] Opened logfile /var/log/vzlogger.log
[Apr 14 21:18:01][] ===> Start meters.
[Apr 14 21:18:01][mtr0] Meter connection established
[Apr 14 21:18:01][mtr0] Meter thread started
[Apr 14 21:18:01][mtr0] meter is opened. Start channels.
[Apr 14 21:18:01][] Startup done.
[Apr 14 21:18:01][mtr0] Number of readers: 32
[Apr 14 21:18:01][mtr0] Config.daemon: 0
[Apr 14 21:18:01][mtr0] Config.local: 1
warning: could not read the whole file
[Apr 14 21:18:03][mtr0] Got 1 new readings from meter:
[Apr 14 21:18:03][mtr0] Reading:
id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
[Apr 14 21:18:03][mtr0] Updating interval to 1
[Apr 14 21:18:03][mtr0] Got 1 new readings from meter:
[Apr 14 21:18:03][mtr0] Reading:
id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
[Apr 14 21:18:03][mtr0] Got 1 new readings from meter:
[Apr 14 21:18:03][mtr0] Reading:
id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
[Apr 14 21:18:03][mtr0] Got 1 new readings from meter:
[Apr 14 21:18:03][mtr0] Reading:
id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
warning: could not read the whole file
mfg
Michael
Am 13.04.2013 20:13, schrieb Peter Evertz:
Am 13.04.2013 18:17, schrieb Peter Evertz:
Am 13.04.2013 02:03, schrieb Peter Evertz:
Am 12.04.2013 15:39, schrieb Michael Kreuzer:
Super, vielen vielen Dank für die schnelle Antwort.
ja.. hab einen Raspberry und hab auch vzlogger selber kompiliert.
Also mein Initstring ist ein HEX String. Vielleicht kannman den in
der vzlogger.conf anpassbar machen?
mfg
Michael
Scheint mir einfach. Ich könnte es am WE mal einbauen und Du
schaust ob es funktioniert. Kannst Du den vzlogger selber aus
einem git-Repo ziehen und übersetzten ?
Test mal https://github.com/peterevertz/vzlogger.git
Im vzlogger.conf kannst Du eine "pullseq" definieren. Die besteht
aus einer HEX string, der vor jedem lesen gesendet wird. Im Beispiel
wäre das "@d d"
"meters" : [{
"enabled" : true, /* disabled meters will be ignored */
"protocol" : "sml", /* see 'vzlogger -h' for list of available
protocols */
"device" : "/dev/usb-ir-lesekopf0",
"baudrate" : 9600,
"pullseq" : "406420640D0A",
"channels": [{
Bitte NICHT ausprobieren ! Ich habe im GIT einen fehlerhaften Stand
produziert ! Ich gebe Bescheid wenn es wieder ok ist !
Der Stand im repo ist wieder ok. Also bitte testen !
Re: [vz-dev] vzlogger.init
Hi Bernd, Am 14.04.2013 um 14:20 schrieb Bernd Gewehr: > das init-script zu vzlogger aus dem Volkszaehler GIT geht von der Existenz > eines Benutzers vzlogger in einer Gruppe vzlogger aus. > > Auf dem “normalen” RPi haben wir den nicht. den kannst Du zu Fuss anlegen: adduser --system --no-create-home --group --disabled-password --shell /bin/false vzlogger usermod -a -G dialout vzlogger touch /var/log/vzlogger.log chown vzlogger:adm /var/log/vzlogger.log chown vzlogger:adm /etc/vzlogger.conf Zu finden war das in https://github.com/volkszaehler/vzlogger/blob/master/debian/vzlogger.postinst Es wird demnächst wieder ein aktuelles Debian-Paket für vzlogger geben. Wenn Du vzlogger damit installierst, wird das automagisch mit erledigt. > P.S.: Warum wird eigentlich das init-Script im “Standard” nicht verwendet? > Macht doch mehr Sinn als den vzlogger per Aufruf aus der rc.local zu starten, > oder? Ist Geschmackssache; wenn das Init-Skript griffbereit liegt, würde ich das der rc.local-Variante vorziehen. Was meinst Du mit "im Standard"? Gruss, J. P.S.: obiges "S-Wort" lässt mich an das hier denken: http://bit.ly/ocMh7y
Re: [vz-dev] Zähler die SML nur im Pull Mode unterstützen - Möglichkeiten mit vzlogger
Am 14.04.2013 21:27, schrieb Michael Kreuzer: Hallo Peter, Vielen Dank schonmal. Es scheint zu funktionieren. Der Zähler antworet schon mal. Jedoch hält sich ITF anscheinend nicht an den Standard. Ich könnte dir mal eine komplette Antwort zukommen lassen. Ich versuche derweil den Zähler mit SML Kommandos abzufragen. --- [Apr 14 21:18:01][mtr0] Creating new meter with protocol sml. [Apr 14 21:18:01][sml] pullseq len:216 found [Apr 14 21:18:01][mtr0] Meter configured. [Apr 14 21:18:01] New meter initialized (protocol=sml) [Apr 14 21:18:01] Have 1 meters. [Apr 14 21:18:01][main] foreground=1, daemon=0, local=1 [Apr 14 21:18:01] NOT Daemonize process... [Apr 14 21:18:01] Opened logfile /var/log/vzlogger.log [Apr 14 21:18:01][] ===> Start meters. [Apr 14 21:18:01][mtr0] Meter connection established [Apr 14 21:18:01][mtr0] Meter thread started [Apr 14 21:18:01][mtr0] meter is opened. Start channels. [Apr 14 21:18:01][] Startup done. [Apr 14 21:18:01][mtr0] Number of readers: 32 [Apr 14 21:18:01][mtr0] Config.daemon: 0 [Apr 14 21:18:01][mtr0] Config.local: 1 warning: could not read the whole file [Apr 14 21:18:03][mtr0] Got 1 new readings from meter: [Apr 14 21:18:03][mtr0] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000 [Apr 14 21:18:03][mtr0] Updating interval to 1 [Apr 14 21:18:03][mtr0] Got 1 new readings from meter: [Apr 14 21:18:03][mtr0] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000 [Apr 14 21:18:03][mtr0] Got 1 new readings from meter: [Apr 14 21:18:03][mtr0] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000 [Apr 14 21:18:03][mtr0] Got 1 new readings from meter: [Apr 14 21:18:03][mtr0] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000 warning: could not read the whole file Die warning kommt aus der libsml: Die messages sind scheinbar unvollständig.
Re: [vz-dev] Aggregierung von Daten im vzlogger ? BETATESTER gesucht !
Am 14.04.2013 10:56, schrieb Daniel Lauckner: Am Samstag, 13. April 2013 um 20:57 schrieb Peter Evertz: Am 08.04.2013 12:09, schrieb Peter Evertz: "aggtime" : 15, /* Das ist die Zeit die mindestens "gesammelt" wird */ In Sekunden? Ja. "aggmode" : "MAX", /* MAX = maximum des Aggregationszeitraum (für Zähler), AVG = Durchschnitt im Aggregationszeitraum (für sensoren), NONE (default) keine aggregierung */ Es ist auch die Kombination "aggtime > 0" und ohne aggmode ( = NONE) sinnvoll: Dabei werden die Daten gesammelt und in einem Schwung an die middleware übertragen. Für Impulszähler wäre ein weiterer Mode nötig: Summe. An welchen Meter denkst Du ? Ich habe im Code keinen gefunden der eine Anzahl liefert. Kann ich aber natürlich einbauen. Außerdem finde ich es eine enorme Fehlerquelle das so zu konfigurieren. Der passende Mode sollte in der json für die Meterconfig hinterlegt sein und in der Userconfig nur aktiviert werden. Aber zum Testen ok. Was meinst Du mit "json für die Meterconfig" ? Redest Du von der middleware ? Einen großen Unterschied bei der CPU-Last im "Leerlauf" konnte ich nicht feststellen. vzlogger braucht soviel wie vorher, die php-Prozesse der middleware(?) auch (bei mir <10%). Scheinen aber in der Anzahl weniger geworden zu sein. Der Vzlogger verbraucht nicht weniger CPU. Der macht ja das gleiche wie vorher. Es ist eine Entlastung für middleware, DB etc. Da merke ich es auf dem raspi deutlich. Mit aggregierung auf 30 Sekunden für 6 Kanäle geht der raspi von 100% CPU auf ca. 20-50. Damit kann man dann auch das Frontend bedienen.
Re: [vz-dev] Aggregierung von Daten im vzlogger ? BETATESTER gesucht !
Morgen, Am Montag, 15. April 2013 um 01:05 schrieb Peter Evertz: > Am 14.04.2013 10:56, schrieb Daniel Lauckner: >> Am Samstag, 13. April 2013 um 20:57 schrieb Peter Evertz: >>> Am 08.04.2013 12:09, schrieb Peter Evertz: >>> "aggmode" : "MAX", /* MAX = maximum des >>> Aggregationszeitraum (für Zähler), AVG = Durchschnitt im >>> Aggregationszeitraum (für sensoren), NONE (default) keine aggregierung */ >>> Es ist auch die Kombination "aggtime > 0" und ohne aggmode ( = NONE) >>> sinnvoll: Dabei werden die Daten gesammelt und in einem Schwung an die >>> middleware übertragen. >> Für Impulszähler wäre ein weiterer Mode nötig: Summe. > An welchen Meter denkst Du ? Ich habe im Code keinen gefunden der eine > Anzahl liefert. Kann ich aber natürlich einbauen. Ist ein wenig Halbwissen aber bei S0-Zählern wird in der DB doch die Impulszahl gespeichert? >> Außerdem finde ich es eine enorme Fehlerquelle das so zu >> konfigurieren. Der passende Mode sollte in der json für die >> Meterconfig hinterlegt sein und in der Userconfig nur >> aktiviert werden. >> >> Aber zum Testen ok. > Was meinst Du mit "json für die Meterconfig" ? Redest Du von der > middleware ? Ja. Die Einstellungen, abhängig vom "type" der Kanäle, sind in der middleware hinterlegt. Mir fällt nur leider noch immer nicht der korrekte Name ein... > Mit aggregierung auf 30 Sekunden > für 6 Kanäle geht der raspi von 100% CPU auf ca. 20-50. Damit kann man > dann auch das Frontend bedienen. Die 100% hattest du immer oder nur bei Zugriff? Das das frontend besser reagiert steht außer Frage. Bei Minutenwerten kann ich auf dem Raspi auch endlich mit den Wochen- und Monatsansichten arbeiten. Und entschuldige das deine Antwort in beide Mailinglisten gesandt wurde. Ich hatte da was falsch konfiguriert. mfg Daniel
