External Sensors - phosphor-pid-control

[Ed Tanous]

Before my last reply, I started playing around to make sure there
weren't any landmines there that I I didn't know about in building a
host sensor.

The totally untested, half baked result of what I wrote is posted here:
https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/35476

Feel free to use it as a starting point if you want (or I take no
offense if you don't).  It still needs a lot of work, but hopefully it
helps you with some of the generic sensor boilerplate.


One interesting thing that this discussion might bring up is I wonder
if we need a detectable entity for "Host Operating system".  You
probably don't want your host OS generated sensors getting invoked if
the host OS utility in question isn't installed.  That might require
more thought.

-Ed

On Mon, Aug 10, 2020 at 10:11 AM Patrick Venture <venture at google.com> wrote:
>
> On Fri, Aug 7, 2020 at 3:44 PM Ed Tanous <ed at tanous.net> wrote:
> >
> > Most (maybe all these days?) of the sensor types support the concept
> > of an "override".  So calling SetProperty on the Value interface of
> > any individual sensor will force it to "stick" to that value, stop
> > normal scanning operations, and send out a PropertiesChanged event as
> > if it had just read that value from its hardware interface.
> > Here's the logic that PWM sensor uses for its set interface.
> > https://github.com/openbmc/dbus-sensors/blob/8b8bcc8700af5ba1d435c7cf0f6467b2b6a8c679/src/PwmSensor.cpp#L53
> > It's slightly special because it actually changes the hardware value.
> > Most other sensors derive from the common sensor class, that just
> > masks the value directly.
> > https://github.com/openbmc/dbus-sensors/blob/1a540b81a3697202f69771785cd22a31294154a7/include/sensor.hpp#L58
> >
> > A host sensor would be exactly that, just with the normal scanning
> > logic deleted, and a reasonable default value put in place.  I'm
> > assuming you probably also need a power on/off check in it to check if
> > the host is off, and revert the value to NAN.
>
> Ok, so someone would need to basically add a new daemon to
> dbus-sensors that provides ownership to host-provided sensors, and
> then it would just be a normal sensor for phosphor-pid-control.  One
> thing, I haven't checked is, with the json sensors there are timeouts
> set, so we track how often a sensor is updated -- is this supported
> with dbus configured sensors?

TL; DR; Yes, it's supported.

One important architectural distinction in dbus-sensors compared to
others is that a sensor has full ownership of its own scan loop.
There is no central manager telling each sensor "it's time to read a
new value now".
In the host sensor you implement, you can have whatever timeout,
masking, or scanning logic you think solves the problem at hand.  I
believe most sensors today implement reading as a failure count, where
if N runs of the scan loop result in an error, then the error is
propagated.  That doesn't make much sense for a Host sensor, so you'd
probably want to implement your timer idea in it with a configurable
timeout.