Pull data from GW1000 via UDP
Opened this issue · 17 comments
There are a couple of python implementations I found using this more efficient method to get data from ecowitt's sensors, it relies on UDP. I found a couple of python implementations, for integrations with weewx and rainmachine (I use both of them and they work fine).
Here's the two projects:
- weewx gw1000 driver: https://github.com/gjr80/weewx-gw1000
- rainmachine gw1000 plugin: https://github.com/pjpeartree/rainmachine-gw1000
The weewx driver also includes support for recent sensors like the WH45. The rainmachine plugin has a nice autodiscovery mechanism to find the GW1000 without even configuring the IP address. I linked both so you can take a look at the approaches.
Like I told you in the other thread, I also have an official doc on the UDP data structure if you need it, but it's reserved and I can't publish it publicly unfortunately. Let me know if you're interested and if you need it.
Hi, sorry for the delay on this.. yeah, I'm interested in those docs.. I'm reading the weewx code right now, trying to see if I can do a simple test to make sure my device supports this
The weewx driver, by @gjr80, is the best I've used for the GW1000.
What do you mean if your device supports it? What device is it?
I don't have the GW1000, I have one of the little TFT HP3501 displays. I did some really basic tests, and did find it listens on TCP 45000, so I'll have to play more, and see if I can write a little test routine. Technically this issue should be under the pyecowitt repo, because realistically that is what needs to be rewritten first...
The UDP API is only available in the GW1000/1001. I also own the HP2551 console, and it only offers the standard API, it doesn't broadcast anything via UDP. I contacted Ecowitt support months ago about this, and they said they have no plans for now to implement the UDP API in the consoles, it will be available only on GW100x products, unfortunately.
I think the console you have is one of the clones of their products, and the firmware is not different.
You're right, if the component is based on pyecowitt, the UDP API should be implemented there. The weewx driver doesn't use other libraries, IIRC.
It's a real Ecowitt.. The TCP thing is interesting, because the rainmachine plugin uses TCP, not UDP.. so I'm curious to see if I can get that to work on mine. When I have a sec, I'll put together a small test and see what happens..
Discovery process uses UDP, default port 46000. Have to check the rest of the code...maybe UDP for discovery and TCP for commands on port 45000.
Yeah, I was actually able to get the discovery to work. (I've been playing with just netcat, before attempting to actually write something). With the 45000 port, on tcp, I just kept getting nonsense back, so I suspect I wasn't sending the proper sequence. The rainmachine code sends a specific 5 byte command and nothing else, and just looks for data from that. When I send that specific command, it's unhappy, but if I fiddle the command around a bit, I start getting back different nonsense.. so there is something there..
Can you check the commands to send in the weewx driver? If you are really interested, there's the official API document available, you just need to ask it to ecowitt support (Lucy). I have it, but Lucy asked not to send it to anybody. But if you ask, explaining what you're doing, they will send it to you. It could be helpful. :)
Yeah, I think I'll ping them for the doc.. I could really use it anyhow. I prefer an actual doc to trying to reverse engineer protocols when possible. :)
The only thing is: prepare a good translation tool from chinese...they're not very good in making documents in plain english. :)
I haven't pinged them for a doc yet, but I did some testing today. It would seem that the HP station I have, doesn't support the same commands as the GW1000's do. Specifically, the 0x27 live data command. I can get it to respond with it's firmware and macaddr, but that's about it. It seems like this is consistent with the app, because the app only allows you to read values off Wunderground, not actually read values directly from the device....
That might make this a non-starter for me, as it would mean I could only support real GW1000's, and not the rest like I do now.
Your findings are correct, I wrote you 7 posts above that only GW1000 supports the UDP pull API and I also asked Ecowitt if they planned to have it also on the consoles but they said no. That's why I have both thw GW1000 and the console. :)
That might make this a non-starter for me, as it would mean I could only support real GW1000's, and not the rest like I do now.
You could support both, via configuration: when installing, the user chooses the device, if it's GW1000 you can do UDP otherwise you do like you do it now. You might even automatically check the device via autodiscovery, if it's GW100x then UDP, otherwise use the standard method. That was my original idea when I started this thread.
This is true, but the API's are wildly different. You would basically end up with a really overly complex HA integration, or two separate ones.
Also, not having one of the units makes it pretty hard. I did actually start to write some code on a branch that played with the device on port 45000, and used a separate class for talking to it.. but.. bleh. Without an actual device I'm just writing guesswork code.
This might have to wait until I buy a GW1000 to play with, I'm still not 100% sure how I want to handle this tho..
No problem, it's not an urgent issue...:)
BTW, just a note. It is TCP 45000, not UDP. UDP is for the broadcast only. I double checked this in the code for the two you linked too, so it's not just mine. Just in case you decide you want to play with it. If you really do, I can push my hacked up branch that semi-barely-doesn't support it yet but attempts to talk to it. :)
Adding this link for posterity: https://ambientweather.com/faqs/question/view/id/1537/
BTW, just a note. It is TCP 45000, not UDP
I wrote how it worked here. :)
Adding this link for posterity: https://ambientweather.com/faqs/question/view/id/1537/
That is from the official API document. The problem is if they keep it in sync with the API...sometimes they change things...:)