Support other RCXAZ devices, starting with the 9-in-1 sensor.

I'm just putting this issue here for others facing the same thing to have a place to track it.

I've got a 9-in-1 device. The 5-in-1 code actually works on it, because the same 5-in-1 messages are used in the 9-in-1 device. It's just that the only sensors you can utilize are those exposed through the 5-in-1 code. So your 9-in-1 will basically be limited at the moment to temp, humidity, formaldehyde, CO2 and TVOC, IIRC. They're not much more expensive than the 5-in-1 devices, which are a bit rarer, and at around $20 USD each, I imagine they're getting more popular.

I'm working on code for this device. I'm not really a frequent C++ user, so I'm taking my sweet time on it. I've already got it handling the additional message type and exposing the sensor, and have found another message type with unclear usage that I'm looking into.

Also working on documenting a bit of what I have. The RCXAZ devices basically seem to only broadcast data when paired, but any other device that broadcasts sensor data on its own in byte messages on a service characteristic when paired can function similarly. One of the planned improvement is to better log unrecognized message bytes received from this characteristic. It should make onboarding new sensor data much easier if it operates similarly.

There's also what looks like a configuration service and an OTA (well, OAD) service.

When the code for the new sensors is not embarrassing, I'll submit it in a PR for review.

Revisiting this briefly. I'll probably just put the code in soon even though it's not super clean and still doesn't manage to successfully expose all the particulate matter sensors. All 3 are exposed in the same way, but for some reason only 2 of them make it up to Home Assistant. I'd been stopped on that for a while, but I don't consider it an issue any more.

As far as the reason why I won't be trying to perfect this? The device doesn't have all the sensors it claims to have. This device claims to detect (with specific accuracy ratings):

CO₂
TVOC (Total Volatile Organic Compounds)
HCHO - Formaldehyde
PM1.0
PM2.5
PM10
Temp
Humidity

And of course every model adds things like clock, stopwatch, date, etc to make it an e.g. "13-in-1" sensor.

Inside the case, there are 3 sensors which are helpfully labeled on the circuitboard:

- Temp (via what looks like a knock-off temp/relative humidity SHT31D - not even the original model)
- PM2.5 (in an enclosure with a board labeled HT5106_P2_20210930, a 5V serial connection and all the chips painted over)
- TVOC (labeled LY-B016 with 5V/B/A/G wires)

So, half of the numbers being "monitored" are algorithmic values intended to fool the user into thinking they're valid. In fact, if you actually set it next to some isopropyl alcohol the CO₂, TVOC and HCHO readings will max out. And I'm not certain what tricks have been done to the legitimate VOC, PM2.5 and RH/T sensors in the name of generating "reasonable" data trends. I think the sensors themselves are probably alright, but I don't know how much they're being altered.

The main board runs apparently on a Beken BK3432 MCU (BT-only - no wifi). So there's definitely a possibility of writing firmware for this that gives you legitimate readings. Potentially one that doesn't require you to pair to it. If the chip was wifi-based, it'd be a lot easier. And the case itself has room for more things, so you could conceivably stick other useful sensors inside.

EDIT: The particulate matter sensor may be a Winsen ZPH03 or ZPH03B laser dust sensor. Refs: https://shop.winsen-sensor.com/products/winsen-zph01b-zph02-zph03-zph04-zh03b-zh06-zh07-dust-sensor-series?variant=43845962498240 https://www.winsen-sensor.com/d/files/manual/zph03.pdf and https://github.com/ShaggyDog18/SD_ZH03B . These sensors can't sense anything smaller than 1μm, which would lead me to believe that sensing PM1.0 (particles smaller than 1μm) is impossible or at least misleading about its efficacy. Not sure that anyone wants to get that pedantic. As far as the chips on the assembly, I managed to make out letters on 2 of the 3 painted over chips: a UART chip and an ARM Cortex-M0 MCU.

3peak TPA8801B ADME

ARM MM32SPIN 27PT 761907-p5 63H6 049

So I'll keep working on these units, but the focus has changed. I'll probably also update with some image snapshots of the device.

Ironically, the issue with not being able to use PM1.0 and PM10 sensors has fixed itself. ESPHome changed their handling for unique ID generation recently.

Prior to that, it dropped certain characters and now it replaces those characters with underscores. I found an error by chance in the logs when looking at something else which indicated that the PM10 (PM10) and PM1.0 (PM1_0) sensors had the same ID and, when trying to work around it, I found evidence that ESPHome had changed since I last built this.

The change occurred in December, so January builds or newer will work fine. Anyone with older builds will have to manually specify the id for those sensors if they're using both PM1 and PM10. So there's no blockers on that anymore.

Warnings about the CO₂ sensor and HCHO sensor values being algorithmically calculated from the TVOC sensor still hold. The PM1.0 sensor being not very sensitive at that level is still notable. And of course the SHT31D Temp/Humidity sensor this is based on is specced for ±2% relative humidity and ±0.3°C, but I've no idea if that needs calibration. Check your numbers.

Those wanting accurate an accurate CO₂ sensor could look into the SCD-41 sensor for similar ranged numbers - 400-5000ppm ±(40 ppm + 5% of reading) - or the more expensive SCD-30 for a 10000ppm measurement range with ±(30 ppm + 3%). You could probably stuff it in this chassis, but the chipset is not compatible with ESPHome as-is.

mheistermann / esphome-component-rcxazair

Support other RCXAZ devices, starting with the 9-in-1 sensor. #3