Comments on Sensor design.

Comments on Sensor design.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Comments on Sensor design.

[Brad Bishop]

> On Oct 31, 2016, at 5:08 PM, Patrick Williams <patrick@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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: Comments on Sensor design.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Tue, Nov 01, 2016 at 10:10:08AM -0400, Brad Bishop wrote:
> 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?

I don't think we lose that.  Someone could always extend it with a
'com.ibm.Sensor.Temperature' interface if they wanted.

I fully expect that we will have at least one extension which is related
to thresholds.
    xyz.openbmc_project.Sensor.Threshold
        property max
        property min

I suspect what I just wrote isn't correct and may require multiple
interfaces to handle all the different threshold types.

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

The big trade-off to me between them, besides minor impact of multiple
implementations of effectively the same content, has to do with signals
and filtering.  I could see it interesting to listen for signals on all
*.Sensor instead of having to listen for them each individually.  Maybe
the path is sufficient for this as well.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Comments on Sensor design.

[Xo Wang]

Hi Patrick,

On Tue, Nov 1, 2016 at 12:24 PM, Patrick Williams <patrick@stwcx.xyz> wrote:
> On Tue, Nov 01, 2016 at 10:10:08AM -0400, Brad Bishop wrote:
>> 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?
>
> I don't think we lose that.  Someone could always extend it with a
> 'com.ibm.Sensor.Temperature' interface if they wanted.
>
> I fully expect that we will have at least one extension which is related
> to thresholds.
>     xyz.openbmc_project.Sensor.Threshold
>         property max
>         property min
>
> I suspect what I just wrote isn't correct and may require multiple
> interfaces to handle all the different threshold types.
>
>> >
>> > 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.
>>
>
> The big trade-off to me between them, besides minor impact of multiple
> implementations of effectively the same content, has to do with signals
> and filtering.  I could see it interesting to listen for signals on all
> *.Sensor instead of having to listen for them each individually.  Maybe
> the path is sufficient for this as well.
>

I don't think that listening to multiple interfaces or even all
interfaces of an object path is an excessive burden to the
application, since that's only a matter of writing the appropriate
sd_bus_add_match match rule.

The benefit is that a signal handler would be able to differentiate
sensor types based on the originating interface, removing the need to
parse its contents for purposes of dispatching or filtering. That also
means signals can be slightly lighter weight (as in payload).

> --
> Patrick Williams
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>

cheers
xo

Re: Comments on Sensor design.

[Rick Altherr]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

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@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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>

[-- Attachment #2: Type: text/html, Size: 4481 bytes --]

Re: Comments on Sensor design.

[Brad Bishop]

> On Nov 2, 2016, at 12:58 AM, Rick Altherr <raltherr@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@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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
> 
> 
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: Comments on Sensor design.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Wed, Nov 02, 2016 at 10:12:47AM -0400, Brad Bishop wrote:
> 
> > On Nov 2, 2016, at 12:58 AM, Rick Altherr <raltherr@google.com> wrote:
> 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.

As long as you feel we have this covered with a mapper call or a signal
filter I am fine.  I was concerned with, especially, the number of calls
the REST server would need to do in order to subscribe to all the
sensors.

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

I think this was making leap that we would require / document paths as
well.  Maybe that is the right thing to do but we don't have a currently
defined mechanism for it.  I'm especially not happy with 'fan_tach' as a
path match string.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Comments on Sensor design.

[Brad Bishop]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

I have changed my mind.  I think I favor the single interface approach now, with sensor type expressed in the path hierarchy.  From an end user perspective, it makes sense to group all the temperature sensors here for example (this would be a REST collection):

/xyz/openbmc_project/sensors/temperature

The only other way to express the type outside the BMC (DBUS interfaces are not exposed) is with a property, but that requires a lot queries from a client or a fancy query mechanism like CIM has.  Given that I’m not seeing any motivation to have different interfaces per type or a property in a unified interface that denotes the type.

So I am proposing just a handful of interfaces for now, found here:

https://gerrit.openbmc-project.xyz/#/c/1106

This should give us enough definition and still be flexible.

Moving past the API definition…there is an unfinished hwmon monitoring application out there:
https://github.com/openbmc/phosphor-hwmon

My expectation is that this application will be started via udev+systemd and enter a polling loop with objects implementing the interfaces above, being created/updated on each poll.  This will generate a stream of dbus signals for the rest of the applications to listen to and act on.

This feels like a pretty general implementation for hwmon class sensors so it seems like a good candidate for the reference implementation.  In the longer term, I anticipate reference implementations for other, non-hwmon classes of sensors.

I’m sure I’ve probably missed something - please let me know.

thx - brad

> On Nov 6, 2016, at 10:54 PM, Patrick Williams <patrick@stwcx.xyz> wrote:
> 
> On Wed, Nov 02, 2016 at 10:12:47AM -0400, Brad Bishop wrote:
>> 
>>> On Nov 2, 2016, at 12:58 AM, Rick Altherr <raltherr@google.com> wrote:
>> 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.
> 
> As long as you feel we have this covered with a mapper call or a signal
> filter I am fine.  I was concerned with, especially, the number of calls
> the REST server would need to do in order to subscribe to all the
> sensors.
> 
>>> 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?
> 
> I think this was making leap that we would require / document paths as
> well.  Maybe that is the right thing to do but we don't have a currently
> defined mechanism for it.  I'm especially not happy with 'fan_tach' as a
> path match string.
> 
> -- 
> Patrick Williams
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc


[-- Attachment #2: Type: text/html, Size: 6062 bytes --]

Re: Comments on Sensor design.

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]

On Tue, Nov 01, 2016 at 09:58:07PM -0700, Rick Altherr 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).  In
> the monitoring systems I've designed, I've used something like:

I would strongly suggest that we pick a base unit for all sensors of
that type to be in.  It is kind of pointless to have everyone consuming
temperatures within the BMC having to know the F->C conversion.

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

We tend to use associations to represent the relationship between
entities.  So, /.../inventory/.../core0/temperature is an association to
/.../sensor/temperature/core0temp and
/.../sensor/temperature/core0temp/measured_element would point back to
the core0 inventory item.

Is that good enough for the 'instance identifier' you are suggesting?

> 
> On Mon, Oct 31, 2016 at 2:08 PM, Patrick Williams <patrick@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@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
> >
> >

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]