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

[Bruce Mitchell]

On 6/2/2021 09:21, Ed Tanous wrote:
> 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.
> 

I prefer the the 2 record solution, it keeps the DPS310 self-contained.
And keeps the Altitude self-contained, to the models can evolve and 
change; also if every a true altitude sensor were created it would help 
keep better abstraction from the DPS310.

>>
>> 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.
>>

Thank you Ed!