WH0290 minor improvement suggestion

[gdt]

@harpchad @peteakalad Thanks for your WH0290 work.

Minor suggestions:

• b[0] is not checked or printed. It seems like it is family and is supposed to be 0x8d. I would think that either it should be printed, or it should be checked and fail the match if not, but I may be missing something. (In general I am a fan of for every bit, either insist it have some value to match, or if not decode it, even if it's just putting the bit in an unknown field.)
• The upper bit of battery MSB is not checked or printed. Would suggest "ub1".
• The bitbench example shows "Bat_MSB:1d Bat_LSB:2d" but that is 110 or 6 which is 1.2, and that seems odd and not matching what is supposed to be.
• Something seems strange with the "PM10" field. In my data (only a bit so far), it seems that PM10 = PM2.5 +1, and I see that in the examples. I wonder if that's another form of coding and not PM10, or if people are seeing different values. I don't have a crisp suggestion for figuring this out.

[zuckschwerdt]

S.a. #1068 #1069 #1617

Yes, the family code is likely important and should be checked. With other FineOffset protocols that code is fixed and likely the message needs to be decoded another way if it differs. The examples show it as 0x42 or 0x41 though?

Not sure about the unknown bit, it's 0 in the examples, right? Perhaps best to output and track it for some time to be sure.

We had ideas about letting users known that developers are interested in some things. Either a debug output along the lines of "this state is unexpected, please let the developers know", but who reads logs and where/how to report?
Another idea would be to offer a way for users to "donate" their bitbuffers with an opt-in to upload them -- not sure if users might find that intrusive? (Maybe make the opt-in very explicit by requiring an API token?) It would help with the recurring question to please collect and paste a good number of codes to find a checksum algorithm. And here users could donate their PM readings to verify your finding. Comments on this?

[peterchs]

On last two points;

• yes battery isnt carried in the ub1 its only the first least sig bit of that byte thats used. The 3 bits that represent the battery bars at runtime for my device have only been seen with a max of 5 tallying with the number of bars shown on the receiver. I see what you mean if I put through the other original commented bits here:
  

  rtl_433/src/devices/fineoffset.c

  Line 338 in dc25708

  aa 2d d4 42 cc 41 9a 41 ae c1 99 9

  
  When put through bitbench this has value of 6 - I'd missed this before. For my family code 0x41 device the code at the moment isnt ever showing 6 bars / 1.2 battery_ok. Presumably the family code 0x42 devices indicate battery in a different way. I dont have one of those to work out how it differs. Do you have one of these devices, which family code/brand is it?
  If we can work out how it differs, then the battery bars bit extraction code here could be switched based on the family code?
  

  rtl_433/src/devices/fineoffset.c

  Line 390 in dc25708

  int battery_bars = (b[2] & 0x40) >> 4 | (b[4] & 0xC0) >> 6; //out of 5

  
  Not following where you see a family code of 0x8d, only see 0x41 and 0x42 from the example packets in the comments put in bitbench.

• My device (Misol brand / family 0x41) has the same behaviour regarding the PM10 value being the PM2.5 value + 1. I just assumed the other branded devices which the original code was created against had an additional PM10 sensor which mine doesnt. I only use the PM2.5 value.

[gdt]

Yes, the family code is likely important and should be checked. With other FineOffset protocols that code is fixed and likely the message needs to be decoded another way if it differs. The examples show it as 0x42 or 0x41 though?

I was misinterpreting the bitbench format string as data. Now I get it.

Not sure about the unknown bit, it's 0 in the examples, right? Perhaps best to output and track it for some time to be sure.

That's what I was thinking. Choose one of 1) always add it to output 2) add it if value is not the expected 0 or 3) fail the decode if it is not zero. I lean to 2 for things that have always been observed to be zeor, and 1 for things that have been multiple ways.

We had ideas about letting users known that developers are interested in some things. Either a debug output along the lines of "this state is unexpected, please let the developers know", but who reads logs and where/how to report?
Another idea would be to offer a way for users to "donate" their bitbuffers with an opt-in to upload them -- not sure if users might find that intrusive? (Maybe make the opt-in very explicit by requiring an API token?) It would help with the recurring question to please collect and paste a good number of codes to find a checksum algorithm. And here users could donate their PM readings to verify your finding. Comments on this?

I am basically opposed to anything that has the capacity to upload in rtl_433. There could be a rtl433_public_uploader.py that is like the mqtt but uploads instead; then it's really clear what it does and also really clear that if you don't run it the main program won't do this. For sensors inside a house, it's definitely intrusive (although some might be ok with that) -- cooking breakfast had a really obvious signature in PM2.5 with the monitor in the room. Some people wouldn't want to publish ids. For a new device, I'd want to grep out just that device, look over the data, and then choose to publish it. Right now people can save json or whatever and then upload it manually.

[gdt]

I was confused about the "6"; I was reading the bitbench format string as if it were decoded data. I don't even know what my family code is, but I'll add that to the decode and see.

* My device (Misol brand / family 0x41) has the same behaviour regarding the PM10 value being the PM2.5 value + 1.  I just assumed the other branded devices which the original code was created against had an additional PM10 sensor which mine doesnt.  I only use the PM2.5 value.

I have more data now. Usually PM10 is +1, but I also saw a 28/30 pair. Looking at data from (regional) proper instruments, it seems PM10 is usually a fair bit higher than PM2.5.

I also have an adafruit sensor that in theory does PM2.5 and PM10 and I should hook it up and compare.

I'll make a change to log what I think needs logging and submit a PR when content and you can respond to an actual proposal that's been sanity-checked rather than confusion :-)

[peterchs]

Yes I had a look back through my data, and the PM10 isnt always +1, as you note it seems at higher values its more than +1, e.g. the max over the time I've recorded is a 162μg/m³ PM2.5 with a 165μg/m³ PM10, so +3. Then at lower values approx. above 50 it goes up to +2, then +3 above 110. PM10 does look to be derived from the PM2.5 value.

On the battery level if you have new batteries do let us know or try a PR if the battery_ok does end up > 1.0, as suspected above decoder may need a change to support battery level for the 0x42 family devices.

[gdt]

So I guess the working theory is that the field we are decoding as PM10 isn't PM10.

I don't have an ecowitt display or GW1000, but I wonder if there has been a correlation of the PM2.5 field and a manufacturer display? AQI seems tricky as there seem to be multiple standards; the US one was revised in 2012.

[gdt]

Wrapping up:

• I'm seeing only 1.0 for battery with freshly-charged batteries. I'll speak up if I see something odd.
• I submitted a PR fineoffset WH0290 minor improvements #1639 that makes little changes.
• I opened FineOffset WH0290: PM10 is apparently not really PM10 #1640 about the PM2.5/PM10 correspondence which is the only bit of this issue that remains useful if my PR is merged.

[merbanan]

I am basically opposed to anything that has the capacity to upload in rtl_433.

Well MQTT sort of has that capacity. Anyway I think we agree on the principle that it is the user who decides how the data is processed. My point and I think @zuckschwerdt's also is that we want to make it easy for everyone to get access to enough relevant data to be able to figure out some signals. For example there has been instances where we needed 10k messages to figure out the crc. Reducing work around how to collect raw messages will benefit everyone.

@zuckschwerdt maybe we should collect the raw bitbuffer in new decoders under an option? Sort of what is done in the wmbus decoder. At least in decoders with lots of unknowns.

[gdt]

Sounds good. I was just trying to make the point that it's not just the user choosing, but not having easy ways to upload when you didn't really mean to. With mqtt, if there's no broker configured, it's not going to happen by accident.

[zuckschwerdt]

Maybe a switch to produce an extended bitbuffer log, i.e. if a selected decoder accepts a message the whole bitbuffer input gets logged. The user can then review the log an get it to us. It would be nice to automate this somewhat, maybe I can add accounts to BitBench someday, so users can maintain annotated list of some data there and share that with a short link to interested people, by private mail, or post it publicly.

[peterchs]

So I guess the working theory is that the field we are decoding as PM10 isn't PM10.

I don't have an ecowitt display or GW1000, but I wonder if there has been a correlation of the PM2.5 field and a manufacturer display? AQI seems tricky as there seem to be multiple standards; the US one was revised in 2012.

Yes I'm thinking for 0x41 family devices (Ecowitt & Misol then) since the sensor doesnt support PM10 it fakes/derives it from the PM2.5. The PM2.5 decoded values do tally with my Misol receiver - no changes were needed for this, the original implemenation for 0x42 family device worked. No PM10 reading on the Misol receiver to verify it.

For AQI I've used this library in node-red to convert PM2.5 to AQI - it outputs AQI the as the same as the receiver, and also includes health advice / warnings / categories I can include in my notifications which is nice.
https://github.com/ThangLeQuoc/aqi-bot

Also thanks for confirming no issues with the battery decoding.

[gdt]

Glad to hear that you have checked PM2.5 ug/m^3 against a vendor display. That library looks great and spot checking what I just read from EPA matches.

The strange thing is that the sensor in the WH41 does actually support PM10 but for some reason it isn't apparently transmitted. Arguably PM2.5 is a bigger deal for health, though.

Is there a basis for believing the 2nd 14-bit field is supposed to be PM10?

[peterchs]

I don't have any evidence that the 2nd 14bit field actually is PM10 since the Misol receiver doesnt show PM10 and I've no other AQ meter to compare the values to. But presumably @harpchad confirmed the PM10 decoding with whichever device/receiver he had when the original decoder was written.