[vz-users] vzlogger: Wie alte Zählerstände unterdrücken

[Thorben Thuermer]

Elias saile at gmx.de, Tue Dec 23 03:36:50 CET 2014
> Das Problem ist aber, dass der DC3
> Standarddatensatz immer die Zählerstände der letzten 15
> Registrierperioden (oder Tage?) enthält und alle vom vzlogger zur
> middleware übergeben werden:
> 
> Dies ist ein Ausschnitt aus dem vzlogger-Log im Loglevel 15:
> [Dec 23 00:26:03][mtr0] Reading: id=255-255:1.8.0*255/ObisItentifier:255-255:1.8.0*255 value=9390.92 ts=1419290588.362
> [Dec 23 00:26:03][mtr0] Reading: id=255-255:1.8.0*14/ObisItentifier:255-255:1.8.0*14 value=9345.12> 
>
> Unter der ID 255-255:1.8.0*255 verbirgt sich der Gesamtzähler-Stand,
> alle anderen sind ältere Zählerstände.
[...]
> Bei der Konfiguration des vzloggers hab ich unter identifier explizit
> *255 mit angegeben, aber leider werden trotzdem alle alten
> Zählerstände übergeben. { "identifier" : "255-255:1.8.0*255"
>
> Irgendeine Idee wie ich erreiche, dass nur die OBIS-Kennzaheln mit
> *255 hinten dran berücksichtigt werden können?

das ist ein "feature" in vzlogger, das mir schon fruehr aufgefallen war.
die 255 wird als wildcard verwendet, und matcht immer (und das in beide richtungen!).
d.h. die 255 in der identifier-angabe matcht auf jedes reading,
(und ein reading mit einer 255 matcht auch wenn im identifier was anderes steht!).

der code dafuer steht in vzlogger/src/Obis.cpp:
bool Obis::operator==(const Obis &rhs) const {
        for (int i = 0; i < 6; i++) {
                if (_obisId._raw[i] == rhs._obisId._raw[i] || _obisId._raw[i] == 0xff || rhs._obisId._raw[i] == 0xff ) {
                        continue; /* skip on wildcard or equal */

versuche mal, die hinteren beiden vergleiche zu entfernen, und vzlogger neu zu kompilieren,
dann sollte es wie erwartet funktionieren.

ich weiss leider nicht, warum diese logik dort eingebaut wurde,
und habe auch keine erfahrung mit zaehlern, die obis-identifier verwenden,
deswegen kann ich auch nicht sagen, was der korrekte fix ist.

(zuvor gab es einmal das problem, das wegen eines fehlers im protokoll-parser
 readings mir nur 255-255:255... im identifier geliefert wurden, die dann in
 allen channels landeten.)

> Lieben Gruß,
> Elias

- Thorben