Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "cumulative" and "pulse" reading types #4

Open
AMEE opened this issue Sep 12, 2011 · 4 comments
Open

Add "cumulative" and "pulse" reading types #4

AMEE opened this issue Sep 12, 2011 · 4 comments
Milestone

Comments

@AMEE
Copy link
Owner

AMEE commented Sep 12, 2011

Feedback is that reading types of "cumulative" (where the measurement is a counter should always go up, but may sometimes re-set back to zero on device restart or counter overflow) and of "pulse" (where the measurement is an indication of the number of times an event has been recorded since the last reading) would complement the existing type of "instant" (where the measurement is simply the value recorded at that instant in time).

@revenco-hk
Copy link
Collaborator

I think your argument here deprecates your idea of removing "durational" measurements because this is essentially what you have just outlined above. Anyway raw pulses are no use in AMEE as they need scaling and units to be used.

@AMEE
Copy link
Owner Author

AMEE commented Sep 13, 2011

Well, "duration" measurements required a start and end date. The "instant", "cumulative" and "pulse" types do/will only require a single timestamp, being the date/time the measurement was generated.

Units should already be supported by AMON, as the reading definition allows the unit to be defined.

What do you mean by scaling, though, please?

@revenco-hk
Copy link
Collaborator

The notion of "duration" or "durational" measurements was actually from the (now defunct) Google PowerMeter initiative. Some devices like Iskra's loggers have a mode where they send the number of pulses within a time period e.g. 14 pulses between 16:00:00 to 16:29:59. It is not realistic to convert durational measurements to instant measurements since any period of pulses lost will throw the whole thing out of kilter. The reason some loggers run in this mode is that it is extremely bandwidth efficient - for example the daily 48 half hour measurements easily fit in a single SMS message.

As for scaling, a single pulse will need to be converted to a value and unit. So typically if a logger is attached to a gas meter (a common scenario) where a pulse equals 10ft3 then then 14 pulses would equal 140ft3 or the equivalent in m3.

@andrewatamee
Copy link
Contributor

Hmmm, interesting!

Perhaps we need to re-think the idea of deprecating duration style meters, in that case. It's probably worth taking this discussion over to https://groups.google.com/forum/#!forum/amon_data_format ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants