-
Notifications
You must be signed in to change notification settings - Fork 65
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
support for deadband in v2 #34
Comments
Hi Pascal, I removed that functionality because I thought it was not usefull, as influx has such good compression that storage shouldn't really be an issue. Could you perhaps elaborate on your use-case? |
If you have for instance a temperature sensor with an accuracy of +- 1% or +-0.5°C and you have a process where in 99% of the time the temperature is constant. You only want to log the changes caused by the process, not the small fluctuations that are caused by a sensor inaccuracy. |
Hi guys, first of all I would like to thank @coussej for puttin in the effort and creating this logger. On this point I must agree with @Scelle, it would be interesting to have an option to save only the relevant data by that I mean high value changes not caused by sensor inaccuracy. Certainly this days storage costs almost nothing but it would be ideal to use less insead of using more. |
I suggest that adding deadband isn't the best solution. Your sensors might have an absolute accuracy of +/-1% but the relative accuracy is useful for sub-sampling. That 'noise' in between your useful measurement periods can be down-sampled to give much better accuracy of the useful data. You're better off pouring the raw data into a short term bucket and running a continuous query in Flux to down-sample the readings into a useful set. |
Hi,
Are there plans for adding deadband facilities, similar to the first version of the logger?
kind regards
Pascal
The text was updated successfully, but these errors were encountered: