WIP: experimental code to extract energy flow direction from status word and apply to power reading

[r00t-]

fixes #431

[r00t-]

[~/vzlogger]$ cat etc/vzlogger.conf.direction_from_status
{
    "verbosity": 15, "retry": 0,
    "meters": [{
            "enabled": true, "allowskip": false,
            "protocol": "sml",
            "device": "/home/r00t/libsml-testing/EMH-ED300L_delivery.bin",
            "direction_from_status": true,
    }]
}
[~/vzlogger]$ ./src/vzlogger -c etc/vzlogger.conf.direction_from_status -f |head -n 32
[Mar 31 05:01:22][mtr0] Got 4 new readings from meter:
[Mar 31 05:01:22][mtr0] Reading: id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=17243675.60 ts=1617159682423
[Mar 31 05:01:22][mtr0] Reading: id=1-0:1.8.1*255/ObisIdentifier:1-0:1.8.1*255 value=17243675.60 ts=1617159682423
[Mar 31 05:01:22][mtr0] Reading: id=1-0:1.8.2*255/ObisIdentifier:1-0:1.8.2*255 value=0.00 ts=1617159682423
[Mar 31 05:01:22][mtr0] Reading: id=1-0:15.7.0*255/ObisIdentifier:1-0:15.7.0*255 value=-126.60 ts=1617159682423
[...]
[~/vzlogger]$ sed -i s,delivery,consumption, etc/vzlogger.conf.direction_from_status
[~/vzlogger]$ ./src/vzlogger -c etc/vzlogger.conf.direction_from_status -f |head -n 32
[...]
[Mar 31 05:01:56][mtr0] Got 4 new readings from meter:
[Mar 31 05:01:56][mtr0] Reading: id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=17243368.30 ts=1617159716495
[Mar 31 05:01:56][mtr0] Reading: id=1-0:1.8.1*255/ObisIdentifier:1-0:1.8.1*255 value=17243368.30 ts=1617159716495
[Mar 31 05:01:56][mtr0] Reading: id=1-0:1.8.2*255/ObisIdentifier:1-0:1.8.2*255 value=0.00 ts=1617159716495
[Mar 31 05:01:56][mtr0] Reading: id=1-0:15.7.0*255/ObisIdentifier:1-0:15.7.0*255 value=137.10 ts=1617159716495
[...]

[r00t-]

successfully tested with a second meter:
#431 (comment)

[r00t-]

-as hinted at in the ticket:

the problem with this code is that the "status" word is not attached to the power reading, but to the energy reading (and i'm not even sure if that's guaranteed?!).
also, it is probably not guaranteed that the reading containing the status word is sent BEFORE the power reading
(currently, if the status word was sent after the power reading, the direction would not be applied.).
is it guaranteed that there is only ONE reading with a status word?
what should the code do if there's more than one status word?

previously, the code that processes the readings did not need to keep any state between the individual readings.

passing the "pointer to bool" into _parse() was the most straightforward way to pass the now-required state information around, but it is not super elegant, we probably want a cleaner way to handle this.

we could (should?) process the status word and perfom actions based on it in the code that calls _parse() instead of inside _parse(),
but at that point applying the sign to the power reading becomes more complex,
because we are dealing with readings wrapped in Reading objects and identified by ReadingIdentifiers at that point.
also, to overcome the issue of the status word not necessarily being sent before the power reading,
we would have to first collect the readings and then iterate over them AGAIN to find and manipulate the power reading.

[r00t-]

is the name of this flag sensible?
it should maybe include "power" too, as we apply it to the power channel.
also it could include "sign"....

"derive_power_sign_from_direction_bit_in_status_field" would be correct, but is a bit excessive.

[r00t-]

this variable has the same name as the property that stores the setting,
which might be confusing.

[r00t-]

should properly check status->type before accessing status->data.
should replace the magic value "5" with a constant.

[r00t-]

is it OK to hardcode this?
will we ever want to apply the direction to any other reading?