Notion of Flakiness in Sensor Readings

[Matt Spinler]

On 10/12/2018 4:23 PM, Patrick Venture wrote:
> 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.

If the hwmon driver for your device provides a _fault attribute, and 
that gets set, the code is already
set up to create an OperationalStatus interface on that sensor instance 
and set the Functional
property to false.

>> 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
>>>