-
Notifications
You must be signed in to change notification settings - Fork 1.4k
No Data shown for ecowitt wh51 433mhz device #2381
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
Comments
Try to grab a sample and upload here as zip. https://triq.org/rtl_433/ANALYZE.html |
Here they are.... |
@owingst : Hi, are you sure of the frequency ? Should be 915 Mhz for you in Texas, if yes try this :
From the fineoffset device :
Here my result with your samples :
|
My device is 433MHZ... I chose 433 version (there are 3 I think) assuming rtl_433 would read it. Here is pic of my device. Running with new setting you gave, I get the following with a segmentation fault after showing 2 readings. `
Registered 125 out of 153 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-104 108-116 119 121 124-128 131-153 ] time : 2023-02-15 20:13:15 time : 2023-02-15 20:13:17 |
Modified run parameters as follows and it appears to finally get readings for wh51 consistently, albeit the data is a little funky:
Not sure what the data means. Any ideas on how to fix it, or understand the data? ` time : 2023-02-15 20:37:47 |
@owingst : Hi, Thanks for the confirmation. The -X option is to get the raw data in hexa byte in order to build a device driver to decode this data. The fineoffset.c is concern here and already manages the devices with such preamble aa2dd4. Looking at the fineoffset.c device line 614, a test is made on byte 0: if not 0x51 then "Msg familly unknown 0x51", and DECODE_ABORT_EARLY, this is your case. This means that your device could be decoded by rtl_433 with the last version of rtl_433. I noticed that you're using an older one from april last year. |
Are you building git master from source when testing? I have used rtl_433 with 3 WH51s on 915 just fine. |
@ProfBoc75/gdt: I am not using the gateway. I am trying to get data from these devices and integrate into my python/IOS apps. I was not aware the gateway played a part in decoding the data ( assumed incorrectly that all decoding was done by rtl_433). I will try a new version of rtl_433 (w/Switchdoc support). Let me know if this makes sense. Thanks! |
@ProfBoc75, like me, didn't remember that we already have WH51 support. The request for original gateway readings was just to analyze the (thought to be) unknown hex data. He did some great work on other sensors using that method. But @gdt is right, it should just work. Please try a recent rtl_433 version. |
That worked when using new build (git clone https://github.com/merbanan/rtl_433.git) but I am missing switchdoc labs drivers. How do I get latest that includes ecowitt and switchdocs lab?
|
When moving to use switchdocs labs build (https://github.com/switchdoclabs/rtl_433) to get both wh51 and switchdoc, I get the following segementation fault: `
Registered 4 out of 155 device decoding protocols [ 23 142 146-147 ] time : 2023-02-16 11:33:32 |
It seems obvious that bugs when running switchdoclabs code should be reported in the switchdoclabs issue tracker. I do not recall them having introduced themselves and the purpose/status of their fork on the list. If it's just someone working on new features and they aren't quite baked enough for a pull request yet, that sounds good. |
@gdt They sell some products that uses rtl_433 in the back end. @owingst if there is a specific sensor you need support for you can follow https://triq.org/rtl_433/ANALYZE.html (again). And we can not support the Switchdock fork but we can probably add the sensors. |
agree with @gdt , the fork is very old, 4 or 3 years ago and logically only the switchdoclabs drivers are updated ... very difficult to merge both version. I hand over ... |
I opened an issue on switchdoc issue tracker. There latest build has some compile issues. I currently run rtl_433 with the following sensors: SwitchDoc Labs FT020T AIO Be great to get a build that has those three plus wh51. Thanks! |
Follow https://triq.org/rtl_433/ANALYZE.html for each and every sensor and we'll get there eventually. But this issue can be closed as there support is already there. |
I did already merge the interesting bits from the switchdoc fork. But since all "switchdoc" devices are rebrands we are using the original names. |
Where can I download that from? Main branch? |
All of that is included since 2021-10. |
Using latest build from main branch, switchdoc stuff is there but no data from wh51 using the following parameters: rtl_433 -R23 -R142 -R146 -R147 -C customary -F json | mosquitto_pub -l -t Sensor -h $IP |
downloaded again from git clone https://github.com/merbanan/rtl_433.git. Now only get wh51 data...no idea what I am doing wrong. |
This is what I get with main branch build using: rtl_433 -R23 -R142 -R146 -R147. No switchdoc data...but getting sc contact time : 2023-02-16 14:59:26 time : 2023-02-16 14:59:26 time : 2023-02-16 15:00:36 time : 2023-02-16 15:01:46 time : 2023-02-16 15:01:46 |
@owingst : can you add -R 20 and -R 153 , to be able to decode the Swichdoc sensors as I found them into your samples :
Notice that without -R and numbers, it will decode all the supported device protocols. with -R only it will list all the protocols supported by rtl_433. |
That worked! Thanks for all your help. |
After changing to use Cotech-367959 from SwitchDocLabs using same weather station, I no longer get UV/Light values from rtl_433, although cotech_36_7959.c shows those values. Any ideas on what is going on?
Here is data I got under switchdoc code: |
The values must have been invalid or out of bounds. |
Here is what I got.... Alternating messages of:
|
This BitBench shows the fields. The UV-Index is 0x29 (41) which is not valid. No idea why this might be and if something could be fixed? |
Is it possible to run two instances of rtl_433 with different builds and share same rtl_sdr? The switchdocslab rtl_433 version shows the uv/light just fine. |
Here is log info from same test but using switchdocslab build.
|
Well, the light value is completely wrong as well. It says rtl_433 supports it but most importantly, there is a table that says UV index is between 1 and 15 : So, to me, it is perfectly expected that an out of bound UV index (and light intensity) be ignored. Note that I also found this page: And this one is a declination of the FT020T specifically with no UV sensor so maybe you have this variant. |
My weather station has uv/light. I don't see any check in the code for a valid uv range in switchdoclabs_FT020T.c. So I guess I will have to open an issue on those folks.... |
To be clear: the values you captured as code were 7.173 kLux and UV-Index 29, so pretty shaded with chance of severe burn in mere minutes. The switchdoclabs fork is old and unmaintained I guess, otherwise both decoders are basically the same (though different on sanity checks). |
I really appreciate the help. Thanks! |
I am unable to see any decoded data from the ecowitt wh51 Soil Moisture Sensor. I am using the command line:
rtl_433 -vvv -R142 and place the device close to the sdr (rtl-sdr). I have several other devices working fine using rtl_433. Any ideas?
Here is the log file:
ecowitt.log
The text was updated successfully, but these errors were encountered: