Comments on Sensor design.

Rick Altherr raltherr at google.com
Wed Nov 2 15:58:07 AEDT 2016


I see Type and Unit being conflated.  I find it perfectly reasonable to
report temperatures (called a Type in the example, in math/physics circles
it would be a measurement dimension) in any of ºF, ºC, or K (units).  In
the monitoring systems I've designed, I've used something like:

Interface xyz.openbmc_project.Sensor
                Properties:
                     - Instance Identifier (map<string, string>)
                     - Value (integer)
                     - Unit (string [enumeration])
                     - Scale (integer, n where real_value = value*10^n)

Where the path conveys a broader grouping of device type and the
measurement dimension:
/xyz/openbmc_project/sensors/cpu/temperature
/xyz/openbmc_project/sensors/fan/current_speed

That allows for querying the data in a variety of ways: all data about a
given element in the system (/xyz/openbmc_project/sensors/cpu with
instance_id <core=1>), one type of measurement across all instances of a
device type (/xyz/openbmc_project/sensors/cpu/temperature), etc.

On Mon, Oct 31, 2016 at 2:08 PM, Patrick Williams <patrick at stwcx.xyz> wrote:

> There was a request for us to start on the openbmc interfaces for
> Sensors in the near future.  Before we get started on it I wanted to
> solicit feedback on two divergent approaches.
>
> Before I start, keep in mind that any proposals for DBus designs will
> show up here:
>     https://gerrit.openbmc-project.xyz/#/q/project:openbmc/phosphor-dbus-
> interfaces+status:open
>
> The two divergent approaches are:
>
>     1. Have a single interface for all sensor readings.  Example:
>             Interface xyz.openbmc_project.Sensor
>                 Properties:
>                      - Value (integer)
>                      - Unit (string [enumeration])
>                      - Scale (integer, n where real_value = value*10^n)
>
>     2. Have unique interfaces for different kinds of sensor readings.
>             Interface xyz.openbmc_project.Sensor.Temperature
>             Interface xyz.openbmc_project.Sensor.Tach
>                 ( Same value and scale properties )
>
> In both cases the dbus path could contain the 'type':
>     /xyz/openbmc_project/sensors/temperature/ambient
>     /xyz/openbmc_project/sensors/fan_tach/fan0
>
> The question is essentially should the "Unit" property be used to
> resolve the 'type' or should we have distinct interfaces for each
> 'type'?
>
> For some comparison with other standards, CIM had a single Sensor class
> while Redfish seems to have multiple classes (Fan, Temperature) for each
> type.
>
> --
> Patrick Williams
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161101/571e2832/attachment.html>


More information about the openbmc mailing list