aggmode=AVG does not handle non-aequidistant tuples (breaks s0 power channel) about vzlogger HOT 16 CLOSED

seems to support that conclusion, and that is with just aggtime=1

from vzlogger.

Btw, middleware already does correct AVG calculation for non-aequidistant tuples.

from vzlogger.

It might be worth thinking about changing the S0 code to not add a reading after each impulse but summing up readings on a certain timeframe already there. Was this discussed already?

Am 29.12.2014 um 09:42 schrieb andig [email protected]:

Btw, middleware already does correct AVG calculation for non-aequidistant tuples.

—
Reply to this email directly or view it on GitHub #86 (comment).

from vzlogger.

@mbehr1:

• the issue theoretically affects all meter types
• why duplicate functionality that already exists?

from vzlogger.

The only difference I see with the S0 meter is that the readings rate/min is actually directly linear to the value.
For all other meters it might be constant time or some other logic but not linear to the value.
IMHO would make it more consistent.

Am 29.12.2014 um 14:03 schrieb r00t- [email protected]:

@mbehr1 https://github.com/mbehr1:

the issue theoretically affects all meter types
why duplicate functionality that already exists?
—
Reply to this email directly or view it on GitHub #86 (comment).

from vzlogger.

imho it's just pure coincedence that most other meter types send readings at a constant rate.

we could still get changes in the rate, i.e. if the user reconfigures the meter or changes a pull-sequence sending rate.

iirc there was a "smart" meter that would vary the rate of it's readings by power (maybe it uses s0 internally?), i will have to dig up the mailing list post or wiki page.

also, at very least we should then warn the user if they enable aggregation on an s0 meter power channel.

from vzlogger.

@mbehr1:

IMHO would make it more consistent.

what would make what more consistent?
you are still suggesting to duplicate aggregafion functionality in the meter code?

from vzlogger.

yes. Would be more consistent to the behavior of the other meters.

But actually I was more worried about the system load induced by some S0 signals that turn at high rate. I even fear that at high rates you might miss some pulses.
So with a new design as discussed (S0_Interface…) I’d even suggest to create a small thread for the S0_RPIO_GPIO interface class that does nothing else than count the signals. Then the S0 logic part could just query a counter from the S0_Interface and do this at whatever rate wanted. By this way it would not really be a code duplication but still have the same benefit of a more constant rate signals.
(On the other hand with e.g. 5000 impulses/kWh and assuming around 60A max. you get around 20 impl./s (if my rough calc. isn’t wrong). 20 readings per second would be quite a high load (but I was assuming a lot more before doing the calc. ;-)

Am 29.12.2014 um 15:10 schrieb r00t- [email protected]:

@mbehr1 https://github.com/mbehr1:

IMHO would make it more consistent.

what would make what more consistent?
you are still suggesting to duplicate aggregafion functionality in the meter code?

—
Reply to this email directly or view it on GitHub #86 (comment).

from vzlogger.

you do realize that vzlogger is already threaded?
the only issue might be the mutex in the buffer (sitting between reading thread and logging thread),
but i don't think any of our operations are heavy enough to lock the buffer for a significant amount of time.

the existing aggregation is imho a perfectly fine general solution to the case of a meter generating too many readings to log them all...

from vzlogger.

also, when logging s0 pulses, we should ideally log them with exact timestamps as they come in,
that's still the preferred way, and gives us the best precision.
(exact time of pulse with milisecond timestamp.)

i wouldn't compromise that by forcing the pulse reporting to fixed intervals.
(no other meter has fixed interfals, besides smart meters where a pull-sequence is sent at a fixed interval.)

from vzlogger.

yes, I’m aware of the multiple threads.
You just need to make sure that with those s0 meters never mtr->interval is >0.
The other operation in the reading_thread seem to be quite fast/non-blocking.
Anyhow as I’ve written I was more concerned about high frequency impulses. 20HZ seems to be feasible with current design.

Am 29.12.2014 um 20:06 schrieb r00t- [email protected]:

you do realize that vzlogger is already threaded?
the only issue might be the mutex in the buffer (sitting between reading thread and logging thread),
but i don't think any of our operations are heavy enough to lock the buffer for a significant amount of time.

the existing aggregation is imho a perfectly fine general solution to the case of a meter generating too many readings to log them all...

—
Reply to this email directly or view it on GitHub #86 (comment).

Gruß

Matthias Behr

from vzlogger.

I'll fix it.

from vzlogger.

gogogo!

from vzlogger.

see #140.

from vzlogger.

@r00t- : any feedback? fitting for your purpose?

from vzlogger.

can be closed?

from vzlogger.