Topic: Using the GW1000 with Weewx in Ecowitt mode

[StephenR0]

This week, I received an Ecowitt GW1000 that I had ordered.  I set it up and found that I really like it.  It's amazingly small for what it does.  Quite cute actually.    When I saw how easy it was to configure a customized server, I thought I'd see how easy it would be to configure the interceptor driver for weewx to use its output.  When I got into it, it wasn't bad at all.  For anyone that's interested what follows is a description of how to install it.

First, you need an installation of weewx.  I didn't want to disturb my raspberry pi SDR installation.  So, I installed weewx on an Ubuntu server that I have.  I followed the directions for installing with setup.py.  You can find them here.

http://www.weewx.com/docs/setup.htm

The rest of this discussion will assume that kind of installation so I can refer to specific directories.  When you test your weewx installation, it's suggested that you run the program directly to be able to see the loop and rec messages.  It takes about five minutes to see the /home/weewx/public_html directory created.  My server has a web server running, so I created a soft link to that directory so I could use a browser to see the new weewx web page.  As root:

cd /var/www/html
ln -s /home/weewx/public_html weewx

At this point, everything looked good so I stopped that weewx running with the simulator.  Now to install the interceptor driver.  Here is where that is documented.

https://github.com/matthewwall/weewx-interceptor

I installed it from /home/weewx so the commands were:

bin/wee_extension --install weewx-interceptor.zip
bin/wee_config --reconfigure --driver=user.interceptor --no-prompt

I didn't start the server yet because I needed to install my modified version of interceptor.py.  I've attached that modified version to this post.  The installed version is in /home/weewx/bin/user.  I went to that directory and renamed interceptor.py to something else so I could keep it.  Then I copied my new version to that directory.

At this point, I tested it.  The simplest way to do that is to run the driver directly.  First, I configured the GW1000 to send data to my server.  I chose port 8000, but you can use pretty much any unused port above 1024.  In the Weather Services menu item on the GW1000, I selected the Ecowitt protocol, input my server hostname, and input port 8000.  I left the upload interval at 60.  I saved that and finished.  Next from /home/weewx I ran the driver.

PYTHONPATH=bin python bin/user/interceptor.py --device=observer --mode=listen --port=8000 --debug

You should see a message every minute.  It should look something like this.

identifiers: {}
raw data: PASSKEY=5DECC8797DB9DA13796C3967C4C3490E&stationtype=GW1000B_V1.4.9&dateutc=2019-07-19+19:49:59&tempinf=75.9&humidityin=49&baromrelin=28.680&baromabsin=28.680&tempf=92.1&humidity=70&winddir=181&windspeedmph=4.03&windgustmph=5.82&maxdailygust=8.05&solarradiation=724.35&uv=7&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.252&monthlyrainin=0.252&yearlyrainin=0.252&totalrainin=0.252&wh65batt=0&freq=915M&model=GW1000
raw packet: {'wind_speed': 4.03, 'humidity_in': 49.0, 'temperature_in': 75.9, 'wind_gust': 5.82, 'battery': 0.0, 'humidity_out': 70.0, 'uv': 7.0, 'radiation': 724.35, 'rain': None, 'dateTime': 1563565799, 'pressure': 28.68, 'temperature_out': 92.1, 'wind_dir': 181.0, 'rain_total': 0.252, 'rain_rate': 0.0, 'usUnits': 1}
mapped packet: {'txBatteryStatus': 0.0, 'pressure': 28.68, 'outHumidity': 70.0, 'UV': 7.0, 'radiation': 724.35, 'rain': None, 'dateTime': 1563565799, 'windDir': 181.0, 'outTemp': 92.1, 'windSpeed': 4.03, 'inHumidity': 49.0, 'inTemp': 75.9, 'windGust': 5.82, 'rainRate': 0.0, 'usUnits': 1}

Once this works, it's time to feed the data to weewx.  I deleted /home/weewx/public_html and /home/weewx/archive/weewx.sdb to clear out the old data from running the simulator.  Next, edit weewx.conf to configure the [Interceptor] section.

    device_type = observer
    port = 8000

Then run weewx directly.  From /home/weewx as root.

./bin/weewxd weewx.conf

You should see loop messages every minute and rec messages every five minutes.  I'm going to run both of my weewx instances to be able to compare them.  If you try this, let me know how it goes.  Once we get confident about it, I can submit it back to the author.


UPDATE:  Please use the driver version attached to post five.  That's the latest version and will work even if you don't perform the rest of the steps in that post.

[Jakon]

You are very professional. This is a great tech tip for GW1000 users.

[galfert]

Great writeup. Can you explain why you would need a modified version of interceptor.py?

[StephenR0]

Sure.  In that debug message that the driver puts out is all the raw data from the GW1000.  I just went through that data and made sure that anything weewx could use was mapped to weewx data fields.  For my WH65B sensor array this came down to two fields, rainratein and wh65batt.  In addition, the driver has an array for unused fields which I updated for the ecowitt protocol.  Actually, there will be further changes needed in the future.  The driver will need to track firmware changes from Ecowitt.  Also, the GW1000 knows about lots of hardware that I don't have.  As people want that hardware supported, the driver will need to be enhanced.  The weewx database schema will need to be extended to use this data in weewx as well.

[Jakon]

You can contact Lucy, who may provide you with all sensor field definitions.

[StephenR0]

I've been customizing my weewx install in various ways.  One customization may interest anyone that is following the instructions in the first post of this thread.  My weather station is a WS-2902A.  The console has a feature that I've always liked, but haven't really used fully.  It's able to display the rain that has fallen in the recent rain event.  From the manual, a rain event is defined as continuous rain, and resets to zero if rainfall accumulation is less than 10 mm (0.039 in) in a 24 hour period.  Since this requires tapping the rain button to switch to this view, I find that I don't use it as much as I'd like to.  But it turns out that the GW1000 keeps track of rain event rainfall as well.  Interestingly, the WS View app doesn't expose this value.  But rain event rainfall is sent to the customized server in Ecowitt mode.  Here's how to get this value displayed in the main weewx web page in the Current Conditions section.

First, you need an updated version of the interceptor driver that returns this value.  I've attached it to this post.  The installation of this file is the same as described in the first post of this thread.  This driver only adds a field and won't interfere with weewx if you don't perform the rest of these instructions.

Next, modify /home/weewx/skins/Seasons/skin.conf to add this line.

        rainEvent            = Rain Event
      
This goes after the 'wind' entry in the [Labels] section.  Again, I copy this file to a different name to save the original before editing.

Next, modify /home/weewx/skins/Seasons/current.inc to add these lines.

      <tr>
        <td class="label">$obs.label.rainEvent</td>
        <td class="data">$current.rainEvent</td>
      </tr>

I added them after this section.

      <tr>
        <td class="label">$obs.label.rain_today</td>
        <td class="data">$day.rain.sum</td>
      </tr>

But, you can put it where ever you want to see it in the Current Conditions section.

Finally, we need to add rainEvent to the rain label group to get the formating of the value right.  The simplest way to do this is to add this at the end of /home/weewx/bin/user/extensions.py.

import weewx.units
weewx.units.obs_group_dict['rainEvent'] = 'group_rain'

None of this was done with any great insight into the programming of weewx.  I just read in the (rather large) documentation and came up with solutions.  Here's a link.

http://www.weewx.com/docs/customizing.htm

Also, I didn't extend the database schema of weewx to add rainEvent.  I didn't see any value to that, but it could be done if that was of interest.  That's also described in the customizing guide.

If you try this, let me know how it goes.  Jump in.  The water is fine. 

[galfert]

I've been customizing my weewx install in various ways.  One customization may interest anyone that is following the instructions in the first post of this thread.  My weather station is a WS-2902A.  The console has a feature that I've always liked, but haven't really used fully.  It's able to display the rain that has fallen in the recent rain event.  From the manual, a rain event is defined as continuous rain, and resets to zero if rainfall accumulation is less than 10 mm (0.039 in) in a 24 hour period.  Since this requires tapping the rain button to switch to this view, I find that I don't use it as much as I'd like to.  But it turns out that the GW1000 keeps track of rain event rainfall as well.  Interestingly, the WS View app doesn't expose this value.  But rain event rainfall is sent to the customized server in Ecowitt mode.

Thank you for sharing. Great write up. I might delve in when I go back to exploring WeeWx. What you mentioned about having to press buttons on the WS-2902A display is annoying. There is so much more data to see but you have to keep pressing so many buttons. You can upgrade to the WS-2000 display and then you don't need to press any buttons...all the data is displayed. You get to see this rain event an many other things all at a glance of the display. The WS-2000 has buttons but they are used for configuration, calibration, alarms, graphs!!!, and data tables.

PS - there was an error in Ambient's definition. It should read 1 mm = 0.039 in. Ambient has now corrected this error in their knowledge base.

[StephenR0]

I'm sure the WS-2000 is nice.  Basically, I'm happy with the WS-2902A.  It doesn't seem to have the receive sensitivity that the GW1000 has, though.  The GW1000 seems to be as reliable as a rock.  The indoor sensors are quite responsive, as well.  And since I can customize weewx so much, I'm kind of putting my attention there.  Next I might start looking at the Belchertown skin.  There are endless things to do with weewx. 

[Briz600]

This is awesome thanks for all the great info.

I managed to get the custom interceptor.py installed, and is currently listening to my GW1000 in Ecowitt mode. Im having some trouble with the data conversions in WeeWx, and I'm not exactly sure what's happening. It seems that my data is coming in as US std but for some reason WeeWx thinks its Metric and doing a conversion.

Incoming data looks like this.

Code: [Select]

raw data: PASSKEY=4E9F8B7637CFC623EECA981BFC06260B&stationtype=GW1000B_V1.5.0&dateutc=2019-08-30+21:25:23&tempinf=76.6&humidityin=54&baromrelin=29.855&baromabsin=29.855&freq=915M&model=GW1000_Pro
raw packet: {'humidity_in': 54.0, 'pressure': 29.855, 'temperature_in': 76.6, 'usUnits': 16, 'dateTime': 1567200323}
mapped packet: {'pressure': 29.855, 'inHumidity': 54.0, 'inTemp': 76.6, 'usUnits': 16, 'dateTime': 1567200323}

WeeWx Logger shows this.

Code: [Select]

Aug 30 17:12:14 WXServerX weewx[830]: engine: 2019-08-30 17:12:10 EDT (1567199530) LOOP value 'pressure' 0.8818835467 outside limits (24.0, 34.5)
Aug 30 17:12:14 WXServerX weewx[830]: engine: 2019-08-30 17:12:10 EDT (1567199530) LOOP value 'inTemp' 169.34 outside limits (10.0, 120.0)

I managed to fix the in temp by commenting out the metric assignment in the interceptor.py.

Code: [Select]

Changed
pkt['usUnits'] = weewx.US if 'tempf' in data else weewx.METRIC

To
pkt['usUnits'] = weewx.US #if 'tempf' in data else weewx.METRIC


Let me know if there is a better way to solve this.
Thanks

[StephenR0]

Those logged messages are very odd.  I suppose you've looked at this, but is everything set correctly on the "Unit Settings" page in the GW1000's WS View app?  Also, your raw data doesn't seem to have any sensor array data.  "tempf" would be there if you had any outdoor temperature data.  Just trying to make sense of it. 

[Briz600]

That makes sense. I don’t have any outdoor sensors yet. That was just the data coming from the gw1000 without any additional sensors. I guess once I install the outdoor sensors it should pickup “tempf’ and everything should start working correctly.

Thanks

[StephenR0]

Briz600, I had an interesting event that left log messages that look very similar to yours.  Here's an example of mine.

Code: [Select]

Aug 31 18:10:26 k9 weewx[29949]: engine: 2019-08-31 18:10:22 CDT (1567293022) LOOP value 'pressure' 0.8601494759 outside limits (24.0, 34.5)
Aug 31 18:10:26 k9 weewx[29949]: engine: 2019-08-31 18:10:22 CDT (1567293022) LOOP value 'inTemp' 164.12 outside limits (10.0, 120.0)

As you can see, the data and values are very similar to yours.  This seemed to happen over a period of less than an hour.  In addition, during this period I got these messages.

Code: [Select]

Aug 31 18:10:26 k9 weewx[29949]: interceptor: MainThread: unrecognized parameter wh26batt=0

This is interesting because the expected data is wh65batt, not wh26batt.  The other thing that happened during this period was this.

Code: [Select]

Aug 31 18:03:19 k9 weewx[29949]: interceptor: MainThread: rain counter wraparound detected: new=0.4106 last=4.106

Those values are suspicious as well.  The interceptor code currently uses the yearly rain amount to determine how much rain has fallen.  Obviously, weewx is prepared for this value to be zeroed out.  But it's suspicious that it happened in the middle of all this.  After this event was over, everything seemed to go back to normal.  I suspect that the GW1000 has a bug or two.  I'm not sure how we would support finding it.  But I thought I'd document this so we can track things like this.

[Briz600]

Thats very interesting... Was there missing data for that period that it was acting up? My python is a bit rusty, however what it looks like its doing is its determining if the dataset is metric based on if there is a 'tempf' property in the set. I wonder if maybe your sensor array failed to send 'tempf' for a short time?

I am not sure what to make of the other bits of data you provided as I am still awaiting of my outdoor sensor array to arrive. Did you upgrade to 1.5 yet?

[StephenR0]

I've done some more research on this.  So far, I've had two 'events' of this.  Both were only temporary.  The reason that I notice them so easily is the yearly rain.  When an 'event' happens, the yearly rain is returned as the correct value divided by ten.  Weewx interprets this as counter wraparound, which is a normal thing.  But when the 'event' ends and things go back to normal, weewx thinks rain has fallen.  Of course, it hasn't really.  But it shows up pretty obviously in the graphs.  Some of the other data is missing too, because it becomes so out of range that weewx throws it away and logs it.  But some of the data looks ok.  The thing with the battery status is interesting because apparently the GW1000 temporarily thinks the sensor array is a WH26, whatever that is.  That doesn't always happen, though.  I've raised the issue with Lucy at Ecowitt.  We're communicating about it, but this kind of thing isn't easy to track down.  If I had a way to recreate the problem or if it would stay in this condition for long enough to troubleshoot it, it would be much better.  I do believe that you have experienced this problem as well.  I guess we'll just have to see if their engineers can think of something.  And yes, I'm on 1.5.

[mauro63]

My gw1000+ws80+wh40+wh31 in a barani meteoshield standard with weewx in ecowitt mode
This is not my job, lot of thanks to a friend of our italian forum

http://www.kwos.org/marinadimontemarciano/indexDesktop.php

Mauro

[StephenR0]

That's a really nice site.  Do you know if anyone using a GW1000 has experienced anything like what I've described?  If anyone does, I'd appreciate a mention in this thread about it.  Thanks.

[Jakon]

I've done some more research on this.  So far, I've had two 'events' of this.  Both were only temporary.  The reason that I notice them so easily is the yearly rain.  When an 'event' happens, the yearly rain is returned as the correct value divided by ten.  Weewx interprets this as counter wraparound, which is a normal thing.  But when the 'event' ends and things go back to normal, weewx thinks rain has fallen.  Of course, it hasn't really.  But it shows up pretty obviously in the graphs.  Some of the other data is missing too, because it becomes so out of range that weewx throws it away and logs it.  But some of the data looks ok.  The thing with the battery status is interesting because apparently the GW1000 temporarily thinks the sensor array is a WH26, whatever that is.  That doesn't always happen, though.  I've raised the issue with Lucy at Ecowitt.  We're communicating about it, but this kind of thing isn't easy to track down.  If I had a way to recreate the problem or if it would stay in this condition for long enough to troubleshoot it, it would be much better.  I do believe that you have experienced this problem as well.  I guess we'll just have to see if their engineers can think of something.  And yes, I'm on 1.5.

PASSKEY=D5FF2C4B824AAD083E81CEA8420FD77F&stationtype=GW1000B_V1.5.1&dateutc=2019-09-03+05:58:20&tempinf=81.7&humidityin=61&baromrelin=29.495&baromabsin=29.495&tempf=82.9&humidity=99&winddir=270&windspeedmph=0.00&windgustmph=2.01&maxdailygust=2.46&solarradiation=0.00&uv=0&rainratein=0.165&eventrainin=0.028&hourlyrainin=0.028&dailyrainin=0.028&weeklyrainin=0.028&monthlyrainin=0.028&yearlyrainin=0.028&totalrainin=0.028&temp1f=79.34&humidity1=62&temp5f=79.34&humidity5=63&temp8f=79.70&humidity8=62&soilmoisture8=0&pm25_ch1=16.0&pm25_avg_24h_ch1=15.2&pm25_ch2=16.0&pm25_avg_24h_ch2=15.5&pm25_ch4=15.0&pm25_avg_24h_ch4=13.8&lightning_num=23&wh65batt=0&wh80batt=2.82&wh40batt=1.6&wh26batt=0&batt1=0&batt5=0&batt8=0&Siolbatt8=1.7&pm25batt1=5&pm25batt2=4&pm25batt4=5&wh57batt=5&freq=915M&model=GW1000

This is a complete HTTP packet, the pressure unit is inHg, it's fixed to 3 decimal places, the rainfall unit is inch, it's fixed to 3 decimal places. There could be a problem with Weewx parsing data. I don't know how Weewx parses the data.

If wh26batt appears in your data, I think you are receiving someone else's transmitter, maybe a neighbor who is far away from you.
You can check whether the T&H ID is registered with the transmitter on the Sensors interface on the WS View.
Set the sensor to Disable if you don't want to be disturbed by it.
I think your outdoor temperature and humidity sometimes not report, it may be the same reason.

[StephenR0]

If wh26batt appears in your data, I think you are receiving someone else's transmitter, maybe a neighbor who is far away from you.
You can check whether the T&H ID is registered with the transmitter on the Sensors interface on the WS View.
Set the sensor to Disable if you don't want to be disturbed by it.
I think your outdoor temperature and humidity sometimes not report, it may be the same reason.

That's a very interesting idea.  Here's my HTTP packet.

PASSKEY=5DECC8797DB9DA13796C3967C4C3490E&stationtype=GW1000B_V1.5.0&dateutc=2019-09-03+12:19:16&tempinf=76.1&humidityin=60&baromrelin=28.753&baromabsin=28.753&tempf=72.9&humidity=90&winddir=272&windspeedmph=0.00&windgustmph=2.24&maxdailygust=9.17&solarradiation=18.60&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.012&weeklyrainin=0.024&monthlyrainin=0.024&yearlyrainin=4.130&totalrainin=4.130&wh65batt=0&freq=915M&model=GW1000

It's not nearly as complete as yours.    I've attached my sensors interface screen.  It doesn't appear to have any indication of having seen another sensor.  Would it remember another sensor on this screen if it had seen one?

[Jakon]

If wh26batt appears in your data, I think you are receiving someone else's transmitter, maybe a neighbor who is far away from you.
You can check whether the T&H ID is registered with the transmitter on the Sensors interface on the WS View.
Set the sensor to Disable if you don't want to be disturbed by it.
I think your outdoor temperature and humidity sometimes not report, it may be the same reason.

That's a very interesting idea.  Here's my HTTP packet.

PASSKEY=5DECC8797DB9DA13796C3967C4C3490E&stationtype=GW1000B_V1.5.0&dateutc=2019-09-03+12:19:16&tempinf=76.1&humidityin=60&baromrelin=28.753&baromabsin=28.753&tempf=72.9&humidity=90&winddir=272&windspeedmph=0.00&windgustmph=2.24&maxdailygust=9.17&solarradiation=18.60&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.012&weeklyrainin=0.024&monthlyrainin=0.024&yearlyrainin=4.130&totalrainin=4.130&wh65batt=0&freq=915M&model=GW1000

It's not nearly as complete as yours.    I've attached my sensors interface screen.  It doesn't appear to have any indication of having seen another sensor.  Would it remember another sensor on this screen if it had seen one?

It seems that you are not affected by the T&H sensor. If you receive it, GW1000 will remember the ID.
Can you store all the HTTP packets? We can analyze it the next time something goes wrong.

[andyk1]

That makes sense. I don’t have any outdoor sensors yet. That was just the data coming from the gw1000 without any additional sensors. I guess once I install the outdoor sensors it should pickup “tempf’ and everything should start working correctly.

Thanks

I am also using the GW1000b but it is getting it's data from the ws-2902's array which includes all the parameters you are all using. Not sure how an outdoor temp/Hum sensor (WH32) I think would help. Receiving data from 2 outdoor outdoor sensors would be bumping heads if I am reading correctly some of you are using.

The only issue I have with the gw1000b is the pressure accuracy. It does not seem to have temperature compensation formulated correctly as the ObserverIP does which is rock solid except for the occasional lockups which the gw1000b does not suffer from. Has not locked up once since I got it in early may.

You can see this pressure issue I have between the two in my two WU accounts from the same location. https://www.wunderground.com/dashboard/pws/KOKNICOM2 is supplied by a WS2902, a meteobridge and an ObserverIP. My second site is https://www.wunderground.com/dashboard/pws/KOKCHOCT15 supplied by the same WS2902 array and the ecowitt gw1000b only. You can see the pressure/barometric differences between the two. I can calibrate the two but after a 10 degree (F) the pressure on the gw1000 is off by a few inHg's. I only use the ObserverIP's data to report to CWOP https://weather.gladstonefamily.net/site/F2084.

I haven't heard or read anywhere if Ambient weather will be picking up there version of the GW1000 but it would be nice to finally get rid of the ObserverIP's issues.

I also read somewhere there is already a replacement/update in the works for the GW1000b and forgot what it is called but a google search may help you find it.

Andy

[galfert]

There is no temperature compensation for barometric pressure on the ObserverIP.
The ObserverIP is not better than the GW1000 for barometric pressure.
What I think you are experiencing on the ObserverIP is is data averaging as I've noticed it responds slowly to changes in every measurement.
I'm able to calibrate my GW1000 and ObserverIP and they match perfectly over time (highs and lows for the day are the same). Perhaps they aren't a match at every given moment but that is a fault of the ObserverIP not the other way around, as I said it reacts slower. The ObserverIP also only updates data every 30 seconds and the GW1000 does it every 16 seconds. These are two separate issues. I'm not saying that the ObserverIP is a few seconds slow. It's actually much slower than that because I see evidence of data averaging.
Since you have a GW1000 and a Meteobridge there is no good reason to feed the Meteobridge data from the ObserverIP.  The ObserverIP is terrible in comparison to the GW1000 when in use with a Meteobridge.
Using the GW1000 for the Meteobridge also let's the Meteobridge have access to all sensors (that's just a plus and not the real reason the GW1000 is better).

Ambient has told me that they plan on carrying a successor to the ObserverIP which they informally told me was potentially to be called ObserverIP 2. It is most probably their version of the GW1000.

The GW1000 is not due to be replaced in name. The newer ones are still called GW1000. They look the same. The only difference is a bit better range performance for acquiring RF signal. Everything else is the same. You don't need a new one if the old one is working.

Throw the ObserverIP out. I did. You don't need it. It's crap. Getting data from ObserverIP via screen scraping as the Meteobridge does is unreliable and the data is not as good. The GW1000 provides the Meteobridge better data using proper local API.

PS - nobody calls it a GW1000B. It's just a GW1000. The B just means you have a 915 MHz version.

[galfert]

You can see the effects of the ObserverIP data averaging in this comparison I posted some time ago.
https://www.wxforum.net/index.php?topic=34976.0

Even though I only posted a picture of the temperature and dew point, the pressure graphs show the same smoothing and averaging.

Having changed my Meteobridge to be feed by the GW1000 proved that it was the ObserverIP's fault.

[galfert]

Why is KOKCHOCT15 set to hardware type Raspberry Pi?
I'd set it to WS-2902A or WS-2000.

[StephenR0]

It seems that you are not affected by the T&H sensor. If you receive it, GW1000 will remember the ID.
Can you store all the HTTP packets? We can analyze it the next time something goes wrong.

I think that's a good idea.  Let me see what I can arrange.  It certainly doesn't seem to happen very often.  But it would be good to have something to analyze if it happens again.

[andyk1]

There is no temperature compensation for barometric pressure on the ObserverIP.
The ObserverIP is not better than the GW1000 for barometric pressure.
What I think you are experiencing on the ObserverIP is is data averaging as I've noticed it responds slowly to changes in every measurement.
I'm able to calibrate my GW1000 and ObserverIP and they match perfectly over time (highs and lows for the day are the same). Perhaps they aren't a match at every given moment but that is a fault of the ObserverIP not the other way around, as I said it reacts slower. The ObserverIP also only updates data every 30 seconds and the GW1000 does it every 16 seconds. These are two separate issues. I'm not saying that the ObserverIP is a few seconds slow. It's actually much slower than that because I see evidence of data averaging.
Since you have a GW1000 and a Meteobridge there is no good reason to feed the Meteobridge data from the ObserverIP.  The ObserverIP is terrible in comparison to the GW1000 when in use with a Meteobridge.
Using the GW1000 for the Meteobridge also let's the Meteobridge have access to all sensors (that's just a plus and not the real reason the GW1000 is better).

