[vz-users] Ferraris-Lesekopf zählt doppelt?

[Andreas Goetz]

Deine Rechnung benutzt ein "delta" (Zeitraum in ms) das Du nirgendwo
herleitest. Hier ist die komplette Rechnung:

Annahme: 1kWh Verbrauch = 1kW Dauerleistung für Zeit von 1 Stunde = 75
Umdrehungen pro Stunde = 75 imp / 3.6e6 ms

Formel:

  value [imp] * 3.6e6 [ms/h] * scale [Wh/kWh]
  ----------------------------------
  resolution [imp/kWh] * delta [ms]

  75 [imp] * 3.6e6 [ms/h] * 1000 [Wh/kWh]
= ---------------------------------------
  75 [imp/kWh] * 3.6e6 [ms]

  75 [imp] * 3.6e6 [ms/h] * 1000 [Wh/kWh]
= ---------------------------------------
  75 [imp] * 3.6e6 [ms] / 1 [kWh]

  1 [ms/h] * 1000 [Wh/kWh] * 1 [kWh]
= ----------------------------------
  1 [ms]

= 1000 [W] = 1 [kW]

Mit anderen Worten: wenn in der DB 75 Impulse für 1 Stunde stehen kommt am
Ende 1kW Dauer/Durchschnittsleistung raus. So würde ich das jedenfalls
erwarten.

Kannst Du mal bitte schauen was bei Dir für diesen Kanal wirklich in der DB
steht?

Viele Grüße,
Andreas


2015-05-13 13:08 GMT+02:00 Nils op den Winkel <nils at kusemuckl.de>:

> Jetzt habt ihr mich verwirrt.
>
> Also vzlogger sendet die 2 an die middleware:
>
> [May 12 21:36:02][s0]   Reading S0 - n=2 power=37.584392
> [May 12 21:36:02][mtr0] Got 2 new readings from meter:
> [May 12 21:36:02][mtr0] Reading: id=Power/StringItentifier: value=37.58
> ts=1431459362092
> [May 12 21:36:02][mtr0] Reading: id=Impulse/StringItentifier: value=2.00
> ts=1431459362092
> [May 12 21:36:02][chn0] Adding reading to queue (value=2.00
> ts=1431459362092)
> [May 12 21:36:02][SUM]  2.000000 @ 1431459362092
> [May 12 21:36:02][SUM]  RESULT 2.000000 @ 1431459362092
> [May 12 21:36:02][chn0] Buffer dump (size=1): {2.0000,}
> [May 12 21:36:02][chn0] ==> number of tuples: 1
> [May 12 21:36:02][chn0] compare: 1431459174383 1431459362092
> [May 12 21:36:02][chn0] JSON request body: [ [ 1431459362092, 2 ] ]
> [May 12 21:36:02][chn0] CURL: Connection #0 seems to be dead!
> [May 12 21:36:02][chn0] CURL: Closing connection #0
> [May 12 21:36:02][chn0] CURL: About to connect() to woodstock port 80 (#0)
> [May 12 21:36:02][chn0] CURL:   Trying 127.0.1.1...
> [May 12 21:36:02][chn0] CURL: connected
> [May 12 21:36:02][chn0] CURL: Sent 24 bytes..
> [May 12 21:36:02][chn0] CURL: Sent '[ [ 1431459362092, 2 ] ]' bytes
> [May 12 21:36:02][chn0] CURL: upload completely sent off: 24out of 24 bytes
> [May 12 21:36:02][chn0] CURL: Received 26 bytes
> [May 12 21:36:02][chn0] CURL: Received '{"version":"0.3","rows":1}' bytes
> [May 12 21:36:02][chn0] CURL: Connection #0 to host woodstock left intact
> [May 12 21:36:02][chn0] CURL Request succeeded with code: 200
>
> in meiner Datenbank steht auch immer ein value von "2" für den Kanal.
>
> Wenn ich den Sourcecode richtig versteht, ist der MeterInterperter für die
> Umrechnung verantwortlich. Darin steht
>
> (float) ($row[1] * 3.6e6 * $this->scale) / ($this->resolution * $delta)
>
> Wenn ich das jetzt mal für zwei Impulse ausrechne:
>
> [May 12 21:53:27][chn0] Adding reading to queue (value=2.00
> ts=1431460407277)
> [May 12 22:13:47][chn0] Adding reading to queue (value=2.00
> ts=1431461627548)
>
> (2 * 3.6e6 * 1000) / (75 * 1220271) = 78,67
>
> Und das zeigt mir das frontend auch bei Ausflösung 75 an. Aber in diesem
> Delta hat sich die Scheibe ja nur ein mal gedreht. Müsste deshalb die
> Rechnung nicht
>
> (1 * 3.6e6 * 1000) / (75 * 1220271) = 39,34
>
> sein?
>
> Ich werde heute abend nochmal den Zähler ablesen, und schauen, wo mein
> Denkfehler ist.
>
> Vielleicht liegt es auch an meiner alten middleware (ich glaube die ist
> von Oktober 2014)
>
> Schönen Gruß
>
> Nils
>
>
> Am 13. Mai 2015 um 09:04 schrieb Andreas Goetz <cpuidle at gmail.com>:
>
>> 2015-05-13 8:59 GMT+02:00 Udo1 <udo1 at gmx.net>:
>>
>>> Moin,
>>>
>>> Am 13.05.2015 um 08:55 schrieb Andreas Goetz:
>>>
>>>>
>>>>     Das heißt, ich stelle in der middleware die Auflösung einfach auf
>>>>     150 statt 75 und alles ist gut? Damit kann ich leben.
>>>>
>>>>
>>>> Nein, es bleibt bei 150. M.E. sendet vzlogger den "Wert" 1 der sich aus
>>>> "Count" 2 Impulsen errechnet hat. Ich besprech das mal mit den Entwicklern
>>>> ob sinnvoll.
>>>>
>>> Nein, auf 75, also die Zählerkonstante.
>>>
>>
>> Entschuldigung, natürlich- trotz der etwas verwirrenden 2 bleibt es bei
>> 75 wie Udo schreibt. Keine Umrechnungen.
>>
>>
>>> Gruß
>>> Udo
>>>
>>
>> Viele Grüße,
>> Andreas
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150513/9686c24b/attachment-0001.html>