Notion of Flakiness in Sensor Readings

[Patrick Venture]

On Fri, Oct 12, 2018 at 2:09 PM James Feist <james.feist at linux.intel.com> wrote:
>
> On 10/12/2018 01:53 PM, Patrick Venture wrote:
> > Currently, there are a few approaches in phosphor-hwmon on how to
> > handle sensors being present sometimes, or flaky on reads.  We've
> > talked in the past about how to handle a read failure that should be
> > ignored.  A real failure that is flaky or temporary.
> >
> > I was thinking of just adding a property to the Sensor.Value interface
> > to report information.  Basically, someone reading the value needs to
> > know if it's valid.  The idea of a range check for validity doesn't
> > work as cleanly for this specific purpose, in my opinion.  The min/max
> > can be used cleanly to determine the linearization though!
> >
> > I was thinking perhaps a boolean, that you can check to see if the
> > value should be used or trusted.  Then, I thought, perhaps, a enum
> > with a series of states, starting with the states of "Valid',
> > "Invalid."  Not being able to think of a third state, I fell back onto
> > a boolean.
>
> For Valid / Invalid we've produced nan on D-Bus to know that the sensor
> is in an invalid state (like power off for tach values). Although I'm
> not sure how this would be produced using the int64 interface, for the
> double std::nan will go over d-bus correctly.

So if i just wait until we're using double, the issue basically
resolves itself? :D :D

>
> >
> > Thoughts?
> >
> > Patrick
> >