Capability airPressure

Capability for measuring the air pressure. Really only needs one ability:

Read the air pressure measurement in millibars.


You mean determine (measure) and report, right? Not “Display”? capability.displayValue is a different Topic.

Also recommend naming this airPressureMeasurement per existing similars (temperatureMeasurement,… ).

1 Like

The unit “bar” and derivatives (including millibar) is actually deprecated. The SI unit is the “pascal” (Pa), with atmospheric pressure typically reported in hectopascals (hPa).

The millibar is, though, still in common (though decreasing) use by meteorologists, as is mmHg (millimetres of mercury).

In other situations where (high) air pressure is measured (e.g. tyres, compressor reservoirs, storage tanks, etc.) it is commonly measured in kilopascals (kPa) or PSI (pounds per square inch).

There are other units (e.g. atmospheres (atm)) but their use is rapidly decreasing.

So - I see two issues:

  1. “Air Pressure” vs. “Atmospheric Pressure” - the former is much broader than the latter. My initial thoughts are that a new capability should be for the former (superset) rather than the latter (subset). The end-user will be making a rational decision when they select a sensor (thing) from the proffered list which has been filtered by capability; I don’t believe we can or should try to have capabilities so granular as to distinguish between the vast multitude of possible use cases.

  2. Supporting multiple units of measure. This is an issue which will reach across most capabilities and which I believe should be addressed via a standardised framework that provides:

● A standard means of expressing which unit of measurement is being used. (Almost already there).

  • A standard means of converting to any other supported unit of measurement.

  • A standard means of converting to displayable formats (comparatively
    simple for air pressure, more complex for other units (e.g.

The issue of a standardised framework for units of measurement is, I believe, worthy of its own thread.

1 Like

If this is for the Ubi and Netatmo devices you just need to add a attribute to the device type and boom done deal.

Ad hoc Attributes & Commands in Device Types need to be a avoided or forbidden in order for the Capability paradigm to hold together. Many different Device Types can report Air Pressure, and thus all should do so with consistent Attribute(s) so the Devices are interchangeable in SmartApps.

Getting new Capabilities defined and quickly added is, of course, essential to support the first point.

1 Like