-
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
Support for VEVOR Wireless Weather Station 7-in-1 #3020
Comments
Are you sure that you want |
Hi @cipriancu : Sounds like it's a Emax protocol but checksum failed can you try:
And see the errors. In your sample, your reset value is 10 x to big, so you have 2 messages in one. Try this flex:
You may have 2 or more same messages for each signal transmit, it's normal. Try also to capture .cu8 samples. Bitbench Based on your data layout explanation, and my assumption Notice that the rain gauge is probably on 2 bytes, ie 0x0138. This is a cumulative value, each time you have a tilt into the rain gauge this value is incremented. To know the corresponding mm/m² you need to do some tests and calculations, or you can trust your weather station and see the gap in mm for each tilt. To calculate yourself:
The raw rain value must be multiplied by 0.2 to get the final rain value in mm/m². The LUX values can coded like that (it's the case for Emax) : 1b + 15 bits, if first bit = 0 then LUX = 15 bits, if first bit = 1, LUX = 10 x 15 bits. UV and LUX are linked, so you may have to look at bit level into the UV data to get the figures. Check also the range from the user guide: LUX value from xx to yy could help to define the require number of bits. Share more samples, note the temp / hum / rain / lux / uv / wind information from the weather station and we'll find/confirm the data layout and probably able to update the current Emax decoder. |
Hi Christian, I chose -Y classic because the beginning of the code resembles the Universal Radio Hacker result. Since I managed to decode some measurements, it seemed like a good starting point. The values 87 and 8908 came from rtl_433 guidance: -A g001_868.3M_1000k.cu8 "Use a flex decoder with -X 'n=name,m=FSK_PCM,s=87,l=87,r=89088'". Here's the .cu8 sample: Bruno I'll try your guidance Thanks both for your help! |
@cipriancu : thanks, based on your cu8 sample, reset value is 1400 to get the 2 messages.
So try with:
|
Bruno |
Thanks for the excel file ! I'll check and back later. So reduce the reset to 1000 or 900 not less to get the 2 messages. |
Hi @cipriancu I drafted a decoder but I need more samples to decode properly the values, the ratio between the raw hexa value and the real values. I confirm that same behavior as with Emax decoder, some data are coded with 0x0101 = 0 (offset 257) or 0x01 = 0 (offset 1) Please test and share samples with the values you have on the weather display station. |
Bruno, I think i made some progress I need higher values to verify the formulas, but up to 2 m/s they seem accurate (except for 0). For rain, I will test with 100 ml poured at once to see the indicator. The display resets to 0 after inactivity, but the string retains the same value. Thanks for your help! |
Hi @cipriancu Thanks a lot, with your last decode.xlsx I found useful information that confirm some assumption and I need to correct few things in my drafted decoder, but I'm very close to the solution. 1- Ok, and in fact, for the decoder, I keep one row and looking the 2 preambles into the row, so not an issue if you still have one row instead of two, with bitbench we can easily split it and add the caca54aa preamble, but I understand for your excel file, it's easier to get directly the 2 rows. 4- LUX value is based on 16 bits (4 nibbles, 31/32/33/34), and first bit + 15 bits, in fact you just need to offset 257 to get LUX value, you don't need to convert the result in KLUX value, so you don't need to divide by 1007, this let us have a better precision than the weather display in KLUX, if the first bit is = 1 (so the 16 bits > 33025) , then x 10 the 15 bits decimal value . ( 33025 = 32768 + 257)
5- Ok for wind speed, not ok for wind gust, the nibble 21 is always = 0, so you just need 19 & 20 for wind gust. 6- Wind speed, (km/h = 3.6 x m/s)
7- Wind gust
Notice that we prefer to get km_h as it is handle by the I will update your excel file accordingly tomorrow. |
Bruno 00f8f79d031d2a0113050201015d04987378817921856ad008dafaab2f644ae30000 (LUX value = 60) I also tested the rain sensor by pouring 100 ml of water: 15 tips: Rain rate = 20.6 mm/h |
Good. For the rain value, you should change the weather display to cumulative or total value and not rain rate mm/h, because this one is an average and each hour the value is reset to 0, so not possible to get the figures, i.e how many mm / tips. And about the rain test, you must pour slowly drip by drip, like the real rain. What is the diameter of the rain gauge ? Here your excel updated, I keep 1 tips = 1 mm for the moment into the formula. (with the offset 257 too) |
ok This is significantly different from the 14.8 mm displayed. My goal is to read this vevor wheather station with and ESP32 that have OpenMQTTGateway on it and to push measurents in home assistant |
I'm answering to myself, as I found the FCC ID of the device (915MHz version) 2AQBD-R56. The original manufacturer is Fujian Youtong Industries Co., Ltd. rebrand under Vevor name. If I'm not wrong the diameter is around 15 cm external photos From your test, I understood a total of 17 tips for 0.1 L glass ( 100ml ) The result is 0.33 mm/tips
The result may be refined if you test 2 or 3 times more, and if you confirm the funnel diameter (the widest internal part at the top of the funnel ). In another hand, from the user guide, the Rain range is from 0-12999 mm/m². And based on 2 bytes values, we have 65536 tips which give : 12999 / 65536 = 0.198 mm/tips, could be round to 0.2 mm , so not exactly 0.33 mm, the reason why it needs to be refined/confirmed. Notice that for other Emax Weather station using the same protocol, it's 0.2 mm/tips. Edit: I did not see your previous answer while writing this comment 😄 So, the 14.8 mm for 65 tips = 14.8 / 65 = 0.227 mm/tips But if I calculate from your values we have 0.4 mm/m²/tips
Edit 2: the 6 ml/tips must be converted into mm/m² so 0.006 L x 69.86 = 0.43 mm/m²/tips |
I just updated the decoder accordingly, can you try to test the rtl_433 version from branch My test with your last lux code (just added the preamble in front of the code to get a result):
|
Bruno Observations: A simple rtl_433 -f 868M command works, but some measurements aren’t captured. When I use -Y classic, all measurements are captured correctly. It seems that without -Y classic, the string isn’t properly split into two pieces. Thank you for your time and help with this |
Hi @cipriancu:
Into the decoder, we don't care as I keep one row, (reset = 9000), and within a loop, I'm searching the first preamble, then extract the first 21 bytes, decode the data, if it's ok, then show the values, if not ok, search for the second preamble, extract the next 21 bytes and decode and so on. May be add
Probably a round value, we can add 0.1f to final value.
We need to change the 0.43 ratio to 0.5 (line 112):
|
Bruno. float rain_mm = rain_raw * 0.233f; The only issue I’m noticing is with rounding. The display doesn’t round numbers; it just takes digits as they come, while rtl_433 rounds the values. This affects the conversion for lux to klux and wind gust as well. Thanks again for your time and help with this! |
Good job ! As you reset all, did you notice if the sensor changed ID ? |
Ciprian I merged the PR with your updates. Enjoy ! Thanks for your contribution. If there is any error, do not hesitate and share here your findings, we'll update accordingly. |
nope nothing was changed after reset other than string for rain which went to 0101 |
Hi, I'm successfully running rtl_433 with the new decoder, and it gives me good results. My unit is a wifi version (YT60234), but it's almost sure that the outdoor units are identical, hence the protocol is the same. Do you guys know, if the pressure sensor values can be decoded? |
Ambient pressure sensors are always mounted in the display units. There is no pressure difference to outside ;) |
You're absolutely right :) |
Hi @JV16Bar , since it's a wifi version, this means that the data is probably sent to the cloud if you have this information in the application and here you may be able to analyze and get the figures. If your are able to capture the wifi frame with Wireshark you may be able to get the data. This needs some knowledge and work ... Edit: from https://fccid.io/2AQBD-60234 internal photos show a nice Ai-Thinker-WB2-12F, another possibility here to deep dive the weather station. |
I did this and currently have Home Assistant ingesting sensor values. I bought the wifi version and didn't want to dedicate a full SDR dongle to just capture this information all of the time. I performed a packet capture and found the URL the station calls containing sensor values. I then used that to write a PHP script that parses sensor data, it then formats a JSON payload that ultimately gets sent to Home Assistant via the Hassio REST API. Luckily, the base station sends the data unencrypted to weather cloud services. This is what I initially suspected and it was what drove me to even attempt this. I thought such an affordable device would not have an advanced enough SoC to deal with cryptographic handshakes like SSL/TLS. The way I redirected station traffic to my script was via DNS record. I run Pi-Hole as DNS server in my IoT vLAN. I just created a DNS record for rtupdate.wunderground.com to resolve to my local docker container which is where I have an NGINX and PHP stack running along with my custom PHP page. If anyone is interested I can share it here as long it's allowed in this forum since it's not rtl_433 related. Edit: Typo |
Any knowledge, discussion or hacks interesting to rtl_433 users or the the wider community is fine with us. |
Thank you @zuckschwerdt. This is in "work in progress" but it works so far. This script redirects weather information uploaded to Weather Underground by the VEVOR 7-in-1 Wi-Fi Solar Self-Charging Weather Station (Model YT60234) into Home Assistant. How to deploy
rtupdate.wunderground.com = (web server IP address)
|
hey @vlovmx! |
If you're asking the external sensor unit, it sends update to the base station every 20 seconds. |
good to know, thanks, but I was asking about the request that sends the data to rtupdate.wunderground.com. |
@JV16Bar, the base station pushes sensor data to rtupdate.wunderground.com every 60 seconds. |
I'd like to use your script. Could you help me to run it? |
@hash6iron please don't full-quote. Read http://www.catb.org/esr/faqs/smart-questions.html on how to write a good question, esp. the "Be precise and informative about your problem" section. |
for compatibility with home assistant using what's discussed above, should I buy YT60234 or YT60231? I'm confused because Vevor says yt60231 doesn't have wifi but @cipriancu says that's what they're using? |
Hello,
I'm trying to decode the strings coming from a Vevor 7 in 1 yt60231 Weather Stations
https://www.amazon.com/VEVOR-Wireless-Stations-Forecast-Temperature/dp/B0CHFF77JS
I’m capturing the data with: rtl_433 -s 1000k -Y classic -f 868.3M -X "n=Vevor,m=FSK_PCM,s=87,l=87,r=89088"
And so far I have managed to figure out some measurements
The captured data looks like this :
time : 2024-08-05 09:02:56
model : Vevor count : 1 num_rows : 1 rows :
len : 963 data : fff8000aaaaaaaaaacaca54aa00f8f79d02e332010e03020b013802397a86e08721856ad008dafaab2f644ae30000fffff000155555555559594a95401f1ef3a05c664021c06041602700472f50dc10e430ad5a011b5f5565ec895c6000000000000000000000000000000000000000000000000000000000
codes : {963}fff8000aaaaaaaaaacaca54aa00f8f79d02e332010e03020b013802397a86e08721856ad008dafaab2f644ae30000fffff000155555555559594a95401f1ef3a05c664021c06041602700472f50dc10e430ad5a011b5f5565ec895c6000000000000000000000000000000000000000000000000000000000
breaking up the data I figure out this
fff8000aaaaaaaaaacaca54aa00f8f7 - this piece never changes
9d - this looks to have something to do with the battery - if the battery is low is 9d when it is good the value is 1d
02e3 - this is temperature, the formula to calculate it is Value in hex converted in decimals /10 minus 50
32 - humidity - Value in hex converted in decimals
010e - Unknown
030 - wind speed but I couldn't figure out the formula
20b - wind direction measured in degrees - Value in hex converted in decimals minus 257
01 - Unknown
38 - rain, the sensor is a tipping bucket rain gauge and it counts each tipping in hex i have no clue how it is converted in values displayed
02 - UVI index - the formula seems to be hex converted in decimals minus 1
397 - lux measurement Here i have a formula that works on small values but not o high-value
a86e087 - Unknown
21856ad008dafaab2f644ae30000fffff000155555555559594a95401f1e - this piece never changes
f - when the battery is 9d is f when battery is 1d is e
3a05c664021c06041602700472f50dc10e-Unknown
430ad5a011b5f5565ec895c6000000000000000000000000000000000000000000000000000000000 - this piece never changes
i can give more sample date
The text was updated successfully, but these errors were encountered: