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

Anomalous data detection #410

Open
catbarph opened this issue Oct 5, 2017 · 6 comments
Open

Anomalous data detection #410

catbarph opened this issue Oct 5, 2017 · 6 comments
Assignees
Labels

Comments

@catbarph
Copy link
Member

catbarph commented Oct 5, 2017

Basic outlier detection is needed to identify & filter out really bad data.
For instance: temperature sensors will never actually read over a few hundred degrees (but they have been spiking to 6K repeatedly!), so it should be easy to detect/throw out values outside of that range.
Note: i2c collisions may have been the culprit...

@JakeHartnell
Copy link
Member

Agreed, we should have some utilities for detecting when sensors are malfunctioning. When you have a temperature that's reporting 6,000 C something is obviously wrong.

@catbarph catbarph changed the title Error correction Anomalous data detection Oct 7, 2017
@catbarph
Copy link
Member Author

Where did you get to re: low-pass filtering?

@JakeHartnell
Copy link
Member

@JakeHartnell JakeHartnell self-assigned this Dec 18, 2017
@catbarph
Copy link
Member Author

Still seems to mainly be an issue for the Pt100 water temperature sensor, connected over SPI.
screen shot 2018-05-26 at 10 29 41 am

@JakeHartnell
Copy link
Member

I was thinking about this on the plane, this issue is mislabel as we can easily detect anomalies now. What's wanted is the ability to filter out anomalies.

This library and Thing.js are in need of some re-architecture if we are to resolve issues like this. As it stands, we can emit alerts just fine, but if we are to filter data we have a problem in that Grow.js itself listens for these events to be emitted (and after they're emitted, it's already to late for filtering as those values will hit the server and F@#$ up timeseries charts).

When Thing.js (an extension of the event emitter class) emits an event, we extend the emit function so that an optional hook function is called and ether returns a truthy value, or returns nothing, in which case we emit the event. If a hook function returns false, we DO NOT emit the event. I'm not sure how I feel about an approach like this.

There might be better ways of achieving similar functionality??? Perhaps piping events in an interesting way that allows them to potentially be intercepted?

Additionally, rather than the above approaches, we could make a helper function that checks whether a value is in bounds. This would be used by implementers when creating a driver as the following pseudo code illustrates:

let grow = require('Grow.js');
grow.registerTargets({
  temperature:{
    min: 20,
    max: 80,
    bounds: [0,100]
  }
})

let value = Math.random() * 200;

if (grow.inBounds('temperature', value)) {
  grow.emit('temperature', value);
}

This introduces extra complexity though, but in a way that isn't "magic" (ie. the developer explicitly chooses to filter values).

@JakeHartnell
Copy link
Member

To address this issue there is a new inBounds() method in Grow.js v0.4.7, to be used as above. We may create a list of default sensible bounds for common sensor types so that they don't have to be defined in a Growfile.

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

No branches or pull requests

2 participants