Oregon Scientific THGR810 and unwise sanity validation

[Steven-Jones911]

This sensor is ignoring data when RTL_433 thinks its sanity is questionable. This seems wrong to me.

The sensor trigger causing the failure to record is high humidity, but it could equally be temperature because of the test at line 660 of oregon_scientific.c:

if (temp_c > 70 || temp_c < -50 || humidity < 0 || humidity > 98) {

This is some arbitrary sanity check that has no validity regarding the sensor:

Humidity range 5% to 95% Humidity resolution 1% Temp. unit ºC (ºF) Temp. outdoor range 30ºC (22ºF) to 60ºC (140ºF) Temp. resolution 0.1ºC (0.2ºF)

(Taken from THGR810_THGN810.pdf )

As tested using an Arduino to capture the signal, this sensor will actually send all the way up to 99% but this will be displayed on the console of the Oregon Scientific WMR86N? as HH or indeed, if below 5% as LL, but it will still send 4%, for example.

Last week we had humidity of 100% reported at my local Bureau of Meteorology site not more than 3 kilometres away. 100% is valid. 99% is valid. Hell, 101% is valid! When this happens, this sensor stops sending.

OK, so here's my points:

POINT 1:

Humidity can be greater than 99%, so picking an arbitrary value of 98% for this sensor when its limit is stated as 95% is wrong.

POINT 2:

Because that high humidity is valid, and because this sensor cannot report 100% (but can report 99%), the program blocks sending the temperature. This is wrong.

SUMMARY:

I don't think it is prudent to perform sanity checks on the sensors providing weather information. This should be done by the end user of the data, not the source.

RESOLUTION:

Remove this check.

[zuckschwerdt]

Those check were a whole batch of fixes with #2086.

We need to establish:

• Does THN132N possibly report temperature > 70, < -50?
• Does THGR81, THGR810a possibly report temperature > 70, < -50?
• Does THGR81, THGR810a possibly report humidity < 0, humidity > 99? (99 already confirmed now)
• Does WGR800 WGR800a possibly report gust windspeed < 0, > 56,| avg windspeed < 0, > 56
• Does WGR800 WGR800a possibly report quadrant < 0, > 337.5 (e.g. as error codes)

[Steven-Jones911]

You're not going to see temperatures on planet earth of 70 deg. You might get this temperature if you boiled the thermometer but I think it won't send anymore... :-)

This is a slippery slope of validating data. You might find, for example, that another THGR810 cannot send more than 98% humidity. Why? Because the manufacturer only rates it as the range 5% to 95% with a guaranteed error rate +/-. Once it exceeds these limits, its own display consoles only display HH or LL.

It is totally up to yourselves what to do in these circumstance, but my suggestion would be, if you really want to validate the sensors, then use the DATA_COND state to just not send the "bad" reading, rather than disabling the entire sensor.

WGR800

I still have that sensor on a pole, and I know from past usage it never exceeded around 30 m/s. Ever. I have validation software running off an Arduino that reports these if they occur. It has been used for years. But, is it possible? Who knows? A bad sensor, perhaps? I do know it has sent wrong readings.

Does WGR800 WGR800a possibly report quadrant < 0, > 337.5 (e.g. as error codes)

Looking at my Arduino code, it's byte [4 ] >> 4, so no, it's only ever going to send 0 to 15.

I think validation should be left to the sink of this data. Problem solved.

[zuckschwerdt]

Yes. As a general policy rtl_433 tries to never limit the values with checks unless it's really needed to verify transmission integrity. We should get rid of those checks unless we get false positive otherwise.

Extreme values might be a valueable error code or give more insight to the sensor state than just valid readings.

[Steven-Jones911]

Great job, thank you for that!

I agree, extreme values might give an insight into the sensor state. More often than not, in my experience, they often just fail outright; especially these cheap sensors. YMMV.

But, once again, thank you for your work!