Add support for the Fine Offset WH45 air quality sensor

[anthyz]

No description provided.

[zuckschwerdt]

See also #2099

Thanks! Looks very good and clean.

[JaraLowell]

It's Froggit DP250 :3 not 150, and so far it did not see mine .. did i forget somting...

[anthyz]

@JaraLowell Thanks for the correction! Not sure why it's not working for you. I did look at the .cu8 files you uploaded but none of them were for a DP250/WH45. If you're certain you're running with the new decoder you could save just signals from the sensor with the following which I'd be happy to look at:
rtl_433 -c 0 -R 0 -X "n=DP250,m=FSK_PCM,s=56,l=56,r=1500,preamble=0x2dd4,match={32}0xaa2dd445" -f 868M -S known

[JaraLowell]

Had to run it without the match={32}0xaa2dd445 as that did not hear it at all; had it like right next to it with no antenna in the sdr

{130}45003750014a9ba0efc0fb812fcf18a04
{130}4500375002953741d281e8025f79f0408
{131}4500375002953741b581c5026185be204
{130}45003750052a6e832d034a04caece8408
{130}45003750029437419681a502666c6a408
{130}45003750029437418781960268cbad408
{129}450037500295374186819202694928408
{130}450037500295374172817a0267b364404

cu8files.tar.gz

[anthyz]

Not sure why the match part didn't work. My decoder did work with your files, though, and the sensor was detected and decoded:
model : Fineoffset-WH45 ID : 003750 Battery Level: 1.0 Temperature: 26.1 C Humidity : 55 % 2.5um Fine Particulate Matter: 37.0 ug/m3 10um Coarse Particulate Matter: 37.8 ug/m3 Carbon Dioxide: 615 ppm External Power: 1 Integrity : CRC

[JaraLowell]

just slaps head,. helps if you run it ./rtl_433 as the darn box has the old apt one installed to lol!

model     : Fineoffset-WH32B                       ID        : 7
Battery   : 1            Temperature: 23.8 C       Humidity  : 55 %          Pressure  : 1014.8 hPa    Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-07-03 04:35:12
model     : FineOffset-WH31L                       id        : 61747
Battery   : 1.000        State     : noise         Flags     : 4043          Strike Count: 39          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-07-03 04:35:41
model     : Fineoffset-WH45                        ID        : 003750
Battery Level: 1.0       Temperature: 25.9 C       Humidity  : 55 %          2.5um Fine Particulate Matter: 23.7 ug/m3
10um Coarse Particulate Matter: 25.9 ug/m3         Carbon Dioxide: 616 ppm   External Power: 1         Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-07-03 04:36:32
model     : Fineoffset-WH24                        ID        : 245
Battery   : 1            Temperature: 14.3 C       Humidity  : 95 %          Wind direction: 12        Wind speed: 0.0 m/s
Gust speed: 0.0 m/s      Rainfall  : 1001.4 mm     UV        : 2             UVI       : 0             Light     : 0.0 lux
Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

So yay see all the froggit sensors now! 👍

[zuckschwerdt]

Thanks for testing. This is ready to merge – least review work in quite some time! Two other decoders that have been waiting should merge before, so it'll be a few days.

[gdt]

The calculations for pm2.5/pm10 are different in form and variable names from the WH0290. This is a maintenance problem as I believe the underlying components are the same. But it's not really clear if they are or are not the same -- I think that should be understood. I do not mean to insist on shared code as @zuckschwerdt has said that isn't necessary. But if it's the same representation from the same hardware, the code should really match, and probably have comments, so that if there is a fix to one, there will be a fix to another.

Related to matching, the new driver has

            "pm10_ug_m3",       "10um Coarse Particulate Matter",  DATA_FORMAT, "%.1f ug/m3", DATA_DOUBLE, pm10,

whereas the WH0290 has

            "estimated_pm10_0_ug_m3",     "Estimate of 10um Coarse Particulate Matter",  DATA_FORMAT, "%i ug/m3", DATA_INT, pm100/10,

The point, discussed at length earlier, is that the sensor used in the WH0290, perhaps the same as the WH45, does not actually measure PM10. It somehow has a formula that outputs a PM10 value based on the PM2.5 value. This is not a PM10 measurement, and should not be represented as such. However, it's rtl_433's job to just decode the fields.

Interestingly, the WH45 is specified to produce PM10. I am very curious if a scatter plot of PM2.5 and PM10 argues for a fixed function or a true PM10 measurement. Either way, I think this should be commented, as I view (and perhaps I'm odd) part of the job of rtl_433 to document for users what's actually going on.

[zuckschwerdt]

Yes, shared code isn't worth it for a single plain field. (Decoders ideally are a self-contained straight decoding recipe.) A short comment "See also X" / "Same as Y" can be a life-safer (life = staring at code).
The other points however (same code style /layout, same output keys /format) are important -- I didn't spot that.

Greg, your guidance is very much appreciated, please take the lead on this! Pretty sure @anthyz can log a few days of data for a plot on correlation.

[gdt]

From reading the ecowitt site, my current best guess is that the WH41 has a different sensor. So probably pm10 is real, between a different sensor and a spec. I wrote to ecowitt support before about this and they were very upfront about the pm10 in the WH0290 not being reliable -- and to be fair their marketing material says that it measures PM2.5 only.

@anthyz I do not remember the details, but my WH0290 (now apparently sold as WH43, the sensor half of W41) reported pm10 = pm2.5 +1 for low values, and then +2 for higher ones, and so on for various breakpoints. It was very clear that it didn't have a PM10 sensor, and on digging the honeywell sensor inside has a PM10 field but (now fuzzy memory) more or less said it wasn't an actual measurement. If you plot a dot for each measurement with pm2.5 on x and pm10 on y, it should be immediately clear if there are two legit measurements vs something inside doing math. (There is no actual relationship between pm2.5 and pm10; the difference is the mass of particles > 2.5 um and <= 10 um, modulo fencepost errors. There is a general trend of what tends to happen, but that's a characterization of typical pollution.)

And I don't meant to sound griping - it's great that you have done this. I earlier decided not to buy a WH45 because it didn't have an rtl_433 decoder.

[anthyz]

Here's a plot of PM2.5/PM10 values from my WH45:

@gdt I read your comments in fineoffset.c regarding the PM sensor in the WH41 and the simplistic calculation that produces a PM10 value from a PM2.5 measurement. I see that the WH41 uses a Honeywell HPMA115S0-XXX sensor and although the datasheet specifies it outputs PM2.5 and PM10 values, accuracy is only specified for PM2.5 values.

From comments here I determined that the WH45 uses a Sensirion SPS30 sensor for the PM2.5/PM10 and a Sensirion SCD30 for CO2.

I read over the SPS30 datasheet and a sensor specification statement here:

https://sensirion.com/media/documents/8600FF88/616542B5/Sensirion_PM_Sensors_Datasheet_SPS30.pdf
https://sensirion.com/media/documents/B7AAA101/61653FB8/Sensirion_Particulate_Matter_AppNotes_Specification_Statement.pdf

The sensor specification statement is very interesting and does spell out that PM10 values are estimated from distribution profiles of PM0.5, PM1.0, and PM2.5 measurements. Unlike the Honeywell sensor, a range of accuracy for PM10 values is specified in the datasheet.

In short, it seems that PM10 values are estimated to a degree of accuracy considered acceptable by Fine Offset for reporting.

I'll add comments to document this.

[gdt]

Very interesting information. It woudl be great to add comments about all of that.

In short, it seems that PM10 values are estimated to a degree of accuracy considered acceptable by Fine Offset for reporting.

Considered acceptable by their marketing department :-) It's too bad that if the sensor is PM0.5, PM1, PM2.5 really, that those aren't exposed. It just doesn't make sense to be able to measure PM10 from those three sensors. Sure, one can guess, based on probability distritbutions of pollution. I don't think it's ok to label it PM10 if it isn't actually a PM10 measurement (I'll try to read the entire thread and datasheets and maybe write to ecowitt support in the next couple of days)., and the estimated_ prefix was the consensus approach for a measurement that isn't really what it says.

[gdt]

Sensiron says "Therefore, the PM4.0 and PM10 outputs of Sensirion’s PM sensors are estimated from PM0.5, PM1.0 and
PM2.5 measurements considering typical aerosol profiles instead of being based on “real” raw data events from
large particles." It's interesting that they use the very same word that we chose. I know someone who may have a clue about the science and will ask them.

[gdt]

Can you plot a whole day or more, with the PM2.5 on x axis, PM10 on y, no time at all? That does look different from the WH41/43/0290.

[anthyz]

A scatter plot of 24 hours of data as requested (PM2.5 on x axis, PM10 on y).

[gdt]

Interesting - thank you for making the plot. We can think of this as "PM10-PM2.5", the weight of the particles in PM10 but not in PM2.5 vs PM2.5. Unlike the WH41, this is showing a variety of values for a given PM2.5 value. I have posted a query to a nerd friend about this.

I would like to soften and mostly withdraw my request about alignment with the WH41. It's really a different sensor so there is much less of an expectation of similarity. I'll try to go over the differences soon.

If you're comfortable rebasing and force-pushing after adding comments, that seems good but I don't know the rtl_433 norms. If not don't worry as I'm 95% sure I could check a "squash" button when merging.

[gdt]

Here are scatter plots from a WH41 for comparison. I have plotted PM10-PM2.5 against PM2.5. One is more zoomed in. This is actually over 10K points, almost two months of data (outside). You can see that there is only one 10/2.5 difference value for a given 2.5 value, and there are clear breakpoints. (These are made with xplot, a very old-school plotting program that was way cool in 1990 and was lean enough to run snappily on uVax III.)

plot1.pdf
plot2.pdf

[JaraLowell]

Messing with js and node for my frogit

[zuckschwerdt]

Neat! You might want to look at our http UI (-F http) and the API (RPC /ReST /WS): https://github.com/merbanan/rtl_433/blob/master/src/http_server.c

[anthyz]

@gdt The WH41 plots look positively unnatural. No wonder there's no claim of accuracy. :-) Thanks for all the feedback and starting me on the sensors deep dive. Interesting stuff!

@JaraLowell Very cool!

[gdt]

Thanks for your patience with my requests. I have squashed the 4 commits together and placed the resulting commit on master, essentially merging this PR from the command line. Please check that I didn't lose anything. While this PR probably shows "CLOSED", logically it is "MERGED".

[zuckschwerdt]

Commit message, attribution, all good, thanks!

(there should be a hidden squash option in the PR button)

[gdt]

Thanks, found the secret button. (In unison, I ask that contributors rebase and organize and then don't squash, so I haven't figured that out in the github UI.)

[zuckschwerdt]

In my experience the Git rebase and squash workflow isn't familiar to many contributors. (which is totally fine for one-off code submissions.) And the commit messages need a little fine tuning always ;) https://triq.org/rtl_433/CONTRIBUTING.html
That way "Squash and merge" seems to be my default here.

Just please no "merge commits", if it's not fast-forward (rebase) then I'd like a person to effect changes, not some "mostly ok diff algorithm" :)

[anthyz]

@zuckschwerdt @gdt I just realized I really wanted the ID field to be a string in order to keep the id value in the mqtt topic to match the on-device label. Also, who normally adds the new protocol line to rtl_433.example.conf? Another PR?

[zuckschwerdt]

wanted the ID field to be a string

We are quite torn on that, the consensus so far is to keep numbers as numbers and let the consumer apply formatting.
I get the issue with MQTT though.

who normally adds the new protocol line to rtl_433.example.conf? Another PR?

Same PR usually, but that's not a requirement. It's simply a ./maintainer_update.py and done. I'll just do that now.

[anthyz]

Okay, I get it. It's a bummer that formatting can't be specified for MQTT topic elements, but I can work around it. Thanks.