Topic: Ecowitt GW1000 and Weewx

[WelshDragon]

Hi all

I'm trying to get my Ecowitt GW1000 to talk to weewx (on a raspberry pi 3)to create my own weather page. I have tried using the interceptor driver in snoop mode and set as wu-client as it says it is for all devices that support Wunderground protocol but it's not finding any data. There are no errors showing up in the syslog and the database is initially created but never gets updated again. When i view the syslog live, it looks like the attachment.

I've also tried the same with the HP2551 console but again, no joy.

I have also tried plugging the gw1000 into the rapsberry pi that I have setup and using the usb driver but the pi doesn't recognise it. This pagehttps://www.wxforum.net/index.php?topic=36922.0 says it should be possible for weewx to read from the gw1000 but I can't figure out what's going wrong.

I have had all this working just fine with my previous Oregon Scientific wmr88 console but this has stumped me.

Anyone got any ideas?

Thanks in advance.

[galfert]

Did you use the WS View app to configure the "Customized" server for the GW1000 under Weather Services to point to the Raspberry Pi's IP address? In the "Customized" server settings you select WU as the protocol type. You enter in the IP address of the Pi. You can enter in whatever into the Station ID and Station Key (WeeWx doesn't care).

The USB port on the GW1000 is not for data. The only purpose of the USB port is for getting power to the GW1000.

[WelshDragon]

Yeah mean't to mention in my original post that I'd set that up via the WS View app.

I'm in work at the moment but will go through all the settings later and make sure I haven't missed anything.

[Mandrake]

I am assuming/hoping that in the near future when the API is released for the GW-1000 that software like WeeWx/Cumulus MX will just pull the data directly from the GW-1000 which will be the best solution. This will be the same way that Meteohub is using now.

[StephenR0]

Funny you should bring this up.  I just got a GW1000 this week and have been working with the interceptor driver to get it to work with it in ecowitt mode.  I think I've got it working, but I haven't hooked it up to weewx yet.  I plan to do that today.  When I think it's ready, I'll post it so people can try it out.  It won't be completely done because I don't have all of the sensors that are supported by the GW1000.  But I don't think it will be difficult to add them as they come up.

[galfert]

Funny you should bring this up.  I just got a GW1000 this week and have been working with the interceptor driver to get it to work with it in ecowitt mode.  I think I've got it working, but I haven't hooked it up to weewx yet.  I plan to do that today.  When I think it's ready, I'll post it so people can try it out.  It won't be completely done because I don't have all of the sensors that are supported by the GW1000.  But I don't think it will be difficult to add them as they come up.

The WeeWx Interceptor driver was designed for WU protocol type not Ecowitt protocol type.

With Ecowitt protocol type it sends all the sensors including extra temperature, soil, PM2.5 ..etc. But the WeeWx Interceptor was not designed for this because besides the data being different overall protocol is different.

With WU protocol type it only sends those parameters that are defined in the WU upload protocol. Therefore you are limited and you don't get data from the extra sensors.

Once the API is out I'm sure other weather software like WeeWx and Weather-Display and Cumulus will adopt support for it. For now it is exclusive to the Meteobridge. The API has just not been finalized. With the API you'll have access to all the sensors and be much better than "intercepting" the data. It is worth noting also that only the GW1000 at this time has support for this API. Other Ecowitt consoles like the WH2551 do not have this API. The WH2551 does have the "Cuztomized" server for both WU and Ecowitt protocol types.

You may be wondering what the Ecowitt protocol type is for. Well I suppose it is there for you to develop your own script to acquire data. I suppose there is also nothing stopping other software developers from embracing this Ecowitt protocol type instead of waiting for the API to be finalized.

I'm not certain but I think the API will be a more elegant solution than the Ecowitt protocol type upload method and the WU protocol type upload. The preferred method for applications to talk to each other is through a JSON API rather than just blindly sending data. I'm not a developer so I probably can't express this in the best words, but the Ecowitt protocol type upload (and WU upload) is more like an HTTP blind send. The JSON API can carry more information about the transfer and error handling...its more capable and intelligent. Beats me ...something like that. But maybe I'm totally wrong.

[galfert]

...a bit more. The API is intended for internal use, meaning on the local network. Where the Ecowitt and WU protocol types are for uploading to external services....not that that service can't also be local.

By internal use I mean to say that typically you have the weather station console (GW1000) and it supports the JSON API within the local network for a local computer running some software or script to access this data. Then that program or script does whatever it wants with the data....save it locally, upload it somewhere else, or generate and display tables and graphs....etc.

