The type of sensor value in redfish should be double or int64?

[Lei YU]

On Wed, Oct 16, 2019 at 8:45 AM Patrick Venture <venture at google.com> wrote:
> > >
> > > This change from int64 to double is big enough though that many
> > > configuration files would need to be adjusted, which is non-trivial.
> > > I argue however that having code that doesn't have a common interface
> > > or interfaces for sensors is less than ideal.  Having multiple options
> > > for talking to sensors is fine, but in my opinion this is only true if
> > > they implement different interfaces, or the same interface.  In this
> > > case, we have dbus-sensors and phosphor-hwmon which both implement the
> > > same interface, but differently: int64 vs double.
> >
> > I agree.  This whole situation is…unfortunate.  I wonder if there is a
> > lesson to be learned here?
>
> There may very well be a lesson here.  In this case, The push to
> double was pushed back, and then we ended up with software that
> followed one version of the interface, and other bits that followed
> another version.  Most of the software is compatible with both types
> here, but having two types does feel like it's defeating the
> well-defined dbus interfaces.
>

The phosphor-dbus-interface xyz.openbmc_project.Sensor.Value interface
specifically defines the `Value` property as int64, so it looks like
dbus-sensors is not following this interface.

> >
> > > I think using doubles makes sense at the dbus level because generally
> > > one wants that version of the value.  Therefore you end up with code
> > > in each daemon that reads the sensor value and the scale so that it
> > > can perform the same operation that another daemon is also going to
> > > perform, etc.  Instead of just doing it once.
> > >
> > > I'll climb off my debate box now and climb onto my voting box and say,
> > > I'd like to make phosphor-hwmon report the value as double
> >
> > Why?  Do you have a desire for this specifically or is it just to solve
> > Carol’s issue?
>
> I argue that maintaining the sensor value in its final form saves some
> operations and I'd like to normalize to that.

The interface defines the Unit and Scale as well, so the application
code could provide a calculated value and unit to end-user, which is
easier to understand.

Going back to Carol's question, what she really needs to do is to
PATCH PowerCap, instead of PATCH a sensor value.
So we are OK that PATCH sensor does not work for phosphor-hwmon sensors.
Carol should be able to write some specific code in bmcweb to
introspect the PowerCap's DBus object  and handle both double and
int_64 case.