Comments on Sensor design.

[Brad Bishop]

> On Oct 31, 2016, at 5: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 )

I can see a path here to extending what a sensor is (additional properties) 
without impacting the existing API.  Do we lose that capability with option #1?
What about com.ibm.Sensor or org.open_power.Sensor?

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

Leaning towards the latter, for the reason stated above.

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