Zweirichtungszähler EHZ-HW8 gibt Leistung immer Positiv an

[ednax]

Hallo,

ich lese mit vzlogger die beiden Zählwerke 1.8.0 und 2.8.0 problemlos von meinem Zähler (EHZ-HW8) aus.
Leider wird die aktuelle Wirkleistung (15.7.0) immer positiv angegeben.
Ich hätte erwartet, dass der Wert beim Einspeisen negativ ist, und nur beim Bezug vom EVU positiv.
Leider funktioniert so openWB nicht (Tagsüber wird ein Verbrauch angezeigt, obwohl die PV-Anlage einspeist).

Gibt es eine Möglichkeit, doch noch den korrekten Wert zu erhalten?

Wäre es vielleicht möglich, eine Modifikation zu erstellen, welche das Vorzeichen der Wirkleistung anhand der Veränderung der Zählwerke ermittelt?
Also wenn 1.8.0 größer wird, dann ist die Wirkleistung positiv, wenn jedoch 2.8.0 größer wird, dann müsste die Wirkleistung negativ sein.

Liebe Grüße
Ednax

[andig]

Ich kann nur vermuten, dass 15.7.0 einfach die falsche Obis für Deinen Zweck ist?

[ednax]

Leider werden nur 1.8.0, 2.8.0 und 15.7.0 gesendet - ich muss also irgendwie mit diesen Werten auskommen.

[andig]

Es scheint als könnten wir das im Moment nicht ändern- alle Werte werden so weiter gegeben wie vom Zähler ausgespuckt. Wenn Du die negativ haben möchtest bliebe daher im Moment nur node-red oder eine ähnliche externe Lösung.

[ednax]

hmm, ok. Danke für die schnelle Antwort.
Leider habe ich mir das schon gedacht - Vzlogger kann ja nix für die Werte...

Ich werde versuchen die Ausgabe von vzlogger durch ein Script zu manipulieren.
Meine Idee ist es, mit buffer=-2 die letzten zwei Werte zu übergeben.
Ein Script müsste die Ausgabe einlesen und wenn sich das Zählwerk 2.8.0 erhöht hat müsste die Leistung mit -1 multipliziert werden.
Ich versuche mal mein Glück (bin nicht so oft in Linux unterwegs...)

[frankrichter]

Wie viele Dezimalstellen liefert denn dein Zähler bei den Zählerständen? ednax <[email protected]> schrieb am Di., 25. Aug. 2020, 13:52:

…

hmm, ok. Danke für die schnelle Antwort. Leider habe ich mir das schon gedacht - Vzlogger kann ja nix für die Werte... Ich werde versuchen die Ausgabe von vzlogger durch ein Script zu manipulieren. Meine Idee ist es, mit buffer=-2 die letzten zwei Werte zu übergeben. Ein Script müsste die Ausgabe einlesen und wenn sich das Zählwerk 2.8.0 erhöht hat müsste die Leistung mit -1 multipliziert werden. Ich versuche mal mein Glück (bin nicht so oft in Linux unterwegs...) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE5P6GYROD6SGVPQBHEBSLSCOQWTANCNFSM4QJ5DIJA> .

[ednax]

laut einem Handbuch welches ich im Internet gefunden habe ist die Datensatzauflösung beim Arbeitszählwerk 0,1Wh und bei der Momentanleistung 0,1W.
Meistens wird mir vom vzlogger auch ein Zählerstand mit einer Dezimalstelle gemeldet (z.B. 23083870.1) - aber sehr oft auch eine Zahl mit 9 Dezimalstellen (z.B. 23083870.200000003).
Keine Ahnung wieso das der Fall ist...

[frankrichter]

Hi, mit 0,1Wh Auflösung wirst du bei kleinen Leistungen nahe 0W auch den Fall haben, dass beide Zählwerke bei aufeinander folgenden Datensätzen unverändert sind. Du wirst also mehr als nur 2 Werte vergleichen müssen. Wenn du nicht viel Linux-Erfahrung hast, schau dir mal Node-RED an, damit lassen sich solche Schnittstellen-Adapter oft ganz gut bauen. Neben der Vorzeichen-Berechnung brauchst du ja auch noch eine Lösung, um den korrigierten Wert wieder an OpenWB zu verfüttern. Die vielen Dezimalstellen kommen durch die begrenzte Genauigkeit des Float-Datentyps zu Stande. Grüße Frank ednax <[email protected]> schrieb am Mi., 26. Aug. 2020, 07:39:

…

laut einem Handbuch welches ich im Internet gefunden habe ist die Datensatzauflösung beim Arbeitszählwerk 0,1Wh und bei der Momentanleistung 0,1W. Meistens wird mir vom vzlogger auch ein Zählerstand mit einer Dezimalstelle gemeldet (z.B. 23083870.1) - aber sehr oft auch eine Zahl mit 9 Dezimalstellen (z.B. 23083870.200000003). Keine Ahnung wieso das der Fall ist... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE5P6FCRRAO53UWRRT67YLSCSNZDANCNFSM4QJ5DIJA> .

[ednax]

Hi,

also ich habe mittlerweile ein Powershell-Script geschrieben, welches auf dem Raspberry läuft (bitte nicht steinigen! 😳) und aus der Ausgabe vom vzlogger die entsprechenden Werte ausliest.
Diese werden dann in eine txt-Datei geschrieben und von openWB mit dem Strombezugsmessmodul (Modus "HTTP") und mit dem PV-Modul "(Modus "WR mit URL abfragen") ausgelesen.
Bisher scheint es gut zu funktionieren.
Aktuell läuft es mit den letzten zwei Werten trotz der Auflösung von 0,1Wh scheinbar gut.
Falls beide Zählwerke sich nicht verändern, gehe ich einfach von Bezug aus - in dem Fall ist die Wirkleistung vermutlich sowieso so gering, dass der "Fehler" wohl nicht auffällt.

P.S. Leider benötigt Powershell auf dem Raspberry einige Sekunden alleine zum Starten - die Ausführung des Scripts geht dann scheinbar schnell.
Da es für meine Zwecke ausreichend ist (und für mich sehr einfach umsetzbar war), lasse ich es jetzt wohl einfach so.

Grüße
Ednax

[r00t-]

is this possibly the same issue as in volkszaehler/libsml#101 ?

[r00t-]

@ednax:
in volkszaehler/libsml#101 another user reports that sml meters actually communicate the energy transfer direction in a separate flag in the sml message, which is currently ignored by libsml (and thus vzlogger).
can you check if your meter sends that flag, and/or provide dump files for both cases?

[ednax]

ok, I'm trying - I think I created a valid dump for consuming (obtaining electricity from the Electricity supplier).
I used the command: dd if=/dev/ttyUSB2 of=yoursmldump.bin bs=1 count=4096 iflag=fullblock
Tomorrow (if the sun is shining again) I will try to fetch again while delivering energy to the Electricity supplier.
How can I see the flag without parsing the SML-dump myself? Last time I did this is 7 years ago - and sadly the knowledge is gone...

[r00t-]

How can I see the flag without parsing the SML-dump myself?

i don't know (yet), which is why i asked for the dumps.
volkszaehler/libsml#101 has links to the relevant documentation,
and i think that with a sample file i can implement support for this.

this might be worth a try too:
https://gitlab.com/wireshark/wireshark/-/wikis/SML
https://ask.wireshark.org/question/13035/sml-dissector-doesnt-work/?comment=13073
(a wireshark protocol dissector is more of a debugging tool than for production use,
but running wireshark to process your meter might actually be more efficient than your powershell script ;) )

[r00t-]

@SirkoVZ provided example data in volkszaehler/libsml#101 , and it seems the flag can be parsed from it just fine.
would like to validate this with yours ( @ednax ).
or you can try yourself,
i posted the code i used in volkszaehler/libsml#101 (comment)

[r00t-]

