Device Support - Ecowitt WS85

[Vertikar]

I've recently purchased the WS85 and have got stuck trying to decode the codes.

The WS85 is very similar to the WS90, except it doesn't have temperature and humidity

I don't currently have a way of verifying the data, but I have an Ecowitt gateway on the way, which I'm hoping will help with this.

I've skipped over the CRC checks for now as I couldn't get my head around that, but the WS90 decoder is able to grab the codes and it looks like the preamble, and sync are the same, as I can see the device type 85 showing up as per the below. I've taken the existing ws90 decoder and just renamed all the functions, and changed the type so the decoder accepts it.

As below all the values are all over the place, the supercap shouldn't be changing voltage that much, the battery voltage looks off, and the light level is completely off for night time, so it looks like the packet layout is quite different to the WS90.

command for testing: _rtl_433/build/src/rtl_433 -vv -R 261:vvv -M level -Y minmax -X 'n=Test,m=FSKPCM,s=58,l=58,r=2048,preamble=aa2dd4'

``` [Test] codes : {260}85002b229ea2030003093fffd4cc8202265e6f578c17d2fa006bd077000000000 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2024-07-16 10:57:01 model : Test count : 1 num_rows : 1 rows : len : 260 data : 85002b229ea2030003093fffd4cc8202265e6f578c17d2fa006bd077000000000 codes : {260}85002b229ea2030003093fffd4cc8202265e6f578c17d2fa006bd077000000000 Modulation: FSK Freq1 : 433.9 MHz Freq2 : 434.0 MHz RSSI : -0.1 dB SNR : 18.1 dB Noise : -18.2 dB [pulse_slicer_pcm] General purpose decoder 'Test' codes : {260}85002b229ea2030003093fffd4cc8202265e6f578c17d2fa006bd077000000000 [pulse_slicer_pcm] Exact bit width (in us) is 58.10 vs 56.00, 40 bit preamble [pulse_slicer_pcm] Exact bit width (in us) is 58.31 vs 56.00, 52 bit preamble [fineoffset_ws85_decode] WS85 detected, buffer is 336 bits length [fineoffset_ws85_decode] Checksum error: b8 50 (50) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2024-07-16 22:14:26 model : Fineoffset-WS85 ID : 002b22 Battery : 1.000 Battery Voltage: 4600 mV Temperature: -40.0 C Humidity : 0 % Wind direction: 255 Wind speed: 6.3 m/s Gust speed: 4.8 m/s UVI : 0.0 Light : 413450.0 lux Flags : 00 Total Rain: 14.4 mm Supercap Voltage: 5.5 V Firmware Version: 0 Extra Data: 1400006308------ae00016b685000 Integrity : CRC Modulation: FSK Freq1 : 433.9 MHz Freq2 : 433.9 MHz RSSI : -0.1 dB SNR : 18.1 dB Noise : -18.2 dB [pulse_slicer_pcm] Fine Offset Electronics WS85 weather station codes : {336}aaaaaaaaaaaaa8b7521400ac8a860798000000fffcc0005000018c200241deb80005ada1400000000000 [Test] codes : {256}85002b22a181e60000003fff30001400006308009077ae00016b685000000000 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2024-07-16 22:14:26 model : Test count : 1 num_rows : 1 rows : len : 256 data : 85002b22a181e60000003fff30001400006308009077ae00016b685000000000 codes : {256}85002b22a181e60000003fff30001400006308009077ae00016b685000000000 Modulation: FSK Freq1 : 433.9 MHz Freq2 : 433.9 MHz RSSI : -0.1 dB SNR : 18.1 dB Noise : -18.2 dB [pulse_slicer_pcm] General purpose decoder 'Test' codes : {256}85002b22a181e60000003fff30001400006308009077ae00016b685000000000 [pulse_slicer_pcm] Exact bit width (in us) is 58.31 vs 56.00, 52 bit preamble [fineoffset_ws85_decode] WS85 detected, buffer is 336 bits length [fineoffset_ws85_decode] Checksum error: 71 ec (ec) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2024-07-16 22:14:34 model : Fineoffset-WS85 ID : 002b22 Battery : 1.000 Battery Voltage: 4600 mV Temperature: -40.0 C Humidity : 0 % Wind direction: 255 Wind speed: 6.3 m/s Gust speed: 4.8 m/s UVI : 0.0 Light : 413450.0 lux Flags : 00 Total Rain: 14.4 mm Supercap Voltage: 3.9 V Firmware Version: 0 Extra Data: 1400006308------ae00016b14ec00 Integrity : CRC Modulation: FSK Freq1 : 433.9 MHz Freq2 : 434.0 MHz RSSI : -0.1 dB SNR : 17.4 dB Noise : -17.5 dB [pulse_slicer_pcm] Fine Offset Electronics WS85 weather station codes : {336}aaaaaaaaaaaaa8b7521400ac8a860798000000fffcc0005000018c2002419eb80005ac53b00000000000 [Test] codes : {258}85002b22a181e60000003fff30001400006308009067ae00016b14ec000000000 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2024-07-16 22:14:34 model : Test count : 1 num_rows : 1 rows : len : 258 data : 85002b22a181e60000003fff30001400006308009067ae00016b14ec000000000 codes : {258}85002b22a181e60000003fff30001400006308009067ae00016b14ec000000000 Modulation: FSK Freq1 : 433.9 MHz Freq2 : 434.0 MHz RSSI : -0.1 dB SNR : 17.4 dB Noise : -17.5 dB [pulse_slicer_pcm] General purpose decoder 'Test' codes : {258}85002b22a181e60000003fff30001400006308009067ae00016b14ec000000000 ``` I've started to try and map some of the codes in an excel spreadsheet and bitbench, but haven't had much progress and also lost my bitbench after a browser restart. Here's some of the codes I've picked up during rain and after some rain  Although the packet layout is different, I can see that bytes 10 and 11 appear to be fixed at 3f ff, which is similar to the WS90 having the same fixed bytes at 14 and 15. Happy to drop what data I've collected so far somewhere if that's helpful, or switch on some logging.

[ProfBoc75]

Hi @Vertikar:

My findings:

 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
YY II II II BB 55 66 77 88 99 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ZZ XX AA 00 00 00 ...
85 00 2b 22 a1 81 e6 00 00 00 3f ff 30 00 14 00 00 63 08 00 90 77 ae 00 01 6b 68 50 00 00 00 00
85 00 2b 22 a1 81 e6 00 00 00 3f ff 30 00 14 00 00 63 08 00 90 67 ae 00 01 6b 14 ec 00 00 00 00 0
85 00 2b 22 9e a2 03 00 03 09 3f ff d4 cc 82 02 26 5e 6f 57 8c 17 d2 fa 00 6b d0 77 00 00 00 00 0

• BB Position 4 looks like battery level, slowly decreasing 0xa1 (=161 x 0.02 V = 3.22 V), 0xa0, 0x9f, 0x9e, 0x9a (=3.08 V), aligned with 2xAA, starting around 3.2 V with brand new batteries (2*1.6 V) .

• ZZ Position 25 is firmware version, 0x6b = 107 = version 1.0.7 , the version 1.0.8 is available on the ecowitt web site.

• XX Position 26, this is the CRC-8, crc8(b, 26, 0x31, 0x00) as others Fine Offset but before the checksum

• AA Position 27, this is the checksum, add_bytes(b,27), so CRC & CHECKSUM position have been swapped compare to other Fine Offset/Ecowitt sensors WS80/WS90.

The WS85 doesn't report UV Index nor LUX, only the Rainfall, Wind speed and Wind direction, and probably Wind Gust.

The other values, you must play with a cloth to put over the sensor to stop any wind in order to identify the wind byte position. Depends how you will put the cloth, you can let 2 openings (in/out) to force wind direction and then identify the wind direction byte(s) and bytes position. And step by step you should be able to find the data layout.

Waiting for your gateway to confirm that.

[Vertikar]

Great, thanks for your help @ProfBoc75! Will do some further testing as you suggested once I've got the gateway.

[cmlburnett]

What I've been able to discern without a gateway:

• byte 0 is model number
• bytes 1-3 are the serial number
• byte 4 is the battery
• byte 5 is the capacitor (rises with light, falls with dark)
• byte 7 is wind speed
• byte 8 is wind direction
• byte 9 is wind gust

I don't know what byte 6 is. Byte 9 always is equal or larger than 7, so I think it represents gust. Assuming 0xFF is max wind speed (40 m/s per spec sheet) and linear then each bit is 0.157 m/s. Additionally, bytes 7 and 9 are zero when covered.

The direction is peculiar. It doesn't appear to be in degrees. Blowing in the four cardinal and four ordinal directions, it looks like the least significant bit is one for the easterly half and zero for westerly half, and the upper seven bits are from north to south with zero being wind out of the north. In hindsight, I didn't include byte 6 when speculating about the wind direction byte, possible a few bits are used to cover a range of 360 to interpret it as integer degrees.

