Support for VEVOR Wireless Weather Station 7-in-1 #150
Comments
|
+1 looking to use this exact weather station with a Lilygo 433 so I understand there are something working settings for the device in rtl_433, how to get those in openmqtt for thé Lilygo device ? |
|
Hello, I'm also interested in support for Vevor Wireless Weather Station. How can we using the LilyGo Lora32 decode FSK signal like cipriancu says above? Thanks in advance. |
|
I just refreshed the library to rtl_433 24.10. Was a fix for this included? |
|
Seems it's not working for me, but maybe my board is broken I get no rtl_433 |
|
Are you able to select the correct frequency and modulation ? |
|
I selected 868.300 as the frequency which seems correct from the manufacturer 's sheet, but I se me no option for modulation, only active library which is RTL_433 only other choice is inactive. |
|
Postive Results from the OMG build - 1technophile/OpenMQTTGateway#2125 |
Could you try 868.35 just for verification? |
|
Thanks for the help, sadly doesn't seem to change RFtoMQTT = {"active":3,"frequency":868.35,"rssithreshold":-106,"rssi":-113,"avgrssi":-115,"count":0,"rtl433_stack":19480,"ookthreshold":15} |
|
Unfortunately the link in the decoder file only links to the US region FCC page with the 915MHz references. I assume you do have the European/other Region 868MHz one from you above posts. Unfortunately with the LilyGo, the reception frequency window is not as wide as with an RLT- SDR stick, especially with 868MHZ FSK. It took me months to find the right frequency for my own weather station, I tried 868.30, 868.40, and so forth, until someone else post about some other device from the same manufacturer stated that his works fine with the in between 868.35, and now it's working perfectly. Does a verbose output with the RLT- SDR stick possibly give any further hints at the exact frequency? If not, and if there is not any other issue with the vevor_7in1 for rtl_433_ESP, your best bet really is to test yourself through the frequency range in 0.05 steps. I know it's tedious work, but if yourself, @cipriancu and @hash6iron split up the testing ranges between yourselves it shouldn't take too long to find the weed spot. |
|
Also, is your weather station Crosby for this testing, or outdoors in its usual place? The LilyGos also don't have the long range reception as an RLT- SDR stick. So not that it's just a case of having to move the LilyGo closer to the station. |
|
Sorry all. I won't be able to make any test till mid December. My wheather station is working on RTL-SDR + homeassistant and the lilygo is sitting in a drawer. In terms of frequency RTL SDR sees 2:one at 868.1 and the other at 868.4. My question for whenever I'll arrive home and do the tests. Do I have to compile openmqttgateway in plaform.io to use this new library or it is included in version 1.8.0 (my lilygo is flashed with 1.7.0) |
That's a good start! @toxic0berliner @hash6iron any luck with these frequencies? Or possibly anything in between in 0.05 steps?
You will have to install a new build, but by the time you'll be back home I assume the new version of the rtl_433_ESP library has been merged into the development version of OpenMQTTGateway, so you can then just web install a development build without any need to compile anything yourself. |
|
managed to get to a computer and ive changed the conf file in HA to get the frequencies: {"time" : "2024-12-03 21:57:43.702091", "protocol" : 263, "model" : "Vevor-7in1", "id" : 63735, "channel" : 0, "battery_ok" : 1, "temperature_C" : 4.500, "humidity" : 88, "wind_avg_km_h" : 0.000, "wind_max_km_h" : 0.000, "wind_dir_deg" : 103, "rain_mm" : 0.000, "uv" : 0, "light_lux" : 0, "mic" : "CHECKSUM", "mod" : "FSK", "freq1" : 868.381, "freq2" : 868.309, "rssi" : -3.314, "snr" : 23.389, "noise" : -26.704} |
|
Humm, the difference between Freq1 and Freq2 is approx 0.080 Mhz Am wondering if changing this to 80 may make a difference if it doesn't work once the frequency is dialled in - rtl_433_ESP/src/rtl_433_ESP.cpp Line 226 in 91bd22a |
|
I tried from 868.1 to 868.45 in .05 increments, nothing yet. Sorry for the noob-level help needed. I'm considering adding my own option in the html dropdown if I can findout the path for the dev builds 🤣 I'm fairly goot at web, shell, but real new to ESP32 & especially RF 😉 Meanwhile I have put the lilygo device on a battery pack and it's sitting outside just next to the weatherstation, can't be any closer. I am going over the same range with .005 increments now and fiving it more time inbetween. Maybe if you have one piece of advice : I plugged in a big antenna I bought a while ago that was for WIFI I expect 2.4GhZ on the liligo device thnking bigger is better, would you advise I switch back to the little antenna provided with the lilygo instead ? |
|
silly me, just found the url in the github actions : https://docs.openmqttgateway.com/dev/ |
|
but hey, I believe it's not using your latest build : in |
|
Northernman is likely asleep in his part of the world right now, so I've done the following @toxic0berliner @hash6iron @cipriancu It will be available until it gets overwritten by the default development nightly build just after midnight UTC tonight. Let's see what it brings. |
|
oups, sorry, I didn't anticipate this last message to be time-sensitive and for sure now I look at it it's alredy gone, sorry for that and thanks for the efforts DigiH |
|
It wasn't so much about 0.4.0 being merged, as you seemed to have done that already fine with your gitpod firmware build, but more to also include the above change from @NorthernMan54. I have started the test build again, and it will be available with the same SHA in about 90 minutes, again only until just after midnight ;) |
|
got it ! Thanks a lot ! |
|
Hi all next, i flashed [SHA:1b50c8 TEST ONLY] with lilygo-rtl_433-fsk, i set different frequencies around both values 868.307, 868.31, 868.376, 868.38, 868.37,868.35 ( in this time I had the RTL-SDR turned on to check if I receive something) and on lilygo no success |
|
Hin @cipriancu
That was the nightly development build again, with rtl_433_ESP 0.4.0, but without Let me start that build again, and in about 90 minutes you should be able to install the SHA:81eb8b build. |
|
in the meantime i flashed a via Platform IO https://github.com/1technophile/OpenMQTTGateway/tree/rtl_433_esp-v0.4.0 N: [ OMG->MQTT ] topic: home/OMG_lilygo_rtl_433_ESP_FSK/RTL_433toMQTT/Vevor-7in1/0/63735 msg: {"model":"Vevor-7in1","id":63735,"channel":0,"battery_ok":1,"temperature_C":24.8,"humidity":49,"wind_avg_km_h":0,"wind_max_km_h":0,"wind_dir_deg":185,"rain_mm":0.466,"uv":0,"light_lux":11,"mic":"CHECKSUM","protocol":"Vevor Wireless Weather Station 7-in-1","rssi":-33,"duration":83996} but it doesn't seems to capture all packets at every 20 seconds, i need to test a bit more |
See how it goes when the SHA:81eb8b build is ready, with the wider frequency deviation. @toxic0berliner don't you have an 868MHZ LilyGo board then, that you didn't get any reception at all with the 0.4.0 build? |
|
I have 81eb8b I have been swiping the frequencies, so far no luck trying again around 868.35 |
I meant your actual LilyGo board, which version is the board hardware? What does it say on the back, under |
|
Wow, something new: |
|
I believed my device to be 433 back then. |
|
I'm afraid you'll need a 868/915MHZ version, where yours now says 433/470MHz. |
|
Cross over ;) yes, you would be a lot luckier with a 868MHz LilyGo 😃 Don't worry about the Paxcounter or Disaster-Radio versions, that is just different pre-installed firmware, which you will be overwriting anyway. You will still be able to pick up any proper 433MHz devices with your version though. |
|
@cipriancu - the SHA:81eb8b build is ready for a test drive … |
|
It's ordered, will take a while to get there though. |
|
Didn't you mention you used GitPod before? I basically have forked this repo here, with the main branch being the 0.4.0 state right now. Once forked just create a new branch and in that branch make the change @NorthernMan54 suggested above - maybe best wait to see if @cipriancu comes back with good results first ;) Then in OpenMQTTGateway, either forked as well or though GitPod again, all you have to do is redirect the rtl_433 library link to your own branch, as I did in the test build with in Platform.ini. Then build and upload - 0.4.0 with the above frequency deviation change. Alternatively just remove the branch tag Or just clone my freqdev branch
I hope it makes sense. |
|
ALL but I did not receive anything with both [v0.4.0] or SHA:81eb8b home assistant is give me this
I'm thinking of downloading OpenMQTTgateway v1.8.0 and changing in the platform.io the link to rtl_433_ESP either to DigiH or NorthernMan54 |
If you look at the commit from 5 days ago, I only added what @NorthernMan54 suggested above 5 days ago main...DigiH:rtl_433_ESP:freqdev but at the same time also wondering if the second occurrence of radio.setFrequencyDeviation(40) at https://github.com/DigiH/rtl_433_ESP/blob/freqdev/src/rtl_433_ESP.cpp#L276 should also be changed. As only one was mentioned I only changed the one. I'm not very versed with the radio tuning intricacies and honestly wasn't too sure about exactly what I was changing, but I just wanted to make the above suggested change available for testing ;) So you can see that the change is included, and if it makes it worse and not better for you I suppose some other tweaking might be required to get a better reception than your current 53 out of 288.
And this is what I did, creating an OpenMQTTGateway branch of the current development branch, and linking the rtl_433 library to my above changed rtl_433_ESP branch 1technophile/OpenMQTTGateway@development...rtl433test which you can see is commit 81eb8b, i. e. the branch the test builds were created from. But do let me know first you think there is anything wrong with the above, or maybe you want to try it with both occurrences of |
|
@DigiH A bit of a moment for me there, if you look at the compiler directives, the first radio.setFrequencyDeviation is for the CC1101 based build, and the second for the SX127X based build. So it should be the second one |
|
@NorthernMan54 You know me, I do my BLE decoding and am used to creating test builds for that, but when it comes to the rtl_433 decoding I just went to the line you stated above ;P without actually looking too closely as I was also working on more BLE decoders at the same time. So @cipriancu better change the second one then, possibly keeping the 1st for CC1101 requiring the same or similar change, if any of the Vevor7in1 owners do have an 868MHz CC1101?!? Where would all the fun and excitement be without small hiccups like that along the way 😜 |
|
And yes, a few lines above it clearly states so my wondering about the second occurrence wasn't that off. |
|
@cipriancu please let us know how you get on with the appropriate or do you quickly want me to make the change in my branch, so you can just link to it from Platform.ini in your OMG build? |
Done, both now with 80 main...DigiH:rtl_433_ESP:freqdev so yo9u can just keep the rtl_433 link from the OMG test branch
|
|
thanks, DigiH but I wonder if there isn't a processing of the data that dont push a record in MQTT as long nothing is changing. because i have the weather station next to me inside the changes are minimal |
AFAIK that should not happen that identical value messages are being filtered. I think you said that your station broadcasts every 20 seconds, so you really should ideally see a received and decoded message envy 20 seconds, even if and when the values do not change. At least that is what I was seeing with my weather station during initial testing and setup. So unless something has changed in regards to that it should still behave the same. I very much doubt it though, as it would just require extra processing and storing previous values for comparison and all - and for what in the end, to suppress some duplicate messages - no, I very much doubt it :) @NorthernMan54 ?? Could it be that the 'missing' decodings might actually fall into another decoder. I have this with my fridge/freezer thermometers, that every now and then they get recognised and decoded as some other brand thermometer, but I do think that is actually unique to my thermometers, as there was quite a long issue thread about these particular ones - just a thought though if you have other devices detected, if one of them might look very similar to your station. 13 records in 15 minutes - with braodcsdsts every 20 seconds, correct? so 13 decoded from 45 broadcasts!?! 29% hits 20 records in 40 minutes - 20 out of 120 broadcasts. Only 17% So it did actually get worse with the change, if the first was with 0.4.0 as is in the PR, and the seconds with 0.4.0 plus the As I said, I'm happy to help with creating forks and running test builds, but with the actual rtl_433 RF decoding side it's up to your guys to come up with what else might be worth trying ;) but I also have to say that the first 29, let's round it to 30% I don't find too bad actually, if correct receptions come in on an average of every 60 seconds, an interval some other stations actually broadcast at as their default. |
|
Now with the frequency deviation set higher, which base frequency setting did you actually use? Still 868.35? Looking at your list of samples further above, it looks as if the base frequency1 is always very close around 868.38 or 868.40 Maybe try another round with setting the frequency in the WebUI to that?? |
|
Thanks, DigiH, for the detailed analysis. I don’t think the frequency deviation needs to be set to 80. I believe it should stay at 40 because the two frequencies emitted by the weather station are 868.307 and 868.376. I changed the base frequency to 868.34 since that, with a deviation of ±40, should cover the full spectrum of the weather station’s signals. With ±80, I suspect it might capture more noise, which could be affecting the decoding rate. Let me know what you think, and I’ll continue testing with this setup.
|
|
I honestly don't know enough about the RF rtl_433 decoding intricacies to know what other parameters might be helpful to try out and tweak, to possibly improve on your 30% reception and decoding rate which you had with the original frequency deviation 40 setting. I'm happy to help though with creating test build with any such changes. |
|
I just recieved the Lilygo 868 !!! Recieved a msg from the weather station right away, seems they are indeed not coming very frequently but will be monitoring over some time. Thanks for the efforts all of you ! |
|
All moved my weather station and LilyGO setup into production using NorthernMan54's version with a deviation set to 40. While it works fine and I'm happy with the results even if i dont receive/decode a signal at each 20 seconds, there’s an occasional issue where I receive strange values. My suspicion is that the CRC checksum for those records is failing. Is there a way to make RTL_433 validate the CRC checksum and discard invalid packets before sending the data via MQTT? This would help filter out corrupted messages and prevent strange values from appearing in Home Assistant.
|
|
The CRC logic in the decoder is here - And looking at the logic it is already discarding them. I wonder if the same data quality issue exists with using rtl_433 and a sdr ? |
|
Also this compiler directive may give more insights into the signal decoding PS - I haven't used this option since the most recent update, fingers crossed it still works with the update |
|
To be honest I'm going to be lazy now, I find that the base station is not sendig over RF, and it is doing quite a lot for me in fact:
|
Current Situation
With Bruno's help, we managed to decode VEVOR Wireless Weather Station 7-in-1 with rtl_433 and RLT- SDR stick
merbanan/rtl_433#3020
but my goal is to integrate it with openmqttgateway installed on a LilyGO TTGO T3 V1.6.1
I installed lilygo-rtl_433-fsk version but my signal is not received/decoded
With RLT- SDR stick i get the data using the command:
rtl_433 -s 1000k -Y classic -M level -f 868M -X "n=Vevor,m=FSK_PCM,s=90,l=90,r=1400,preamble=caca54aa"
what i need to do to integrate rtl_433 branch development in openmqttgateway?
Proposed Change
add support for VEVOR Wireless Weather Station 7-in-1
Additional Context
No response
The text was updated successfully, but these errors were encountered: