Comments on Sensor design.
Patrick Williams
patrick at stwcx.xyz
Fri Nov 4 00:39:12 AEDT 2016
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 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
> >
> >
--
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/20161103/5e8ca63e/attachment-0001.sig>
More information about the openbmc
mailing list