@ednax:
#476 has some experimental code to extract the direction and apply it to the power reading.

git clone -b direction_from_status https://github.com/r00t-/vzlogger.git

usage example in #476 (comment)

[ednax]

ok, I hope it is ok to post the dump here:

the first is while importing about 2kW of energy:
deleted

the second dump is while exporting about 8kW of energy (sun is shining onto the photovoltaik):
deleted

[r00t-]

@ednax: is it ok if i add your dumps to https://github.com/devZer0/libsml-testing ?

[r00t-]

$ cat etc/vzlogger.conf.direction_from_status
{
    "verbosity": 15, "retry": 0,
    "meters": [{
            "enabled": true, "allowskip": false,
            "protocol": "sml",
            "device": "/tmp/EMH-eHZ-HW8E2A5L0EQ2P_2kw_imp.bin",
            //"device": "/tmp/EMH-eHZ-HW8E2A5L0EQ2P_8kw_exp.bin",
            "direction_from_status": true,
    }]
}
[~/vzlogger]$ ./src/vzlogger -c etc/vzlogger.conf.direction_from_stat
us -f |head -n 32
[...]
[Mar 31 15:32:56][mtr0] Got 6 new readings from meter:
[Mar 31 15:32:56][mtr0] Reading: id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*25
5 value=25531006.50 ts=1617197576209
[Mar 31 15:32:56][mtr0] Reading: id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*25
5 value=110615354.90 ts=1617197576209
[Mar 31 15:32:56][mtr0] Reading: id=1-0:1.8.1*255/ObisIdentifier:1-0:1.8.1*25
5 value=25531006.50 ts=1617197576209
[Mar 31 15:32:56][mtr0] Reading: id=1-0:2.8.1*255/ObisIdentifier:1-0:2.8.1*25
5 value=110615354.90 ts=1617197576209
[Mar 31 15:32:56][mtr0] Reading: id=1-0:1.8.2*255/ObisIdentifier:1-0:1.8.2*25
5 value=0.00 ts=1617197576209
[Mar 31 15:32:56][mtr0] Reading: id=1-0:15.7.0*255/ObisIdentifier:1-0:15.7.0*
255 value=2896.60 ts=1617197576209

[~/vzlogger]$ cat etc/vzlogger.conf.direction_from_status
{
    "verbosity": 15, "retry": 0,
    "meters": [{
            "enabled": true, "allowskip": false,
            "protocol": "sml",
            //"device": "/tmp/EMH-eHZ-HW8E2A5L0EQ2P_2kw_imp.bin",
            "device": "/tmp/EMH-eHZ-HW8E2A5L0EQ2P_8kw_exp.bin",
            "direction_from_status": true,
    }]
}
[~/vzlogger]$ ./src/vzlogger -c etc/vzlogger.conf.direction_from_stat
us -f |head -n 32
[Mar 31 15:36:12][mtr0] Got 6 new readings from meter:
[Mar 31 15:36:12][mtr0] Reading: id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*25
5 value=25530941.00 ts=1617197772291
[Mar 31 15:36:12][mtr0] Reading: id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*25
5 value=110615070.20 ts=1617197772291
[Mar 31 15:36:12][mtr0] Reading: id=1-0:1.8.1*255/ObisIdentifier:1-0:1.8.1*25
5 value=25530941.00 ts=1617197772291
[Mar 31 15:36:12][mtr0] Reading: id=1-0:2.8.1*255/ObisIdentifier:1-0:2.8.1*25
5 value=110615070.30 ts=1617197772291
[Mar 31 15:36:12][mtr0] Reading: id=1-0:1.8.2*255/ObisIdentifier:1-0:1.8.2*25
5 value=0.00 ts=1617197772291
[Mar 31 15:36:12][mtr0] Reading: id=1-0:15.7.0*255/ObisIdentifier:1-0:15.7.0*
255 value=-8226.90 ts=1617197772291

there you go

[ednax]

is it ok if i add your dumps to https://github.com/devZer0/libsml-testing ?

Does these files contain any security relevant data?
If they don't contain sensitive data (or if you scramble these), you are free to add the files to the libsml-testing.
I deleted the files here in the comment-section (as they are not needed here anymore).

EMH-eHZ-HW8E2A5L0EQ2P_2kw_imp.bin
Reading: id=1-0:15.7.0255/ObisIdentifier:1-0:15.7.0255 value=2896.60 ts=1617197576209

EMH-eHZ-HW8E2A5L0EQ2P_8kw_exp.bin
Reading: id=1-0:15.7.0255/ObisIdentifier:1-0:15.7.0255 value=-8226.90 ts=1617197772291

looks verry good 👍
does that mean, that vzlogger will support this in a future version?

[J-A-U]

vzlogger will support this in a future version?

Da stimme ich dafür.
Möchte aber anmerken das User sich schon daran gestört haben wenn der Graph ins Negative geht.

[r00t-]

@ednax:

does that mean, that vzlogger will support this in a future version?

you can simply use the code from my branch,
i posted the command to download it above.

i think merging it into master will take a little longer, because

• i think the code should be a little bit cleaner
• i think we should export each of the status bits as a separate loggable channel,
  as an alternative to applying the direction as the sign.

@J-A-U:
if you read my above post, you would see that even my "experimental" implementation has this as an option that defaults to off:

            "direction_from_status": true,

i wonder if this should be a channel- instead of a meter-property,
to allow for logging both variants, or choosing which channel to apply the sign to...
but we could leave that to possible future improvement aswell.

[r00t-]

is it ok if i add your dumps to https://github.com/devZer0/libsml-testing ?

Does these files contain any security relevant data?
If they don't contain sensitive data (or if you scramble these), you are free to add the files to the libsml-testing.

not security anyway,
it probably contains your meter's serial number, which might be considered private, but does no harm really.
editing the files is unattractive because that changes the checksum.
as you can see here, development of metering software is heavily dependant on having access to sample data.

[ednax]

you can simply use the code from my branch,

well, ok. I will try it on my raspberry.
I don'nt know yet, how that works and if that voids the updateability.
I'm going to try a bit and decide, if I will use that.
The powershell script had to give way for an very fast (but ugly) shell script.
If the change is not going into vzlogger, I could keep my solution with the script.

Dumps from similar meters are already in libsml-testing, but more data is always good,
so you can use my two dumps for libsml-testing.

[SirkoVZ]

@r00t- Thanks for your effort! "Delivery" values are now logged with "-" in front as wished :-)

i think we should export each of the status bits as a separate loggable channel,
as an alternative to applying the direction as the sign.

I would appreciate if it would be possibe to log the negative and positive values into two different channels.

[r00t-]

@SirkoVZ:
enjoy, good that it's of use.

as said, the code needs some improvements before i would consider it ready for merge to master.
see #476 (review)

[r00t-]

@SirkoVZ:

I would appreciate if it would be possibe to log the negative and positive values into two different channels.

i think that's the thing @J-A-U already hinted at?
"people don't like negative graphs with negative values"?

i think that's out of scope of this ticket,
if splitting consumption and delivery into separate channels is a valid feature,
it would be equally valid for meters that return signed power readings without needing to parse the "direction" bit.
suggest to create a new ticket.

[J-A-U]

i think that's the thing @J-A-U already hinted at?

No, my concern was already addressed with the option in config.

if splitting consumption and delivery into separate channels is a valid feature,

This may be an option with different states: only positive values, only negatives and both.
But it would be necessary to config this in [channel] instead of [meter].

If it is possible to move the switch, the hardcode #476 (comment) could be removed.

[etas-github-sb]

Hi, I am using this branch now with my DZG DVS74 meter. Negative values now work. I just wonder why this is not good to merge to master?

[r00t-]

@etas-github-sb: i really gave lots of details on my thoughts on the implementation, both here at #431 (comment) and in #476 .
i think the path to a workable solution is to finish #585 first, which has it's own complexity.