It hasn't rained since I've had this so I don't know the rain bytes at all.

[Vertikar]

I've got my gateway, but unfortunately life has got in the way, and I've got the data in Home Assistant via the gateway now. I do still want to revisit this, as I'd much rather I have it in HA via MQTT. I'll see if I can spend some time on it this week, we've got some rain forecast in the next few days.

[zuckschwerdt]

We usually see average and gust speed with more than 8 bits, so bit 6 might have the MSBs of that. I don't think we ever saw wind direction with 1 deg steps, rather a step of 22.5 deg seems common.

[cmlburnett]

I bought a GW1200 and this is what I found:

• byte 4 is battery in 0.02 V per bit (app was indicated 2.94V for 0x93=147 -> 2.94V)
• byte 5 contains the MSB for wind as described below
• byte 6 is the capacitor in 0.052 V per bit (app was indicated 5.3V for 0x61=97 so 5.3/97=0.054639 V/bit); I haven't confirmed with other voltages. Possible it's 0.1 V per bit but limits to 5.3V?

The data I've reviewed, byte 5 is 0x82=1000 0010 for direction < 256 and is 0xA2=1010 0010 for direction 256-359

The wind speed and gust I'm getting about 0.2235 mph per bit. For example, 0x1D=29 I got 6.49mph so 0.2237 mph/bit.

Byte 5:

• 0x80 = always 1
• 0x40 = MSB of gust speed
• 0x20 = MSB of wind direction
• 0x10 = MSB of wind speed

A gust of 63 mph from compressed air flipped bit 0x40 (0x82 to 0xC2). A sustained wind of 72mph with gust of 74mph flipped bits 0x40 and 0x10 (0x82 to 0xD2) so 0x10 is wind MSB.

That satisfies me for the wind data. Will try dripping water to see the rain bytes next.

[cmlburnett]

The rain is a bit more intricate and seems not well understood? Per WS90 docs anyway "Bytes 17 and 18 are affected by rain, but it is unknown what they report."

Bytes 10 & 11 are fixed at 0x3FFF during this experiment.

Byte 12 was 0x00 when dry then went through 0x10, 0x30, and stayed fixed at 0x50 suggesting 0x10 means "start rain" and 0x50 means "raining" with 0x30 is a state in between. After raining stopped, 0x51 flipped to 0x61.

Bytes 13 & 14 appear to be the rain counter and spills into the lower nibble of 12. So it rolled over from 0x50 to 0x51 when [13] overflowed. So probably a 20-bit number. Over the time of my experiment, these 20-bits went from 0x007732 to 0x01103A with difference of 39176 in decimal. The GW1200 repots 6.1mm of rain so 6.1/39176 = 0.00015571 mm/bit, a rather obscure constant.

Byte 15 was fixed at 0x00. [EDIT: I wonder if this a 16-bit value with byte 16 of minutes rained. Not sure when/how this number resets.]

Bytes 16 and 18 appear to be independent counters that increment during raining. I suspect byte 16 is minutes of rain as it started at 76 and ended at 136 and my experiment was just at an hour in duration.

Byte 17 is unusual. It started 0x34 when dry, 0xB4 when raining then slowly DECREMENTED to 0x0xAE when the rain stopped, jumped to 0x6E, decremented to 0x6C then jumped down to 0x2B. This suggest 0x80 is "raining" and 0x40 is "recent rain" that may resume all the counters if it starts raining again (a "Rain Event") and 0x20 is "No more rain, new rain even if it starts again"? Haven't tested this idea.

Bytes 19 to 22 are a single counter then incremented from 0x1DFFEFFD to 0x2159D51D at the end of the experiment and incremented to 0x21FF8AEE with the dripping stopped. After the water stopped this incredibly slowly. I wonder if it's a raw value from the piezo sensor.

Bytes 23 & 24 start at 0x00 when dry and 0x00 after the rain stopped. I suspect 23 may be another 8 bits of 19-22 making it a 40-bit field.

In summary,

• Bytes 12 through 24 are all involved in the rain counter, 25 is the firmware, 26/27 are the CRC/checksum (I haven't verified these fields yet).
• The rain day/week/month/year in the gateway are calculated and stored on the gateway, not the sensor, and not communicated in the radio stream.
• I believe the primary variables reported are accumulated rain and time, thus the mm/hr rate is derived.
• The rate of rain is NOT the primary data variable presented by the WS85, but rather the accumulated rain during an event. Rate is derived/calculated.

[cmlburnett]

Also confirmed that byte 26 is the CRC8 and byte 27 is the checksum. I can now throw away bad packets!