New GW1000 Driver available for testing

[NanoG5Kite]

Just recocnized the very promising announcement in the developer forum...:

https://groups.google.com/forum/#!topic/weewx-development/bhtsW6WWtvQ

On Github:

https://github.com/gjr80/weewx-gw1000

Will test this API driven driver certainly during the weekend.

Matthias

[galfert]

For anyone discussing this new GW1000 API driver in the WeeWX development section STOP. Use this user section instead to discuss its use.

[steeple ian]

???

On Thu, 23 Jul 2020 at 19:39, galfert <gal...@gmail.com> wrote:

For anyone discussing this new GW1000 API driver in the WeeWX development section STOP. Use this user section instead to discuss its use.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/91d513a8-cf9a-4cf2-8e16-261a02b67bebo%40googlegroups.com.

[galfert]

There is a thread in the developer section where some questions were asked that were not directly related to development. This thread is good. I'm just inviting people to ask their questions here in this thread rather than in the developer section.

On Thursday, July 23, 2020 at 2:56:51 PM UTC-4, steeple ian wrote:

???

On Thu, 23 Jul 2020 at 19:39, galfert <gal...@gmail.com> wrote:

For anyone discussing this new GW1000 API driver in the WeeWX development section STOP. Use this user section instead to discuss its use.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[Bill Arthur]

FYI:
wget -P /var/tmp https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/weewx-gw1000-0.1.0b4.tar.gz 

gives me an Error 404 

[Bill Arthur]

This link works: https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/gw1000-0.1.0b4.tar.gz

[Bill Arthur]

I couldn't get it to run from the command line.
When I  did   python -m user.gw1000 --help
I get   /usr/bin/python: No module named user.gw1000

But I have it up and running, everything looks good on my Seasons page.
I'll give the data a closer look tomorrow.

But I'm scratching my head trying to find how to specify the IP address in weewx.conf
I have three GW1000s here, I have no idea which one is being used  

[gjr80]

My apologies all round Bill, a few typos and a wrong assumption about package installs - have rewritten and simplfied the GitHub readmes this afternoon. They should be correct now. Perhaps a bit late now but to run the driver directly the following should work:

$ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --help

When you used wee_config --reconfigure to reconfigure WeeWX to use the driver it should have prompted you for the IP address, unfortunately I included --no-prompt in the wee_config command and that left you with no IP address set (in which case the driver uses the first GW1000 that replies). You can run the following command and step through the prompts until you are asked for an IP address and then enter the IP address of the GW1000 you wish to use:

$ wee_config --reconfigure --driver=user.gw1000

Alternatively you can just edit weewx.conf and add a line ip_address under [GW1000]:

[GW1000]
    ....
    ip_address = 1.2.3.4

Either way you will need to restart once you have set the IP address.

Gary

[NanoG5Kite]

Yet not working for me...:

root@DietPi:~# sudo /home/weewx/bin/wee_extension --install=/var/tmp/gw1000-0.1.0b5.tar.gz
Request to install '/var/tmp/gw1000-0.1.0b5.tar.gz'
Extracting from tar archive /var/tmp/gw1000-0.1.0b5.tar.gz
Saving installer file to /home/weewx/bin/user/installer/GW1000
Saved configuration dictionary. Backup copy at /home/weewx/weewx.conf.20200724165212
Finished installing extension '/var/tmp/gw1000-0.1.0b5.tar.gz'
root@DietPi:~# PYTHONPATH=/home/weewx/bin python -m user.gw1000 --test-driver
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/weewx/bin/user/gw1000.py", line 267, in <module>
    import weecfg
  File "/home/weewx/bin/weecfg/__init__.py", line 22, in <module>
    import configobj
ImportError: No module named configobj
root@DietPi:~#

[steeple ian]

Hi Bill,

Are you still using the Weather34 skin. If so, I am interested what barometer reading you are displaying when using the gw1000 driver.

Thanks,

Ian 

[gary....@gmail.com]

I see that b5 maps 'luminosity': 'light'

In my weewx.conf I have

radiation = light / 126.7 if light is not None else None

To display that value in the Belchertown skin I have 

station_observations = barometer, dewpoint, outHumidity, rainWithRainRate, radiation, UV

When running with the Interceptor driver I have a value, running with this driver I have N/A

Any ideas?

[NanoG5Kite]

Got it running by setting Python 3.5 to default this way:

https://raspberry-valley.azurewebsites.net/Python-Default-Version/

Matthias

[Bill Arthur]

Hi Ian
No, I don't have Weather34 on the RasPi that I'm testing the GW1000 extension, it's a fresh install.
It'll be a while until I'm ready to modify the RasPi that has Weather34. Sorry.

[steeple ian]

Hi Bill,

No need to be sorry. Just wanted to exchange notes on experiences. I assume you then using the default Seasons skin. How is that looking?

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/6cb996ae-fc26-4cb8-85ce-b408a9cefa5dn%40googlegroups.com.

[Bill Arthur]

Ian,
Yes, just the simple Seasons skin for now. I now have 12 hours of data and it's looking good. 
I've compared it to my weather station console and the data all looks correct.

[steeple ian]

Hi Bill,

What sensors do you have connected?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/bf6c137d-9973-4a6c-896f-6d43b535ab94n%40googlegroups.com.

[Bill Arthur]

Gary,
No need for apologies. I'm glad that I was able to spot these things. And in a small way, I feel like I'm helping improve it for everyone. 

[Bill Arthur]

Hi Ian,
I have the Ambient Weather WS-2902 array:  temperature, rainfall, humidity, wind speed & direction, UV and solar.  Indoor and pressure is from the GW-1000

[steeple ian]

That is the same array that I am using with gw1000 except I do not have a console. Does this show up as WH65? I have anomaly with the barometer but I cannot understand why. Have you changed the sensor map at all?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/3edbf050-313a-49ec-9fab-3f1faf99beddn%40googlegroups.com.

[Bill Arthur]

I started as you and later added a WiFi-less console.  I'm not sure where to look for the WH65 designation. 
No, I didn't change the map. I was unable to run the driver directly to test, so I just launched it blindly... and it worked.
I am seeing an anomaly with pressure, too. I'm looking at the output as reported to CWOP. I'm seeing 989mb where I expect 1019mb
So...I have some work to do.

[steeple ian]

That’s exactly what I am seeing. I am going to look at the interceptor map for WH65 and see where things appear to deviate.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/48e7cbff-e6d4-4b0b-8b5c-c28ff29b623en%40googlegroups.com.

[pa...@pauland.net]

Bill

About not being able to run the driver directly, If you have python 2 on your system, but have installed WeeWX to use python 3 you may not have installed the prerequisites for python 2. If you have a setup.py install and try to run:

PYTHONPATH=/home/weewx/bin python -m user.gw1000 --test-driver

You will get an error message that includes "ImportError: No module named configobj"

What you can do is specify python 3 on the command and it should run fine:

PYTHONPATH=/home/weewx/bin python3 -m user.gw1000 --test-driver

Have Fun!

Paul

[Vetti52]

When running reconfigure with prompts, there are two changes, that occured in my case without asking:

group_pressure turns to inHg, and group_speed and group_speed2 turn to mile_per_hour and ~2 respectively.You better diff old and new version before restarting.

In addition, 'radiation': 'solar_radiation', is missing in default_field_map in gw1000.py.

hopefully easy to correct.

Thanks

Peter

Am Freitag, 24. Juli 2020 15:44:57 UTC+2 schrieb gjr80:

[gjr80]

On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:

When running reconfigure with prompts, there are two changes, that occured in my case without asking:

group_pressure turns to inHg, and group_speed and group_speed2 turn to mile_per_hour and ~2 respectively.You better diff old and new version before restarting.

This almost certainly is an issue with wee_config and your config; the GW1000 driver has no ability to change WeeWX units/unit system. I do have a vague recollection that there was a previous issue that was raised (and fixed) regarding unexpected unit changes (it may have been on upgrade). I will make a note to look into this.

 

In addition, 'radiation': 'solar_radiation', is missing in default_field_map in gw1000.py.

This is intentional. Unfortunately the GW1000 API has no ability to obtain what in WeeWX parlance we know as field radiation (solar insolation). The API can return what the API terms 'light' or luminosity in Lux as well as UV index and what the API terms 'UV' in microWatts per square metre. Some folks derive field radiation from luminosity though I believe the relationship is somewhat complex. It's not the place for the GW1000 driver to derive obs such as radiation from other obs, rather derived observations should be derived by the StdWXCalculate service. Whilst the StdWXCalculate service does not really lend itself at present to the addition of user defined derived obs, a user can add simple derived obs by adding appropriate entries under [StdCalibrate] [[Corrections]] in weewx.conf, for example:

[StdCalibrate]
    [[Corrections]]
        new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)

would create the field new_obs using the (nonsense) formula shown. The default GW1000 driver mapping passes the light, UV and UV index observations through to the WeeWX loop packet (UV index is mapped to WeeWX field UV) so they are available for use in StdCalibrate as required.

Gary

[gjr80]

I am not sure if this impacts on the WH65 issue mentioned below but I now have the driver distinguishing whether there is a WH65 or WH24 connected to the GW1000. This will (I hope) have a flow on affect on battery status fields but given the manner in which the API works I don't believe it will impact any weather related observations. I should have b6 in the next couple of days.

Gary

On Saturday, 25 July 2020 04:50:38 UTC+10, steeple ian wrote:

That’s exactly what I am seeing. I am going to look at the interceptor map for WH65 and see where things appear to deviate.

[Greg Troxel]

gjr80 <gjrod...@gmail.com> writes:

> Some folks derive field radiation from luminosity though I believe the
> relationship is somewhat complex.

I'm not at all clear on what labels the various stations use.

I would use "solar irradiance" or less pedantically "solar radiation".
The term "field radiation" is interesting and I have not previously
encountered it.

For the arriving light per unit area, the term is Illuminance.
Luminosity strictly refers to total power departing a light source.

https://en.wikipedia.org/wiki/Solar_irradiance
https://en.wikipedia.org/wiki/Illuminance

One cannot accurately convert illuminance to irradiance, because
illuminance applies wavelength-based weights to power based on human
visual response. So, two light sources arriiving at a surface, having
the same illuminance, will in general have differenrt irradiances. But
people assume "sunlight" and then onc can make a reasonable
approximation.

My previous rant:

https://github.com/weewx/weewx/wiki/Watts-and-lux

and something I just found that seems interesting

https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance

> It's not the place for the GW1000 driver to derive obs such as
> radiation from other obs, rather derived observations should be
> derived by the StdWXCalculate service.

Agreed.

[gjr80]

On Sunday, 26 July 2020 08:55:08 UTC+10, Greg Troxel wrote:

gjr80 writes:

> Some folks derive field radiation from luminosity though I believe the
> relationship is somewhat complex.

I'm not at all clear on what labels the various stations use.

I would use "solar irradiance" or less pedantically "solar radiation".
The term "field radiation" is interesting and I have not previously
encountered it.

You will notice the highlight on the word radiation (but not the word field) in my original post, this was in reference to the WeeWX field named radiation, not to something known as 'field radiation'.

 

For the arriving light per unit area, the term is Illuminance.
Luminosity strictly refers to total power departing a light source.

https://en.wikipedia.org/wiki/Solar_irradiance
https://en.wikipedia.org/wiki/Illuminance

One cannot accurately convert illuminance to irradiance, because
illuminance applies wavelength-based weights to power based on human
visual response.  So, two light sources arriiving at a surface, having
the same illuminance, will in general have differenrt irradiances.  But
people assume "sunlight" and then onc can make a reasonable
approximation.

My previous rant:

  https://github.com/weewx/weewx/wiki/Watts-and-lux

and something I just found that seems interesting

  https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance

I don't disagree but irrespective the GW1000 API has no ability to return data that is suitable to be placed in the WeeWX field called radiation. If the user wishes to derive values to place in any WeeWX fields that of course is their call and whilst WeeWX has the machinery to do such things it is left as an exercise for the user.

Gary

[Greg Troxel]

gjr80 <gjrod...@gmail.com> writes:

> You will notice the highlight on the word radiation (but not the word
> field) in my original post, this was in reference to the WeeWX field named
> radiation, not to something known as 'field radiation'.

Sorry, reading in plain text so I did not actually notice that :-)

> I don't disagree but irrespective the GW1000 API has no ability to return
> data that is suitable to be placed in the WeeWX field called radiation. If

Sure, didn't mean to come across as questioning that as all.

> the user wishes to derive values to place in any WeeWX fields that of
> course is their call and whilst WeeWX has the machinery to do such things
> it is left as an exercise for the user.

