Comments on Sensor design.

[Patrick Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161031/a1afea0b/attachment.sig>