hardcoded median function in phosphor-virtual-sensor

[Ed Tanous]

On Mon, Jan 4, 2021 at 9:49 AM Matt Spinler <mspinler at linux.ibm.com> wrote:
>
> Hi,
>
> Just putting on the list what was decided after some lengthy discussions
> on discord.
>
> I need a median of some sensor values, where this median sensor has
> threshold interfaces
> whose values must be defined in entity-manager.  Since exprtk
> expressions are not allowed in
> entity-manager, I cannot just port the PVS's JSON config into an
> entity-manager config.
>
> Instead, I will make a new entity-manager config that will have the
> component sensors
> along  with the thresholds to use, with a subtype of median, vaguely
> something like:
>
> {
>
> Type: "VirtualSensor"

I'm kinda thinking we just go with Type: "MedianSensor".  Technically
there are already other "virtual" sensors that have their own primary
type, so let's be consistent with them, and just declare this as a
primary type: "Median"

>
> Name: "MySensorName"
>
> Subtype: "Median"
>
> Sensors: [ "Sensor1", "Sensor2", .... ]

Just call this "Inputs" to be consistent in naming with the PID type
and stewise type.

>
> ThresholdsWithHysteresis [ ]

Should this just forward on thresholds from the sensors themselves to
reduce the amount of configuration, and to be consistent?  I'm
assuming this could be omitted, and we could just forward on the
median sensors threshold state if we wanted to.

If we really do need it, it should be called "Thresholds" to be
consistent with the other sensors.

>
> minInput: 0
>
> maxInput: 100
>
> }
>
>
> The minInput/maxInput are needed so we don't use garbage sensor readings
> in the median
> algorithm.

Doesn't the median algorithm already give you that behavior without
having to declare a new range?  If a sensor goes out of range, it's
very unlikely to be the median, so pre-gating the sensors just seems
like extra work.  Overall, this kind of config feels like something
each sensor itself should own, as they already have more information
than the median sensor.  If the sensor knows it has "garbage" values,
it should post some form of NAN that the virtual sensor can see and
act on.

What is the behavior if all sensors go out of this range or are invalid?
How will the MinOutput and MaxOutput for the sensor be calculated?  I
would assume based on the max/min of the inputs, but it's probably
worth calling out explicitly.
Do we need to add a PowerState parameter so the thresholds don't trip
on power cycles?


>  PVS will look for this config to be provided on D-Bus by
> entity-manager, and if
> it's there it will calculate the median (in C++, not exprtk) and use it
> as the virtual sensor value.
>
> Thanks,
> Matt
>