-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Device Support - Ecowitt WS85 #2998
Comments
Hi @Vertikar: My findings:
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. |
Great, thanks for your help @ProfBoc75! Will do some further testing as you suggested once I've got the gateway. |
What I've been able to discern without a gateway:
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. |
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. |
We usually see average and gust speed with more than 8 bits, so bit 6 might have the MSBs of that. |
I bought a GW1200 and this is what I found:
The data I've reviewed, byte 5 is 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:
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. |
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,
|
Also confirmed that byte 26 is the CRC8 and byte 27 is the checksum. I can now throw away bad packets! |
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=FSK_PCM,s=58,l=58,r=2048,preamble=aa2dd4'
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.
The text was updated successfully, but these errors were encountered: