Is Fine Offset WS69 weather station supported?

[mcmlxxvii]

I see that there's a registering protocol [213] already in place for "Fine Offset Electronics WS80 weather station" and [113] for "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge, WS68 weather station", so I'm wondering: Is Ecowitt WS69 also supported by rtl_433?

If yes, which rtl_433 protocol ID should I use?

If not, are there any plans to support it in the near future?

Thanks!

[zuckschwerdt]

Support for the WS69 was asked before but I don't know if anyone took a look at it. It should be very similar to others we already support.
https://groups.google.com/g/rtl_433/c/aFjgg-4kdJ8/m/OjCaIrg6AAAJ

[tomburke25]

Mine seems to identify as a WH65B (so -R 78)

I've only just starting messing with it, but sensor data seems to be correct

[neillbell]

I was looking at the WS69 today, so it's surprising to find that you posted about this just last week.
Were you able to make any progress?

[kbahey]

@tomburke25

So all the sensor values show up (rain, wind, solar, ...etc.)?

[sillyfrog]

I have a LILYGO® TTGO LoRa32 V2.1_1.6 board, running OpenMQTTGateway, I used the pre-built lilygo-rtl_433-fsk image - (note: After flashing, I had to set the frequency to 433.920 MHz in the web UI, as this didn't happen by default).

I have the Ecowitt WS80, and the Ecowitt WS69, and both "just work" with the above MQTT Gateway. I did not have to do anything to configure the weather station once MQTT was setup to get the data into Home Assistant, all the discovery MQTT events were sent and the data started coming in.

Sample MQTT event from the WS80:

.../RTL_433toMQTT/Fineoffset-WS80/31759	{"model":"Fineoffset-WS80","id":31759,"battery_ok":1.11,"battery_mV":3180,"temperature_C":19.7,"humidity":46,"wind_dir_deg":298,"wind_avg_m_s":3,"wind_max_m_s":3.4,"uvi":4,"light_lux":63680,"flags":162,"mic":"CRC","protocol":"Fine Offset Electronics WS80 weather station","rssi":-70,"duration":11001}

Sample MQTT event from the WS69:

.../Fineoffset-WH65B/211	{"model":"Fineoffset-WH65B","id":211,"battery_ok":1,"temperature_C":19.4,"humidity":47,"wind_dir_deg":249,"wind_avg_m_s":0,"wind_max_m_s":0,"rain_mm":326.136,"uv":2162,"uvi":5,"light_lux":74250,"mic":"CRC","protocol":"Fine Offset Electronics, WH25, WH32B, WH24, WH65B, HP1000, Misol WS2320 Temperature/Humidity/Pressure Sensor","rssi":-79,"duration":11000}

Sample data in Home Assistant (note the wind speed is zero because the spinny things are not currently connected as I'm about to mount it in it's real location, but it does work).

[neillbell]

Thanks for letting us know!

[kbahey]

Thanks indeed for a comprehensive reply ...

[sillyfrog]

I'm considering getting hardware to use this library as well, and have a WS69. I have a HP2560_C display, and it says the sensor is a WH65/69 - so I'm hoping that the WH65 that's already supported will just work as @tomburke25 suggests if even their own hardware treats them as the same thing.

[BombusAlpinus]

i recently switched from a bresser clearview to an ecowitt ws3900/ws69 and i'm not able to receive data from this external unit.
i'm running an nooelec usb dongle and rtl-433 25.02 which works fine with the clearview (-f 868M -R 172) but not with the ws69/wh65b. i tried it without any protocol definition and also with the suggested protocol 78. any ideas? thanks!

this is the output when both units are "sending":

rtl_433 -f 868M 
rtl_433 version 25.02 (2025-02-19) inputs file rtl_tcp RTL-SDR SoapySDR

New defaults active, use "-Y classic -s 250k" if you need the old defaults

Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
Allocating 15 zero-copy buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-12-08 09:08:13
model     : Bresser-7in1 id        : 44008
Temperature: 9.0 C       Humidity  : 99            Wind Gust : 0.0 m/s       Wind Speed: 0.0 m/s       Direction : 222           Rain      : 0.0 mm
Light     : 3.052 klx    Light     : 3052.000 lux  UV Index  : 0.0           Battery   : 1             Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

[zuckschwerdt]

Try https://triq.org/rtl_433/ANALYZE.html to get data packets. Check with https://triq.org/pdv3/ and upload a good sample file as zip here if the packet is complete and not clipping (red bars) much, but still not recognized.

[BombusAlpinus]

@zuckschwerdt thanks for your fast reply. i'm by far not a radio technican ;) but i will have a look at it.

[BombusAlpinus]

@zuckschwerdt
ok, don't know if this data packet is a good one, got about 130 packets stored ... maybe you can point me in the right direction then.
g130_868.3M_1000k.cu8.zip

[zuckschwerdt]

The 100µs signal seems boring, mostly the same two codes alternating: {72}f35fecb19d57ae909f and {72}f254d7db0c07ce304c

The 58µs codes are good, 25 bytes with two checksums at the end: add_bytes(b, 24) == b[24]; and crc8(b, 23, 0x31, 0x30) == 0;
You can now put those codes in a BitBench and try to find the value fields, e.g. try to find the value that changes with temperature.

[BombusAlpinus]

ok, thanks for your help. but i have no clue what to do. as already mentioned i'm by far no radio technican...
but i tried it with gemini:

Daten-Set B: Langzeitvergleich (8 Stunden)

**Rohdaten-Pakete für diesen 8-Stunden-Vergleich (`pak2.txt`):**

* [cite_start]**Paket A (Start: 2025-12-10 16:43:16):** `241c5981b06305010033000000000f1ddf80ffffff8017e73c80` [cite: 75959]
* [cite_start]**Paket B (Ende: 2025-12-11 00:42:43):** `241c4d018a63020000330000000000a95901ffffff002f17f60` [cite: 74759]

**Beobachtete Änderungen in den Feldern über 8 Stunden:**

| Byte-Index | Feld | Start-Hex | Ende-Hex | Änderung (Δ) | Bemerkung |
| :---: | :--- | :--- | :--- | :--- | :--- |
| **02 - 03** | **Rolling Code/ID** | `5981` | `4d01` | Stark | Erwartet über lange Zeit |
| **04 - 05** | **Temperatur** | `b063` | `8a63` | Stark | Erwartete Abkühlung über Nacht |
| **06 - 07** | **Wind** | `0501` | `0200` | Stark | Erwartet über lange Zeit |
| **09** | **Konstanter Wert?** | `33` | `33` | Keine | **Bemerkung:** In Set A war dieser Byte 09: `34`. Hier ist er `33`. |
| **13 - 16** | **Wind/Regen** | `0f1ddf80` | `00a95901` | Stark | Erwartet |
| **20** | **Regen/Flags** | `80` | `00` | Stark | Regen war 0.0 mm in Set A. |

[zuckschwerdt]

Ok, I'll take a look then.

[zuckschwerdt]

Ah nice, the Fine Offset / Ecowitt WS69 is basically the WH65B plus 8 bytes extra data. Support added with #3426

[kbahey]

Thanks @zuckschwerdt

But I am now confused ...

@sillyfrog reported the WS69 working (per this comment), yet @zuckschwerdt had to add code for the same model to work?

OpenMQTTGateway is based on rtl_433, and should not have independent code for each device.

What am I missing?

[zuckschwerdt]

If the reception is bad enough and packets are truncated then WH65B will work for WS69. But nominal the WS69 packets (260 bits) are too long and the WH65B decoder will reject them (> 215).

[zuckschwerdt]

It is possible that @BombusAlpinus's WS69 is a newer model though and that older WS69 have shorter packets.
@kbahey or @sillyfrog do you have an older WS69? Can you upload a zipped .cu8 of that?

[kbahey]

Thanks for elaborating on this ...

No, I don't have a WS69.

I have a Vevor that does some odd things (every week or two, excessive values are reported for various sensors, such as Lux, humidity, rainfall, ...etc.)
So I was considering a WS69 to replace the Vevor.
However, for the time being, I worked around these values.
If they continue to be annoying, I will consider a WS69 again.