Dealing with a sensor which doesn't have valid reading until host is powered up

Patrick Williams patrick at stwcx.xyz
Fri Sep 4 01:54:15 AEST 2020


On Thu, Sep 03, 2020 at 08:43:16AM -0700, Ed Tanous wrote:
> On Thu, Sep 3, 2020 at 8:38 AM Patrick Williams <patrick at stwcx.xyz> wrote:
> >
> > I might have missed this but what are we going to do about the
> > Sensor.Value in the case when the data isn't yet available?  Is the
> > sensor only going to exist when the data is available?  Do we need to
> > define a specific value to indicate that a Sensor.Value isn't available?
> > Now that we've moved to a `double` for Sensor.Value it seems like we
> > could use NaN.
> 
> CPUSensor code that does exactly what you describe :)
> 
> https://github.com/openbmc/dbus-sensors/blob/105a19754f003956def5934612b1de86225a4bc1/src/CPUSensor.cpp#L180
> 
> dbus-sensors has done exactly this basically since its creation.  I
> wonder how we'd get that more formalized in phosphor-dbus-interfaces.
> 

First step would be a comment here:

https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml#L23

There isn't currently a way in the YAML to define specific values as
meaningful, other than enums.  Certainly something that could be
improved.  It seems like we also have fixed values like object-path segments
that are in demand.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200903/c2625f2c/attachment-0001.sig>


More information about the openbmc mailing list