[vz-users] Zählerstand anzeigen

Sun Jan 11 11:52:25 CET 2015

     Hi,

wenn ich year durch day ersetzte, bekomme ich mein gesammten verbrauch
angezeigt.
Mein VZ läuft seit 20 Dezember.
Bei "http://.../middleware.php/data/.json?from=0&tuples=1&group=year"
bekomme ich 207 kW und das stimmt auch.
Gesammt habe (seit 20 Dezember bis Jetzt) ca.460 kW.
Also müsste ich 2014 ca. 253kW haben und das bekomme ich nicht hin.

Gruß

Am Sonntag, den 11.01.2015 um 11:34 schrieb Andreas Goetz:

Moin,

2015-01-11 11:19 GMT+01:00 Wolf, Sergej :

  Hallo Andreas,

wenn ich
"http://.../middleware.php/data/.json?from=0&tuples=1&group=year"
verwende, bekomme ich mein Verbrauch ab 01.01.2015 bis Jetzt.
was muss ich machen wenn ich mein verbrauch von 2014 sehen möchte?

Ersetze year durch day wie ein meinem Beispiel. Prinzipbedingt wird
der allererste Datenpunkt immer weggeworfen- bei Dir also das ganze
Jahr 2014, bei mir nur der erste Tag.

Gruß

Viele Grüße,
Andreas

Am Sonntag, den 11.01.2015 um 10:18 schrieb Andreas Goetz:

Moin,

2015-01-10 23:27 GMT+01:00 Marius Hellmann :

Hallo Sascha,

Hab mir fürs Anzeigen des Zählerstandes ein kleines PHP Script
"gestrickt" das den letzten Eintrag / Zählerstand aus der MySQL DB
abfragt und ausgibt welchen ich mir in FHEM per HTTPMOD abhole... Kann
ich bei Interesse zur Verfügung stellen...

Oder man nimmt einfach das API um den gesamten vom VZ ermittelten
Verbrauch(!- nicht den Zählerstand) abzufragen:

http://.../middleware.php/data/.json?from=0&tuples=1&group=day

Die Gruppierung dient dabei nur der Performance und veranlasst die
Middleware die Aggregationstabelle zu nutzen.

Der Unterschied von "ermittelten Verbrauch" und "Zählerstand" liegt
genau im Feld "Initialverbrauch" welches jedoch nur vom Frontend,
nicht von der Middleware verwendet wird.

Viele Grüße,
Andreas

Gruß Marius

Von meinem iPhone gesendet

Am 10.01.2015 um 10:43 schrieb Sascha Merg :

Guten Morgen Andreas,

in Ordnung, die Kurve an sich macht nicht viel Sinn, da bin ich bei
dir. In meinem FHEM-Frontend würde ich aber gerne Zählerstände
darstellen. Siehe dazu der Screenshot hier auf dieser Seite
unten: http://www.fhemwiki.de/wiki/Volkszaehler

Da die Werte richtig aus dem Kopf gelesen und in die DB geschrieben
werden, war ich der Annahme, dass ich sie auch richtig im Frontend
darstellen kann, zumal der Kanal ja auch vom Typ „Zählerstände"
ist.

Daher also meine Annahme, dass bei mir im Frontend etwas nicht stimmt.

Ein schönes Wochenende :)
Sascha

Am 09.01.2015 um 23:37 schrieb Andreas Götz :

Sascha,

Nochmal, ist wohl nicht klar geworden. Das Frontend zeigt die Leistung
an (!!!) und keinen Zählerstand. Ein Liniendiagramm für monoton
wachsende Zählerstände wäre ziemlich sinnlos...

Viele Grüße, Andreas

Am 09.01.2015 um 23:27 schrieb Sascha Merg :

Siehe Betreff: ich versuche die ganze Zeit, den aktuellen Zählerstand
anzuzeigen (das wäre der Wert 4978759.80, der auch erkannt und in die
Datenbank geschrieben wird). 4978759 sind genau die 4978 kWh, die am
Zähler angezeigt werden. Nur das Frontend zeigt ihn nicht an, sondern
irgendeinen anderen Wert.

Danke,
Sascha 

Am 09.01.2015 um 22:44 schrieb Andreas Götz :

Was heisst keine Verbesserung? Was erwartest Du? Scheint als hättest
Du ca. 1000W Last anliegen die leicht schwankt- erscheint mir nicht
falsch wenn Dein Zähler den Stand ausgibt?

Viele Grüße, Andreas

Am 09.01.2015 um 21:27 schrieb Sascha Merg :

Habe alle bis auf einen Channel rausgeschmissen. vzlogger liest ihn
richtig aus (letzte Zeile, Zählerstand):

[Jan 09 21:13:23][mtr0] Got 7 new readings from meter:
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:1.8.0*255/ObisItentifier:1-0:1.8.0*255 value=4978759.80
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 value=4977759.80
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:1.8.2*255/ObisItentifier:1-0:1.8.2*255 value=1000.00
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:2.8.0*255/ObisItentifier:1-0:2.8.0*255 value=2687276.30
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:2.8.1*255/ObisItentifier:1-0:2.8.1*255 value=2686276.30
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:2.8.2*255/ObisItentifier:1-0:2.8.2*255 value=1000.00
ts=1420834403.110
[Jan 09 21:13:23][mtr0] Reading:
id=1-0:16.7.0*255/ObisItentifier:1-0:16.7.0*255 value=1060.00
ts=1420834403.110
[Jan 09 21:13:23][chn0] Adding reading to queue (value=4978759.80
ts=1420834403.110)

Via phpmyadmin sehe ich, dass die Werte dort ankommen:

Und die entity 38 ist so konfiguriert:

Im Frontend aber keine Verbesserung:

Am 09.01.2015 um 21:01 schrieb Andreas Götz :

Hast du die conf korrigiert? ML nur den einen Channel drin lassen? Was
steht im logfile vom vzlogger?

Raten hilft nicht...

Viele Grüße, Andreas

Am 09.01.2015 um 20:57 schrieb Sascha Merg :

Danke für den Hinweis! War wohl ein Copy/Paste-Fehler. Ändert aber
leider nichts am Frontend.

Ich habe jetzt festgestellt, dass die vom vzlogger erfassten Werte
genau dieser Channel nicht in die Datenbank geschrieben werden. Was
könnte die Ursache dafür sein?

Danke,
Sascha

Am 09.01.2015 um 08:56 schrieb Andreas Goetz :

2015-01-09 8:22 GMT+01:00 Daniel Lauckner :
Am Donnerstag, 8. Januar 2015 um 22:06 schrieb Sascha Merg:
>             "device": "/dev/ttyUSB0",       // Haus und PV
>             "channels": [{
>                 "identifier": "1-0:1.8.0",  // Zaehlerstand
>                 "uuid":
"6fdf0aa0-9771-11e4-8a2f-1d45fd8b3483",
[...]
>             "device": "/dev/ttyUSB1",       // Waermepumpe
>             "channels": [{
>                 "identifier": "1-0:1.8.0",  // Zaehlerstand
>                 "uuid":
"6fdf0aa0-9771-11e4-8a2f-1d45fd8b3483",
>                 "middleware":
"http://localhost/middleware.php"

Wenn man die selbe UUID zweimal verwendet kann es nur in die Hose
gehen.

So ist es. Du mischst Daten von 2 Zählern in einen Kanal der
Middleware. Dabei mag irgendwas rauskommen, auch wenn Beides
Zählerstände sind...

mfg Daniel

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com [1]

Links:
------
[1] http://www.avast.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150111/2eb4a1b1/attachment-0001.html>