AdrianP - Having recently done some work to add...
Having recently done some work to address issues logged for the
derived-data plugin, it is clear that there is a lack of input validation in some calculations and varying approaches to what the response is when input values are deemed to be invalid.
To ensure consistency and a level of trust in the values produced by the plugin, what should be the recommended action for a calculation when the input values are deemed to be invalid:
1. Set the value of the derived paths to null
2. Return and not update the derived paths value?9 Replies
I would output
null. A further optimisation would be limiting the rate of outputting null if the last value is also null 🤔null seems the logical best ….. and yes let the null go “stale”?
and given some recent questions in threads … can i also suggest that somewhere in the plugin config …
it indicates what the “thumbs up” means
A legend has been added in V1.38.0 for just this reason.
👍 excellent
just saw it in the app store , ive updated … and the red X’s are very obvious , well done
Should this functionality be implemented more centrally i.e.
handleMessage() rather than left to plugin implementation?i don't think this should be global, as one policy may not fit all sources
It felt like we had the making of a "principle"...
"If the current value of a path is
null, a delta should not be emitted for that path until a non-null value is assigned"
or something to that effect.a null value with a fresh timestamp tells me that the sensor producing the data is working and I am getting data, it just happens to be invalid now
classic example is a depth sounder - a depth gauge should actually indicate 2 values
- what is the depth or if we don't have one it is null
- is the shown value (number or null) stale or fresh?
@Teppo Kurki Initial attempt at solution https://github.com/SignalK/signalk-derived-data/pull/167