How should Capabilities indicate the Units of Measurement of their Attributes and Commands

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

Continuing the discussion from Capability.airPressure:

@chuckles

The unit “bar” and derivatives (including millibar) is actually deprecated. The SI unit is the “pascal” ¶, 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.
  Lat/Long).

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

I don’t have many suggestions at the moment, but figured I’d spin off the Topic.
Almost everything in the above post is relevant (i.e., definition of the Attribute, units, conversion, etc.).

Offhand: SmartThings ought to pick a universal measurement system (i.e., metric!) and that should be the basis for primary Attribute values units. A static Attribute could confirm the units, but really, it should be sufficient to define it in the documented Capability.

This leaves it up to the Device Handler to do unit conversion for Tile Displays.
SmartApps probably should do their own unit conversion if needed.

I hate to “go there”, but I suppose “optional” attributes could be provided by some Capabilities or “ad hoc” attributes by some Device Handlers.

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

So the Event Class has a Property called “unit”.

https://graph.api.smartthings.com/ide/doc/event

I suppose that helps avoid ambiguity of the data value; but this sure puts a LOT of pressure on the SmartApp to interpret the value. – Unless, of course, the sole purpose is for display (i.e., "${value} ${unit}).