Erweiterung von 15_CUL_EM

[Guest]

Originally posted by: <email address deleted>

Hallo Leute,

da mein EM 1000 WZ entweder nicht richtig ausgerichtet ist, oder der
rote Strich auf meiner Drehscheibe im Zähler etwas blass ist, sind die
Zählerwerte des EMWZ immer etwas zu hoch und der kumulierte
Zählerstand muss immer mal wieder nachkorrigiert werden. Da es mir zu
umständlich war, immer die fhem.save zu editieren und ich außerdem der
Meinung bin, dass der Basis-Wert in eine Konfigurations-Datei rein
sollte, habe ich die 15_CUL_EM etwas umgebaut, so dass die define-
Zeile in fhem.cfg den Basiswert mit übergeben kann. Folgende
Änderungen habe ich durchgeführt:

In CUL_EM_Define($$):

return "wrong syntax: define CUL_EM ".
                                "[corr1 corr2 CostPerUnit
BasicFeePerMonth BasisCnt]"
            if(int(@a) < 3 || int(@a) > ;

und weiter unten:

  $hash->{BasicFeePerMonth} = (int(@a) > 6 ? $a[6] : 0);
  $hash->{BasisCnt} = (int(@a) > 7 ? $a[7] : 0);

Und dann in CUL_EM_Parse($$):

    # initialize basis_cnt with value from fhem.cfg
    my $basis_cnt = $hash->{BasisCnt};
    # initialize basis_cnt_last
    my $basis_cnt_last = 0;
    if(defined($hash->{READINGS}{basis_cnt_last})) {
      $basis_cnt_last = $hash->{READINGS}{basis_cnt_last}{VAL};
    }
    if ($basis_cnt ne $basis_cnt_last) { # new value in fhem.cfg
entered
      $readings{basis_cnt_last} = $basis_cnt;
    }
    else { # if new value in fhem.cfg, stored basis value is
irrelevant
      if(defined($hash->{READINGS}{basis})) {
        $basis_cnt = max($hash->{READINGS}{basis}{VAL},$basis_cnt);
      }
    }

    # correct counter wraparound
    if($total_cnt< $total_cnt_last) {
      $basis_cnt += 65536;
    }
    if($basis_cnt >0) {
      $readings{basis} = $basis_cnt;
    }
    #

Folgende Überlegungen/Erläuterungen dazu:
- Der basis_cnt kann nicht immer aus der CFG genommen werden, da
dieser Wert bei einem "counter wraparound" erhöht werden muss. Eine
Alternative wäre da, die fhem.cfg zu ändern, wenn ein Zählerüberlauf
stattfindet.
- Wenn ein neuer Wert im CFG eingegeben wird (dies wird überprüft mit
dem in fhem.save gespeicherten Wert basis_cnt_last) darf der (u.U.
schon um 65536 erhöhte) basis-Wert nicht verwendet werden.

Noch ein Hinweis an alle Neulinge (zu denen ich mich auch noch zähle),
der aber auch in der diesbezüglichen Doku steht:

Der Basis-Wert ergibt sich aus dem aktuellen Zählerstand (Stromzähler)
mal Umdrehung pro KW (steht auf dem Zähler) minus aktuellem Wert für
total_cnt des EMWZ.

@Rudi: Falls du es wert findest, dies entsprechend einzuchecken, muss
natürlich auch die entsprechende Doku geändert werden. Falls es nicht
eingecheckt wird, welche Möglichkeit gibt es, Dateien durch ein
updatefhem nicht(!) überschreiben zu lassen??

Viele Grüße,

Harry

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 04.09.2011 18:45, schrieb hmayr:
> umständlich war, immer die fhem.save zu editieren und ich außerdem der
> Meinung bin, dass der Basis-Wert in eine Konfigurations-Datei rein
> sollte, habe ich die 15_CUL_EM etwas umgebaut, so dass die define-

der Basis-Wert ist keine Eigenschaft des Geräts sondern ein Teil der
Meßwerte (readings). Ich finde daher, daß er nicht ins define gehört.
Den Grund lieferst Du ja selbst hier:

> - Der basis_cnt kann nicht immer aus der CFG genommen werden, da
> dieser Wert bei einem "counter wraparound" erhöht werden muss. Eine
> Alternative wäre da, die fhem.cfg zu ändern, wenn ein Zählerüberlauf
> stattfindet.

Meiner Meinung nach solltest Du ein set ... total implementieren, das
basis und cnt setzt. Ein Beispiel findest Du im Modul 81_M232Counter.pm,
das ich bisher für die gleiche Aufgabe genutzt habe (mit dem gleichen
Problem, nur einer anderen Ursache).

Viele Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Liste,

an dem Modul habe ich auch ziemlich viel umgebaut - vor allem, weil
die Benennungen etwas kryptisch sind, und wegen des oben beschriebenen
Problems.

Werde ich auch noch soweit treiben, dass das für alle Anderen
akzeptabel und nachvollziehbar ist - derzeit bin ich aber knapp in der
Zeit.

Dennoch würde mich interessieren, wie man das Problem mit dem EM 1000
in den Griff bekommen kann - das habe ich nämlich auch. Ein
Stromzähler für den Energieverbrauch, und ein Einspeisezähler für
meine Fotovoltaikanlage.

Da ich den Wechselrichter der PV-Anlage auch direkt abfrage, habe ich
immer eine gute Kontrolle über die Glaubwürdigkeit der EM 1000-
Messungen - und die ist barbarisch schlecht. Wenn ich nämlich die
Empfindlichkeit hoch genug setze, um den "blassen" Strich zu lesen -
dann löst die Lichtschranke auch bei jedem kleinsten Schmutzfleck auf
dem Rad aus. Aber - und das ist das Problem ! - nur bei geringen
Umdrehungszahlen. Wenn die Solaranlage richtig brummt, werden diese
Unregelmäßigkeiten überlesen.

Dieser &/(=%/=-EM 1000 liest also bei geringer Leistung 600
Umdrehungen pro kWh, und bei hoher Leistung 150 U/kWh.

Wahrscheinlich werde ich die Lichtschranke austauschen müssen.

Gruß

Peter A. Henning

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 5 Sep., 18:27, pahenning wrote:
>
> Dieser &/(=%/=-EM 1000 liest also bei geringer Leistung 600
> Umdrehungen pro kWh, und bei hoher Leistung 150 U/kWh.
>

Hallo Peter,

sprichst du hier von der Durchschnittsleistung oder von der
Spitzenleistung? Bei der Spitzenleistung war nämlich bis zum 6.8.2011
ein Fehler in der Berechnung drin (siehe hier:
http://groups.google.com/group/fametest/browse_thread/thread/16ab6fd7722caba1/df6fefec7eeb9ada?q=#df6fefec7eeb9ada).
Wenn du einiges in dem 15_CUL_EM-Modul umgebaut hast, gabs bei dir ja
vielleicht schon länger kein Update und du hast diese Änderung nicht
drin.
Trotzdem gibt es in der Spitzenleistung immer noch Peaks, die ich aber
sowohl bei niedriger, als auch bei hoher Durchschnittsleistung sehe.
Diese "Verzähler" schlagen aber auf die Durchschnittsleistung nicht so
durch, sorgen halt nur dafür das der kumulierte Zählerstand immer dem
tatsächlichen Zählerstand vorrauseilt.
Ich will mal versuchen, ob man das Problem nicht mit einem RC-Glied an
der richtigen Stelle lösen kann. Sobald ich Erfolg habe melde ich mich
wieder.

Viele Grüße,

Harry

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com