Define a specific order, by which plugins receive deltas?
I am using the following plugin to detect outliers in sensor data (depth, STW, AWS): https://github.com/chris0348/signalk-detect-outliers
This works fine for depth, STW and AWS. But TWS, that is provided by the derived-data plugin (based on among others AWS), still shows an outlier when the apparent wind speed AWS had an outlier. So apparently derived-data gets the deltas before they are handled via the detect-outlier plugin.
Is there an option to assure, that the deltas that derived-data gets are handled before by the detect-outlier-plugin?
27 Replies
The only way currently would to make the detect-outlier-plugin use registerDeltaInputHandler
wait. it already does
actually looks like there's a bug in that plugin
unless I am crazy, it's actnually not filtering anything out except position
it's definitely not implemented correctly
Is that your plugin?
the plugin is setting that path to null when is wants to filter
but it should just not call next() when it wants to filter
"send = 0"
Yes, its my plugin
The github version is not up to date...
let me check
I'm not 100% sure this is the issue
but setting path to null is definitely not the right way to do this
the delta input handlers definitely get called before derived data
I checked the github version against my locally running version: The only differences are some debug messages etc.
and the plugin works fine
Here two examples for depth and AWS: Corrupt values are detected and a diagnostic "outlier"-delta is send instead
but if that was true, derived-data would not get the delta
Hhmm, strange
Here a more specific example: An outlier in AWS is detected, the "outlier"-delta is sent, but the TWS is corrupt (close to zero)
And TWS comes from derived-data:
can you try fixing the plugin? I really don't know the impact of setting the path to null
or actually. just change the path to ..._outlier
instead of emitting a new delta
I've set the value to "null" to explicitly show that no clean data is available, otherwise iirc, the value for path would still show the last clean value, wich might be misleading of eg. for depth over longer time no clean data is received.
I guess this issue would also appear if I change the path to the the corrupt data to the _outlier path. Then the "real" path would remain unchanged and show the last clean value. Misleading in case I do not constantyl check the _outlier path.
shoot, sorry, I misread the code
so I wonder if derived data is not handling null values correctly?
for TWS
Oh, indeed, that might be the case!
The corrupt TWS values are identically 0
so probably null is interpreted as 0...
yep. I bet that's it