Barometer sensor: Soft-remove `hPA` unit for compatibility reasons

[dbrgn]

This way, an endpoint with a barometer sensor can be compatible with both 0.13 and 0.14. See discussion in #69.

[gidsi]

I'm not sure if we should add the unit if there is just one unit that you can choose from? We have the same thing with wind direction and wind elevation.

I mean, it's more explicit that way, but also kinda useless.

[dbrgn]

I'm not sure if we should add the unit if there is just one unit that you can choose from?

It's mostly a compatibility thing, v0.13 requires the unit and if we remove the unit field we break compatibility.

It's also more open for extension in case there are other units in the future. We can of course say that all units must be normalized to standardized SI units, but for example for air pressure, would you specify Pa or hPa? Pa is the SI base unit but hPa is what's being used to specify air pressure.

I'd keep the unit, it doesn't break compatibility and it makes the sensor values self-describing.

[gidsi]

I'm not sure if we should add the unit if there is just one unit that you can choose from?

It's mostly a compatibility thing, v0.13 requires the unit and if we remove the unit field we break compatibility.

It's also more open for extension in case there are other units in the future. We can of course say that all units must be normalized to standardized SI units, but for example for air pressure, would you specify Pa or hPa? Pa is the SI base unit but hPa is what's being used to specify air pressure.

I'd keep the unit, it doesn't break compatibility and it makes the sensor values self-describing.

It wouldn't break compatibility if we remove it, 0.13 should still have it and 0.14 wouldn't care.

Alternatively i would also add kPa (that's what i3 uses, 1 of 4 spaces that has barometer readings). Isn't Pa the SI unit and hPa and kPa are just factors and by that still a SI unit?

[dbrgn]

It wouldn't break compatibility if we remove it, 0.13 should still have it and 0.14 wouldn't care.

Oh, I forgot that we'll simply ignore unknown values... That is true. But it would only work if we'd take hPa as the unit, otherwise a v0.13 value of 1013 hPa would be treated as 1013 Pa in v0.14.

If we'd start from a green field, I would suggest to leave away the unit and to always force the use of appropriate SI units (Pa or hPa in this case), but I think since all sensors currently have a unit field I'd stick probably to that (and ensure that those contain reasonable but not too many units).

Alternatively i would also add kPa (that's what i3 uses, 1 of 4 spaces that has barometer readings).

Hm, yeah, we need to find a tradeoff between making it easy to enter the data (by just using the units that are available) versus making it easy to consume the data (since data needs to be normalized). kPa seems to be a common unit for car tire pressure, for example. Meteorology uses hPa mostly. I'm not sure whether we should add kPa. Maybe we should always add the base unit and the commonly used unit for the type of sensor being used (if different)? In this case that would be hPa and Pa. (Barometers measure atmospheric pressure, they're not used for measuring tire pressure. Manometers are. Maybe some spaces would like to track the pressure of gas bottles in their workshop? Then an appropriate sensor with an appropriate unit could be added.)

(Edit: I just saw that i3 also provides a compressed_air sensor with psi as unit. All their sensor values are invalid though since they're strings, not numbers.)

---

Some brainstorming: Another approach would be to specify the value together with a factor. So pressure would be Pa, hectopascal values would use a factor of 100, bar values would use a factor of 100000 and atm values would use a factor of 101325. But again, easier to consume but harder to provide. Using units is probably better, the consumers can map those units to factors if desired.