[vz-dev] Easymeter mir Ethersex

[Tom Weber]

Hi Justin,

im Anhang meine gesammelten Daten der vergangenen Nacht.

Ich habe wohl sporadisch Fehlausleser, die zu völlig abstrusen Werten
führen. Der Wert unter "aktuell" ist aber richtig. Wenn ich direkt auf die
DB schaue, finde ich viele Datensätze mit Leistungen im MW bis GW-Bereich.
Andererseits auch so selten, dass schon mal über Stunden völlig konsistente
Daten ankommen - damit liegt es wohl nicht am Buffer, ist aber nur eine
Vermutung.

Wo die Fehldaten her kommen, wenn ihr das nicht habt - keinen blassen Dunst.
Mein "Labor" ist im 4.OG, der Stromzähler im Keller, ich gehe mit 3 freien
Adern der Amtsleitung da runter, also sicherlich so um die 15m ungeschirmt
im Versorgungskanal. Ich werde heute mal das NetIO in die Nähe des
Easymeters bringen und das dort laufen lassen - man darf hoffen, dass das
dann verschwunden ist.

Mir fällt vorerst nur eine Fehleranalyse ein, wo man solche falschen Daten
abfangen kann. Man wird sie wohl auch daran erkennen, dass der Datensatz
eine andere Länge hat. Frage wäre, kommt man da mit vzlogger weiter?

Irgendwo habe ich einen Beitrag gelsen, in dem jemand die Daten der RS2323
ohne vzlogger direkt auswertet, doch wie kriege ich das hin? Wenn ich mit
netcat <ip> 7970 die Daten lese, läuft das unendlich lange. Gibt es eine
Möglichkeit, die Datensätze einzeln von der RS232 zu lesen und an ein Skript
zu übergeben?

Grüße,
Tom

Möglicherweise ist der Buffer nicht gut, 
-----Ursprüngliche Nachricht-----
Von: Justin Otherguy [mailto:justin at justinotherguy.org] 
Gesendet: Dienstag, 27. März 2012 20:27
An: Tom Weber
Cc: 'volkszaehler.org'
Betreff: Re: [vz-dev] Easymeter mir Ethersex

Hallo Tom,

(BTW: wir haben einen IRC-Kanal: http://wiki.volkszaehler.org/contact ;
abends ist da auch immer was los)

Am 27.03.2012 um 20:06 schrieb Tom Weber:

> Ja, aber mein Stromzähler liefert das komplette Programm wirklich jede 
> Sekunde. Das wird dann doch etwas viel an Daten, oder?
ja, das stimmt, das sind viele Daten. Die Idee, nicht jeden Datensatz
auszuwerten, ist neu. Hat jemand ne Idee?

> Ich habe jetzt versucht, mit einem Skript
> 
> #!/bin/bash
> 
> while true
> do
>  vzlogger
>  sleep 15
> done
> 
> das etwas einzudämmen, doch leider "hängt" der prozess vzlogger nach 
> einigen Durchläufen im System fest. Erst wenn ich den Prozess vzlogger 
> kille, läuft er wieder weiter.
nuja - da spielt ja auch noch der Puffer im Net-IO rein; der füllt sich erst
mal an, auch wenn Du ihn erst mal nicht leerst. So einfach ist das wohl
nicht.

> Wenn ich den daemon laufen lasse, habe ich leider immer mal 10-100MW 
> Impulse in der DB
das klingt seltsam, aber ich weiss auch von Niemandem, der das schon mal so
benutzt hätte.

Lass mal laut nachdenken:
- die Zwischenwerte schlicht zu ignorieren halte ich für keine gute Lösung
(unpräzise, Probleme mit dem Puffer)
- vzlogger könnte mehrere Werte mitteln und dann nur diesen Mittelwert
übertragen
- wir könnten die Werte in der Datenbank verdichten, ganz ähnlich wie
RRD-Tool das tut; da könnte dann ein Job über die Datenreihe drüber laufen,
der faktisch die Auflösung in Abhängigkeit vom Alter der Daten verringert,
z.B.
  - alle Daten der vergangenen 4 Wochen -> volle Auflösung
  - alle Daten älter als 4 Wochen bis 6 Monate -> nur noch ein Messwert pro
Minute
  - alle Daten älter als 6 Monate -> nur noch ein Messwert pro 15 Minuten
  wenn wir sowas implementieren, liessen sich die Werte (sowohl die
Grenzwerte als auch die Auflösungen) sehr einfach anpassen
  ich sehe 2 Stellen, an denen das Skript "laufen" könnte:
  - via Middleware/API: 
    - das klappt immer
    - erfordert, dass Daten via API gelöscht werden dürfen
    - das wäre dann ein Skript in einer beliebigen Sprache, welches auf
einem beliebigen Host laufen kann (, der die Middleware erreichen kann)
    - würde allerdings Last auf der DB erzeugen
  - lokal auf der Datenbankmaschine; unschön, weil direkt auf der DB
(Backend-spezifisch, unschön)

Kommentare?


Gruss, J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Unbenannt.png
Type: image/png
Size: 198259 bytes
Desc: not available
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20120328/739cef7f/attachment-0001.png>