[REQ] Component Request: Sensirion SEN55 Particulate / NOx / VOC / RHT Sensor unit

[tyeth]

What's the full name of the component you'd like to see in Adafruit.io WipperSnapper?
Sensirion SEN55

What type of component is this (i.e.: Pin, I2C)?
I2C

Product URL or Datasheet
https://sensirion.com/products/catalog/SEN55/

Additional context
I plan to add the SEN55, although depending on adafruits upcoming products it may be worth supporting lower models:
SEN50 (only particulate matter signals available)
SEN54 (no NOx signal available)
SEN55 (full feature set)

[tyeth]

I would love some advice on how best to handle the two gas values (Nitric/Nitrous Oxide, and VOCs/ethanol), which are indexes rather than unit based, but still very effective at showing change / events. I've initially stuck them in as the first two raw bytes for a raw event as I swear I read that was the thing to do somewhere sometime ago 🤞 No idea what I'll do with them from there but that's next weeks problem.
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/compare/main...tyeth:Adafruit_Wippersnapper_Arduino:add-SEN55?diff=unified#diff-1b95044a0a20c33a93edf6a4bfb2fcce4ca8a791ca0862e09dc7acef46f53a1dR133

[brentru]

which are indexes rather than unit based, but still very effective at showing change / events

Setting the readings as raw events is good, if they're unit-less. How many of these event types do you need to log?

[tyeth]

Just those two, nox/voc, although I did consider logging the particle counts (#/cm3) as raw or integers too (another 5), for now I'm happy with just the ug/m3 particle metrics.

I guess if there were space for 8 instead of 4 I'd maybe add a status bit too, showing if it's broken or currently running the weekly cleaning cycle or something, no real need as all that happens is reads fail for ten minutes.

[tyeth]

My biggest issue with raw is it needs demodulating somewhere. Fine for complex scenarios, not easily logged. I assume the raw values aren't broken up and plotted separately in adafruit io? Alternatively I guess when the ability to have multiple of the same metric type comes up then it will all come together.

[brentru]

I assume the raw values aren't broken up and plotted separately in adafruit io?

Not currently.. we may actually want to handle these as new sensor types (unit-less). Could you checkout a new issue here and tag @lorennorman and myself on it with the sensor types you'd like to add.

[lorennorman]

Off the top of my head, I think I use a sensor's type as part of its unique ID, assuming no I2C device would have 2 sensors of the same type.

That assumption breaks down for unitless, I now see. I'll need to do some rethinking around this use case and get an enhancement in to support it.

[tyeth]

I had thought the displayname could be used to differentiate (after sanitizing - prefixed by type), so I would define two raw subComponent a bit like this one with voltage and unitless-percentage, but two raw types with vocIndex and noxIndex as displaynames. I would also include the usual suspects for particles+temp+humidity.

The displaynames can be supplied, which would mean one of each type if not changed, as they default to

Having looked at mqtt topic length on aws, seven slashes (256bytes of utf8), I'm less confident in that idea working, maybe if there was a feedName/metricName property or something but that screws with the whole system.

[tyeth]

@lorennorman just spotted the subcomponents has a type as well as displayname, different to the other uses of type in the non-i2c schemas. Seems like no example of usage but exactly what we need

Wippersnapper_Components/components/i2c/schema.json

Lines 18 to 23 in 6a7d094

	"type": {
	"description": "A unique string used to look up this sensor's definition, and its parent component's definition.",
	"type": "string",
	"minLength": 3,
	"maxLength": 24
	},

[brentru]

@tyeth Could we instead add nox and voc as sensor unit types. These would be unitless, so nox-index and voc-index would be the sensor unit type names?

[tyeth]

@brentru Yeah sure, sounds like a much easier win before Christmas, should I add the types to sensor repo even though they stretch the definition of SI units?
Desperate to get my burnt-toast detector running as my burn rate is >70%🧯 broken dial... get a new toaster? Nah, I'm calling it fixing by over-complication, a speciality of mine

[brentru]

should I add the types to sensor repo even though they stretch the definition of SI units?

Yes, and to the I2C driver file(s) via your existing SEN55 PR

[tyeth]

Updated #105 and the sensors repo. The driver is done too, think I got protobuffer updated, but there's probably something I missed. Mostly I think the new component sensor types wont exist for a while so checks will fail.
Also just curious if the dev component Could exist with voc-index type and not break the matrix if I hadn't yet added voc-index methods to the i2c driver.

Side note, the gas resistance for BME680 presents an index too, and meant to represent VOC or Air quality index, but I'm not 200% on what else needs changing in backend etc so leaving that for now. It's setup to return resistance for now. I got confused and thought that was the true voc sensor with parts per billion, nevermind https://github.com/tyeth/Adafruit_Wippersnapper_Arduino/blob/827692822570265fba2d16bb50366fb7983d0df5/src/components/i2c/drivers/WipperSnapper_I2C_Driver_BME680.h#L155-L170

[brentru]

Updated #105 and the sensors repo.

Sweet, working on reviewing everything!

Side note, the gas resistance for BME680 presents an index too,

Could you split this into a new issue so we can properly track and address it?