Offline data doesn't distinguish between two metrics/subcomponents with same Units, e.g. PM2.5 + PM10.0

[tyeth]

Wippersnapper supports sensors with multiple subcomponents that have the same units, e.g. particle sensors like SEN54 have 3 outputs (PM1.0, PM2.5, PM10.0) using PPM for units. There are also some multi-object ranging ToF sensors and maybe power sensors that come to mind.

The offline mode records data with just i2c address and units, so it's currently impossible to distinguish between the three different sized particulate count values in each periodic cycle with this SEN54:

The idea of having the full component type in each JSONL row doesn't feel great, maybe an abbreviated version of those names.

Better yet, if the component definition in config.json has more than one subcomponent using the same units, then we could qualify just those ones when output? Does that wreck peoples minds too much to have some lines with an extra type field, probably...
There must be a better way!

I would almost appreciate the component type (shortname) being saved along with i2c address, but it's probably unnecessary. For now I've made the converter access a config file if available and adding the component names back from that.
It led me to wonder about including an index number to tally with the config.json subcomponent number (position in array) and help distinguish between pm2.5 and pm10, but it's all a bit less than ideal.

Maybe instead of all that we fix up the units column which does the same job anyway (translating from Adafruit SENSOR Type), and have the units for some clashing types with labels to disambiguate, like *C (Ambient) and *C (Object), along with ppm (PM1.0) and ppm (PM2.5).
That's less ideal to work with, but not difficult (and easily converted / split to two columns or just used directly)

@brentru any cunning plans come to mind?

[brentru]

The offline mode records data with just i2c address and units, so it's currently impossible to distinguish between the three different sized particulate count values

The least impact would be implementing a "new unit" like how we have ambient temperature and object temperature. Would something like that work?

and have the units for some clashing types with labels to disambiguate, like *C (Ambient) and *C (Object), along with ppm (PM1.0) and ppm (PM2.5).

This is a good idea too, maybe a better one than what I had. We already use the sensor type to convert to a label.