post-processing readings inside vzlogger?

[r00t-]

it appears that it would sometimes be desirable to have some ability to manipulate readings inside vzlogger before sending them off to an API.

for example: #431 (comment)
it's desired to log negative (delivery) and positive (consumption) power reading into separate channels.
in the #431 case, we could (should!) also provide the sml "energy direction" status bit as a separate channel,
and could then use generic logic to apply it as the sign of the power channel, or log power to a different output channel depending on it.
there might also be S0 meters that output a direction signal in addition to the impulses, that could also be processed that way.
building generic functionality instead of hardcoding it in specific places (same as #445).
(if you have further examples, please comment)

volkszaehler.org has gained "virtual channels" in volkszaehler/volkszaehler.org#729 ,
which is a similar feature.
but we might want to:

• manipulate the data before logging it
• use this with other APIs than volkszaehler.org

such a feature could either be added to the vzlogger core (like aggregation),

or, which seems somehow sensible to me at the moment,
as a module that exposes both an API and a meter, "loopback"-style,
so that readings from any meters can be sent to it with the existing config syntax
(which would also provide a way to pass processing options),
and it could process them and output the results as readings for logging to another "real" API.
(no idea if i'll get to implement this or any of it, as i have no use for it personally.)

[J-A-U]

volkszaehler.org has gained "virtual channells" in volkszaehler/volkszaehler.org#729 ,

I'm already trying to wrap my brain around how this could be applied to e.g. separated channels. Merging them together how ever the user wants them to be. Or an flag [-1] to mathematically apply to the data. Looking for a solution to keep vzlogger-config easy.

It will be complicated to get the messages across. Maybe it heavily collides with user expectations.

And my thoughts only apply to VZ...

[r00t-]

@J-A-U:
it's a typical tradeoff, you can't have complex features with an "easy" configuration.
this won't happen before we have strong AI than can actually understand what the user wants from any nonsensical inputs they give. (something humans can sometimes do, but typically find extremely annoying to deal with.)

[r00t-]

quoting @J-A-U from #431 (comment)

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].

we could ofcourse provide a hardcoded sub-set of transformations (and thus sub-set of the feature suggested above) as channel-properties,
like for this case you described, we would need combinations of min(), abs() and max(), like:
abs(min(value,0)) to get only the export part of the energy readings,
and max(value,0) to get only the consumption part.
(incidentially that's what aggmode=max did before #425 was fixed ;) )

at best we could pull in some expression-parser library to support arbitrary expressions of that style.

but i'd be reluctant to implement such a thing, because supporting only transformations within one channel, while it might solve SOME use-cases, is very limited, and sooner or later somebody will come along and ask for something more complex.