Ambient has told me that they plan on carrying a successor to the ObserverIP which they informally told me was potentially to be called ObserverIP 2. It is most probably their version of the GW1000.

The GW1000 is not due to be replaced in name. The newer ones are still called GW1000. They look the same. The only difference is a bit better range performance for acquiring RF signal. Everything else is the same. You don't need a new one if the old one is working.

Throw the ObserverIP out. I did. You don't need it. It's crap. Getting data from ObserverIP via screen scraping as the Meteobridge does is unreliable and the data is not as good. The GW1000 provides the Meteobridge better data using proper local API.

PS - nobody calls it a GW1000B. It's just a GW1000. The B just means you have a 915 MHz version.

Hi Galfert!!!

I'll try to answer all your points and questions as I remember them in order.

I am not aware of or know if OIP has temp compensation built into the software or not but it seems as far as CWOP is concerned the more accurate of the Two OIP and gw1000 (dropping the b for you... ).

I think you are right about the averaging on the OIP also as with CWOP and other sites I feed the only take data every 5 minutes or so like you said and that's a good thing. My meteotemplate site also uses this method to take measurements as I'm sure your aware.

After calibrating both OIP and the gw1000 to match exactly (Pressure only) as all the other readings match exactly with no other changes by me required ever. I am not sure why over time and temp changes of 10 degrees Fahrenheit for me in the US but there is a slight .03 inHg just about every time. Yes I know the OIP and gw1000 have different update internals and for me the OIP is every 16 sec and the gw1000 every 60 seconds but I usually wait 2-3 or 5-6 minutes to wait on the locals reads to verify the changes.

I very much like the gw1000 way more than the OIP as far as reliability of the hardware and software is concerned but the slight pressure differences over time (not a few seconds or even hours) but for CWOP's presumed accuracy is concerned. That is another point that is a problem that I know is a pain for everyone feeding them as way more factors go into that than my sites accuracy is concerned. I don't pay attention to every sites readings as allot are almost always more than .10 or more off in inHg. I don't even pay attention to my local airport readings as we all know they don't really recalibrated their high dollar weather instruments but maybe every 6 months or a year if then.

My problem is that it reads off and I have been fighting this problem since I got my gw1000 back in early May of this year.

There is a temperature compensation formula for every 10 degree of temp changes and humidity (weight of air and temp) that is .003 or .03 I don't remember which off hand but most software has this built in. Not sure if OIP or the gw1000 has this but for me the OIP if closest. I may have a bad gw1000 which I considered replacing but I got word a newer update to the gw1000 is in the works. I am just guessing it may be the fine offsets WS-80 which we aren't supposed to know about yet. (Man I wished I could have been selected to be a tester) I am going to wait for that before making hardware changes.

Another problem is with the Ambient Weather's WS-2902's console which has the same pressure offset problem and sometimes even worse. I am no longer able to access the console in WiFi pairing mode to make any calibration changes on it. Hardware issue or software since last update a few months back but I really don't need it as I wanted to update to the WS-2000 console anyway. Now not sure with all the Ambient Weather and fine offset changes coming down the road.

I was waiting for the VP3 but like everyone, seems it's vaporware as far as vantage pro goes. Either way, Ambient and Ecowitt/Fine offset has some really good and I think for the money better hardware. It's just a waiting game on who releases what sooner than the other.

I like the fact that meteobridge jump in and supported the gw1000 soon after release. I like the MB personally. easy, simple and reliable with almost never an issue unlike with the OIP. I would have no issue with the gw1000 other than my pressure issue.

Re-reading your post I think your right about the newer version of the gw1000 only having a longer range off 200 yards verses the 100 feet they have now but I don't have an issue at 150 feet or so through 2 walls one being brick siding.

I would throw the OIP out now but...(so aggravated with it)  well I stated that above and it... for now makes a decent backup for the gw1000 and the CWOP thing.

You have an eccellent write up on the OIP I read while composing this.

The reason I have Raspberry Pi still set on my KOKCHOCT15 site is it was running on a Ras Pi way back and I haven't changed it. Being feed by the GW1000 Thanks for reminding me. It mostly uses the same protocal's as the OIP and GW1000 but I'll get around to changing it.

Andy