Comments (16)
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.
- 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.
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.
Related Issues (20)
- protocol "exec" should drop elevated privileges instead of suggesting to recompile to allow popen as root HOT 3
- MQTT stop working HOT 10
- Libraries are linked dynamic and static HOT 11
- s0 impuls counter inverted signal possible to configure? HOT 1
- read from file, instead of device HOT 4
- CMake Error: Unknown argument -ENABLE_MQTT=on HOT 6
- vzlogger - Illegal instruction HOT 29
- Get live data from HTTP server with active aggregation HOT 3
- vzlogger.service has hardcoded install location, should be templated and generated according to build configuration
- measurements discarded due to invalid timestamp evaluation in version 0.8.3 HOT 7
- Dockerfile throws cmake error - fix proposal HOT 1
- install.sh gives "Unknown argument -ENABLE_MQTT=on" error HOT 7
- remove install.sh (or maintain it better) HOT 5
- no logging HOT 6
- VZLOGGER V0.8.3 without "oms" protocol HOT 13
- Version information is inconsistent HOT 2
- Future of OMS support HOT 9
- MQTT not publishing any messages HOT 5
- Integration Wasserzähler / Integration Water Metering HOT 3
- Gateway Timeout HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vzlogger.