In the glorious future, there might be a stdconvert routine to create
radiation from illuminace, perhaps enabled with a config variable
becusae 1) not everybody wants it and 2) it's not really sound. I meant
to be in agreement and offer pointers to further info for people looking
into this.

[gjr80]

Agreed completely :)

Gary

On Sunday, 26 July 2020 09:37:41 UTC+10, Greg Troxel wrote:

[gjr80]

Whilst there definitely is nothing in the API for retrieving what WeeWX knows as 'radiation', there is a calibration setting labelled 'SolarRad Gain' in the WS View app (interestingly there is no gain setting for anything to do with 'light', luminosity, illuminance etc so it could be a mis-labelling/inconsistent labelling of the parameter in the app). If you have been obtaining 'radiation' data via the interceptor driver can you please give me some further details, it may be a case of the GW1000 deriving a radiation value suitable for on-line weather services such as WU and that is how WeeWX has obtained the 'radiation' data or, more unlikely, it may be that there is something else available in the API that is not documented.

Gary

[NanoG5Kite]

Is‘t it better to post possible errors on Githup? In addition to Radiation I‘m also missing rain and current rain rate now.

Will open issues on Github now.

[NanoG5Kite]

https://github.com/gjr80/weewx-gw1000/issues

[gjr80]

I don't mind, Github is probably easier for tracking and hopefully keeps one problem per issue unlike posts here which tend to grow many heads. All I ask is that some appropriate details of the problem are included (eg an explanation of the problem and a startup debug log extract - a list of attached sensors/stations would help too) rather than 'xxxx does not work'

Gary

[gjr80]

Hmm, seems GitHub has decided not to notify me of new issues/posts to issues on my own repos. I have noticed a few there now and will work through them IDC.

Gary

[Vetti52]

The setting 'radiation': 'solar_radiation', is copied from interceptor.py, which is propagated into radiation in weewx. When changing to gw1000 api driver, the data are lost. So I went back to the interceptor.py. You can see the little gap in the graph during my test of the gw1000 driver:

I have changed the title into German in Weewx.conf

[[[[Generic]]]]

                radiation = Sonnenstrahlung

So, somewhere the observation type radiation has to be filled with data. In interceptor.py, this is done by 'solar_radiation' which comes from the ecowitt-customized upload. I would just like to continue with these data.

Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:

[gjr80]

Can you please issue the following two commands(assuming a setyp.py install) and post the console output and (WeeWX) log output from each:

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data

If possible, would also help to know what solar radiation value you are seeing at the time the commands were executed. Also, no need to stop the interceptor, gw1000 will happily interrogate the GW100 even while the GW1000 sends to the interceptor. Note you may have to change the python command to python2 or python3 if WeeWX is set to run under a different python version to the default on your system.

Gary

[NanoG5Kite]

Several samples posted on Github.... seems to be e.g. uv: 9.1 x 10 = 91,9w/m²

Matthias

[Vetti52]

That's the output:

root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m user.gw1000 --debug=3 --sensors
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

Sensor     Status
WH65       sensor ID: f9  signal: 0  battery: 4
WS68       sensor is registering...
WS80       sensor is registering...
WH40       sensor is registering...
WH32       sensor is registering...
WH31 ch1   sensor is registering...
WH31 ch2   sensor is registering...
WH31 ch3   sensor is registering...
WH31 ch4   sensor is registering...
WH31 ch5   sensor is registering...
WH31 ch6   sensor is registering...
WH31 ch7   sensor is registering...
WH31 ch8   sensor is registering...
WH51 ch1   sensor is registering...
WH51 ch2   sensor is registering...
WH51 ch3   sensor is registering...
WH51 ch4   sensor is registering...
WH51 ch5   sensor is registering...
WH51 ch6   sensor is registering...
WH51 ch7   sensor is registering...
WH51 ch8   sensor is registering...
WH41 ch1   sensor is registering...
WH41 ch2   sensor is registering...
WH41 ch3   sensor is registering...
WH41 ch4   sensor is registering...
WH57       sensor is registering...
WH55 ch1   sensor is registering...
WH55 ch2   sensor is registering...
WH55 ch3   sensor is registering...
WH55 ch4   sensor is registering...

root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m user.gw1000 --debug=3 --live-data
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1005.9, datetime: 1595765605, daymaxwind: 8.4, gustspeed: 3.0, inhumid: 76, intemp: 20.7, light: 117722.0, outhumid: 82, outtemp: 19.8, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.1, uv: 367.5, uvi: 9, winddir: 27.8, windspeed: 1.8

Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:

[Vetti52]

Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1006.2, datetime: 1595765980, daymaxwind: 8.4, gustspeed: 0.7, inhumid: 76, intemp: 20.7, light: 24226.0, outhumid: 82, outtemp: 19.7, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.4, uv: 49.1, uvi: 1, winddir: 27.4, windspeed: 0.3

solar radiation acutally is

853 W/m²

Sorry, I forgot

Peter

[NanoG5Kite]

It´s in process on Github now... better to post there.

https://github.com/gjr80/weewx-gw1000/issues/6

[gjr80]

I have released v0.1.0b6 on Github. A summary of the significant changes can be found against the v0.1.0b6 release on Github. It has not (fully) addressed the issue of some battery states not making their way through to the loop packets, unfortunately that is still a  work in progress.

Those that have already installed the driver can download and install v0.1.0b6 using the following commands depending on your WeeWX install type:

for setup.py installs:

$ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.py
$ sudo wget -P /home/weewx/bin/user https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

for package installs:

$ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/gw1000_orig.py
$ sudo wget -P /usr/share/weewx/user https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

There has been no change to the [GW1000] structure so you can just restart WeeWX/run v0.1.0b6 directly without further changes.

Gary

[Bill Arthur]

Thanks Gary. 
Your instructions worked perfectly.

I'm still seeing a couple of things. Here are links to two reporting stations. They both receive data from the same GW-1000
The -1 station uses the old push method. The -5 station uses the new API method.  I'm seeing differences in wind direction and barometer
-1 Station
-5 Station

[steeple ian]

Bill, 

I will send you the sensor mapping that you need to use later today when I am near my computer.

Ian

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/871c9da9-3218-4bcf-9b14-321678e4e8f0n%40googlegroups.com.

[gjr80]

v0.1.0b6 added the --system-params command line option to the driver to display a number of GW1000 system parameters, eg:

GW1000 frequency: 0 (433MHz)
GW1000 sensor type: 0 (WH24)
GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
GW1000 timezone: 94

Whilst I know which byte to look at for the frequency, and what value represents 433MHz as used on my GW1000, I do not know what value is used to represent operation on 868MHZ and 915MHz. Was wondering if any users of v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the frequency their GW1000 uses as well as the output from the following command (adjusting python version and path as required):

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params

I don't believe any of the information is particularly sensitive, but if you are concerned I really just need to know the frequncy your GW1000 operates on as well as the line starting 'GW1000 frequency'. If you don't know what frequency your GW1000 operates on it should be printed on the back of your GW1000 (well at least mine is like that!)

thanks,

Gary

[gary....@gmail.com]

This is a 915 MHz unit

Interrogating GW1000 at 10.10.100.125:45000

GW1000 frequency: 2 (Unknown)

GW1000 sensor type: 1 (WH65)

GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)

GW1000 timezone: 19

[gary....@gmail.com]

Though this is not a WH65

I have a GW1000, WS68, WH40, WH32-EP, WH32B

[gjr80]

Thanks, I am guessing 868MHz will be 1 but we shall see.

Gary

[gjr80]

Yes, not surprised, am still working through sensor names and the API to get the code right. Fortunately, this disconnect does not affect the observational data only battery state field names and some of the 'informational' commands such as --system-params. Once I get the battery states into the loop packets they can be easily fixed (temporarily) with a few field map extensions.

Gary

[steeple ian]

Gary,

This is my output (my GW1000 is 868MHz): -

Using configuration file /home/weewx/weewx.conf

Interrogating GW1000 at 192.168.1.234:45000

GW1000 frequency: 1 (Unknown)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-28 07:37:39 UTC (1595921859)
GW1000 timezone: 39

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d6b32000-d7a8-483d-9822-6b47d24e1b23o%40googlegroups.com.

[steeple ian]

So with a modification to the parameters section I get: -

Using configuration file /home/weewx/weewx.conf

Interrogating GW1000 at 192.168.1.234:45000

GW1000 frequency: 1 (868Mhz)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-28 07:52:28 UTC (1595922748)
GW1000 timezone: 39

[gjr80]

Thanks Ian, that confirms the last one.

Gary

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

[gjr80]

I have released v0.1.0b7 on Github. b7 adds the battery states to the default field map which should see battery states appear in the loop packets. I expect there will still be some naming issues, especially with WH65 and WH32. b7 also fixes a n issue where wind direction was wrongly decoded..

Those that have already installed the driver can download and install v0.1.0b7 using the following commands depending on your WeeWX install type:

for setup.py installs:

$ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.

py
$ sudo wget -P /home/weewx/bin/user https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py

for package installs:

$ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/gw1000_orig.

py
$ sudo wget -P /usr/share/weewx/user https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py

There has been no change to the [GW1000] structure so you can just restart WeeWX/run v0.1.0b7 directly without further changes.

Gary

[gjr80]

Bill, the incorrect wind direction decode likely accounts for your wind direction discrepancies. Not sure about the pressure issues, as far as I am aware pressure is being correctly decoded. I will look into it further in the morning.

Gary

[gary....@gmail.com]

My wind results have been corrected.

[Paul R Anderson]

Gary

First just a note that I was running v0.1.0b6 as a service and my GW1000 lost it's WIFI connection. Actual dropped WIFI connecting by the GW1000.

Looking at the log I see that  the driver worked perfectly, it logged a connection failure after 3 attempts, but weewx itself kept running so that only the supplemental data from the GW1000 was lost. Once I relocated the GW1000 to a better location , without restarting WeeWX, the GW1000 data started flowing again. Perfect just the behavior I would want.

Just updated to v0.1.0b7 here is what is returned for battery status:

wh31_ch2_batt: 0, wh31_ch4_batt: 0, wh31_ch5_batt: 0, wh31_ch7_batt: 0, wh57_batt: 5

So all sensors recognized, not sure of the meaning of "0" and "5" and why wh57 returns "5" All sensors installed with new batteries 3 days ago .

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%40googlegroups.com.

[NanoG5Kite]

Regarding Evowitt Battery Status. There are new Sensors like the WH 57 which report the battery status from 0-5 (5=fully charged), but former sensors like the 7in1 with 0 or 1 (1=empty, to be replaced asap). There was a useful threat in the wxforum.net telleing which sensors show which kind of level, but can‘t find it back currently...

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[NanoG5Kite]

Battery status on different devices:

https://www.wxforum.net/index.php?topic=37373.msg408190#msg408190

Matthias

[gjr80]

I will put a battery state table in the driver wiki today.

Gary

[gjr80]

I have added a page to the GW1000 driver wiki with details of the battery state information provided by the driver. The details on the page a a combination of details specified in the API, information posted on wxforum.net and anecdotal evidence obtained during development of the driver. Please let me know if you observe/notice any discrepancies.

[Graham Eddy]

i expect my new GW1000 (to augment my vp2) to arrive monday so have started planning…

looking at gw1000 driver default_field_map, there seem to be a few mislabelled mappings into wview_extended.schema and weewx.units.obs_group_dict, they should be:

gw1000 → weewx

rainday → dayRain (not passed thru unchanged)

rainhour → hourRain (not passed thru unchanged)

rainmonth → monthRain (not passed thru unchanged)

uvi → UV (misspelt as uv)

uv → radiation (misspelt as uvRadiation)

[gjr80]

I must admit that I only looked at the wview-extended schema when developing the default field map and did not consider weewx.units.obs_group_dict, though it makes sense to use weewx.units.obs_group_dict where possible. Will change the default mapping for the three rain fields as suggested.

Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been mapped to ‘UV’.

The GW1000 API supports two UV related observations, these are labelled UV and UVI with supporting comments that UV is in micro watts/sq metre and UVI is an index from 0 to 15. UVI is mapped to WeeWX field UV. The GW1000 UV value is not what WeeWX knows as radiation. The discussion at https://github.com/gjr80/weewx-gw1000/issues/6 revealed the GW1000 derives what WeeWX knows as radiation from a luminosity observation. Also, the units don’t gel, the GW1000 UV field uses 2 bytes and thus a maximum of 65536 micro watts/sq metre, solar isolation on the other hand is of the order of hundreds of watts/sq metre. I am happy to be corrected but for now will be leaving uvRadiation mapping as is (actually will change uvRadiation to uvradiation).

Changes will appear in b8.

Gary

[Graham Eddy]

> Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been mapped to ‘UV’.

