add handling for absolute power (obis 15.7.0) of two-way meter

[gusoer]

OBIS 15.7.0 added to Obis.cpp with new alias "power-abs".
This is the absolute value of current power of a two-way meter (eg EMH eHZ-H). The value is without a sign, that means it is not possible to see if the power was consumed from grid or sent to the grid which might be an issue especially if you like to use it eg in EVCC.
For this reason, I added a special handling for obis 15.7.0 in MeterSML.hpp/MeterSML.cpp:
Matthias Schütze (https://demo.volkszaehler.org/pipermail/volkszaehler-dev/2017-April/005591.html) and Daniel Lauckner (https://demo.volkszaehler.org/pipermail/volkszaehler-dev/2017-April/005592.html) figured out, that the information about the direction of power was given by the status byte (bit 5) of the first obis energy counter (obis 1.8.0).
In this change, I evaluate the status byte of obis 1.8.0 and set the sign of the value of obis 15.7.0 corresponding to the status as positive if the power was consumed from grid and as negative if the power was sent to the grid.
I add also an additional attribute to vzlogger.conf ("obis1570abs") to activate (false) and deactivate (true, default) this feature.

[r00t-]

this seems to be largely redundant with #476 ? 😕

i created #476 four years(!) ago,
it never got any further/merged because of open questions that i can't answer myself, and nobody participated.

i will try to review/compare later, hope you can do the same,
maybe we can together find out which approach is best and finally merge a solution.

[r00t-]

from my first read,your fix is largely identical to the one in #476 ,
except for:

• you use different terminology.
  • i questioned if mine is sensible: WIP: experimental code to extract energy flow direction from status word and apply to power reading #476 (comment)
  • your "obis1570" might be closer to the standard, but appears mangled beyond recognition anyway
• you store the sign in the meter object instead of locally in the parser.
  this makes access more convenient,
  but i somewhat dislike this, as the sign is a property of the individual telegram, not a permanent property of the meter,
  we should at least ensure that it's initialized to "unknown" for every new sml telegram,
  and only used if a value was actually received. (not implemented in my mr either)

unless somebody can point out where exactly the sml specification requires/guarantees the reading containing the status flags to be sent before the power reading, i think we need #585 first, as discussed at #476 (review) .

[r00t-]

just as in #476 (comment) ,
we should avoid "magic" constants.
i think 1 << 5 is a bit less magic than 0x20 and i think it's common practice to notate bit-flags like that.
(this should probably ideally be defined in libsml - but surely not worth breaking compatibility.)

[r00t-]

we should at least ensure that it's initialized to "unknown" for every new sml telegram,
and only used if a value was actually received. (not implemented in my mr either)

unless somebody can point out where exactly the sml specification requires/guarantees the reading containing the status flags to be sent before the power reading, i think we need #585 first, as discussed at #476 (review) .

a valid solution (that i had not considered before) should be to log a warning if the option is enabled but no status byte was read yet when the power reading is processed.

[gusoer]

this seems to be largely redundant with #476 ? 😕

i created #476 four years(!) ago, it never got any further/merged because of open questions that i can't answer myself, and nobody participated.

i will try to review/compare later, hope you can do the same, maybe we can together find out which approach is best and finally merge a solution.

thanks for the review. At first glance, it looks like very similar - I was not aware about #476. I'll check it asap next days, appreciate to find a common / best solution together :-)

[gusoer]

I did some additional research. For my understanding, the status byte from obis 1.8.0 which indicates the "direction" of power (obis 15.7.0) is not part of the standard and also not requested by "Marktkommunikation". Because of this, I guess we wont find anyone who is able to/willing to guarantee that our interpretation is correct in any cases.
I guess, it depends of the type of the two-way meter. So, from my point of view, we should implement it in a specific way, not general - may be similar to my change. ;-) However, I agree and like your suggestion that we should give a warning if the option is enabled but no status byte was read when the power reading is processed.

[r00t-]

this seems kind of stuck again...
i'm not opposed to merge your version,
if you feel ilke addressing the open issues:

• consider finding a more sensible name than obis1570, see also WIP: experimental code to extract energy flow direction from status word and apply to power reading #476 (comment)
• generate a warning if the option is enabled but no status byte found
• make our ci format checker happy (can do for you if you really don't want to and allow maintainer push)

[gusoer]

The formatting issue should be fixed. I ran "check-formatting" - shame on me.

If the option is enabled and there is no status byte on obis1.8.0, a warning message will be written. Btw. I checked it on my system for a while and never saw a warning. :-)

You are right, the naming is not the best but I like to keep the name because it is a very specific behaviour, not documented in the standard or requested by "Marktkommunikation" - see my previous comment. I don't want to suggest that this is universally valid behavior.

[r00t-]

thanks for making those changes,
sorry that this got stalled so long again...
still not happy with the name, but that really should not be a reason to block this.
i am one of the maintainers, but also don't feel solely responsible for this repository, would appreciate if any of the others could voice their opinion.

[r00t-]

maybe those messages should explicitly refer to the status byte too?
"<name of feature>: sign in status byte indicates power sent to grid"
(is that terminology even correct?)

[r00t-]

this should also have i think, and probably even be a level higher than warning.
consider "<name of feature>: got power reading but direction not known (no status byte seen)".
personally i'd drop the reading then, but ymmv, i'm not a user of this.