Seeking your opinion on ways to report both Altitude and Pressure sensors for the DPS310 as well as Temperature from dbus-sensors.

[Ed Tanous]

On Wed, Jun 2, 2021 at 9:14 AM Bruce Mitchell
<bruce.mitchell at linux.vnet.ibm.com> wrote:
>
> On 6/2/2021 09:03, Ed Tanous wrote:
> > On Wed, Jun 2, 2021 at 8:58 AM Bruce Mitchell
> > <bruce.mitchell at linux.vnet.ibm.com> wrote:
> >>
> >> On 6/2/2021 08:39, Ed Tanous wrote:
> >>> On Tue, Jun 1, 2021 at 8:43 AM Bruce Mitchell
> >>> <bruce.mitchell at linux.vnet.ibm.com> wrote:
> >>>>
> >>>> Hello Ed,
> >>>>
> >>>> It has been suggest I seeking your opinion on ways to report both
> >>>> Altitude and Pressure sensors for the DPS310 as well as Temperature from
> >>>> dbus-sensors before going to far down the road.  Thus that is what I am
> >>>> attempting to do in the email, others on the mailing list input is
> >>>> desirable as well.
> >>>
> >>> Thanks for discussing this before getting too far along.  I haven't
> >>> worked on any systems with physical pressure sensors, but I'm excited
> >>> to see new things get added.
> >>>
> >>>>
> >>>> As I see it, Altitude and Pressure are different in that
> >>>>        1) Altitude is computed base off of essentially a policy
> >>>
> >>> I have no idea what this means.....   In what way is altitude a
> >>> "policy"?  Can you elaborate a little?
> >>>
> >>
> >> I view a mechanism is something like update a FLASH part with
> >> an image provided.
> >>
> >> I view a policy is what decides if the the update of the FLASH part
> >> with the specific image is allowed.
> >>
> >> I the case if Pressure and Temperature I view them as mechanism,
> >> merely a simple reading and possibly some well defined computations
> >> that are universal.
> >>
> >> With Altitude computed from Pressure there are several ways to
> >> compute the Altitude and they are not universal.  So I see it as
> >> a policy of which Pressure to Altitude model is chosen and why.
> >
> > Sounds like I interpreted your intention correctly. (I think).
>
> I believe you did.
>
> >
> >>
> >>>>        2) Pressures is a read measurement which is a mechanism
> >>>>        3) Temperature is a read measurement which is also a mechanism
> >>>
> >>> I'm really struggling with the above to understand what you're getting
> >>> after, so if I go down the wrong path, please forgive me.
> >>>
> >>> I think what you're saying is that altitude is calculated based on
> >>> pressure + some transfer function to determine an altitude?  And that
> >>> transfer function might be fungible depending on the platform?
> >>>
> >>> If I got the above right (big if) I would probably expect a new
> >>> pressure sensor type to be added that reports a pressure sensor, then
> >>> we'd put the transform code in something that looks a lot like CFM
> >>> sensor (which oddly enough has a hardcoded 0 for altitude in its
> >>> algorithm for systems without pressure sensors).  Considering how
> >>> related a pressure sensor is to altitude, I could see putting them in
> >>> the same application if you wanted;  It might simplify the code some.
> >>>
> >>>
> >>> I think overall a better picture of what you're wanting to accomplish
> >>> would be a good place to start, then we can iterate from there on what
> >>> pieces we need that are new.
> >>
> >> I have Temperature, Pressure, possibly Humidity sensors all which are
> >> variables to different models to compute Altitude from.  I do not have a
> >> true Altitude sensor.
> >
> > This sounds exactly like the CFM sensor, and Exit air temp sensor;
> > Most systems don't have exit air temp sensors, but they have input
> > power and individual fan speeds, which can be put into models to
> > determine CFM and ultimately exit air temperature.  I would expect
> > Altitude to do something very similar in code (although with a
> > completely different algorithm).
> >
>
> So the DPS310 has 2 sensors in it a Pressure and a Temperature sensor.
> Do I create a Pressure reading and a Temperature reading for the DPS310
> and then add Altitude to it as well?
>
> Or do I create 3 separate things,  one for each Pressure, Temperature,
> and Altitude?

Assuming in this case "things" are intended to mean "entity manager
exposes records" you would create one config record for the DPS310
itself (which would in turn create 2 sensors).  This is one "record"
because physically it's one part, and can't be separated, similar to a
TMP421.  After that, I would create another config record for the
"Here's the math to combine these into an altitude".  It might just be
a type and a name, depending on how many inputs go into the transfer
function to convert pressure+temperature into an altitude.

If the math to combine into an altitude isn't system specific, I could
be convinced that the math should go into a single record within the
DPS310 exposes and have that live in the daemon itself, but I don't
have enough detail on how these are usually deployed to know that.

>
> Also I believe I should be looking to the CFM sensor and Exit air
> temperature sensor as reference examples.
>
> >>
> >> I am being asked to provide Altitude.
> >>
> >> Personally I believe the desired feature is how much cooling a parcel of
> >> air per unit of time.  Thus I would think air Temperature, Humidity, and
> >> Density (probably compute-able from Pressure, but I have not checked on
> >> the specifics) would be the important factors.
>