i misread the code and thought the case was wrong (it isn’t). i blame my spectacles. cheers

[Paul R Anderson]

Should we map  'altimeter': 'relbarometer' ?

Gw1000 produces 2 pressure readings:

As defined by Ecowitt Calibration of barometric pressure settings

Absolute Pressure

"Absolute barometric pressure, can be calibrated at manufacturing time by comparing with a precise instrument that measures pressure at the same location. In practice, sometimes small adjustments of a few hPa may be needed"

Relative Pressure

"The relative pressure represents what the air pressure would indicate if your station was at sea level and depends on the altitude of your console and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use the  WS View app to set 2 offsets:

Abs Offset

Rel Offset

To set Rel Offset they have you determine station elevation and direct you to a site that produces a offset based solely on elevation. So Rel Offset is a STATIC offset applied against your Absolute Pressure. It never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will always read 6.0 hPa higher than Absolute Pressure.

As we see in WeeWX Wiki

Station or Gauge Pressure (key pressure): This is the absolute, raw pressure as measured by your instrument. It is not corrected for altitude or pressure. Pilots call this QFE

Sea-level Pressure (barometer): This is the pressure corrected for altitude, temperature, and (frequently) humidity. Pilots call this QFF. This is the value displayed by the standard skin.

Altimeter Pressure (altimeter) : This is the pressure corrected for altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way to apply a temperature compensation I believe that mapping   'altimeter': 'relbarometer' may be more appropriate. StdWXCalculate will calculate barometer for us when it appears in a template. 

Thanks

Paul

You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com.

[gjr80]

Thanks for the input Paul, I believe your are correct. As soon as you see Rel Offset being calculated as an altitude only offset it is pretty clear it is altimeter and that means the pressure you are offsetting from must be pressure. I am not sure why I put down barometer, perhaps it was the liberal of the word barometer throughout the Ecowitt calibration instructions.Will be fixed in b8.

One nagging thought I have have had this afternoon is what pressure value is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on the face of it that is the one pressure value the GW1000 does not have. I did set my GW1000 to do a customised upload in WU protocol to one of my VMs and it included fields named baromabsin and baromrelin being the two GW1000 pressure values in inches Hg. If I had the time I would intercept the GW1000 actual upload to WU but I somehow suspect it will be the same.

Gary

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

[gjr80]

I have released v0.1.0b8 on Github which:

- fixes an incorrect mapping of GW1000 field relbarometer that will have resulted in incorrect barometer and altimeter fields in WeeWX

- changes default field mappings of GW1000 fields rainhour, rainday, rainweek, rainmonth, rainyear, raintotals and rainevent to hourRain, dayRain, weekRain, monthRain, yearRain, totalRain and stormRain respectively

- changes default field mapping of GW1000 field uv from uvRadiaition to uvradiation

- fixes a bug that resulted in battery state mappings not being included in the default field map displayed with the --default-map command line option

- adds extractors for all fields from default field map (incl battery state map) that need an extractor function other than avg

As b8 includes extractor functions for a number of fields b8 requires changes to weewx.conf. For this reason the best way to upgrade to or install b8 is by downloading the extension package and installing using wee_extension. I will update the manual install instructions on the GW1000 driver wiki shortly. Upgrading by installing the extension package should retain any customised settings you may have made to weewx.conf, in any case a timestamped backup copy of weewx.conf is made by wee_extension and it might pay to check that any customisations in the [GW1000] stanza have been retained.

For those that may have incorrect barometer/altimeter data as a result of the incorrect relbarometer mapping, users of WeeWX 4.0.0 or later should be able to recalculate the incorrect data by first deleting the incorrect barometer and altimeter data from the archive and then running wee_database using the --calc-missing action. You will then need to rebuild your daily summaries using --rebuild-daily. i will publish some detailed instructions later tonite.

Gary

[gary....@gmail.com]

I have installed b8 successfully and note that nothing was changed in my weewx.conf except the addition of the extractors.

[gjr80]

Good, just check that you have [Accumulator] entries for hourRain, dayRain etc and not rainhour, rainday etc. If you don’t download the b8 extension package again and re-install. I had an upload issue with the package earlier today.

Gary

[George Alfert]

Paul,

I disagree. Simply adding a constant offset to Absolute does not give you Altimeter. I understand your point in that Altimeter is a similar thing that uses a temperature constant, but Altimeter should be something that is properly calculated from Absolute using a proper formula. I'm sure that WeeWX already has a built in conversion to get from Absolute to Altimeter. 

The only online weather service that requires Altimeter sent to them that I know of is CWOP. 

Yes there are some people that prefer to only use Altimeter and for those people there are other means to accomplish this and that would be to zero out their elevation on their consoles. 

Yes the Relative Pressure out these stations is not technically totally accurate Sea Level Pressure but perhaps that is why they call it Relative pressure and they don't try to pass it up as Sea Level Pressure. The Relative Pressure Offset is an average offset. If you were to calibrate to the exact offset for a given pressure amount you would notice that when the pressure changes that your Relative would no long match as well the Sea Level Of that you calibrated against. That is why when you figure out your Relative Offset you should be using 1013.25 hPa as your Sea Level Pressure. You can read a great deal about how to best calibrate these a Fine Offset stations on wxforum.net.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/3KF7XMLQGsA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAOAVAefsj387Cx%2B8ffLt%2BjLS3vhnrwGp2%2Bpy3zUeuc2h7etKDg%40mail.gmail.com.

[Greg Troxel]

George Alfert <gal...@gmail.com> writes:

> I disagree. Simply adding a constant offset to Absolute does not give you
> Altimeter. I understand your point in that Altimeter is a similar thing
> that uses a temperature constant, but Altimeter should be something that is
> properly calculated from Absolute using a proper formula. I'm sure that
> WeeWX already has a built in conversion to get from Absolute to Altimeter.

I was going to point this out too, that just adding a fixed offset in
hPa is not the same as applying the altitude formula.

So, from a hard-core viewpoint, perhaps the best approach is:

map absolute pressure to station pressure

ignore "relative pressure" as unsound

let StdCalculate computer altimiter pressure and barometer pressure

with an implicit

let the user calibrate the GW1000's absolute pressure, or enter in a
calibtration in StdCalibrate (or just not worry about it)

[George Alfert]

Gary,

WU expects you to upload Sea Level Pressure. The best that is an equivalence to is Relative pressure if the station has been properly calibrated. 

