Code change:
This should now consider and . There are no perfect solutions for these, but the solutions chosen should be close.
I don't agree wth some of this but agree with a bunch. I took carsten's changes for all the parts I agree with and put them in URL
I might suggest we pull that PR and then look at what is left (on a bunch of them it is simply if there should be an * suggesting don't use or not) then we can rebase this PR and see what is left to resolve.
Oops, I just changed my PR to react to your comments before seeing
Pushed another version that has both / and % for the same thing, where % is marked with a *
Now, instead of delete, it's "not recommend" and mentions kg as exception. I think this is good to merge.
The following units are questionable: % -- this looks like a percentage (0..100), but it is not (0..1). count -- what? This is about a dimensionless quantity? %RH, %EL appear to be percentages, but imply a quantity. EL may be a quantity, but the unit is second. In SI, we don't do new units for new quantities (there is no "millimeter radius" or "nanometer wavelength"). Bspl -- this really should be in dB (see ), SPL is the quantity again. beat/min, beats -- these should be 1/min (but see ) and 1 (dimensionless); how is beats different from count? We don't have bit (but bit/s), byte. 1/min is there only for heartbeats, not for revolutions ("rpm"). Should really be 1/s (but see ). lat and lon are a bit weird, too. (Celsius is also questionable -- the rationale of should call for all measurements being expressed in Kelvin.)
on on kevin vs C, every thermostat manufacture I can find has said they want C over kelvin. bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what. Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way. They use this and it works well for them
So I changed % to mean percentage. Cel of course stays in (even though it is wrong wrong wrong :-). I have marked count and EL with the "not so recommended for new producers" range. But we don't really have a base unit for "1" (dimensionless) either. The problem remains that giving a unit doesn't tell you what quantity actually has been measured, and the trend to make more and more finer grained units for the same kinds quantities measured in different ways (as in psi vs. psig etc.) leads into the woods.
just finding all the email now … I think the thing that people like about this is it’s not a SI unit, it’s something that tells you something useful about what you are measuring across a wide range of devices. I think we need to think of these from a point of view of broadly useful than are they a SI unit. Agree with your slippery slope psi, psig, etc argument but all of those exist for a reason.
The SI unit for mass is kg. says: That leads to being unable to use the SI unit for mass, instead, we are using g. But then we are using derived units such as l (dm3) and l/s (dm3/s). So: We need to decide the above TODO. We need to decide whether to stick with SI units or allow simple names for derived units (gram, minute, liter). Domain-specific units are often weird (1/min = "rpm", mmHg or mol/dl in medicine, ...).
I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up. Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information. As related to our whole conversation on why we needed the IANA table, the ability to have things in this that are not really a classic SI unit is the key value of SenML. The rules are just guidelines. If we want to change the unit of mass from g to kg, we can do that but the point on the prefixes was not to have both g and kg as that just reduces interoperability

Related discussion:
text: IANA will create a registry of SenML unit symbols.  The primary purpose of this registry is to make sure that symbols uniquely map to give type of measurement.  Definitions for many of these units can be <del> found in location such as NIST811 and BIPM. </del> <ins> found in location such as NIST811 and BIPM.  Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations, but are in active use and SHOULD be implemented by consumers that can use the related base units. </ins> Note 1: A value of 0.0 indicates the switch is off while 1.0 <del> indicates on and 0.5 would be half on. </del> <ins> indicates on and 0.5 would be half on.  The preferred name of this unit is "/".  For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! </ins> Note 2: Assumed to be in WGS84 unless another reference frame is known for the sensor.