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