The Customized upload in WU format only includes baromin. It is only when you use Ecowitt format that you see baromrelin and baromabsin. 

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/3KF7XMLQGsA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a9efe943-d23e-4458-b475-3daed4d3cac5o%40googlegroups.com.

[gjr80]

The Customized upload in WU format only includes baromin. It is only when you use Ecowitt format that you see baromrelin and baromabsin.

 

Don't know what happened this afternoon, must have been tongue tied switching between Ecowitt and WU.

Yes the Relative Pressure out these stations is not technically totally accurate Sea Level Pressure but perhaps that is why they call it Relative pressure and they don't try to pass it up as Sea Level Pressure.

But it is good enough to pass off as Sea Level Pressure for WU though. :)

Looking at the WeeWX fousb driver it actually discards Relative Pressure and uses Absolute Pressure as WeeWX field pressure. WeeWX fields barometer and altimeter are calculated (by WeeWX). The interceptor driver when processing Ecowitt format messages does the same, Relative Pressure is ignored.

So it seems we have take 3 coming up.

Gary

On Thursday, 30 July 2020 21:22:26 UTC+10, galfert wrote:

Gary,

WU expects you to upload Sea Level Pressure. The best that is an equivalence to is Relative pressure if the station has been properly calibrated. 

The Customized upload in WU format only includes baromin. It is only when you use Ecowitt format that you see baromrelin and baromabsin. 

On Thu, Jul 30, 2020, 1:19 AM gjr80  wrote:

Thanks for the input Paul, I believe your are correct. As soon as you see Rel Offset being calculated as an altitude only offset it is pretty clear it is altimeter and that means the pressure you are offsetting from must be pressure. I am not sure why I put down barometer, perhaps it was the liberal of the word barometer throughout the Ecowitt calibration instructions.Will be fixed in b8.

One nagging thought I have have had this afternoon is what pressure value is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on the face of it that is the one pressure value the GW1000 does not have. I did set my GW1000 to do a customised upload in WU protocol to one of my VMs and it included fields named baromabsin and baromrelin being the two GW1000 pressure values in inches Hg. If I had the time I would intercept the GW1000 actual upload to WU but I somehow suspect it will be the same.

Gary

On Thursday, 30 July 2020 10:50:16 UTC+10, Paul Anderson wrote:

Should we map  'altimeter': 'relbarometer' ?

Gw1000 produces 2 pressure readings:

As defined by Ecowitt Calibration of barometric pressure settings

Absolute Pressure

"Absolute barometric pressure, can be calibrated at manufacturing time by comparing with a precise instrument that measures pressure at the same location. In practice, sometimes small adjustments of a few hPa may be needed"

Relative Pressure

"The relative pressure represents what the air pressure would indicate if your station was at sea level and depends on the altitude of your console and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use the  WS View app to set 2 offsets:

Abs Offset

Rel Offset

To set Rel Offset they have you determine station elevation and direct you to a site that produces a offset based solely on elevation. So Rel Offset is a STATIC offset applied against your Absolute Pressure. It never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will always read 6.0 hPa higher than Absolute Pressure.

As we see in WeeWX Wiki

Station or Gauge Pressure (key pressure): This is the absolute, raw pressure as measured by your instrument. It is not corrected for altitude or pressure. Pilots call this QFE

Sea-level Pressure (barometer): This is the pressure corrected for altitude, temperature, and (frequently) humidity. Pilots call this QFF. This is the value displayed by the standard skin.

Altimeter Pressure (altimeter) : This is the pressure corrected for altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way to apply a temperature compensation I believe that mapping   'altimeter': 'relbarometer' may be more appropriate. StdWXCalculate will calculate barometer for us when it appears in a template. 

Thanks

Paul

You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/3KF7XMLQGsA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Gary Hammer]

I have the incorrect entries and will reinstall. Luckily, my rainfall
occurred before installing this morning.

[gary....@gmail.com]

I have reinstall b8 and now have both the old and new rain related entries in weewx.conf

[[stormRain]][[hourRain]][[dayRain]][[weekRain]][[monthRain]][[yearRain]][[totalRain]]

    

[[rainevent]][[rainhour]][[rainday]][[rainweek]][[rainmonth]][[rainyear]][[raintotals]]

[gjr80]

Same data just different field name. There would be no lasting damage unless you had hourRain, dayRain, weekRain monthRain, yearRain, stormRain or totalRain in you database schema. You would have noticed some temporary errors on pages if you were using tags such as $current.hourRain, $current.dayRain etc. I suspect few if any will have noticed let alone been adversely affected.

Gary

[gjr80]

They won't cause any harm other than taking up room, you will need to manually delete the old ones.

Gary

[Paul R Anderson]

Well aware that the manner in which the Rel Offset is determined does not apply the proper standard temperature profile. That's why I said it may have been more appropriate to map it to altimeter. Reasoning was at least it was a static numeric offset, coming closer to altimeter , and certainly not even close to being proper for barometer.

Totally happy with only using the gw1000 value from Absolute Pressure as weewx key pressure. Actually had considered this option, but didn't want to raise hysteria at the thought of letting WeeWx calculate a value in software that was available in hardware.

As Tom Keffer has pointed out in the past there are many times that given the fact that some hardware has undocumeted, incorrect, or sketchy, ways of generating some variables, that WeeWx can do a much better job in software than the hardware can. But I think as users most of us are hesitant to acknowledge this and want to defer to the hardware.

[galfert]

I can see it both ways as to how to deal with data from hardware versus having WeeWX calculate it. Some users that use WeeWX would surely go nuts if what they see on their display consoles does not match what they see in WeeWX. It would certainly make calibration very difficult. Certainly I think this is not something that should be a decision for the driver to do. I feel that some controls in WeeWX are the appropriate method to deal with this as other weather software also employ this method to deal with these issues. The software should allow the user to decide if to use data as provided by the hardware of if to have WeeWX calculate it.  I think therefore the only point to debate is what should be the default action. But then again I think that is not up the driver to decide but rather for core WeeWX to decided that based on what data is available from hardware what should be the default.

[galfert]

I believe that this is exactly how Meteobridge also works. It just uses Absolute. I think this is probably the best solution.

[Paul R Anderson]

Only had my GW1000 and a few sensors since Last Saturday, just had some minor Thunderstorm activity, so first time seeing WH57 Lighting Detector work.

Lightning Last Distance 0.6 miles

Lightning Last Time 07/30/2020 06:53:04 PM
Lightning Strikes Today 73

Seemed to detect strikes within maybe at least 12 miles. Knew that it was a low end device, so I am very happy with the way it performed. And yes I Am like a little kid... doesn't take a lot to amuse me 😁

  

[gjr80]

To complete the trifecta b9 will (by default) map the GW1000 Absolute Pressure to WeeWX field pressure and the StdWXCalculate service can then be used to calculate WeeWX fields barometer and altimeter. GW1000 Relative Pressure will be mapped through (again by default) to WeeWX field relbarometer. As such it will be available for use by folks in reports via the $current.relbarometer tag but will essentially have no other affect unless folks include relbarometer in their db schema. Should anyone want to map GW1000 Relative Pressure to WeeWX field barometer or altimeter (or for that matter any other field) they can do so by adding an appropriate field map entry entry under [GW1000] in weewx.conf.

I think this gives us a practical and realistic default supported by precedent whilst giving users the ability to tailor the behaviour to suit their tastes.

Gary

[galfert]

Perfect. I agree. 

Thank you

[Paul Anderson]

Sounds like a good plan I like it! Restarted my test system here today with previous version of driver but only mapping pressure. Just checked and barometer, pressure and altimeter between that system and one of the VP2 stations I run still tracking within .1 millibar on all three parameters. Obviously one day is not a very good test but looks good so far.

[gjr80]

I have released v0.1.0b9 on Github. The main change is the (I hope) final resolution of the pressures issue. In short, the GW1000 Absolute Pressure is now mapped to WeeWX field pressure with WeeWX to calculate barometer and altimeter via StdWXCalculate. GW1000 Relative Pressure will be passed through to WeeWX as field relbarometer for those that may wish to access it. The default behaviour can be changed by suitable field map entries in weewx.conf.

b9 includes requires no changes to weewx.conf; however, upgrading to b9 by downloading the b9 extension package and installing with the wee_extension utility is the preferred means of installing/upgrading to b9.

Gary

[Bill Arthur]

The first time I set this up (on a fresh install) I had low barometer and two digit wind direction. Wednesday I did a fresh install (on a Pi Zero) and the barometer and wind direction were OK but the outside temp was about 30 degrees low.
I'm going to try another fresh install tonight.

[Bill Arthur]

One other thing I noticed....
Even though I had set the ip_address in weewx.conf it chose to use a different one.
This will be hard to troubleshoot unless you have several GW-1000s to work with.

[gjr80]

Bill,

I doubt a fresh install will change things, either gw1000.py is there and being run or it isn’t. Could you do a few things for me please to try and troubleshoot. Could you run the driver directly with —live-data —debug=3 and post the console and log output. How does temperature on screen relate to what is shown in the WS View app? Could you also post a —sensors —debug=3 output and log as well.

Gary

[gjr80]

Bill,

Does this occur every time or occasionally? Could you post your [GW1000] stanza, the output from my previous post should contain everything else I need to troubleshoot this issue.

Gary

[Bill Arthur]

Hi Gary,
I wasn't able to make time to get the logs tonight. I'll try again tomorrow.
But I did test running the driver directly. I have three GW-1000s, 192.168.0.104, 204 and 205.
Out of ten runs it chooses 204 four times, 205 four times and 104 two times.

# Options for extension 'GW1000'                                                                                       
[Accumulator]                                                                                                               

[[lightning_strike_count]]                                                                                                  

extractor = sum                                                                                                          

[[lightning_last_det_time]]                                                                                                 

extractor = last                                                                                                                                                                                                                        

##############################################################################                                                                                                                                                                  

# Options for extension 'GW1000'                                                                                       

 [GW1000]                                                                                                                   

 driver = user.gw1000                                                                                                    

ip_address = 192.168.0.104                                                                                                                                                                                                                  

####################################

[Bill Arthur]

Hi Gary,
I believe I found my problem. Sorry to have caused any confusion.

After I ran wee_install I saw the GW1000 stanzas at the end of weewx.conf and I falsely assumed it was configured.
I had a ton of problems because I didn't run wee_config.

[gjr80]

Hi Bill,

Yes that will cause problems. I have two GW1000 on my network and the when run as a driver/service the ip_address setting has always been honoured in my testing. Running the driver directly is a little different, I thought i had coded the driver such that it would take the IP address from weewx.conf or the command line, seems I never included weewx.conf and it was being ignored. b9 and earlier exhibited the following behaviour:

• when run as a driver/service as part of a running WeeWX install:

1. if an IP address is specified at [GW1000] ip_address that IP address is used
2. if [GW1000] ip_address is 'auto' or the setting is omitted the driver searches for GW1000 on the local network and uses the address of the first GW1000 that responds

• when run directly:

1. if --ip is specified  on the command line that IP address is used
2. if --ip is not specified on the command line the driver searches for GW1000 on the local network and uses the address of the first GW1000 that responds

Under b10 the behaviour will change when run directly:

1. if --ip is specified  on the command line that IP address will be used
2. if --ip is not specified on the command line weewx.conf is checked and [GW1000] ip_address will be used if set
3. if --ip is not specified on the command line and there is nothing under [GW1000] in weewx.conf the driver searches for GW1000 on the local network and uses the address of the first GW1000 that responds

The behaviour when run as part of a running WeeWX install will not change.

Gary

[galfert]

If you only have one GW1000 is there an advantage to still specifying the IP address in weewx.conf? 

I'm wondering if specifying the IP address allows for more timely data access, as the driver doesn't need to find the GW1000. Also once the GW1000 is found by 'auto' setting, how long does it keep that found address set for? 

What happens if the DHCP sever decides to renew the GW1000 IP address with a different IP address, like for example the GW1000 gets restarted and it ends up with a new IP address but WeeWX never stopped running? Is there a potential to lose the GW1000 connection if 'auto' is used if the IP address changes unexpectedly? Or does the driver only search for a new IP address if there is no response from the previous found IP address?

In short what is the programmed logic behind finding, using, and finding again if needed a GW1000 if set to 'auto'?

Perhaps there is a better way than this below logic...but in my likely short sighted view I would expect for the 'auto' setting the following behavior (I think).

- Search for IP and continue to search indefinitely until GW1000 found

- Store IP address of found GW1000

- Repeatedly Continue querying GW1000 for data using found IP address unless no response to weather data request occurs

- If no response from found IP address then go back to search again for IP address

If that in fact in the logic then using 'auto' or configuring a static IP in weewx.conf probably doesn't matter and it doesn't really add overhead to the system looking for a GW1000...unless one is never found. But if setting it to 'auto' somehow makes it so that it often (every 5 minutes or some other interval) or perhaps before every new weather data request is received it needs to be checked for what IP address to query then that to me seems like overhead that probably could better be avoided by just using a static IP in the weewx.conf.

[gjr80]

Answers/comments below.

Gary

On Monday, 3 August 2020 13:05:31 UTC+10, galfert wrote:

If you only have one GW1000 is there an advantage to still specifying the IP address in weewx.conf? 

Only in as much as it will save half a second during initialisation.

 

I'm wondering if specifying the IP address allows for more timely data access, as the driver doesn't need to find the GW1000. Also once the GW1000 is found by 'auto' setting, how long does it keep that found address set for? 

Not really, refer to my previous comment. The GW1000 is discovered once during initialisation and the (chosen) IP address retained.

What happens if the DHCP sever decides to renew the GW1000 IP address with a different IP address, like for example the GW1000 gets restarted and it ends up with a new IP address but WeeWX never stopped running? Is there a potential to lose the GW1000 connection if 'auto' is used if the IP address changes unexpectedly? Or does the driver only search for a new IP address if there is no response from the previous found IP address?

If the GW1000 is allocated a different address by DHCP for some reason then at present the connection to the GW1000 will be lost until WeeWX is restarted/reloaded. 

In short what is the programmed logic behind finding, using, and finding again if needed a GW1000 if set to 'auto'?

At the moment it is very basic, unless an IP address is specified by the user a one off discovery occurs and an IP address chosen, retained and used until WeeWX restart/reload. 

Perhaps there is a better way than this below logic...but in my likely short sighted view I would expect for the 'auto' setting the following behavior (I think).

- Search for IP and continue to search indefinitely until GW1000 found

- Store IP address of found GW1000

- Repeatedly Continue querying GW1000 for data using found IP address unless no response to weather data request occurs

- If no response from found IP address then go back to search again for IP address

Yes, there certainly is a better way of doing things. It was always my intent that something would be done if contact with the GW1000 was lost, exactly what that is I don't know and it was something I planned to tackle later. I am hesitant to have the driver continually search for a device, I would much rather have the driver conduct a search limited in time or attempts and then hand things back to WeeWX for WeeWX to make the decision whether to continue or exit (WeeWX has some logic/controls built in to it to handle stations that don't respond/lose connectivity). But that is yet to be determined implementation detail.

If that in fact in the logic then using 'auto' or configuring a static IP in weewx.conf probably doesn't matter and it doesn't really add overhead to the system looking for a GW1000...unless one is never found. But if setting it to 'auto' somehow makes it so that it often (every 5 minutes or some other interval) or perhaps before every new weather data request is received it needs to be checked for what IP address to query then that to me seems like overhead that probably could better be avoided by just using a static IP in the weewx.conf.

If anything auto will cause a new discovery upon a timeout occurring when the driver tries to obtain data from the GW1000, there will be no regular/scheduled connectivity check, other than checking that a response is received to any command from driver to GW1000. But that is something the driver does already anyway.

[galfert]

Ok, thank you for the explanation. Good to hear that WeeWX has some controls for non-responding stations and that you were already thinking about utilizing them. 

[gjr80]

I have released v0.1.0b10 on Github. The changes include:

- renamed --ip command line option to --ip-address
- reworked field map processing, field_map_extensions entries should no longer result in multiple mapping for GW1000 'fields'
- --system-params command line option should now show the correct GW1000 time
- reworked up front installation/setup comments in gw1000.py
- GW1000 driver and service now use the same [GW1000] config stanza in weewx.conf
- when run directly the source of the IP address and port settings is printed to console if debug >= 1
- when run directly any --ip-address and --port command line options override any IP address and port settings in weewx.conf,  if --ip-address and/or --port are not specified ip_address and/or port from the [G1000] stanza in weewx.conf are used otherwise the address of the first discovered GW1000 is used

b10 only changes weewx.conf if you were using the GW1000 driver as a service; however, upgrading to b10 by downloading the b10 extension package and installing with the wee_extension utility is the preferred means of installing/upgrading to b10. If you are using the GW1000 driver as a service upgrading with wee_extension will see a [GW1000] stanza with default install settings added to weewx.conf, after upgrading just copy your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in toto.

Gary

[Graham Eddy]

that fixed mappings using gw1000 as service - thanks

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%40googlegroups.com.

[Paul R Anderson]

Gary

V 10 as a service is almost 100% there. 

However if you add a 

    [[field_map]] stanza to weewx.config, it gets honored correctly, however with the current logic we don't get a battery_field_map added at all.

One way to fix, altho you probably have a more eloquent solution is: 

       """Initialise a GW1000 object."""

        # construct the field map, first obtain the field map from our config
        field_map = gw1000_config.get('field_map')
        # construct the battery state field map
        battery_field_map = gw1000_config.get('battery_field_map')
        # now add in the battery state field map
        field_map.update(battery_field_map)
        # obtain any field map extensions from our config

No changes after that.

Wow this thing is getting more complicated by the day 😁

 

--

[Paul R Anderson]

Forgot to say that user would need to add [[battery_field_map]] to weewx.conf as well

[gjr80]

Paul,

The current field_map behaviour is deliberate, it probably doesn’t help that I have not documented the behaviour yet. The expected behaviour is:

1. If the user specifies nothing the default field map is used. (The default field map can be viewed by running the driver directly with the —default-map command line option. The default field map happens to be constructed from the field map dict and battery map dict)

2. The user can specify a mapping under [field_map], in this case the user specified field map replaces the default field map, in other words the user takes full responsibility for the field map. You can run the driver directly using the —live-data command line option to see what data , including battery state data, is available from the GW1000 for mapping. You can extend the [field_map] with [field_map_extensions] but why would you.

3. If the user is happy with the default field map but wants to map a few fields differently they can use [field_map_extensions] to modify the field map rathe4 than having to specify every mapping with [field_map]. [field_map_extensions] are used to modify the field map (typically the default field map), basically any GW1000 ‘fields’ in the [field_map_extensions] are removed from the field map then the [field_map_extensions] entries are added to the field map.

The behaviour above is fairly much standard among drivers that use field/sensor maps with [field_map] and [field_map_extensions].

I will document this in the driver wiki shortly.

Gary