[StephenR0]

Well, I won't post it if it doesn't work.  Actually if you examine the interceptor code, it already has provisions in the observer device for the ambient weather protocol.  The way the observer device code is written, it's pretty easy to add support for the ecowitt protocol.  If they come up with a better method to do this, that will be fine.  But this is low hanging fruit.

[galfert]

Well, I won't post it if it doesn't work.  Actually if you examine the interceptor code, it already has provisions in the observer device for the ambient weather protocol.  The way the observer device code is written, it's pretty easy to add support for the ecowitt protocol.  If they come up with a better method to do this, that will be fine.  But this is low hanging fruit.

Good information. I hadn't looked at it that closely. It seems reasonable that the Ambient protocol is the same as the Ecowitt protocol. I suppose it can't hurt to try. Let us know.

[galfert]

One more thing about using the API method.... With the API the software is the one requesting the data from the console. So it is a pull rather than a push. When you configure an API pull it means that you can have multiple software all at the same time issuing pull of data via the API. When you push data which is what the console does with the Ecowitt and WU protocol types then you are limited to sending the data just to one place....hence the need to intercept it. The nice thing about the newest Ecowitt consoles is that besides uploading to WU and Ecowitt directly they also provided this extra "Customized" server upload, but that is it....you just have one more location to send data. The advantage of the API (pull) method is that you can have multiple devices running different weather software all at the same time all getting data Live and directly themselves.

[WelshDragon]

Morning all!

Just an update on this. The issue was that my gw1000 and the HP2551 console were both set to allow custom connections via WU protocol. I disabled the HP2551 custom connection and all is working now. I also had to tweak the apache so it uses 8032 instead of 80 as the gw1000 was using 80 but it's all now working well with the weewx template showing my data.

Now to setup the weather34 plugin - wish me luck 

[galfert]

Good going on figuring that out. Thanks for sharing your experience.

[WelshDragon]

@galfert

Thanks! It's great fun fiddling!

[WA4OPQ]

I'm using the GW1000 to send data to WeeWx using this method. Another Raspberry Pi arrived today. Can you have the GW1000 send to two different IP addresses?

Did you use the WS View app to configure the "Customized" server for the GW1000 under Weather Services to point to the Raspberry Pi's IP address? In the "Customized" server settings you select WU as the protocol type. You enter in the IP address of the Pi. You can enter in whatever into the Station ID and Station Key (WeeWx doesn't care).

The USB port on the GW1000 is not for data. The only purpose of the USB port is for getting power to the GW1000.

[Rover1822]

I'm sorry for jumping in here, but no. BUT.... you can obviously just resend from the first recipient ... code required

I mean , if you have the skill set to acquire the data, you can fairly easily re transmit it back out, original format or altered , depends on use.

I'm just so happy the "custom" was offered ... Once you have the data...possibilities are only limited to what you want to do with it

Edit, sorry I noticed you were using WeeWx, and I'm not ... but if you are receiving the data on your equipment, you should be able to send it back out.. yes there would be coding required

[galfert]

I'm using the GW1000 to send data to WeeWx using this method. Another Raspberry Pi arrived today. Can you have the GW1000 send to two different IP addresses?

The GW1000 can not send to more than one IP address server. But let's not say just yet that this is a problem. First let's establish what you want to run on that Raspberry Pi? Were you planning on running another instance of WeeWX? Or were you planning on running Cumulus MX or Weather-Display? Because if the answer is yes, that you wanted to run one of these others then there is no problem. This is because Cumulus MX and Weather-Display get data from the GW1000 using a different method. When you use WeeWX that is a push data from the the GW1000. When you use Cumulus MX and Weather-Display it uses a pull data method. Essentially Cumulus MX and Weather-Display don't use the GW1000's Customized server, they instead use a local network API and all you need to do is give Cumulus MX and Weather-Display the IP address of the GW1000 and they ask the GW1000 for data (pull method). And there is nothing required on the GW1000 for this to happen.

Incidentally the Meteobridge uses the same pull method. Give it the IP address of the GW1000 and done.

[Storm017]

Believe the driver was updated for GW1000. 

https://github.com/weewx/weewx/wiki/gw1000-recipe
https://groups.google.com/forum/#!searchin/weewx-user/GW1000%7Csort:date/weewx-user/Dbqe3_eJ1bE/Inx5dytQGAAJ

[galfert]

I didn't say that the GW1000 is not compatible with WeeWX. What I'm saying is that the way WeeWX gained compatibility with the GW1000 is by using a totally different method than what Cumulus MX, Meteobridge, and Weather-Display use to get the data from the GW1000.

The question is if the GW1000 is already sending data to one IP address server running WeeWX, can it then also send data to another WeeWX instance on a different IP address, and the answer is no. Because the GW1000 can only send data to one IP address using the push method which is what you are doing when you configure the GW1000 to send to a Customized server address, that of your WeeWX system.

But there is another method to get data from the GW1000. Instead of the GW1000 being the one that gets configured to send data, the other software program just asks the GW1000 for live data... This is a pull method. It doesn't require doing anything in the GW1000.  Because of this the GW1000 will respond to any device that asks for live data (this is the local API method...or what I'm calling pull method) . This is how the WS View app gets data. Think about it... You don't need to tell the GW1000 how to send data to WS View. The WS View knows at what IP address the GW1000 is at on the network and it asks the GW1000 for data. Cumulus MX, Meteobridge, and Weather-Display do the same thing.  Totally different than how WeeWX gets data from the GW1000 using the Interceptor driver.

[WA4OPQ]

I had hoped to push to two RasPi running WeeWx.  I thought I'd ask before attempting, in case I broke anything. But I grew impatient and put two IP addresses on the line. As expected, it did not work, and I set it back. Everything began working, except the wind direction. After a lot of troubleshooting, wind direction began working again, with no real explanation.
Luckily I had an extra GW1000 so I set it with one GW1000 per RasPi.

So now we know.

[galfert]

Technically speaking there is a way to use the Customized server push method so that two different WeeWX servers get the data from one GW1000. But it requires some extra networking expertise and special networking hardware. You would need a layer 3 network managed switch and you would then configure a few network ports in promiscuous mode. Then two WeeWX systems would be able see the network packets of weather data.

[WA4OPQ]

Really?  If the GW1000 only spits out data once a minute, couldn't it spit out one IP and then a few seconds later spit out a different IP?

[Storm017]

@galfert Basically you are saying, you need a $20.00 managed switch and mirror the port? If not, let us know how you would do it.

[galfert]

Really?  If the GW1000 only spits out data once a minute,

Why do you say it is limited to once a minute? You can change the interval.

couldn't it spit out one IP and then a few seconds later spit out a different IP?

As it stands currently, the firmware only allows for one IP address to be saved as a destination. I suppose Ecowitt could change that if they wanted.  But this is what we have currently.

@galfert Basically you are saying, you need a $20.00 managed switch and mirror the port?

Yes. But the GW1000 is a WiFi only device. So you would need to put it behind an access point that is then cabled to the managed switch.

There is another way without the managed switch. You make the first Pi a hotspot. The GW1000 use that Pi as its WiFi connection. The GW1000 then sends data to the IP address of the second Pi WeeWX system. The first Pi that is acting as a hotspot sees the data because it is the man in the middle. Even though the GW1000 is not sending data directly to the first Pi the data is there for the WeeWX Interceptor driver to see it.

[StephenR0]

There is another way without the managed switch. You make the first Pi a hotspot. The GW1000 use that Pi as its WiFi connection. The GW1000 then sends data to the IP address of the second Pi WeeWX system. The first Pi that is acting as a hotspot sees the data because it is the man in the middle. Even though the GW1000 is not sending data directly to the first Pi the data is there for the WeeWX Interceptor driver to see it.

I was going to suggest something similar.  I would get the first Pi working with the interceptor driver in the normal fashion by having the GW1000 send the data to it.  Then I would have that Pi send the data to the second Pi using one of the packet capture configurations that the interceptor driver supports.  The only thing about this option is that the interceptor driver might need to be in Observer mode to do this.  You'd have to play around with it to get it working and get all of the data that you're interested in.

As an aside, lately my attention has been on the Weatherflow Tempest.  I'm a field tester for the Tempest.  Interestingly, the Tempest could do this without effort.  The Tempest broadcasts its data by UDP by default.  So basically, anything on the same subnet can see the packets.  Currently, I have a weewx instance collecting the data without issue.  I could set up any number of weewx instances to do the same thing.  It's an interesting device.

[Rover1822]

Is there any reason someone could not set up a man in the middle app server locallly ?  Point the gw1000 to that, then forward the request (get or post) , wherever they wanted including multiple sites.

Yes I know this is a coding thing, but fairly simple for a coder in just about any language to do.

Scott