Re: [vz-dev] Falsche Darstellung von Stromzählerwerten
Am Dienstag, 19. November 2013 um 16:35 schrieb Jürgen Müller: Wird dann wieder Strom bezogen zeigt mir der Graph immer eine ansteigende Rampe, statt eines Pulses nach einer langen Flatline Ist hier schon ein Fehler bekannt? Ja, ein Konfigurationsfehler. Du kannst bei den Graphen als Style line oder steps wählen. Bei dir ist mit Sicherheit noch line aktiv, das wäre für Temperaturen passend. Bei Leistungen ist die Darstellung mit steps dann korrekt. mfg Daniel --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com
[vz-dev] Middleware, Data, Rows und Anzahl der Rows und Tuples
Hi,
wenn ich auf meinem Pi diese Anfrage stelle:
http://raspberrypi/middleware.php/data/14d37a00-34f4-11e3-91b6-3f631c60f726.json?from=now
Dann bekomme ich diese Antwort:
{version:0.3,data:{uuid:14d37a00-34f4-11e3-91b6-3f631c60f726,from:1384965305505,to:1384969505309,min:[1384966205759,429],max:[1384969505309,1277],average:723.585,consumption:844.143,rows:14,tuples:[[1384965905543,492,1],[1384966205759,429,1],[1384966505900,433,1],[1384966805009,444,1],[1384967105212,450,1],[1384967405732,490,1],[1384967705873,550,1],[1384968005193,487,1],[1384968305450,1117,1],[1384968605668,1100,1],[1384968905893,1123,1],[1384969205557,1246,1],[1384969505309,1277,1]]}}
Rows sind 14. Es werden jedoch nur 13 Tuples zurückgegeben. Ist das richtig so?
Im Wiki steht:
Die Antwort wird in Form eines JSON-Arrays zurück geliefert. z.B.:
[[123456789, 100, 1], [1234567891000, 98, 1], ... [123456790, 116, 1]]
Es besteht aus:
einem Zeitstempel
einem Messwert (keine Pulse!)
und die Anzahl der Messwerte/Pulse die für die Berechnung des Messwertes
genutzt wurden
Ist mit den Anzahl der Messwerten Rows gemeint? Dann würde es nicht passen.
Jedenfalls bei mir.
smime.p7s
Description: S/MIME cryptographic signature
Re: [vz-dev] Falsche Darstellung von Stromzählerwerten
Am Mittwoch, 20. November 2013 um 19:37 schrieb Jürgen Müller: Der Zähler hat nur eine Auflösung von 0.01 kWh, weshalb nicht bei jeder Messung eine Änderung erfolgt. Die Summe die unten Angezeigt wird (360 Wh) stimmt. Der Graph entspricht dem aber nicht. Hast du hier auch einen Vorschlag? Mit vzlogger auslesen und aggregieren lassen. Wird das zwar nicht genauer aber richtiger. Wenn du im frontend weiter rausgehst siehts besser aus? mfg Daniel --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com
Re: [vz-dev] Falsche Darstellung von Stromzählerwerten
On Wed, 20 Nov 2013 19:37:25 +0100 Jürgen Müller juergen4.muel...@gmail.com wrote: Ich habe die Einstellung jetzt auf steps geändert. Die Darstellung ändert sich da auch. Leider ist sie immer noch falsch. Der Zähler hat nur eine Auflösung von 0.01 kWh, weshalb nicht bei jeder Messung eine Änderung erfolgt. Die Summe die unten Angezeigt wird (360 Wh) stimmt. Der Graph entspricht dem aber nicht. Hast du hier auch einen Vorschlag? das problem ist ja recht klar: der zaehler liefert zwar immer den gleichen wert, aber intern werden halt die nicht angegeben nachkommastellen hochgezaehlt, die dann erst beim ueberlauf in die 2. nachkommastelle auftauchen. wenn der meterinterpreter aus den werten die leistung berechnet, ermittelt dieser (korrekt!), dass die leistung null sein muss, wenn zwei aufeinanderfolgende arbeitswerte gleich sind, und erzeugt entsprechend dort wo die aenderung stattfindet einen kurzen leistungs-peak. du koenntest nach daniel's vorschlag die werte ueber laengere zeitraeume aggregieren, dann wahre unwahrscheinlicher, dass aufeinanderfolgende gleiche werte geloggt werden, allerdings wird auch die ohnehin schon geringe aufloesung des zaehlers dann noch schlechter. was aber sinnvoller erscheint, waehre, die identischen werte nicht zu speichern, bzw keinen neuen wert, wenn keine aenderung stattgefunden hat, dann sollte der interpreter den verbrauch korrekt auf den gesamten zeitraum zwischen den aenderungen verteilen. dafuer gibt es wohl bisher keine methode. ich denke man koennte dafuer die delta-aggregation die jemand implementiert hatte verwenden? http://demo.volkszaehler.org/pipermail/volkszaehler-dev/2013-November/003182.html damit koenntest du dann einen recht langen aggregations-zeitraum waehlen, aber die aufloesung wuerde nicht schlechter werden, da trotzdem jede aenderung geloggt wird. (aber scheinbar auch nicht optimal, da, wie er schreibt, der erste wert immer geloggt wird, auch wenn er keine veraenderung darstellt, du haettest also weiterhin zwischendurch nulllinien.) alternativ muesste man das ganze verwerfen identischer werte irgendwie in vzlogger oder die middleware reinbekommen, notfalls vlt. ein script (anpassung von vzcompress?) das die werte nachtraeglich aus der db entfernt. Mit freundlichen Grüßen Jürgen Müller juergen4.muel...@gmail.com - Thorben Am 20.11.2013 um 17:27 schrieb Daniel Lauckner mail...@jahp.de: Am Dienstag, 19. November 2013 um 16:35 schrieb Jürgen Müller: Wird dann wieder Strom bezogen zeigt mir der Graph immer eine ansteigende Rampe, statt eines Pulses nach einer langen Flatline Ist hier schon ein Fehler bekannt? Ja, ein Konfigurationsfehler. Du kannst bei den Graphen als Style line oder steps wählen. Bei dir ist mit Sicherheit noch line aktiv, das wäre für Temperaturen passend. Bei Leistungen ist die Darstellung mit steps dann korrekt. mfg Daniel --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com
[vz-dev] vzlogger MeterD0.cpp Master branch parity
Hallo,
erfreulicherweise kann man nun für das Protokoll D0 parity und baud rate
über die vzlogger.conf konfigurieren.
(Nötig z.B. für Landis+Gyr E350 EDL21 .)
...
protocol : d0, /* see 'vzlogger -h' for list of available
protocols */
device : /dev/ttyUSB0,
enabled: true,
parity: 7e1,
baudrate:300,
...
Leider hat sich ein Fehler beim Setzen der einzelnen bits eingeschlichen.
(Ich weiss nicht, ob es schon jemand gesehen hat)
Dadurch wird unbeabsichtigt u.a. CRTSCTS gesetzt.
Damit sendet Udos USB IR Schreiblesekopf nicht. (macht er richtig, denn
ohne den vzlogger arbeitet er einwandfrei.)
falsch ist z.B.
...
case parity_7e1:
tio.c_cflag |= ~ PARENB;
...
Damit werden alle bits gesetzt (außer PARENB)
Richtig ist:
switch(_parity) {
case parity_8n1:
tio.c_cflag = ~ PARENB;
tio.c_cflag = ~ PARODD;
tio.c_cflag = ~ CSTOPB;
tio.c_cflag = ~ CSIZE;
tio.c_cflag |= CS8;
break;
case parity_7n1:
tio.c_cflag = ~ PARENB;
tio.c_cflag = ~ PARODD;
tio.c_cflag = ~ CSTOPB;
tio.c_cflag = ~ CSIZE;
tio.c_cflag |= CS7;
break;
case parity_7e1:
tio.c_cflag = ~CRTSCTS; // für paranoide, aber nicht
allgemein gültig.
tio.c_cflag |= PARENB;
tio.c_cflag = ~ PARODD;
tio.c_cflag = ~ CSTOPB;
tio.c_cflag = ~ CSIZE;
tio.c_cflag |= CS7;
break;
case parity_7o1:
tio.c_cflag = ~ PARENB;
tio.c_cflag |= PARODD;
tio.c_cflag = ~ CSTOPB;
tio.c_cflag = ~ CSIZE;
tio.c_cflag |= CS7;
break;
}
Dann klappt es auch mit dem Senden (geprüft mit Digitalkamera) und dem
Empfang (geprüft mit IR Fernbedienung vom Fernseher)
An dem Acknowledge, das der Zähler braucht arbeite ich noch. Außerdem
kann man die Schnittstelle auch mit einem Timeout versehen, so das der
read nicht für immer hängen bleibt.
/* Set return rules for read to prevent endless waiting*/
tio.c_cc[VTIME]= 50; /* inter-character timer 50*0.1s*/
tio.c_cc[VMIN] = 0; /* VTIME is timeout counter */
Der praktische Beweis der Funktion steht aber noch aus.
Gruß
Reinhard
Re: [vz-dev] vzlogger MeterD0.cpp Master branch parity
On Wed, 20 Nov 2013 23:36:13 +0100
Reinhard Wilzeck reinh...@wilzeck.de wrote:
erfreulicherweise kann man nun für das Protokoll D0 parity und baud rate
über die vzlogger.conf konfigurieren.
(Nötig z.B. für Landis+Gyr E350 EDL21 .)
protocol : d0,
parity: 7e1,
baudrate:300,
Leider hat sich ein Fehler beim Setzen der einzelnen bits eingeschlichen.
(Ich weiss nicht, ob es schon jemand gesehen hat)
Dadurch wird unbeabsichtigt u.a. CRTSCTS gesetzt.
Damit sendet Udos USB IR Schreiblesekopf nicht. (macht er richtig, denn
ohne den vzlogger arbeitet er einwandfrei.)
falsch ist z.B.
case parity_7e1:
tio.c_cflag |= ~ PARENB;
Damit werden alle bits gesetzt (außer PARENB)
Richtig ist:
switch(_parity) {
case parity_8n1:
tio.c_cflag = ~ PARENB;
das koennte die probleme erklaeren die andere user schon mit porteinstellungen
bei vzlogger hatten...
(finde den thread gerade nicht)
An dem Acknowledge, das der Zähler braucht arbeite ich noch. Außerdem
kann man die Schnittstelle auch mit einem Timeout versehen, so das der
read nicht für immer hängen bleibt.
/* Set return rules for read to prevent endless waiting*/
tio.c_cc[VTIME]= 50; /* inter-character timer 50*0.1s*/
tio.c_cc[VMIN] = 0; /* VTIME is timeout counter */
Der praktische Beweis der Funktion steht aber noch aus.
ich kann das leider mangels zaehlern wenig testen.
schickst du uns einen patch, sobald du eine version hast die laeuft?
danke!
Gruß
Reinhard
- Thorben
