Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

915MHz FSK weather station reports incorrect rain values #1951

Closed
lachesis opened this issue May 24, 2024 · 4 comments
Closed

915MHz FSK weather station reports incorrect rain values #1951

lachesis opened this issue May 24, 2024 · 4 comments

Comments

@lachesis
Copy link

Describe the bug
My weather station reports rain_mm = 4472.1001 in typical rtl_433, tested with two different receivers. When using OpenMQTTGateway, it instead reports rain_mm = 3786.378.

The weather station uses this decoder in rtl_433:

[78]  Fine Offset Electronics, WH25, WH32B, WH24, WH65B, HP1000 Temperature/Humidity/Pressure Sensor

To Reproduce
Steps to reproduce the behavior:

  1. Use weather station Fineoffset WH25.
  2. Compare results of OpenMQTTGateway with rtl_433.
  3. Optionally, wait for rain and compare to real measurement. 😆

Expected behavior
I expect rain_mm to parse identically between both rtl_433 and OpenMQTTGateway. I also expect it to go up by 1 for each mm of rain we receive.

Screenshots
N/A

Environment (please complete the following information):

  • OpenMQTTGateway version from git hash 743083c

Additional context
Sorta related, see issue #1616.

  • You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation
    Build Status
  • If you are not sure this is a bug or an enhancement post your question to the forum below
    Community forum
@lachesis
Copy link
Author

Reading the rtl_433_ESP code, especially this line:
https://github.com/NorthernMan54/rtl_433_ESP/blob/main/src/rtl_433/devices/fineoffset.c#L254

This error is consistent with rtl_433 and rtl_433_ESP coming to different conclusions about type == MODEL_WH24. In particular, if the standard rtl_433 (on Linux) believes that I have a WH24, but the rtl_433_ESP thinks that I have a WH65B, this error would occur.

$ calc 4472.1001  / .3 * 0.254
3786.3781

One would also expect this to affect the wind speed, which it very well may, but which I did not notice.

My weather station bills itself as Ambient Weather WS-2902.

Further testing is required, but maybe this bug should be opened against rtl_433_ESP instead of this project.

@lachesis
Copy link
Author

Oh! It looks like typical rtl_433 is the one that is incorrect. According to the screen that came with the weather station, this machine has accumulated 149.1 inches of rainfall, which is 3787.14mm. I will go ahead and close this now, while I investigate what is wrong with my standard rtl_433.

@DigiH
Copy link
Collaborator

DigiH commented May 24, 2024

Hi @lachesis

Saw that you already closed this issue just when I wanted to tell you that your Ambient Weather WS-2902 is actually a rebranded Fineoffset WH65B ;)

Might help to have a look at
merbanan/rtl_433#844

@lachesis
Copy link
Author

lachesis commented May 24, 2024

Thank you for the reply. merbanan/rtl_433#1220 seems related as well. In fact, the heuristic to detect WH24 vs WH65B seems unreliable. My OpenMQTTGateway device detects both WH24 and WH65B, while two of my rtl_433 Linux machines reliably detect WH24 and the third reliably detects WH65B. I've gone ahead and added a little hack to my MQTT -> statsd translation layer that will correct for the changes in rainfall and wind speed. Unless the author of rtl_433 has any more feedback (unlikely IMO), I'll go ahead and run with this as it stands today.

In particular, the heuristic seems very sensitive to center frequency. I can cause one of my rtl_433 machines to change between WH24 and WH65B by moving the center frequency by about 50 Hz. I would guess that none of the clocks involved are very high quality, so the transmitter frequency may well drift based on temperature, insolation, or battery state of the sensor, and the receiver frequency of the OpenMQTTGateway device may drift due to temperature as well.

This also matches the issue I linked above, where the author reported that the issue began occurring after they changed the battery of the sensor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants