Comments on Sensor design.

[Brad Bishop]

> On Nov 2, 2016, at 12:58 AM, Rick Altherr <raltherr at google.com> wrote:
> 
> 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).  

I don’t think either approach prevents this.  For either approach the
logic for getting a single sensor or a group of sensors is the same:
(GetObject and GetSubTree are methods provided by the mapper service).

Get a specific temperature<type> sensor in degrees K<unit>:
---
sensor = GetObject(path=/xyz/openbmc_project/sensors/temperature/ambient)
val = sensor.value
unit = sensor.unit

Get all temperature sensors:
---
sensors = GetSubTree(path=/xyz/openbmc_project/sensors/temperature)
for s in sensors:
    val = s.value
    unit = s.unit

The difference really is just with signal match rules and I don’t really see that one approach over the other
provides any more or less flexibility.  If you want signals for an entire class of sensors, you just use
the pathnamespace match rule.

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

You can still do this if the sensor objects themselves are the instances.  I think I prefer that because:
 - it moves the query semantics into the rest (or dbus for that matter) domain, which is uniform across the entire project.

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

Patrick - after reading this again I don’t understand.  Why would you not just use
the path namespace to resolve the 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
> 
> 
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc