Proposing new ReadingType values for Sensor Oct 29, 2021 16:20:44 GMT
Post by jautor on Oct 29, 2021 16:20:44 GMT
Picking up a thread started by Bill altitech and building on it from some items I had gathered up looking at various IoT sensor products, here's a list of additional possible ReadingType values for a Sensor instance. I'd like to hear feedback on these - are they useful? Is the definition wide or narrow enough to avoid confusion? And probably most importantly - are the units correct given common usage. Note that in Redfish, we try to use SI units whenever possible, but there are cases where non-SI units were just too common to avoid.
|Vibration||[g] ||Dynamic vibration or force (g force)|
|Shock||[g] ||Static force (g force)|
|Velocity||m/s||Velocity (should this just be "Speed" since direction is a different measure?)|
|Radiation||Sv||Radiation dose equivalent (sievert)|
|Luminosity||lx||Luminosity or light measurement (lux)|
|Sound||dB||Sound pressure level C-weighted dB(C) |
|Noise||dB||Noise pressure level A-weighted dB(A)|
|Distance ||m||Linear position / offset|
|Angle ||deg||Angular position|
* Units column lists the "case sensitive" normative values from the Unified Code for Units of Measure specification, as used in Redfish - see ucum.org/ucum.html
As feedback comes in, if there's agreement on any of these, I can bring them to the group to add to the schema. Adding enum values to Redfish is "easy" - we can add these over time as desired. I don't want to define enum values that won't be used - but I also don't want to hold up development that could use standard reading types for sensors.
EDIT: Updating the table to incorporate feedback as it comes...
Bring on that feedback!